From nobody Sun Apr 1 23:15:00 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB78E1270AB for ; Sun, 1 Apr 2018 23:14:58 -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=POVak6YR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WOmCjMMx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBmQvy7d3RJR for ; Sun, 1 Apr 2018 23:14:56 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2288F124205 for ; Sun, 1 Apr 2018 23:14:56 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 470CF20E52; Mon, 2 Apr 2018 02:14:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 02 Apr 2018 02:14:55 -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; s=fm2; bh=Qrn/RS2aYLMkdJKzsXIep8MGA/CYt g8rmGo0hycM5gA=; b=POVak6YRKWWIlWu8V6AJ6DjeQJ+79OXV22rHxr0UfUZr2 IV+hTIRNsxKu3crCTIJ9uUo9+VQhnkAfcFh1reJMR6QSIx3mgcsQ/VM+q7IIvi5P wAY95DdxPTzksQ83A4tGLtGarY081a9NDu7c+RczszJ70GtwFkAY/WWXhVjzKDDd v7lrH4UFGBKIubpyjV452/4jWeff319abSkpVvl7yB07Swq2Mr3TMcgDo054TK5b TrYP7Mi3JQn7L08vAxyzZgvNQ4ejntll+zZwuwxXWRGXphSJTzs/Sdb8dVSR+EIb MbltT/VdQC0a0/ok2r8ZVRidZYtELQU+/Ay7hvK2A== 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; s=fm2; bh=Qrn/RS 2aYLMkdJKzsXIep8MGA/CYtg8rmGo0hycM5gA=; b=WOmCjMMxfoWCujtZEZf+E+ oakbfFC5rVEbDZWq093V9IIAz7+B14+mH/l81443eipGntc7UlkJpVNeyalr1DI9 vbGGdVvOfyhbo9TjZZp9frXUBD//I6UMO4yiAh9d708TSttKQD5/kuO7wr6yWKbo QOTEwGjbcnVRwhwPSnRhwQuw1s+6lIzzBci1+DXMaU8v3eOaJOQqLr/FsOOvSktd /YlbcQxRIZGnBzZVbesl/E0vQPaDouHnBITIrAdnwbp9iYz/PltzwXoMoxnEnlwl rhFMtynjhq5nv+vH302iEo8AtChF8hZaqMoPxP+VzUN00TlXOLFhdxOxNmJJ9OPg == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 458DD10259; Mon, 2 Apr 2018 02:14:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Hardware acceleration and packet number encryption From: Mark Nottingham In-Reply-To: Date: Mon, 2 Apr 2018 16:14:51 +1000 Cc: IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <27F88FC9-D6EA-485B-8D0C-0A735CAC342C@mnot.net> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> To: Praveen Balasubramanian X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 02 Apr 2018 06:14:59 -0000 Hi Praveen, On 1 Apr 2018, at 4:17 am, Praveen Balasubramanian = wrote: >=20 > PN size and location needs to be part of invariants. How the field is = transformed and encoded in the clear is an end-to-end function and can = change between versions.=20 Invariants is in WGLC now, but does not include packet numbers. If you = believe it needs to be in there, please raise an issue and we can = discuss it (in a separate thread). Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Sun Apr 1 23:15:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC81124205 for ; Sun, 1 Apr 2018 23:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522649699; bh=bP+xPbReNFKEt7hTcpP+DVKq+gr2WVimYfRj3z/Ohbc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=cqLACKcOYy2ZgTNjlkhICJGwTnuYkxBLwed+kEwlM+is1k52i3VZbbaT4OwtBwkkx miUM5a3GtnXG+ULBQqC7NT4zgxYE/gsVoFukVAb1UkwJPQAM4uwkHoCs1+CBPAbH6A qojBtfB3B59gUQH2TpOkWUvz6YYPRVo3/1vm6UuY= X-Mailbox-Line: From mnot@mnot.net Sun Apr 1 23:14:59 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE6E126C25 for ; Sun, 1 Apr 2018 23:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522649699; bh=bP+xPbReNFKEt7hTcpP+DVKq+gr2WVimYfRj3z/Ohbc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=cqLACKcOYy2ZgTNjlkhICJGwTnuYkxBLwed+kEwlM+is1k52i3VZbbaT4OwtBwkkx miUM5a3GtnXG+ULBQqC7NT4zgxYE/gsVoFukVAb1UkwJPQAM4uwkHoCs1+CBPAbH6A qojBtfB3B59gUQH2TpOkWUvz6YYPRVo3/1vm6UuY= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E113124205 for ; Sun, 1 Apr 2018 23:14:59 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=POVak6YR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WOmCjMMx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzX7Lp5xr6FI for ; Sun, 1 Apr 2018 23:14:56 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2652A126C25 for ; Sun, 1 Apr 2018 23:14:56 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 470CF20E52; Mon, 2 Apr 2018 02:14:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 02 Apr 2018 02:14:55 -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; s=fm2; bh=Qrn/RS2aYLMkdJKzsXIep8MGA/CYt g8rmGo0hycM5gA=; b=POVak6YRKWWIlWu8V6AJ6DjeQJ+79OXV22rHxr0UfUZr2 IV+hTIRNsxKu3crCTIJ9uUo9+VQhnkAfcFh1reJMR6QSIx3mgcsQ/VM+q7IIvi5P wAY95DdxPTzksQ83A4tGLtGarY081a9NDu7c+RczszJ70GtwFkAY/WWXhVjzKDDd v7lrH4UFGBKIubpyjV452/4jWeff319abSkpVvl7yB07Swq2Mr3TMcgDo054TK5b TrYP7Mi3JQn7L08vAxyzZgvNQ4ejntll+zZwuwxXWRGXphSJTzs/Sdb8dVSR+EIb MbltT/VdQC0a0/ok2r8ZVRidZYtELQU+/Ay7hvK2A== 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; s=fm2; bh=Qrn/RS 2aYLMkdJKzsXIep8MGA/CYtg8rmGo0hycM5gA=; b=WOmCjMMxfoWCujtZEZf+E+ oakbfFC5rVEbDZWq093V9IIAz7+B14+mH/l81443eipGntc7UlkJpVNeyalr1DI9 vbGGdVvOfyhbo9TjZZp9frXUBD//I6UMO4yiAh9d708TSttKQD5/kuO7wr6yWKbo QOTEwGjbcnVRwhwPSnRhwQuw1s+6lIzzBci1+DXMaU8v3eOaJOQqLr/FsOOvSktd /YlbcQxRIZGnBzZVbesl/E0vQPaDouHnBITIrAdnwbp9iYz/PltzwXoMoxnEnlwl rhFMtynjhq5nv+vH302iEo8AtChF8hZaqMoPxP+VzUN00TlXOLFhdxOxNmJJ9OPg == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 458DD10259; Mon, 2 Apr 2018 02:14:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Hardware acceleration and packet number encryption From: Mark Nottingham In-Reply-To: Date: Mon, 2 Apr 2018 16:14:51 +1000 Cc: IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <27F88FC9-D6EA-485B-8D0C-0A735CAC342C@mnot.net> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> X-Mailer: Apple Mail (2.3445.6.18) To: Praveen Balasubramanian Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 02 Apr 2018 06:15:00 -0000 Hi Praveen, On 1 Apr 2018, at 4:17 am, Praveen Balasubramanian = wrote: >=20 > PN size and location needs to be part of invariants. How the field is = transformed and encoded in the clear is an end-to-end function and can = change between versions.=20 Invariants is in WGLC now, but does not include packet numbers. If you = believe it needs to be in there, please raise an issue and we can = discuss it (in a separate thread). Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Apr 2 04:43:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CDC126BF7 for ; Mon, 2 Apr 2018 04:43:37 -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 m8BfmbkQmBbn for ; Mon, 2 Apr 2018 04:43:35 -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 AB0BD124D37 for ; Mon, 2 Apr 2018 04:43:35 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id v13so17617456iob.6 for ; Mon, 02 Apr 2018 04:43:35 -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=VSlU97dst+gJDVGf4GJnJnIb0BW2Zfp0vdQ7zB4CzW0=; b=JjBautpKN4MThiBANOS6N9eyI2FDxZFEZsBSHR8SbcuNohIwzeeDLQg5X9jWbDKbna d6XIcCD2PYugdb9ahpZ7cXlmSmg2Ag/3hcaaeB9nN6hzfQZtNPxoicQ5xoaZNT3iQImm 6YnD4pm8NYyaM4ADtgCB31y2w9zTdF+z+pWhvatgzgppkYDPSUeV41XpcJFVDqywX1zH lwVask5sX1QgASKzDPzvOC2Ye07Gf10givRjdNWNgTCUN1GYcSJKc8nAsV11fQFIQvOt v71C+g14pIMbyz+PdK1W43+OA2+ZeADKRsDigkLpM2yEwNnNwfdPtCvJQh0+bTjevek6 EaMw== 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=VSlU97dst+gJDVGf4GJnJnIb0BW2Zfp0vdQ7zB4CzW0=; b=pmqG0Q2zk7mL3I+Hvu8XLcAdKSlc2GB183KSHdWQruagFfE8h81djYn6zDAyCrAruN EaHLHsLiqUWz9GLAFPHXOZ1SPj/dbGJhvnTdmhOsEBezirLvQNOHCuoBxLcl0Eu8sGyL F/rHH4IZ17bfZDzEGLB7xVkwU9hcUqiH+P784R77bewGwk2CH+3R3W4+BPTUJw1AKYPw v0i+em8TRUA01qVKDGseFpDXRophWK6l4FZUzCW5orR0ha6qrXESlJlP2WZa6+Vo5FO2 tIjpDCrcc6i5Wp321xLhLFY+2EfGI35OZ/E2IxevYWyaoMfsqMTWJaqgkaeE/YtmzJ+R NmLw== X-Gm-Message-State: AElRT7F2WzZk9ZOWkkoyxGqlbJtjV7lxZ5CXYPAUEXq8yD4Ji1eEzNt4 S+YLDD7b1OMOGTQc57FbhfYE4UX1cjPDWE5gME00FA== X-Google-Smtp-Source: AIpwx4/K2OzArZ6OLmUuo19CD/AO5t4sue50QrpClPphtNwLnHiyxu1oTvKHtqJbxxRblQlG68w1fcsjw+i3fWojSwU= X-Received: by 10.107.6.32 with SMTP id 32mr8366830iog.24.1522669414636; Mon, 02 Apr 2018 04:43:34 -0700 (PDT) MIME-Version: 1.0 From: Marten Seemann Date: Mon, 02 Apr 2018 11:43:23 +0000 Message-ID: Subject: Implicitly opened streams and exposing stream IDs To: QUIC WG Content-Type: multipart/alternative; boundary="001a113fbf5c91e1b10568dc19a1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 02 Apr 2018 11:43:37 -0000 --001a113fbf5c91e1b10568dc19a1 Content-Type: text/plain; charset="UTF-8" Recently, the implicit opening of streams (i.e. that when a receiver receives a frame for stream N+4, it can assume that stream N was already opened, but the packet might have been reordered) was removed from the draft. I think this change has some consequences that we haven't discussed so far. For the purpose of writing some pseudocode, I'm assuming a QUIC API that provides an *AcceptStream()* method, but the conclusions will be the same for a callback-based API. - If QUIC has implicit stream opening, *AcceptStream()* would return the streams in order (and if a frame opening stream N+4 is received before stream n is opened, *AcceptStream()* will first return stream N and then stream N+4). - Without implicit stream opening, *AcceptStream()* just returns whatever stream is received first. Streams might be returned in arbitrary order, if the peer doesn't open streams consecutively or if packets are reordered. Now imagine an application protocol where the first unidirectional stream opened by the client is a control stream, and all higher unidirectional streams are data streams. The application on the server side needs to find out which stream is the control stream, because it needs to be handled separately. With implicit stream opening, the server code would be: control_stream = AcceptStream() // is guaranteed to open the first stream // handle the control stream while true: stream = AcceptStream() // handle the data stream and without implicit stream opening: while true: stream = AcceptStream() if stream.ID() == kControlStreamID: // handle the control stream else: // handle the data stream In this case, after accepting a stream, we first have to check the stream ID, since there's no guarantee if the control stream will actually be received first. For this stream mapping, it seems like the removal of implicitly opened streams implies that QUIC has to expose stream IDs to the application layer. I'm not sure if this was intended when making the change, especially since we're considering to change HQ such that it doesn't rely on QUIC stream IDs any more. We only manage to avoid the problem described here in our HTTP mapping, because the HTTP control streams are unidirectional and the request streams are bidirectional, and can therefore be told apart by their directionality. However, as a general transport protocol, other applications built on top of QUIC will have to find some way to deal with it. --001a113fbf5c91e1b10568dc19a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Recently, the implicit opening of streams (= i.e. that when a receiver receives a frame for stream N+4, it can assume th= at stream N was already opened, but the packet might have been reordered) w= as removed from the draft. I think this change has some consequences that w= e haven't discussed so far.

For the purpose of= writing some pseudocode, I'm assuming a QUIC API that provides an A= cceptStream() method, but the conclusions will be the same for a callba= ck-based API.
  • If QUIC has implicit stream opening, Acc= eptStream() would return the streams in order (and if a frame opening s= tream N+4 is received before stream n is opened, AcceptStream() will= first return stream N and then stream N+4).=C2=A0
  • Without implicit= stream opening, AcceptStream() just returns whatever stream is rece= ived first. Streams might be returned in arbitrary order, if the peer doesn= 't open streams consecutively or if packets are reordered.

Now imagine an application protocol where the first = unidirectional stream opened by the client is a control stream, and all hig= her unidirectional streams are data streams. The application on the server = side needs to find out which stream is the control stream, because it needs= to be handled separately.

With implicit stream op= ening, the server code would be:

=C2=A0 =C2=A0 control_= stream =3D AcceptStream() // is guaranteed to open the first stream
=C2= =A0 =C2=A0 // handle the control stream
=C2=A0 =C2=A0 =C2=A0while true:<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0stream =3D AcceptStream()
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0// handle the data stream

and= without implicit stream opening:

=C2=A0 =C2=A0 wh= ile true:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 stream =3D AcceptStream()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if stream.ID() =3D=3D kControlStreamID= :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // handle the control= stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else:
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 // handle the data stream

=
In this case, after accepting a stream, we first have to check the str= eam ID, since there's no guarantee if the control stream will actually = be received first.

For this stream mapping, it see= ms like the removal of implicitly opened streams implies that QUIC has to e= xpose stream IDs to the application layer. I'm not sure if this was int= ended when making the change, especially since we're considering to cha= nge HQ such that it doesn't rely on QUIC stream IDs any more.
We only manage to avoid the problem described here in our HTTP mapping, be= cause the HTTP control streams are unidirectional and the request streams a= re bidirectional, and can therefore be told apart by their directionality. = However, as a general transport protocol, other applications built on top o= f QUIC will have to find some way to deal with it.
--001a113fbf5c91e1b10568dc19a1-- From nobody Mon Apr 2 05:05:58 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0BA1276AF for ; Mon, 2 Apr 2018 05:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM25skLOeOXU for ; Mon, 2 Apr 2018 05:05:54 -0700 (PDT) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489141275AB for ; Mon, 2 Apr 2018 05:05:54 -0700 (PDT) Received: from BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w32C5qgk008899; Mon, 2 Apr 2018 13:05:52 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) with mapi id 14.03.0361.001; Mon, 2 Apr 2018 13:05:52 +0100 From: Lucas Pardue To: Marten Seemann , QUIC WG Subject: RE: Implicitly opened streams and exposing stream IDs Thread-Topic: Implicitly opened streams and exposing stream IDs Thread-Index: AQHTynffVfsbpETavE+fePgnAUwmm6PtYJd5 Date: Mon, 2 Apr 2018 12:05:51 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.211] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23758.006 x-tm-as-result: No--16.104300-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 12:05:56 -0000 Hi Marten, Would Stream headers fix this problem? I.e. anything that requires special = behaviour other than "bulk data" has some bytes of of magic at the start of= the stream. Regards Lucas ________________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Marten Seemann [martenseema= nn@gmail.com] Sent: 02 April 2018 12:43 To: QUIC WG Subject: Implicitly opened streams and exposing stream IDs Recently, the implicit opening of streams (i.e. that when a receiver receiv= es a frame for stream N+4, it can assume that stream N was already opened, = but the packet might have been reordered) was removed from the draft. I thi= nk this change has some consequences that we haven't discussed so far. For the purpose of writing some pseudocode, I'm assuming a QUIC API that pr= ovides an AcceptStream() method, but the conclusions will be the same for a= callback-based API. * If QUIC has implicit stream opening, AcceptStream() would return the = streams in order (and if a frame opening stream N+4 is received before stre= am n is opened, AcceptStream() will first return stream N and then stream N= +4). * Without implicit stream opening, AcceptStream() just returns whatever= stream is received first. Streams might be returned in arbitrary order, if= the peer doesn't open streams consecutively or if packets are reordered. Now imagine an application protocol where the first unidirectional stream o= pened by the client is a control stream, and all higher unidirectional stre= ams are data streams. The application on the server side needs to find out = which stream is the control stream, because it needs to be handled separate= ly. With implicit stream opening, the server code would be: control_stream =3D AcceptStream() // is guaranteed to open the first st= ream // handle the control stream while true: stream =3D AcceptStream() // handle the data stream and without implicit stream opening: while true: stream =3D AcceptStream() if stream.ID() =3D=3D kControlStreamID: // handle the control stream else: // handle the data stream In this case, after accepting a stream, we first have to check the stream I= D, since there's no guarantee if the control stream will actually be receiv= ed first. For this stream mapping, it seems like the removal of implicitly opened str= eams implies that QUIC has to expose stream IDs to the application layer. I= 'm not sure if this was intended when making the change, especially since w= e're considering to change HQ such that it doesn't rely on QUIC stream IDs = any more. We only manage to avoid the problem described here in our HTTP mapping, bec= ause the HTTP control streams are unidirectional and the request streams ar= e bidirectional, and can therefore be told apart by their directionality. H= owever, as a general transport protocol, other applications built on top of= QUIC will have to find some way to deal with it. ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specif= ically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- From nobody Mon Apr 2 09:17:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F8B12D77C for ; Mon, 2 Apr 2018 09:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522685860; bh=udWQnZ1ngHLn7EvfCygQ+ZYvaFCG5aiVdW04XAUPzu4=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=I2fLngViLFyvK3VFc5XtpCpeHjGyiDGfuMblQwTtJfhSe6yaufIwI33sWLnlI+H1H u5ctCwt1qJXy2We0TiOfTsBVogn3CHcP1B/pZyDBAp19YvkMVWntNidh62oOWjoYeI G9Kep4S3kSPS23zGXbZM2+RyOmOectphkDC8DSL0= X-Mailbox-Line: From pravb@microsoft.com Mon Apr 2 09:17:40 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C82412D77B for ; Mon, 2 Apr 2018 09:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522685860; bh=udWQnZ1ngHLn7EvfCygQ+ZYvaFCG5aiVdW04XAUPzu4=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=I2fLngViLFyvK3VFc5XtpCpeHjGyiDGfuMblQwTtJfhSe6yaufIwI33sWLnlI+H1H u5ctCwt1qJXy2We0TiOfTsBVogn3CHcP1B/pZyDBAp19YvkMVWntNidh62oOWjoYeI G9Kep4S3kSPS23zGXbZM2+RyOmOectphkDC8DSL0= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DEF12D77C for ; Mon, 2 Apr 2018 09:17:39 -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 (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 69u3aCVT2w2U for ; Mon, 2 Apr 2018 09:17:37 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on071c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe41::71c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66DC712D77B for ; Mon, 2 Apr 2018 09:17:37 -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=uisAc3vwqZeRsE0Q7qHG97EI2PMs89KPmuFt0D0PpFg=; b=M+2JUMIWbzaLhnbjGuiSD3wj2DxWpADHoDCN9U40GbuRgsx8klZaHqqR2f87JXrOlqS/z02WXgxcGArSOZjnr5SB788VU2wf5qImrGMgVDw2mWNoDkQpAbCKVSIlwt5ZvnfQsK5TWMnuXWhIWvB4BFDj24eRtwPxLbfgLBuZp98= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0631.namprd21.prod.outlook.com (10.175.115.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.1; Mon, 2 Apr 2018 16:17:35 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.000; Mon, 2 Apr 2018 16:17:35 +0000 From: Praveen Balasubramanian CC: IETF QUIC WG Subject: RE: Hardware acceleration and packet number encryption Thread-Topic: Hardware acceleration and packet number encryption Thread-Index: AQHTw2pWXYDTIV9KLUGmQTRvaS20baPfab+AgAAo/YCAAFZ6AIAADAQAgAAvsICAAAzVgIAB2cSAgABzBgCAAAxXAIAADMAAgAANjwCAABZegIADoGkAgAAJ9QCAABTugIAADYsQgAQGnWCAAB1gAIAAAbwAgAJe34CAAKUXAA== Date: Mon, 2 Apr 2018 16:17:34 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <27F88FC9-D6EA-485B-8D0C-0A735CAC342C@mnot.net> In-Reply-To: <27F88FC9-D6EA-485B-8D0C-0A735CAC342C@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:7::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0631; 7:+6OG0fgw9FtXQPsHZcWymQhnk6VyqlMVtBPzUGXqxbEanDoerQbKmrsWUUOKoYX7+IUVeSSUcJvqduGfeLZ6YipindEzTHt53TLGx7l7TY2MthzHRvH+nqTbRBhAdyVmWz2JgOxJjGObfLTb+QC63BUMmCUw31Y5tiKwjYDMIrtQ8c3iiClwGQMDR2s0N0Y/LQyelvqIWwtymjTtfCkjucuf+upqRXywJ1Uo8ERjIvVSIPIEz2BMguCMDwR78w9C; 20:1mjKr0Z6Y/+POOXehA5pLM9s2iw+FK8336bpoGZ4O/J/yMskToLDkXREaWwP+6xSQQObaF9mKNYT/JF6M33zK0eWYORxQxC1eArgI+KmUnwxZkSBq3heQC2BYdSMunX3ysXMBcyM4RgRoS0bh6d97b025TbTVMDl8y/xpzuzM8Y= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 80e89cd7-b7bd-420d-40b7-08d598b53eae x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0631; x-ms-traffictypediagnostic: CY4PR21MB0631: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0631; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0631; x-forefront-prvs: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39380400002)(39860400002)(366004)(376002)(13464003)(199004)(189003)(76176011)(478600001)(68736007)(316002)(2900100001)(93886005)(105586002)(7696005)(33656002)(97736004)(229853002)(11346002)(8936002)(74316002)(7736002)(8990500004)(3660700001)(305945005)(99286004)(5250100002)(22452003)(4326008)(2906002)(6246003)(10090500001)(81156014)(81166006)(486005)(476003)(3280700002)(486005)(186003)(110136005)(53546011)(102836004)(6506007)(25786009)(966005)(46003)(5660300001)(14454004)(446003)(86362001)(6436002)(53936002)(9686003)(86612001)(6306002)(10290500003)(8676002)(55016002)(6116002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0631; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: W3YrLomXNvf6yA16b5RLBENmnZPTDP8TncQUvMY59y+AVl4WjRzlB1fueZYlNTuWW8Ij6y8/H7pAZjJwn4p6YPIyEZsMTpl9yrdvfvBM1JmDCdnu/SiBEQPSgEDSsgNeilvYHDjKzi38IsnkyBuJZNJFmIUsVf259kGvJXdvlDkPoVLABaGJ+B1wQyWiUrZOr16BSY9TG11EixmvVpWzzXxh8A3ur1hYpE1VSdFE/488KO5Jg4ksTO+5z2S0zq3bP/IJu+a8VhbYmMh7MBMlWUynLdTlNORNogA/s9AdJ1gLEJWunw+c5YQbNiz7L/Vtg0v/kyncXzbojVYNddOV4Fg/VZXLaweRtrpuIy3+G5oBWQbmz9xSETba8RjP4DGGEY2QYlYn3PBgbDyqKiTXE9kR6qlG5ezi0/JFnLvIBJ0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80e89cd7-b7bd-420d-40b7-08d598b53eae X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2018 16:17:34.9041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0631 To: Mark Nottingham To: Praveen Balasubramanian Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 02 Apr 2018 16:17:40 -0000 Since PN is the very last field before encrypted payload, it should be ok t= o exclude the field from invariants. Several benefits ensue - well behaved = middleboxes don't even look at an end-to-end field, leaves room for future = crypto that doesn't need a cleartext nonce, datacenter QUIC could subsume P= N into the encrypted portion, and cleartext QUIC in a controlled environmen= t can just skip the encryption step. However if we add any new fields to in= variants some future version onwards, would they need to be placed before P= N? Since implementations will do version specific parsing this shouldn't be= a big problem.=20 -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham Sent: Sunday, April 1, 2018 11:15 PM To: Praveen Balasubramanian Cc: IETF QUIC WG Subject: Re: Hardware acceleration and packet number encryption Hi Praveen, On 1 Apr 2018, at 4:17 am, Praveen Balasubramanian wrote: >=20 > PN size and location needs to be part of invariants. How the field is tra= nsformed and encoded in the clear is an end-to-end function and can change = between versions.=20 Invariants is in WGLC now, but does not include packet numbers. If you beli= eve it needs to be in there, please raise an issue and we can discuss it (i= n a separate thread). Cheers, -- Mark Nottingham https://na01.safelinks.protection.outlook.com/?url=3Dhttp= s%3A%2F%2Fwww.mnot.net%2F&data=3D02%7C01%7Cpravb%40microsoft.com%7Ce135b2a8= beff46bdf44208d598611381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63658= 2465072048656&sdata=3DOigvpPbNPqhLMJDYJ4xyphpFuyanfQzrY9eOwLwX2xU%3D&reserv= ed=3D0 From nobody Mon Apr 2 09:17:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E430012D77B for ; Mon, 2 Apr 2018 09:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 GqozNRgNJfEm for ; Mon, 2 Apr 2018 09:17:37 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0121.outbound.protection.outlook.com [104.47.36.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF30126BF6 for ; Mon, 2 Apr 2018 09:17:37 -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=uisAc3vwqZeRsE0Q7qHG97EI2PMs89KPmuFt0D0PpFg=; b=M+2JUMIWbzaLhnbjGuiSD3wj2DxWpADHoDCN9U40GbuRgsx8klZaHqqR2f87JXrOlqS/z02WXgxcGArSOZjnr5SB788VU2wf5qImrGMgVDw2mWNoDkQpAbCKVSIlwt5ZvnfQsK5TWMnuXWhIWvB4BFDj24eRtwPxLbfgLBuZp98= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0631.namprd21.prod.outlook.com (10.175.115.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.1; Mon, 2 Apr 2018 16:17:35 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.000; Mon, 2 Apr 2018 16:17:35 +0000 From: Praveen Balasubramanian To: Mark Nottingham , Praveen Balasubramanian CC: IETF QUIC WG Subject: RE: Hardware acceleration and packet number encryption Thread-Topic: Hardware acceleration and packet number encryption Thread-Index: AQHTw2pWXYDTIV9KLUGmQTRvaS20baPfab+AgAAo/YCAAFZ6AIAADAQAgAAvsICAAAzVgIAB2cSAgABzBgCAAAxXAIAADMAAgAANjwCAABZegIADoGkAgAAJ9QCAABTugIAADYsQgAQGnWCAAB1gAIAAAbwAgAJe34CAAKUXAA== Date: Mon, 2 Apr 2018 16:17:34 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <27F88FC9-D6EA-485B-8D0C-0A735CAC342C@mnot.net> In-Reply-To: <27F88FC9-D6EA-485B-8D0C-0A735CAC342C@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:7::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0631; 7:+6OG0fgw9FtXQPsHZcWymQhnk6VyqlMVtBPzUGXqxbEanDoerQbKmrsWUUOKoYX7+IUVeSSUcJvqduGfeLZ6YipindEzTHt53TLGx7l7TY2MthzHRvH+nqTbRBhAdyVmWz2JgOxJjGObfLTb+QC63BUMmCUw31Y5tiKwjYDMIrtQ8c3iiClwGQMDR2s0N0Y/LQyelvqIWwtymjTtfCkjucuf+upqRXywJ1Uo8ERjIvVSIPIEz2BMguCMDwR78w9C; 20:1mjKr0Z6Y/+POOXehA5pLM9s2iw+FK8336bpoGZ4O/J/yMskToLDkXREaWwP+6xSQQObaF9mKNYT/JF6M33zK0eWYORxQxC1eArgI+KmUnwxZkSBq3heQC2BYdSMunX3ysXMBcyM4RgRoS0bh6d97b025TbTVMDl8y/xpzuzM8Y= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 80e89cd7-b7bd-420d-40b7-08d598b53eae x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0631; x-ms-traffictypediagnostic: CY4PR21MB0631: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0631; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0631; x-forefront-prvs: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39380400002)(39860400002)(366004)(376002)(13464003)(199004)(189003)(76176011)(478600001)(68736007)(316002)(2900100001)(93886005)(105586002)(7696005)(33656002)(97736004)(229853002)(11346002)(8936002)(74316002)(7736002)(8990500004)(3660700001)(305945005)(99286004)(5250100002)(22452003)(4326008)(2906002)(6246003)(10090500001)(81156014)(81166006)(486005)(476003)(3280700002)(486005)(186003)(110136005)(53546011)(102836004)(6506007)(25786009)(966005)(46003)(5660300001)(14454004)(446003)(86362001)(6436002)(53936002)(9686003)(86612001)(6306002)(10290500003)(8676002)(55016002)(6116002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0631; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: W3YrLomXNvf6yA16b5RLBENmnZPTDP8TncQUvMY59y+AVl4WjRzlB1fueZYlNTuWW8Ij6y8/H7pAZjJwn4p6YPIyEZsMTpl9yrdvfvBM1JmDCdnu/SiBEQPSgEDSsgNeilvYHDjKzi38IsnkyBuJZNJFmIUsVf259kGvJXdvlDkPoVLABaGJ+B1wQyWiUrZOr16BSY9TG11EixmvVpWzzXxh8A3ur1hYpE1VSdFE/488KO5Jg4ksTO+5z2S0zq3bP/IJu+a8VhbYmMh7MBMlWUynLdTlNORNogA/s9AdJ1gLEJWunw+c5YQbNiz7L/Vtg0v/kyncXzbojVYNddOV4Fg/VZXLaweRtrpuIy3+G5oBWQbmz9xSETba8RjP4DGGEY2QYlYn3PBgbDyqKiTXE9kR6qlG5ezi0/JFnLvIBJ0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80e89cd7-b7bd-420d-40b7-08d598b53eae X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2018 16:17:34.9041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0631 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 02 Apr 2018 16:17:41 -0000 Since PN is the very last field before encrypted payload, it should be ok t= o exclude the field from invariants. Several benefits ensue - well behaved = middleboxes don't even look at an end-to-end field, leaves room for future = crypto that doesn't need a cleartext nonce, datacenter QUIC could subsume P= N into the encrypted portion, and cleartext QUIC in a controlled environmen= t can just skip the encryption step. However if we add any new fields to in= variants some future version onwards, would they need to be placed before P= N? Since implementations will do version specific parsing this shouldn't be= a big problem.=20 -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham Sent: Sunday, April 1, 2018 11:15 PM To: Praveen Balasubramanian Cc: IETF QUIC WG Subject: Re: Hardware acceleration and packet number encryption Hi Praveen, On 1 Apr 2018, at 4:17 am, Praveen Balasubramanian wrote: >=20 > PN size and location needs to be part of invariants. How the field is tra= nsformed and encoded in the clear is an end-to-end function and can change = between versions.=20 Invariants is in WGLC now, but does not include packet numbers. If you beli= eve it needs to be in there, please raise an issue and we can discuss it (i= n a separate thread). Cheers, -- Mark Nottingham https://na01.safelinks.protection.outlook.com/?url=3Dhttp= s%3A%2F%2Fwww.mnot.net%2F&data=3D02%7C01%7Cpravb%40microsoft.com%7Ce135b2a8= beff46bdf44208d598611381%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63658= 2465072048656&sdata=3DOigvpPbNPqhLMJDYJ4xyphpFuyanfQzrY9eOwLwX2xU%3D&reserv= ed=3D0 From nobody Mon Apr 2 10:39:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E62B124BE8 for ; Mon, 2 Apr 2018 10:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04nbZOTuTITe for ; Mon, 2 Apr 2018 10:39: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 6C4AC126B72 for ; Mon, 2 Apr 2018 10:39:33 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id o4so18762570iod.3 for ; Mon, 02 Apr 2018 10:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=XtNOFw875udm4SJgvcFCdHohvk3RA0Iq7rWZgkH9LtU=; b=RXz90Pya468bpP99uS3pudsptXX+n+olgXV1f7hz4DaI72hVTu88xPzaP7ccsmPICM +Nxngv8G5Vxrrk+bX1W3R2URj+Th2j2ddg0RbH9xUhCVq9st8BM5IWMy/SXTy7T8VGhW wcIZ0llF89irgNlGmjOlT993qxIx7qzwS/BYA6mKmRJpdzdpDBlrEmh0autMNGfPb/kK 5TGO7HI6wZi/+sPfBhsOsiSmPspGZ05FB5IF7NQe4rlBw/ZqYS9O0zQaVWv5O6ScY58y f1E7ErZExJ2mRWDSibCAbaAzsw5/6kC4BOvCMLwvi1GGxUuy3c+YKVJLAN6D4Xm2VspF VDzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=XtNOFw875udm4SJgvcFCdHohvk3RA0Iq7rWZgkH9LtU=; b=ko3d6Ai9NGpaIubfivqe8LWuBeRHnT+/4e/nNJYwSucCjdjBDkNjJJ08awFugNU42c dZ1O/OjYmCoqBqDpnaWzUX+YwuhKebC+BuyKdSnN8CQjkpSu7BkC20TW2yIVc1CbNxsR uD7/Dln5VM0GWl3TR4mqBbAQwzzIB8gc3czK7azK9NMOT+Xxh4+hWMD2LYeR5J8qD7DV P8SyrsdkNkBwot1pxkuo3W5jRZ1P7Y/zQKsq7QGtP2qQoogg0yqETf+eWKJEdEEaLv9Q inOssWa1AnVVnDXwCqsvK4KfLwrwYrbgSASWrGcCaZ/ykWVlhKPJZ6/3dKriHG2WfzSc bpqw== X-Gm-Message-State: ALQs6tCnsC2onYuIY8ub8yeVesxyjlMjyUK+tsEWOrsAZZ6AJ5itlv1o +XzgAmwy4ixy4OfSbKtC7glU3Nj1HXSksdiQsdw= X-Google-Smtp-Source: AIpwx48xhLic5uUWLrT58oEXGFfeHrt2+mYRgJRIjZ4TQBhztRtF9DRUOg8tglj8iIjpN1/vL6ZCuf5lrysZ/7NZxWg= X-Received: by 10.107.6.163 with SMTP id f35mr9948157ioi.165.1522690772793; Mon, 02 Apr 2018 10:39:32 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 2 Apr 2018 14:39:31 -0300 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 2 Apr 2018 14:39:31 -0300 Message-ID: Subject: RE: Implicitly opened streams and exposing stream IDs To: Lucas Pardue , QUIC WG , Marten Seemann Content-Type: multipart/alternative; boundary="001a113e06a29d7bb20568e112b0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 02 Apr 2018 17:39:36 -0000 --001a113e06a29d7bb20568e112b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Isn=E2=80=99t this between QUIC, the QUIC application API, and the applicat= ion protocol? If you tell QUIC to feed streams in order, just like you it to feed data inside a stream in order, then it can virtually open streams in order stream towards the API without affecting the network. QUIC is also permitted to deliver data out of order inside a stream AFAIR, although this would not be the usual API behaviour. In the end, specific broadly accepted app protocols like QUIC/HTTP will drive the API design. For other use cases such as some small brief message streams and some heavy data loaded streams, you might very well want to have the latest stream arrive first, to process priority messages. Saying that QUIC can never, as opposed to usually, expose the stream ID seems pointless. It is like saying a QUIC api can never expose holes in a single streams data stream. I don=E2=80=99t really see an issue on the wire, and I believe removing imp= licit open takes a way some fear, uncertainty and doubt about stream resource handling - at least I never felt completely comfortable with the stream design until now. Regards, Mikkel On 2 April 2018 at 14.06.04, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote: Hi Marten, Would Stream headers fix this problem? I.e. anything that requires special behaviour other than "bulk data" has some bytes of of magic at the start of the stream. Regards Lucas ________________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Marten Seemann [ martenseemann@gmail.com] Sent: 02 April 2018 12:43 To: QUIC WG Subject: Implicitly opened streams and exposing stream IDs Recently, the implicit opening of streams (i.e. that when a receiver receives a frame for stream N+4, it can assume that stream N was already opened, but the packet might have been reordered) was removed from the draft. I think this change has some consequences that we haven't discussed so far. For the purpose of writing some pseudocode, I'm assuming a QUIC API that provides an AcceptStream() method, but the conclusions will be the same for a callback-based API. * If QUIC has implicit stream opening, AcceptStream() would return the streams in order (and if a frame opening stream N+4 is received before stream n is opened, AcceptStream() will first return stream N and then stream N+4). * Without implicit stream opening, AcceptStream() just returns whatever stream is received first. Streams might be returned in arbitrary order, if the peer doesn't open streams consecutively or if packets are reordered. Now imagine an application protocol where the first unidirectional stream opened by the client is a control stream, and all higher unidirectional streams are data streams. The application on the server side needs to find out which stream is the control stream, because it needs to be handled separately. With implicit stream opening, the server code would be: control_stream =3D AcceptStream() // is guaranteed to open the first stream // handle the control stream while true: stream =3D AcceptStream() // handle the data stream and without implicit stream opening: while true: stream =3D AcceptStream() if stream.ID() =3D=3D kControlStreamID: // handle the control stream else: // handle the data stream In this case, after accepting a stream, we first have to check the stream ID, since there's no guarantee if the control stream will actually be received first. For this stream mapping, it seems like the removal of implicitly opened streams implies that QUIC has to expose stream IDs to the application layer. I'm not sure if this was intended when making the change, especially since we're considering to change HQ such that it doesn't rely on QUIC stream IDs any more. We only manage to avoid the problem described here in our HTTP mapping, because the HTTP control streams are unidirectional and the request streams are bidirectional, and can therefore be told apart by their directionality. However, as a general transport protocol, other applications built on top of QUIC will have to find some way to deal with it. ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- --001a113e06a29d7bb20568e112b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Isn=E2=80=99t this b= etween QUIC, the QUIC application API, and the application protocol?
<= 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">
If you tell QUIC to feed = streams in order, just like you it to feed data inside a stream in order, t= hen it can virtually open streams in order stream towards the API without a= ffecting the network.

QUIC is also permitted to deliver data out of order inside a stream AFAIR,= although this would not be the usual API behaviour.

In the end, specific broadly accepted app p= rotocols like QUIC/HTTP will drive the API design.

For other use cases such as some small brief = message streams and some heavy data loaded streams, you might very well wan= t to have the latest stream arrive first, to process priority messages. Say= ing that QUIC can never, as opposed to usually, expose the stream ID seems = pointless. It is like saying a QUIC api can never expose holes in a single = streams data stream.

= I don=E2=80=99t really see an issue on the wire, and I believe removing imp= licit open takes a way some fear, uncertainty and doubt about stream resour= ce handling - at least I never felt completely comfortable with the stream = design until now.


Regards,
Mikkel


On 2 Ap= ril 2018 at 14.06.04, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote:

Hi Marten,

Would Stream headers fix this problem? I.e. anything that requires spec= ial behaviour other than "bulk data" has some bytes of of magic a= t the start of the stream.

Regards
Lucas
________________________________________
From: QUIC [quic-bounces@ietf.= org] on behalf of Marten Seemann [martenseemann@gmail.com]
Sent: 02 April 2018 12:43
To: QUIC WG
Subject: Implicitly opened streams and exposing stream IDs

Recently, the implicit opening of streams (i.e. that when a receiver re= ceives a frame for stream N+4, it can assume that stream N was already open= ed, but the packet might have been reordered) was removed from the draft. I= think this change has some consequences that we haven't discussed so f= ar.

For the purpose of writing some pseudocode, I'm assuming a QUIC API= that provides an AcceptStream() method, but the conclusions will be the sa= me for a callback-based API.

* If QUIC has implicit stream opening, AcceptStream() would return = the streams in order (and if a frame opening stream N+4 is received before = stream n is opened, AcceptStream() will first return stream N and then stre= am N+4).
* Without implicit stream opening, AcceptStream() just returns what= ever stream is received first. Streams might be returned in arbitrary order= , if the peer doesn't open streams consecutively or if packets are reor= dered.

Now imagine an application protocol where the first unidirectional stre= am opened by the client is a control stream, and all higher unidirectional = streams are data streams. The application on the server side needs to find = out which stream is the control stream, because it needs to be handled sepa= rately.

With implicit stream opening, the server code would be:

control_stream =3D AcceptStream() // is guaranteed to open the firs= t stream
// handle the control stream
while true:
stream =3D AcceptStream()
// handle the data stream

and without implicit stream opening:

while true:
stream =3D AcceptStream()
if stream.ID() =3D=3D kControlStreamID:
// handle the control stream
else:
// handle the data stream

In this case, after accepting a stream, we first have to check the stre= am ID, since there's no guarantee if the control stream will actually b= e received first.

For this stream mapping, it seems like the removal of implicitly opened= streams implies that QUIC has to expose stream IDs to the application laye= r. I'm not sure if this was intended when making the change, especially= since we're considering to change HQ such that it doesn't rely on = QUIC stream IDs any more.
We only manage to avoid the problem described here in our HTTP mapping,= because the HTTP control streams are unidirectional and the request stream= s are bidirectional, and can therefore be told apart by their directionalit= y. However, as a general transport protocol, other applications built on to= p of QUIC will have to find some way to deal with it.


-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless sp= ecifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

--001a113e06a29d7bb20568e112b0-- From nobody Mon Apr 2 10:48:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B473E127010 for ; Mon, 2 Apr 2018 10:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By53Cra_Fyfv for ; Mon, 2 Apr 2018 10:48:16 -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 662E1126B72 for ; Mon, 2 Apr 2018 10:48:16 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id o64so15824795qkl.7 for ; Mon, 02 Apr 2018 10:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=DmmoNWUKXXGHYh8DlsAR5ETwa72MCKx8ENGFhb/BKUY=; b=kzUTc0coje8wT22hLDlS7arbuoltRzv5OFdfR1Xw9Ca+PCSMcFtN2QaX2BylZfV/5r dRgW7B1sibHAsf5Gu/J42Lfxv2BVb8zHM3fPralTtnAFBlVh6PN/ypeNS5x6AVSJQPIM LWJ+Q/ar54mx02BndSOawUC3oB8hiZvV5Ftxx2Ol264mPnfNlRCLWb9nJTIbeLDzwxV6 wQ2ERrHhJy3egswmPfvktodl0Zae/Qx4GLw5u+kLIl8RbW0hkDuAqLh5fYpe6yU+k7Vl OaDqE7bnGRHCNRHklN/k/5+YmuCkS6wELalSprXoOPFJCGTCX4tncFkAZ2v4P+8U42Do czZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=DmmoNWUKXXGHYh8DlsAR5ETwa72MCKx8ENGFhb/BKUY=; b=M/8hWyGSYNc34GEHIEIEiGO9m6GZf0ZjqEhXYTOQ7gMfHd06kc33weuoMighr62IsK f8QxgPOhvmXVtL5754PutioJLYfGiql3hKT4ohuPfdv0xOo7O3A6R9FS9yrnUpPXnjMl ZJ00/hSZpnH7qUl1XhjSEYrqU9YRP2epUcgln204tEm4xZDkHFFqLGP8iazXDBv1ijg6 ZZahcP9AUvkb7RUERnMTakRRb/s6C28PdKlAF4eRApIOJzfRqVoB+HBsgkUt1RKD9Aw2 5MxWLN4+fP3kfJvQ9Bg8eJmZYFZKdZKCGlTjv6xudDw1M93C/mOnroyrzJwJFY1Nsvxl XhIA== X-Gm-Message-State: ALQs6tC5736RdWzvMQOcH1kL/K8Sr6l0SOQbb0C9lxiBq42CqxgIlp/O NKfXiugxvyLapbdpSkjXeDRVKA== X-Google-Smtp-Source: AIpwx4/l/el7oVqtRNGmkoVVUnkGjPts1eHKq6eKHdDl6g4kUXiYj7LQrB9L+En+ptRuNcbCdnKBJw== X-Received: by 10.55.214.211 with SMTP id p80mr14232613qkl.1.1522691295479; Mon, 02 Apr 2018 10:48:15 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id f6sm648547qth.44.2018.04.02.10.48.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Apr 2018 10:48:14 -0700 (PDT) Date: Mon, 2 Apr 2018 13:48:11 -0400 From: Dmitri Tikhonov To: Marten Seemann Cc: QUIC WG Subject: Re: Implicitly opened streams and exposing stream IDs Message-ID: <20180402174810.GA2015@ubuntu-dmitri> Mail-Followup-To: Marten Seemann , QUIC WG References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 17:48:19 -0000 On Mon, Apr 02, 2018 at 11:43:23AM +0000, Marten Seemann wrote: > In this case, after accepting a stream, we first have to check the stream > ID, since there's no guarantee if the control stream will actually be > received first. > > For this stream mapping, it seems like the removal of implicitly opened > streams implies that QUIC has to expose stream IDs to the application > layer. I don't see a problem with that -- HTTP is the application layer, and the draft specifies that streams 2 and 3 are the control streams. > I'm not sure if this was intended when making the change, especially > since we're considering to change HQ such that it doesn't rely on QUIC > stream IDs any more. Are you referring to a specific pull request or an issue on GitHub? (I must have missed it.) - Dmitri. From nobody Mon Apr 2 20:45:54 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E9D126D74 for ; Mon, 2 Apr 2018 20:45: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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=S3hBnwH8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UBhdn5t8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdaClTjq4pxC for ; Mon, 2 Apr 2018 20:45:49 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A93126D73 for ; Mon, 2 Apr 2018 20:45:49 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 83D7F21111; Mon, 2 Apr 2018 23:45:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 02 Apr 2018 23:45:48 -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; s=fm2; bh=HTHVEO2ZBVnRcP767A5U5C4o5nidX /tRmulDn+7kBVY=; b=S3hBnwH8pep4rloZxU0AMaMzgcJBIjJTiNeyz0/CMuhiO /7B8xPIUUdooGzzJZ16GkmRTIr1KZaLjA6nIzpx0FPNklrCL3NR9Y0Gr4EO7lrBK P2hFFgwqhtI02a3adh+4HH3VMk1Kj2zS9vq+DF289WEugkVzoE7mzcT+A6SLvy0f FjQeDDU9Wz991OF8nM5TRWRxpDn6LqpEZfZrj9q0V57BjfjXmysAjyEzl5MRorss MpNlEO0mPQp43rT5ILUsZgONYQW60PE2ZJzMLyewgeBbg+pa6Ge08p/crZigvCHx auDsYwWGdfBZaJ1tjbkTmnwO2xkwZ8BVMwhn1WHKg== 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; s=fm2; bh=HTHVEO 2ZBVnRcP767A5U5C4o5nidX/tRmulDn+7kBVY=; b=UBhdn5t8fJ6yDwJhh+/9WM vYBrDT8oCVNR8fJ4TjYk7Iert56xmoVHnUZq3ffrK6GEeRp1Oci5XriV1w1DN2J3 zSZwAPuQDnEys1SU9NGca4Rx4Vr4EmstM6pXiERZ1P9vQ1HbsRr7c1PwtnTXJ5Mz RRlmbSYydVZ52/iaLCEi0o7bvEOLxP0dnI6kd3fdIDCDbPo8ObsiO9PxsSBiMq2U isKwtTRXhFzIQY764GOI5ACnse9uMMItppKb9KZsZyXWjwVvf/EJKhzI086LpDIh aHkxxa4Z1BZRb2BTuGXUdVC7s7Z9EirJri6m9QjK9TbyCataAGp0BujmrDvXfnAg == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 8F092E444F; Mon, 2 Apr 2018 23:45:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: QUIC (quic) WG Interim Meeting: 2018-06-06 From: Mark Nottingham In-Reply-To: <6203282A-CD65-4049-A499-DED34431E912@mnot.net> Date: Tue, 3 Apr 2018 13:45:44 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <80C50C46-2BCF-4716-B239-FEE5F1264AD0@mnot.net> References: <151809506296.17228.17281018611304930059@ietfa.amsl.com> <6203282A-CD65-4049-A499-DED34431E912@mnot.net> To: QUIC WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 03 Apr 2018 03:45:52 -0000 Reminder: registration closes in about a month. > On 9 Feb 2018, at 10:02 am, Mark Nottingham wrote: >=20 > Registration is now open; see the arrangements page. Please note the = guidelines for attendance there. >=20 > Cheers, >=20 >=20 >> On 9 Feb 2018, at 12:04 am, IESG Secretary = wrote: >>=20 >> The QUIC (quic) Working Group will hold >> a multi-day interim meeting. >>=20 >> Session 1: >> 2018-06-06 09:00 to 17:00 Europe/Berlin >> Session 2: >> 2018-06-07 09:00 to 17:00 Europe/Berlin >>=20 >> Meeting Location: >> Kista, SE >>=20 >> Agenda: >> = https://github.com/quicwg/wg-materials/blob/master/interim-18-06/agenda.md= >>=20 >> Information about remote participation: >> = https://github.com/quicwg/wg-materials/blob/master/interim-18-06/arrangeme= nts.md >>=20 >> Preceded by non-IETF QUIC interop event on June 4-5, same location >>=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 3 00:10:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DB51201FA for ; Tue, 3 Apr 2018 00:10: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, 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 3eY9ALyKIa1P for ; Tue, 3 Apr 2018 00:10:45 -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 44B00120047 for ; Tue, 3 Apr 2018 00:10:45 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id m83so20717687ioi.8 for ; Tue, 03 Apr 2018 00:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S8OyK9ujcEawfHSz24/647e1Y4C5T1mAM4ZFQ/s20Hs=; b=tHaRzO5XFwOqvPne+PpYtEtuOxj0UjeFH3wTjTFjsLUqXwD9Uw0Vfhl7CdFnOD76HA +/sN1Bw/Kf1peUQF8IyydHWlTt1S4LPXfpuDW0qPBkgrJFG6zO2nxgfJ6PiCX7uLVI9Y CYW6xhGlkJ0FWTQutxus+ayZZ4I//XeBCLvaTli0oYDM5uX+FAKR4Vko9r1XdZiehTvm CCZyoH9IYFned40ob8+IPxxVoFhS5qlDEjjKe/jIqeM/orEIrpFyx5PLPruQFUPnjIl5 CuMp5yvB60GCBhof9/GSqYE4F6RNLN1Db38tUTb84R7lI26dYUAQ9ZexYJDYtZ5naeCA oz/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S8OyK9ujcEawfHSz24/647e1Y4C5T1mAM4ZFQ/s20Hs=; b=WU1zJ+GOmrD8ps0oUO7gTAtO4IyePiZL/dCSr36lSaQ9mO4sdWEzDtfEraaUoaO5h6 TPF7X0ZjviE7VSI5FxHTstQhpE/mBeoTGLdiMlNEgWto3dWCtUrXkN+KqQf0AA8vOL6a AdKpScpoO+c+8TGW6zgfNZxhcjUj/cF5uU5ynGuXq3uGMBXPD5OIQgQl4feLNjvpUH3K ffDsObs40+qPjFJ/kX5zHKR4AihJuRZQIlQr67SkA5dn2gjfKKxs37KhRA4JPw7pjXJT QanbieypWf8Uuq8PFAYuhF6X+m8vYBpCCHvhJkChLBIrGN4fySDxswd1Y7mbLfhb+BH+ BoBw== X-Gm-Message-State: ALQs6tDgOIqS4DeUsEARKUQIEoxhYsgdXtTuyj3WuTU5KixHD+3YId6O +OHHkWDFVkx5LvnxavrgM61E6l11gjMtp1yznK4= X-Google-Smtp-Source: AIpwx4+px2TUK6n8d2BWOAzEKBR0oYXpJjDSwDwQa34H+Putvh4KBPA55GHcG1SkKnAVwnwse3OYO9aPefQ0c+k6adA= X-Received: by 10.107.180.136 with SMTP id d130mr10927079iof.129.1522739444318; Tue, 03 Apr 2018 00:10:44 -0700 (PDT) MIME-Version: 1.0 References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> From: Marten Seemann Date: Tue, 03 Apr 2018 07:10:33 +0000 Message-ID: Subject: Re: Implicitly opened streams and exposing stream IDs To: Lucas Pardue Cc: QUIC WG Content-Type: multipart/alternative; boundary="94eb2c06b27aaa07d30568ec6781" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 03 Apr 2018 07:10:48 -0000 --94eb2c06b27aaa07d30568ec6781 Content-Type: text/plain; charset="UTF-8" Hello, Sure, the application *could* deal with it by starting every stream with some kind of header, to signal what kind of stream type this is. I'm not sure if I like this solution, since it creates additional complexity, and it is only necessary because we removed a useful feature from the spec. What did we actually gain from removing implicit stream opening from the protocol? As far as I can see, we were able to relax the requirement "endpoints MUST open the send side of streams for each type in order" to "endpoints SHOULD open the send side of streams for each type in order". This might seem nice from a conceptual viewpoint, but honestly, I don't really see why anyone would actually want to do this. I think the main argument against the MUST was that it's not enforceable anyway, but this applies to a lot of other MUSTs in the spec as well (e.g. that flow control limits can't be decreased). The fix for this is straightforward: We should REQUIRE a peer to open streams in order. How the receiver handles out of order streams then is an implementation and API decision. I see two ways that an implementation could reasonably deal with this: 1. Return streams in the order they are received, e.g. return N+4 before N, if packets are reordered. 2. Return streams ordered by stream ID, i.e. return first N and then N+4 if a frame for N+4 is received. This way, we wouldn't need to reintroduce implicitly opened streams, but leave this up to implementations. I should have named this thread differently, if only I had realized this earlier ;) Regards, Marten On Mon, Apr 2, 2018 at 7:05 PM Lucas Pardue wrote: > Hi Marten, > > Would Stream headers fix this problem? I.e. anything that requires special > behaviour other than "bulk data" has some bytes of of magic at the start of > the stream. > > Regards > Lucas > ________________________________________ > From: QUIC [quic-bounces@ietf.org] on behalf of Marten Seemann [ > martenseemann@gmail.com] > Sent: 02 April 2018 12:43 > To: QUIC WG > Subject: Implicitly opened streams and exposing stream IDs > > Recently, the implicit opening of streams (i.e. that when a receiver > receives a frame for stream N+4, it can assume that stream N was already > opened, but the packet might have been reordered) was removed from the > draft. I think this change has some consequences that we haven't discussed > so far. > > For the purpose of writing some pseudocode, I'm assuming a QUIC API that > provides an AcceptStream() method, but the conclusions will be the same for > a callback-based API. > > * If QUIC has implicit stream opening, AcceptStream() would return the > streams in order (and if a frame opening stream N+4 is received before > stream n is opened, AcceptStream() will first return stream N and then > stream N+4). > * Without implicit stream opening, AcceptStream() just returns > whatever stream is received first. Streams might be returned in arbitrary > order, if the peer doesn't open streams consecutively or if packets are > reordered. > > Now imagine an application protocol where the first unidirectional stream > opened by the client is a control stream, and all higher unidirectional > streams are data streams. The application on the server side needs to find > out which stream is the control stream, because it needs to be handled > separately. > > With implicit stream opening, the server code would be: > > control_stream = AcceptStream() // is guaranteed to open the first > stream > // handle the control stream > while true: > stream = AcceptStream() > // handle the data stream > > and without implicit stream opening: > > while true: > stream = AcceptStream() > if stream.ID() == kControlStreamID: > // handle the control stream > else: > // handle the data stream > > In this case, after accepting a stream, we first have to check the stream > ID, since there's no guarantee if the control stream will actually be > received first. > > For this stream mapping, it seems like the removal of implicitly opened > streams implies that QUIC has to expose stream IDs to the application > layer. I'm not sure if this was intended when making the change, especially > since we're considering to change HQ such that it doesn't rely on QUIC > stream IDs any more. > We only manage to avoid the problem described here in our HTTP mapping, > because the HTTP control streams are unidirectional and the request streams > are bidirectional, and can therefore be told apart by their directionality. > However, as a general transport protocol, other applications built on top > of QUIC will have to find some way to deal with it. > > > ----------------------------- > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and > may contain personal views which are not the views of the BBC unless > specifically stated. > If you have received it in > error, please delete it from your system. > Do not use, copy or disclose the > information in any way nor act in reliance on it and notify the sender > immediately. > Please note that the BBC monitors e-mails > sent or received. > Further communication will signify your consent to > this. > ----------------------------- > --94eb2c06b27aaa07d30568ec6781 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Sure, the application = could deal with it by starting every stream with some kind of header= , to signal what kind of stream type this is. I'm not sure if I like th= is solution, since it creates additional complexity, and it is only necessa= ry because we removed a useful feature from the spec.
What did we= actually gain from removing implicit stream opening from the protocol? As = far as I can see, we were able to relax the requirement "endpoints MUS= T open the send side of streams for each type in order" to "endpo= ints SHOULD open the send side of streams for each type in order". Thi= s might seem nice from a conceptual viewpoint, but honestly, I don't re= ally see why anyone would actually want to do this. I think the main argume= nt against the MUST was that it's not enforceable anyway, but this appl= ies to a lot of other MUSTs in the spec as well (e.g. that flow control lim= its can't be decreased).

The fix = for this is straightforward: We should REQUIRE a peer to open streams in or= der. How the receiver handles out of order streams then is an implementatio= n and API decision. I see two ways that an implementation could reasonably = deal with this:
  1. Return streams in the order they are rece= ived, e.g. return N+4 before N, if packets are reordered.
  2. Return st= reams ordered by stream ID, i.e. return first N and then N+4 if a frame for= N+4 is received.
This way, we wouldn't need to reintrodu= ce implicitly opened streams, but leave this up to implementations. I shoul= d have named this thread differently, if only I had realized this earlier ;= )

Regards,
Marten=

On Mon= , Apr 2, 2018 at 7:05 PM Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Hi Marten,

Would Stream headers fix this problem? I.e. anything that requires special = behaviour other than "bulk data" has some bytes of of magic at th= e start of the stream.

Regards
Lucas
________________________________________
From: QUIC [quic= -bounces@ietf.org] on behalf of Marten Seemann [martenseemann@gmail.com]
Sent: 02 April 2018 12:43
To: QUIC WG
Subject: Implicitly opened streams and exposing stream IDs

Recently, the implicit opening of streams (i.e. that when a receiver receiv= es a frame for stream N+4, it can assume that stream N was already opened, = but the packet might have been reordered) was removed from the draft. I thi= nk this change has some consequences that we haven't discussed so far.<= br>
For the purpose of writing some pseudocode, I'm assuming a QUIC API tha= t provides an AcceptStream() method, but the conclusions will be the same f= or a callback-based API.

=C2=A0 *=C2=A0 =C2=A0If QUIC has implicit stream opening, AcceptStream() wo= uld return the streams in order (and if a frame opening stream N+4 is recei= ved before stream n is opened, AcceptStream() will first return stream N an= d then stream N+4).
=C2=A0 *=C2=A0 =C2=A0Without implicit stream opening, AcceptStream() just r= eturns whatever stream is received first. Streams might be returned in arbi= trary order, if the peer doesn't open streams consecutively or if packe= ts are reordered.

Now imagine an application protocol where the first unidirectional stream o= pened by the client is a control stream, and all higher unidirectional stre= ams are data streams. The application on the server side needs to find out = which stream is the control stream, because it needs to be handled separate= ly.

With implicit stream opening, the server code would be:

=C2=A0 =C2=A0 control_stream =3D AcceptStream() // is guaranteed to open th= e first stream
=C2=A0 =C2=A0 // handle the control stream
=C2=A0 =C2=A0 =C2=A0while true:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0stream =3D AcceptStream()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// handle the data stream

and without implicit stream opening:

=C2=A0 =C2=A0 while true:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 stream =3D AcceptStream()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if stream.ID() =3D=3D kControlStreamID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // handle the control stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // handle the data stream

In this case, after accepting a stream, we first have to check the stream I= D, since there's no guarantee if the control stream will actually be re= ceived first.

For this stream mapping, it seems like the removal of implicitly opened str= eams implies that QUIC has to expose stream IDs to the application layer. I= 'm not sure if this was intended when making the change, especially sin= ce we're considering to change HQ such that it doesn't rely on QUIC= stream IDs any more.
We only manage to avoid the problem described here in our HTTP mapping, bec= ause the HTTP control streams are unidirectional and the request streams ar= e bidirectional, and can therefore be told apart by their directionality. H= owever, as a general transport protocol, other applications built on top of= QUIC will have to find some way to deal with it.


-----------------------------
http:= //www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specif= ically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------
--94eb2c06b27aaa07d30568ec6781-- From nobody Tue Apr 3 00:28:32 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFDC1201FA for ; Tue, 3 Apr 2018 00:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiugX78Bbriz for ; Tue, 3 Apr 2018 00:28:29 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 D3A27124205 for ; Tue, 3 Apr 2018 00:28:22 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id j8-v6so10783989ota.7 for ; Tue, 03 Apr 2018 00:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eWBdAXIRKAcoco0OEWQOu+mD1h2ZkYufyYXupJJjWRk=; b=j4qa2npu3M7i0wOscazKn0pdJVvBl1vsl0INgiy7QSUIx1gwjkCY8w55UTaCPdWP39 L1THlX5cjKgzhv5mfa6Ery1zZCfI06AlWUuMP+YjW7rZiaGjZ1K9hN4TOrze8aLR4aov 5KLqbeVqgLGiADJloMxVgvj7f8eZl3t/hlUxnSSMzvFYm5J5feuNzRp6owXHiLravqC8 Ew777jk62nV6XVytKg3HrMnQ3H5w1SDcXwxwKaHA/WIoWYzaC/aamI7LZL//Tvk6CjVO FVzUciyo4QlEOCUj51yzG9tQAnJUwsvx0ip0Y+BV3rh788HhRf6vqLsDjUpIafmUNzQj RJNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=eWBdAXIRKAcoco0OEWQOu+mD1h2ZkYufyYXupJJjWRk=; b=fMcJbkY0gk/E0vsWVs3cnhqpFDToUASGN5yXpv6vT0oT0CZfAa7iUTa/LNzV/2WdTh BUiX56aZLnft+LUCk6KHE0JtzBJqcjMyo6nP5oNMAyNzpG2B0VBmmZjd+F+VX3ezHKzz sLL6tHUx6p+VMJNPomJZY3o1qYjc/dnc6s+BTYc60UuhhhoLsJwe3YWkL3HXyiseeEPk v1ZotSXUEdTyqHx4XJvAXenQr6wXfs1/1qwcYkX6vG764tqeD/aBMm+AIsN9zQtUWQa5 8L9yFMNHsmUU+Ows5ir+ADklxdyqEVnqaAdGSSUn16L5I9vp6ropg+Ad8mlRyhERq5RQ PTBw== X-Gm-Message-State: ALQs6tAsP+slIJ4XNvtlGWmKVnXZDXTrqFwk2TYDrjjlGgWGtP9RGwOe 5WGXQyG8fcgW510d7uGUl/bEROu5uo34ucLJeG4= X-Google-Smtp-Source: AIpwx49C30a4PiqqNUZaH//DfkqnHeJGo4oLD63MTd263oLCeexI5Od9dG4qSvxM3hMXQrD9RxJ8aQ4zyWhfNNIXl9U= X-Received: by 2002:a9d:6001:: with SMTP id h1-v6mr6947507otj.283.1522740501989; Tue, 03 Apr 2018 00:28:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Tue, 3 Apr 2018 00:28:21 -0700 (PDT) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> From: Martin Thomson Date: Tue, 3 Apr 2018 17:28:21 +1000 Message-ID: Subject: Re: Implicitly opened streams and exposing stream IDs To: Marten Seemann Cc: Lucas Pardue , 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, 03 Apr 2018 07:28:31 -0000 Requiring in-order opening is harder than it sounds. Say you have a multithreaded application that is initiating requests. The usual process is something like: s = connection.OpenStream() s.Write(request.Headers.Encode()) That is, there is time between acquisition of the stream and its use. Do that with enough concurrency and you end up having to add late binding of stream identifiers to streams, which complicates the design of the stack considerably. It also complicates usage because now there is a period where s.Id() returns an undefined result. Alternatively, you could track the highest stream ID on which data has been sent and send an empty, offset 0 STREAM frame rather than create a gap. Or, you could decide that a MUST here is unenforceable (even more so than the flow control limits one) and just wantonly ignore that requirement if this race condition happens. While it is in theory possible to catch someone in a violation, it requires some interesting conditions (like zero packet loss). BTW, I also wish to make it possible to avoid relying on specific stream IDs for special functions. I hadn't considered opening order as a way to do that though and had assumed that we'd use an in-stream header for that. I don't think that makes the complexity worse, or at least no worse than having to deal with different frame types for different functions. On Tue, Apr 3, 2018 at 5:10 PM, Marten Seemann wrote: > Hello, > > Sure, the application could deal with it by starting every stream with some > kind of header, to signal what kind of stream type this is. I'm not sure if > I like this solution, since it creates additional complexity, and it is only > necessary because we removed a useful feature from the spec. > What did we actually gain from removing implicit stream opening from the > protocol? As far as I can see, we were able to relax the requirement > "endpoints MUST open the send side of streams for each type in order" to > "endpoints SHOULD open the send side of streams for each type in order". > This might seem nice from a conceptual viewpoint, but honestly, I don't > really see why anyone would actually want to do this. I think the main > argument against the MUST was that it's not enforceable anyway, but this > applies to a lot of other MUSTs in the spec as well (e.g. that flow control > limits can't be decreased). > > The fix for this is straightforward: We should REQUIRE a peer to open > streams in order. How the receiver handles out of order streams then is an > implementation and API decision. I see two ways that an implementation could > reasonably deal with this: > > Return streams in the order they are received, e.g. return N+4 before N, if > packets are reordered. > Return streams ordered by stream ID, i.e. return first N and then N+4 if a > frame for N+4 is received. > > This way, we wouldn't need to reintroduce implicitly opened streams, but > leave this up to implementations. I should have named this thread > differently, if only I had realized this earlier ;) > > Regards, > Marten > > On Mon, Apr 2, 2018 at 7:05 PM Lucas Pardue wrote: >> >> Hi Marten, >> >> Would Stream headers fix this problem? I.e. anything that requires special >> behaviour other than "bulk data" has some bytes of of magic at the start of >> the stream. >> >> Regards >> Lucas >> ________________________________________ >> From: QUIC [quic-bounces@ietf.org] on behalf of Marten Seemann >> [martenseemann@gmail.com] >> Sent: 02 April 2018 12:43 >> To: QUIC WG >> Subject: Implicitly opened streams and exposing stream IDs >> >> Recently, the implicit opening of streams (i.e. that when a receiver >> receives a frame for stream N+4, it can assume that stream N was already >> opened, but the packet might have been reordered) was removed from the >> draft. I think this change has some consequences that we haven't discussed >> so far. >> >> For the purpose of writing some pseudocode, I'm assuming a QUIC API that >> provides an AcceptStream() method, but the conclusions will be the same for >> a callback-based API. >> >> * If QUIC has implicit stream opening, AcceptStream() would return the >> streams in order (and if a frame opening stream N+4 is received before >> stream n is opened, AcceptStream() will first return stream N and then >> stream N+4). >> * Without implicit stream opening, AcceptStream() just returns >> whatever stream is received first. Streams might be returned in arbitrary >> order, if the peer doesn't open streams consecutively or if packets are >> reordered. >> >> Now imagine an application protocol where the first unidirectional stream >> opened by the client is a control stream, and all higher unidirectional >> streams are data streams. The application on the server side needs to find >> out which stream is the control stream, because it needs to be handled >> separately. >> >> With implicit stream opening, the server code would be: >> >> control_stream = AcceptStream() // is guaranteed to open the first >> stream >> // handle the control stream >> while true: >> stream = AcceptStream() >> // handle the data stream >> >> and without implicit stream opening: >> >> while true: >> stream = AcceptStream() >> if stream.ID() == kControlStreamID: >> // handle the control stream >> else: >> // handle the data stream >> >> In this case, after accepting a stream, we first have to check the stream >> ID, since there's no guarantee if the control stream will actually be >> received first. >> >> For this stream mapping, it seems like the removal of implicitly opened >> streams implies that QUIC has to expose stream IDs to the application layer. >> I'm not sure if this was intended when making the change, especially since >> we're considering to change HQ such that it doesn't rely on QUIC stream IDs >> any more. >> We only manage to avoid the problem described here in our HTTP mapping, >> because the HTTP control streams are unidirectional and the request streams >> are bidirectional, and can therefore be told apart by their directionality. >> However, as a general transport protocol, other applications built on top of >> QUIC will have to find some way to deal with it. >> >> >> ----------------------------- >> http://www.bbc.co.uk >> This e-mail (and any attachments) is confidential and >> may contain personal views which are not the views of the BBC unless >> specifically stated. >> If you have received it in >> error, please delete it from your system. >> Do not use, copy or disclose the >> information in any way nor act in reliance on it and notify the sender >> immediately. >> Please note that the BBC monitors e-mails >> sent or received. >> Further communication will signify your consent to >> this. >> ----------------------------- From nobody Tue Apr 3 00:50:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF1412E053 for ; Tue, 3 Apr 2018 00:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjXhosTyY74b for ; Tue, 3 Apr 2018 00:50:18 -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 A6A91124205 for ; Tue, 3 Apr 2018 00:50:18 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id l3so20873465iog.0 for ; Tue, 03 Apr 2018 00:50:18 -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=Ujp8zeDrv6zB1rLdiua90JrJPudt1NmIhL/rALLb5fw=; b=I27qjFTW9mn5gaOVbcDfutRoVv07mCoaiQyuVyllot1nFDGx44cnl+Nkstf1HknMMi +aP6BA1/rc5U+HtiDypiOKPc3kifIpMxOVSIJP01FaYZnEMn8RD7DQiOAucuzx+S7au8 LFfGkL2X70OOxvUebrXCsnOojxI07vEbM4iNg+GLmj+iEYFrtAR6IHPSjNcTGiCqBE8p MovxTeDG983wBl3d4GX0cobrMsg9gqaEh5OCzFqi+UQhSzp/hNbx0L7tCM92RVTl5P5N BRu8gYAoPiwJstgTlnxw3BYri7meVbE5S8dwBq5J5IllZHrMLeARaSmbikP4hk2j1URQ DP2Q== 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=Ujp8zeDrv6zB1rLdiua90JrJPudt1NmIhL/rALLb5fw=; b=ggP/gqsSp9F7yA+umqyvxIWm6JwrbGyDVjuDKxUD3nkdpaaMPZVv9VSTTbfHxNAFA0 1KF5gDqFkGRTZ8DsXrZ7XmB3RvehdCagrUdC2hhcvFw3sed6VN/utAsbigfFUDS5E3hw 90iZhz7/MKMO20VB9GD8fktQZdVVo7+jyqILs2TDQH09ncy9Xz5iViCqVd0y+vzyLaqr VbI2Vkw6JazwqjyqtchoNA+EQPOWlK5wv2Ezc2giti+EPtJglVJBRv1Kb04vPqVPITk3 oWjF/HG2Q3le6i8Ng396YP0uj5wnsCXGLzP+SSLYTBggta7j3SSerRgwsBfnNjkfGgpM aETA== X-Gm-Message-State: ALQs6tCDCXWmO26ReZzsHd5wV+Cd+2zy/oUl71k17q1ZQg85EbKtX7VB LDzGNm4J1ovX75gAsfnGg4gIMdTScSbLvXn3WevdZQ== X-Google-Smtp-Source: AIpwx4/qKT4gzEVeg9AHDHqJQ1ACO6t2b9cfdf+LFpPXfsM0YThi/LPLO4NkDWxJUDTRxElqIh8D8uhHh2TZClkWZJo= X-Received: by 10.107.6.163 with SMTP id f35mr12050953ioi.165.1522741817849; Tue, 03 Apr 2018 00:50:17 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 3 Apr 2018 00:50:17 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 3 Apr 2018 00:50:16 -0700 Message-ID: Subject: Re: Implicitly opened streams and exposing stream IDs To: Martin Thomson , Marten Seemann Cc: Lucas Pardue , QUIC WG Content-Type: multipart/alternative; boundary="001a113e06a2233d310568ecf595" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 03 Apr 2018 07:50:22 -0000 --001a113e06a2233d310568ecf595 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Say you deal with 10K outbound bidi streams. As Martin suggests, you can make this heavily concurrent and also reserve certain patterns for certain use. With implicit bi-directional streams you must be prepared to handle connection state for all 10K streams that is supposed to be started by you. You cannot create an error if you receive data, at least not at transport level, so you must open and track state. This in turn will limit you number of streams you are willing to handle at once, or force you to split streams into linked uni-streams. Further, there might be zero application logic that understands what data on such a stream means so when an unfortunate subsystem decides to open a stream, it has to ponder whatever the data already pending on that stream means. Opening strictly in order (whether required or not) reduces those problems, but it also severely constrains the application. For example you cannot send a stream id internally to a subsystem and ask it to produce data once ready to do so. You need to invent a complex mapping that is difficult to coordinate in a distributed system. It is much simpler to deal with the stream id=E2=80=99s directly. With multi-path you could even have multiple = hosts managing a single connection, and if not, you could still do it with proper address mapping. So implicit streams and strict opening order might simplify very simple problems, but also make very hard problems even harder. Also, the entire idea of linearising QUIC seems to go against the spirit of independent non-blocking streams. Still, having a maximum stream ID is very useful in limiting the resources that must be managed. Mikkel On 3 April 2018 at 09.28.38, Martin Thomson (martin.thomson@gmail.com) wrote: Requiring in-order opening is harder than it sounds. Say you have a multithreaded application that is initiating requests. The usual process is something like: s =3D connection.OpenStream() s.Write(request.Headers.Encode()) That is, there is time between acquisition of the stream and its use. Do that with enough concurrency and you end up having to add late binding of stream identifiers to streams, which complicates the design of the stack considerably. It also complicates usage because now there is a period where s.Id() returns an undefined result. Alternatively, you could track the highest stream ID on which data has been sent and send an empty, offset 0 STREAM frame rather than create a gap. Or, you could decide that a MUST here is unenforceable (even more so than the flow control limits one) and just wantonly ignore that requirement if this race condition happens. While it is in theory possible to catch someone in a violation, it requires some interesting conditions (like zero packet loss). BTW, I also wish to make it possible to avoid relying on specific stream IDs for special functions. I hadn't considered opening order as a way to do that though and had assumed that we'd use an in-stream header for that. I don't think that makes the complexity worse, or at least no worse than having to deal with different frame types for different functions. On Tue, Apr 3, 2018 at 5:10 PM, Marten Seemann wrote: > Hello, > > Sure, the application could deal with it by starting every stream with some > kind of header, to signal what kind of stream type this is. I'm not sure if > I like this solution, since it creates additional complexity, and it is only > necessary because we removed a useful feature from the spec. > What did we actually gain from removing implicit stream opening from the > protocol? As far as I can see, we were able to relax the requirement > "endpoints MUST open the send side of streams for each type in order" to > "endpoints SHOULD open the send side of streams for each type in order". > This might seem nice from a conceptual viewpoint, but honestly, I don't > really see why anyone would actually want to do this. I think the main > argument against the MUST was that it's not enforceable anyway, but this > applies to a lot of other MUSTs in the spec as well (e.g. that flow control > limits can't be decreased). > > The fix for this is straightforward: We should REQUIRE a peer to open > streams in order. How the receiver handles out of order streams then is an > implementation and API decision. I see two ways that an implementation could > reasonably deal with this: > > Return streams in the order they are received, e.g. return N+4 before N, if > packets are reordered. > Return streams ordered by stream ID, i.e. return first N and then N+4 if a > frame for N+4 is received. > > This way, we wouldn't need to reintroduce implicitly opened streams, but > leave this up to implementations. I should have named this thread > differently, if only I had realized this earlier ;) > > Regards, > Marten > > On Mon, Apr 2, 2018 at 7:05 PM Lucas Pardue wrote: >> >> Hi Marten, >> >> Would Stream headers fix this problem? I.e. anything that requires special >> behaviour other than "bulk data" has some bytes of of magic at the start of >> the stream. >> >> Regards >> Lucas >> ________________________________________ >> From: QUIC [quic-bounces@ietf.org] on behalf of Marten Seemann >> [martenseemann@gmail.com] >> Sent: 02 April 2018 12:43 >> To: QUIC WG >> Subject: Implicitly opened streams and exposing stream IDs >> >> Recently, the implicit opening of streams (i.e. that when a receiver >> receives a frame for stream N+4, it can assume that stream N was already >> opened, but the packet might have been reordered) was removed from the >> draft. I think this change has some consequences that we haven't discussed >> so far. >> >> For the purpose of writing some pseudocode, I'm assuming a QUIC API that >> provides an AcceptStream() method, but the conclusions will be the same for >> a callback-based API. >> >> * If QUIC has implicit stream opening, AcceptStream() would return the >> streams in order (and if a frame opening stream N+4 is received before >> stream n is opened, AcceptStream() will first return stream N and then >> stream N+4). >> * Without implicit stream opening, AcceptStream() just returns >> whatever stream is received first. Streams might be returned in arbitrary >> order, if the peer doesn't open streams consecutively or if packets are >> reordered. >> >> Now imagine an application protocol where the first unidirectional stream >> opened by the client is a control stream, and all higher unidirectional >> streams are data streams. The application on the server side needs to find >> out which stream is the control stream, because it needs to be handled >> separately. >> >> With implicit stream opening, the server code would be: >> >> control_stream =3D AcceptStream() // is guaranteed to open the first >> stream >> // handle the control stream >> while true: >> stream =3D AcceptStream() >> // handle the data stream >> >> and without implicit stream opening: >> >> while true: >> stream =3D AcceptStream() >> if stream.ID() =3D=3D kControlStreamID: >> // handle the control stream >> else: >> // handle the data stream >> >> In this case, after accepting a stream, we first have to check the stream >> ID, since there's no guarantee if the control stream will actually be >> received first. >> >> For this stream mapping, it seems like the removal of implicitly opened >> streams implies that QUIC has to expose stream IDs to the application layer. >> I'm not sure if this was intended when making the change, especially since >> we're considering to change HQ such that it doesn't rely on QUIC stream IDs >> any more. >> We only manage to avoid the problem described here in our HTTP mapping, >> because the HTTP control streams are unidirectional and the request streams >> are bidirectional, and can therefore be told apart by their directionality. >> However, as a general transport protocol, other applications built on top of >> QUIC will have to find some way to deal with it. >> >> >> ----------------------------- >> http://www.bbc.co.uk >> This e-mail (and any attachments) is confidential and >> may contain personal views which are not the views of the BBC unless >> specifically stated. >> If you have received it in >> error, please delete it from your system. >> Do not use, copy or disclose the >> information in any way nor act in reliance on it and notify the sender >> immediately. >> Please note that the BBC monitors e-mails >> sent or received. >> Further communication will signify your consent to >> this. >> ----------------------------- --001a113e06a2233d310568ecf595 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Say you deal with 10= K outbound bidi streams.
As Martin suggests, you can make this heavily concurrent and al= so reserve certain patterns for certain use.

With implicit bi-directional streams you must be pr= epared to handle connection state for all 10K streams that is supposed to b= e started by you. You cannot create an error if you receive data, at least = not at transport level, so you must open and track state. This in turn will= limit you number of streams you are willing to handle at once, or force yo= u to split streams into linked uni-streams.

Further, there might be zero application logic that = understands what data on such a stream means so when an unfortunate subsyst= em decides to open a stream, it has to ponder whatever the data already pen= ding on that stream means.

Opening strictly in order (whether required or not) reduces those pro= blems, but it also severely constrains the application. For example you can= not send a stream id internally to a subsystem and ask it to produce data o= nce ready to do so. You need to invent a complex mapping that is difficult = to coordinate in a distributed system. It is much simpler to deal with the = stream id=E2=80=99s directly. With multi-path you could even have multiple = hosts managing a single connection, and if not, you could still do it with = proper address mapping.

So implicit streams and strict opening order might simplify very simple = problems, but also make very hard problems even harder.

Also, the entire idea of linearising QUI= C seems to go against the spirit of independent non-blocking streams.=C2=A0=

Still, having a maxi= mum stream ID is very useful in limiting the resources that must be managed= .

<= div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:= 13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Mikkel

On 3 April 2018 at 09.28.38, Martin Thomson (martin.thomson@gmail.com) wrote:

Requir= ing in-order opening is harder than it sounds. Say you have a
multithreaded application that is initiating requests. The usual
process is something like:

s =3D connection.OpenStream()
s.Write(request.Headers.Encode())

That is, there is time between acquisition of the stream and its use.
Do that with enough concurrency and you end up having to add late
binding of stream identifiers to streams, which complicates the design
of the stack considerably. It also complicates usage because now
there is a period where s.Id() returns an undefined result.

Alternatively, you could track the highest stream ID on which data has
been sent and send an empty, offset 0 STREAM frame rather than create
a gap.

Or, you could decide that a MUST here is unenforceable (even more so
than the flow control limits one) and just wantonly ignore that
requirement if this race condition happens. While it is in theory
possible to catch someone in a violation, it requires some interesting
conditions (like zero packet loss).

BTW, I also wish to make it possible to avoid relying on specific
stream IDs for special functions. I hadn't considered opening orde= r
as a way to do that though and had assumed that we'd use an in-stre= am
header for that. I don't think that makes the complexity worse, or= at
least no worse than having to deal with different frame types for
different functions.


On Tue, Apr 3, 2018 at 5:10 PM, Marten Seemann <martenseemann@gmail.com> wrote:
> Hello,
>
> Sure, the application could deal with it by starting every stream = with some
> kind of header, to signal what kind of stream type this is. I'= m not sure if
> I like this solution, since it creates additional complexity, and = it is only
> necessary because we removed a useful feature from the spec.
> What did we actually gain from removing implicit stream opening fr= om the
> protocol? As far as I can see, we were able to relax the requireme= nt
> "endpoints MUST open the send side of streams for each type i= n order" to
> "endpoints SHOULD open the send side of streams for each type= in order".
> This might seem nice from a conceptual viewpoint, but honestly, I = don't
> really see why anyone would actually want to do this. I think the = main
> argument against the MUST was that it's not enforceable anyway= , but this
> applies to a lot of other MUSTs in the spec as well (e.g. that flo= w control
> limits can't be decreased).
>
> The fix for this is straightforward: We should REQUIRE a peer to o= pen
> streams in order. How the receiver handles out of order streams th= en is an
> implementation and API decision. I see two ways that an implementa= tion could
> reasonably deal with this:
>
> Return streams in the order they are received, e.g. return N+4 bef= ore N, if
> packets are reordered.
> Return streams ordered by stream ID, i.e. return first N and then = N+4 if a
> frame for N+4 is received.
>
> This way, we wouldn't need to reintroduce implicitly opened st= reams, but
> leave this up to implementations. I should have named this thread
> differently, if only I had realized this earlier ;)
>
> Regards,
> Marten
>
> On Mon, Apr 2, 2018 at 7:05 PM Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
>>
>> Hi Marten,
>>
>> Would Stream headers fix this problem? I.e. anything that requ= ires special
>> behaviour other than "bulk data" has some bytes of o= f magic at the start of
>> the stream.
>>
>> Regards
>> Lucas
>> ________________________________________
>> From: QUIC [quic-boun= ces@ietf.org] on behalf of Marten Seemann
>> [martenseemann@gmai= l.com]
>> Sent: 02 April 2018 12:43
>> To: QUIC WG
>> Subject: Implicitly opened streams and exposing stream IDs
>>
>> Recently, the implicit opening of streams (i.e. that when a re= ceiver
>> receives a frame for stream N+4, it can assume that stream N w= as already
>> opened, but the packet might have been reordered) was removed = from the
>> draft. I think this change has some consequences that we haven= 't discussed
>> so far.
>>
>> For the purpose of writing some pseudocode, I'm assuming a= QUIC API that
>> provides an AcceptStream() method, but the conclusions will be= the same for
>> a callback-based API.
>>
>> * If QUIC has implicit stream opening, AcceptStream() woul= d return the
>> streams in order (and if a frame opening stream N+4 is receive= d before
>> stream n is opened, AcceptStream() will first return stream N = and then
>> stream N+4).
>> * Without implicit stream opening, AcceptStream() just ret= urns
>> whatever stream is received first. Streams might be returned i= n arbitrary
>> order, if the peer doesn't open streams consecutively or i= f packets are
>> reordered.
>>
>> Now imagine an application protocol where the first unidirecti= onal stream
>> opened by the client is a control stream, and all higher unidi= rectional
>> streams are data streams. The application on the server side n= eeds to find
>> out which stream is the control stream, because it needs to be= handled
>> separately.
>>
>> With implicit stream opening, the server code would be:
>>
>> control_stream =3D AcceptStream() // is guaranteed to open= the first
>> stream
>> // handle the control stream
>> while true:
>> stream =3D AcceptStream()
>> // handle the data stream
>>
>> and without implicit stream opening:
>>
>> while true:
>> stream =3D AcceptStream()
>> if stream.ID() =3D=3D kControlStreamID:
>> // handle the control stream
>> else:
>> // handle the data stream
>>
>> In this case, after accepting a stream, we first have to check= the stream
>> ID, since there's no guarantee if the control stream will = actually be
>> received first.
>>
>> For this stream mapping, it seems like the removal of implicit= ly opened
>> streams implies that QUIC has to expose stream IDs to the appl= ication layer.
>> I'm not sure if this was intended when making the change, = especially since
>> we're considering to change HQ such that it doesn't re= ly on QUIC stream IDs
>> any more.
>> We only manage to avoid the problem described here in our HTTP= mapping,
>> because the HTTP control streams are unidirectional and the re= quest streams
>> are bidirectional, and can therefore be told apart by their di= rectionality.
>> However, as a general transport protocol, other applications b= uilt on top of
>> QUIC will have to find some way to deal with it.
>>
>>
>> -----------------------------
>> http://www.bbc.co.uk
>> This e-mail (and any attachments) is confidential and
>> may contain personal views which are not the views of the BBC = unless
>> specifically stated.
>> If you have received it in
>> error, please delete it from your system.
>> Do not use, copy or disclose the
>> information in any way nor act in reliance on it and notify th= e sender
>> immediately.
>> Please note that the BBC monitors e-mails
>> sent or received.
>> Further communication will signify your consent to
>> this.
>> -----------------------------

--001a113e06a2233d310568ecf595-- From nobody Tue Apr 3 01:41:09 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3FB12DA6A for ; Tue, 3 Apr 2018 01:41:08 -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 EgnPzyjXCqjc for ; Tue, 3 Apr 2018 01:41:05 -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 23444126DFB for ; Tue, 3 Apr 2018 01:41:05 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id x77so14766123ioi.2 for ; Tue, 03 Apr 2018 01:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NZQPJcpwASLOSkGC+gXr0OVpsPJZ9fXanOPq6zzUgGU=; b=q+MGx6N2wQeGsg8YxlgT0Luv0Ia0dc9au4lSu4FsUH4JEOnE5r+LfGgZv/w1SGu5F4 p3HS++KBZTqfMqKnoM+tXuD7BIInO6YxDnvzBIMFLfEYUV556ZPrQh0/Lz3Oo/Q7mkEa nglXl5oM7hmqUVPRJ/2WSA+osYveWZE0NWCJuYo9QEzauyeMuqHSrctZdtf6t4FVRMdD Cg/CmVdnrDRRdUeUbVvpA9K4jgJQTm8+Cq05VlwPfGd8ruJFc5VEDz6guHNhHYXHiBsh aCS30tmuHk3n0GjNa94bqj8o9NLAaQLwBPXbrQ4LL1QJss7fNC+Pnbt9CRaEiAP+0wbr vbaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NZQPJcpwASLOSkGC+gXr0OVpsPJZ9fXanOPq6zzUgGU=; b=OzjcprjKzMiFQGGidseH5fpskUt6weC9SKOEpjiQHuzrpe19raCmHr5fmWQdA9spQz ns75mKLwtKTdTRF0PZ7ETXcqQAgSUFYDe7XAP6yHgpA5blRtY7EPuNoAOHNCEhdqvCsO 63q1K2qhGof0XyUfx7f+5VJxc1axR4svD62VnoedycbpJUbMMpLnEd12IfBfrvR0zMjP Qzqk4Mxry82SeGUl4vFCICJL40NYGcmDv0BcbvAU97VsjRfHTDPmOSTCbPMBAuasEsGW XbiC/UjBC/MpEXfMa/Js81EU2DqxVIJnqT74jXKcM7Hc+2CMWBSLfN25U7b6lVYSNCcS BPOQ== X-Gm-Message-State: AElRT7GIdOfxZYXtO+9DNtVsaf3EttS3hqHoYumabC4wRe0JCHKWppYE djHjUYNIkDyrHKMdA0pX/KTwg9KswGFzGIjvXU0= X-Google-Smtp-Source: AIpwx49zVLARE4QW0cte8BXXkozLKfNjU4Mvx4JzDEpSpnsEU7PX3ufKqNG/kDT/jHJAtWnm3hQT3BBYoHxG/O2CQf0= X-Received: by 10.107.28.15 with SMTP id c15mr11803221ioc.247.1522744863878; Tue, 03 Apr 2018 01:41:03 -0700 (PDT) MIME-Version: 1.0 References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> In-Reply-To: From: Marten Seemann Date: Tue, 03 Apr 2018 08:40:53 +0000 Message-ID: Subject: Re: Implicitly opened streams and exposing stream IDs To: Martin Thomson Cc: Lucas Pardue , QUIC WG Content-Type: multipart/alternative; boundary="001a11409812b1f2ac0568edaa2b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 03 Apr 2018 08:41:08 -0000 --001a11409812b1f2ac0568edaa2b Content-Type: text/plain; charset="UTF-8" Hi Martin, I don't think delayed stream usage is a problem here. To be precise, what I mean is not opening the stream (as in actually sending a frame on this stream), but creation of the stream. So all I want is to REQUIRE here is that peers *create* streams in order. There's an important difference in how the receiving peer is allowed to act. Assume for example the receiver wants to grant a higher flow control limit than it advertised during the handshake: - If streams MUST be created in order, the receiver can send a MAX_STREAM_DATA for streams N and N+4 as soon as it receives a frame for N+4. - If streams only SHOULD be created in order, sending a MAX_STREAM_DATA for stream N (after receiving a frame for N+4) will cause a connection error, if the sender decided to skip stream N. I'm not saying that this is an important use case, but this example shows that implementations *only* have the two options for handling out of order streams described in my last email *if* we require in order stream creation. I'd therefore suggest to change the text in the spec to something like this: "Endpoints MUST create the send side of streams for each type in order". Best, Marten On Tue, Apr 3, 2018 at 2:28 PM Martin Thomson wrote: > Requiring in-order opening is harder than it sounds. Say you have a > multithreaded application that is initiating requests. The usual > process is something like: > > s = connection.OpenStream() > s.Write(request.Headers.Encode()) > > That is, there is time between acquisition of the stream and its use. > Do that with enough concurrency and you end up having to add late > binding of stream identifiers to streams, which complicates the design > of the stack considerably. It also complicates usage because now > there is a period where s.Id() returns an undefined result. > > Alternatively, you could track the highest stream ID on which data has > been sent and send an empty, offset 0 STREAM frame rather than create > a gap. > > Or, you could decide that a MUST here is unenforceable (even more so > than the flow control limits one) and just wantonly ignore that > requirement if this race condition happens. While it is in theory > possible to catch someone in a violation, it requires some interesting > conditions (like zero packet loss). > > BTW, I also wish to make it possible to avoid relying on specific > stream IDs for special functions. I hadn't considered opening order > as a way to do that though and had assumed that we'd use an in-stream > header for that. I don't think that makes the complexity worse, or at > least no worse than having to deal with different frame types for > different functions. > > > On Tue, Apr 3, 2018 at 5:10 PM, Marten Seemann > wrote: > > Hello, > > > > Sure, the application could deal with it by starting every stream with > some > > kind of header, to signal what kind of stream type this is. I'm not sure > if > > I like this solution, since it creates additional complexity, and it is > only > > necessary because we removed a useful feature from the spec. > > What did we actually gain from removing implicit stream opening from the > > protocol? As far as I can see, we were able to relax the requirement > > "endpoints MUST open the send side of streams for each type in order" to > > "endpoints SHOULD open the send side of streams for each type in order". > > This might seem nice from a conceptual viewpoint, but honestly, I don't > > really see why anyone would actually want to do this. I think the main > > argument against the MUST was that it's not enforceable anyway, but this > > applies to a lot of other MUSTs in the spec as well (e.g. that flow > control > > limits can't be decreased). > > > > The fix for this is straightforward: We should REQUIRE a peer to open > > streams in order. How the receiver handles out of order streams then is > an > > implementation and API decision. I see two ways that an implementation > could > > reasonably deal with this: > > > > Return streams in the order they are received, e.g. return N+4 before N, > if > > packets are reordered. > > Return streams ordered by stream ID, i.e. return first N and then N+4 if > a > > frame for N+4 is received. > > > > This way, we wouldn't need to reintroduce implicitly opened streams, but > > leave this up to implementations. I should have named this thread > > differently, if only I had realized this earlier ;) > > > > Regards, > > Marten > > > > On Mon, Apr 2, 2018 at 7:05 PM Lucas Pardue > wrote: > >> > >> Hi Marten, > >> > >> Would Stream headers fix this problem? I.e. anything that requires > special > >> behaviour other than "bulk data" has some bytes of of magic at the > start of > >> the stream. > >> > >> Regards > >> Lucas > >> ________________________________________ > >> From: QUIC [quic-bounces@ietf.org] on behalf of Marten Seemann > >> [martenseemann@gmail.com] > >> Sent: 02 April 2018 12:43 > >> To: QUIC WG > >> Subject: Implicitly opened streams and exposing stream IDs > >> > >> Recently, the implicit opening of streams (i.e. that when a receiver > >> receives a frame for stream N+4, it can assume that stream N was already > >> opened, but the packet might have been reordered) was removed from the > >> draft. I think this change has some consequences that we haven't > discussed > >> so far. > >> > >> For the purpose of writing some pseudocode, I'm assuming a QUIC API that > >> provides an AcceptStream() method, but the conclusions will be the same > for > >> a callback-based API. > >> > >> * If QUIC has implicit stream opening, AcceptStream() would return > the > >> streams in order (and if a frame opening stream N+4 is received before > >> stream n is opened, AcceptStream() will first return stream N and then > >> stream N+4). > >> * Without implicit stream opening, AcceptStream() just returns > >> whatever stream is received first. Streams might be returned in > arbitrary > >> order, if the peer doesn't open streams consecutively or if packets are > >> reordered. > >> > >> Now imagine an application protocol where the first unidirectional > stream > >> opened by the client is a control stream, and all higher unidirectional > >> streams are data streams. The application on the server side needs to > find > >> out which stream is the control stream, because it needs to be handled > >> separately. > >> > >> With implicit stream opening, the server code would be: > >> > >> control_stream = AcceptStream() // is guaranteed to open the first > >> stream > >> // handle the control stream > >> while true: > >> stream = AcceptStream() > >> // handle the data stream > >> > >> and without implicit stream opening: > >> > >> while true: > >> stream = AcceptStream() > >> if stream.ID() == kControlStreamID: > >> // handle the control stream > >> else: > >> // handle the data stream > >> > >> In this case, after accepting a stream, we first have to check the > stream > >> ID, since there's no guarantee if the control stream will actually be > >> received first. > >> > >> For this stream mapping, it seems like the removal of implicitly opened > >> streams implies that QUIC has to expose stream IDs to the application > layer. > >> I'm not sure if this was intended when making the change, especially > since > >> we're considering to change HQ such that it doesn't rely on QUIC stream > IDs > >> any more. > >> We only manage to avoid the problem described here in our HTTP mapping, > >> because the HTTP control streams are unidirectional and the request > streams > >> are bidirectional, and can therefore be told apart by their > directionality. > >> However, as a general transport protocol, other applications built on > top of > >> QUIC will have to find some way to deal with it. > >> > >> > >> ----------------------------- > >> http://www.bbc.co.uk > >> This e-mail (and any attachments) is confidential and > >> may contain personal views which are not the views of the BBC unless > >> specifically stated. > >> If you have received it in > >> error, please delete it from your system. > >> Do not use, copy or disclose the > >> information in any way nor act in reliance on it and notify the sender > >> immediately. > >> Please note that the BBC monitors e-mails > >> sent or received. > >> Further communication will signify your consent to > >> this. > >> ----------------------------- > --001a11409812b1f2ac0568edaa2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

I don't think delayed st= ream usage is a problem here. To be precise, what I mean is not opening the= stream (as in actually sending a frame on this stream), but creation of th= e stream. So all I want is to REQUIRE here is that peers=C2=A0create= streams in order.

There's an important differ= ence in how the receiving peer is allowed to act. Assume for example the re= ceiver wants to grant a higher flow control limit than it advertised during= the handshake:
  • If streams MUST be created in order, the = receiver can send a MAX_STREAM_DATA for streams N and N+4 as soon as it rec= eives a frame for N+4.
  • If streams only SHOULD be created in order, = sending a MAX_STREAM_DATA for stream N (after receiving a frame for N+4) wi= ll cause a connection error, if the sender decided to skip stream N.
    • I'm not saying that this is an important use case, but this exa= mple shows that implementations *only* have the two options for handling ou= t of order streams described in my last email *if* we require in order stre= am creation.

    I'd therefore suggest to change t= he text in the spec to something like this: "Endpoints MUST create the= send side of streams for each type in order".

Best,
Marten

On Tue, Apr 3, 2018 at 2:28 PM Martin Thomson <martin.thomson@gmail.com&= gt; wrote:
Requiring in-order openi= ng is harder than it sounds.=C2=A0 Say you have a
multithreaded application that is initiating requests.=C2=A0 The usual
process is something like:

s =3D connection.OpenStream()
s.Write(request.Headers.Encode())

That is, there is time between acquisition of the stream and its use.
Do that with enough concurrency and you end up having to add late
binding of stream identifiers to streams, which complicates the design
of the stack considerably.=C2=A0 It also complicates usage because now
there is a period where s.Id() returns an undefined result.

Alternatively, you could track the highest stream ID on which data has
been sent and send an empty, offset 0 STREAM frame rather than create
a gap.

Or, you could decide that a MUST here is unenforceable (even more so
than the flow control limits one) and just wantonly ignore that
requirement if this race condition happens.=C2=A0 While it is in theory
possible to catch someone in a violation, it requires some interesting
conditions (like zero packet loss).

BTW, I also wish to make it possible to avoid relying on specific
stream IDs for special functions.=C2=A0 I hadn't considered opening ord= er
as a way to do that though and had assumed that we'd use an in-stream header for that.=C2=A0 I don't think that makes the complexity worse, o= r at
least no worse than having to deal with different frame types for
different functions.


On Tue, Apr 3, 2018 at 5:10 PM, Marten Seemann <martenseemann@gmail.com> wrote:=
> Hello,
>
> Sure, the application could deal with it by starting every stream with= some
> kind of header, to signal what kind of stream type this is. I'm no= t sure if
> I like this solution, since it creates additional complexity, and it i= s only
> necessary because we removed a useful feature from the spec.
> What did we actually gain from removing implicit stream opening from t= he
> protocol? As far as I can see, we were able to relax the requirement > "endpoints MUST open the send side of streams for each type in or= der" to
> "endpoints SHOULD open the send side of streams for each type in = order".
> This might seem nice from a conceptual viewpoint, but honestly, I don&= #39;t
> really see why anyone would actually want to do this. I think the main=
> argument against the MUST was that it's not enforceable anyway, bu= t this
> applies to a lot of other MUSTs in the spec as well (e.g. that flow co= ntrol
> limits can't be decreased).
>
> The fix for this is straightforward: We should REQUIRE a peer to open<= br> > streams in order. How the receiver handles out of order streams then i= s an
> implementation and API decision. I see two ways that an implementation= could
> reasonably deal with this:
>
> Return streams in the order they are received, e.g. return N+4 before = N, if
> packets are reordered.
> Return streams ordered by stream ID, i.e. return first N and then N+4 = if a
> frame for N+4 is received.
>
> This way, we wouldn't need to reintroduce implicitly opened stream= s, but
> leave this up to implementations. I should have named this thread
> differently, if only I had realized this earlier ;)
>
> Regards,
> Marten
>
> On Mon, Apr 2, 2018 at 7:05 PM Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:=
>>
>> Hi Marten,
>>
>> Would Stream headers fix this problem? I.e. anything that requires= special
>> behaviour other than "bulk data" has some bytes of of ma= gic at the start of
>> the stream.
>>
>> Regards
>> Lucas
>> ________________________________________
>> From: QUIC [quic-bounces@ietf.org] on behalf of Marten Seemann
>> [mart= enseemann@gmail.com]
>> Sent: 02 April 2018 12:43
>> To: QUIC WG
>> Subject: Implicitly opened streams and exposing stream IDs
>>
>> Recently, the implicit opening of streams (i.e. that when a receiv= er
>> receives a frame for stream N+4, it can assume that stream N was a= lready
>> opened, but the packet might have been reordered) was removed from= the
>> draft. I think this change has some consequences that we haven'= ;t discussed
>> so far.
>>
>> For the purpose of writing some pseudocode, I'm assuming a QUI= C API that
>> provides an AcceptStream() method, but the conclusions will be the= same for
>> a callback-based API.
>>
>>=C2=A0 =C2=A0*=C2=A0 =C2=A0If QUIC has implicit stream opening, Acc= eptStream() would return the
>> streams in order (and if a frame opening stream N+4 is received be= fore
>> stream n is opened, AcceptStream() will first return stream N and = then
>> stream N+4).
>>=C2=A0 =C2=A0*=C2=A0 =C2=A0Without implicit stream opening, AcceptS= tream() just returns
>> whatever stream is received first. Streams might be returned in ar= bitrary
>> order, if the peer doesn't open streams consecutively or if pa= ckets are
>> reordered.
>>
>> Now imagine an application protocol where the first unidirectional= stream
>> opened by the client is a control stream, and all higher unidirect= ional
>> streams are data streams. The application on the server side needs= to find
>> out which stream is the control stream, because it needs to be han= dled
>> separately.
>>
>> With implicit stream opening, the server code would be:
>>
>>=C2=A0 =C2=A0 =C2=A0control_stream =3D AcceptStream() // is guarant= eed to open the first
>> stream
>>=C2=A0 =C2=A0 =C2=A0// handle the control stream
>>=C2=A0 =C2=A0 =C2=A0 while true:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stream =3D AcceptStream()
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // handle the data stream
>>
>> and without implicit stream opening:
>>
>>=C2=A0 =C2=A0 =C2=A0while true:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0stream =3D AcceptStream()
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if stream.ID() =3D=3D kControlStr= eamID:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// handle the contr= ol stream
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// handle the data = stream
>>
>> In this case, after accepting a stream, we first have to check the= stream
>> ID, since there's no guarantee if the control stream will actu= ally be
>> received first.
>>
>> For this stream mapping, it seems like the removal of implicitly o= pened
>> streams implies that QUIC has to expose stream IDs to the applicat= ion layer.
>> I'm not sure if this was intended when making the change, espe= cially since
>> we're considering to change HQ such that it doesn't rely o= n QUIC stream IDs
>> any more.
>> We only manage to avoid the problem described here in our HTTP map= ping,
>> because the HTTP control streams are unidirectional and the reques= t streams
>> are bidirectional, and can therefore be told apart by their direct= ionality.
>> However, as a general transport protocol, other applications built= on top of
>> QUIC will have to find some way to deal with it.
>>
>>
>> -----------------------------
>> http://www.bbc.co.uk
>> This e-mail (and any attachments) is confidential and
>> may contain personal views which are not the views of the BBC unle= ss
>> specifically stated.
>> If you have received it in
>> error, please delete it from your system.
>> Do not use, copy or disclose the
>> information in any way nor act in reliance on it and notify the se= nder
>> immediately.
>> Please note that the BBC monitors e-mails
>> sent or received.
>> Further communication will signify your consent to
>> this.
>> -----------------------------
--001a11409812b1f2ac0568edaa2b-- From nobody Tue Apr 3 02:23:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC0912E856 for ; Tue, 3 Apr 2018 02:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 UxSTWWHlV_Hs for ; Tue, 3 Apr 2018 02:23:43 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE9E12E854 for ; Tue, 3 Apr 2018 02:23:43 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id l190-v6so15338396oig.9 for ; Tue, 03 Apr 2018 02:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5e5aUZJ1JW82rL0/ADiueuC9jcXipnAnqhrwmBfdqfw=; b=mk9gG73lDrfw7i98nxLtuiVpWuj0bXyCcrYWy5v6TZuvQBSspvZcfQZq6psgWRLwl1 gndNHhJF0VruDfMFD0t9OA14K4ZhnRAoBIKQhmi6nOb9l5V9zShwYTCYfL9D+YCqCLbO Q8cuq+K2JOOFUfXqF8GibmBSeExjXNhLLtfW9nIK4cg4pzc+FF8mKxGUhX+gancyCwIW D1xMN/aoyirL7bNq+NNgqU1HaSsAonI+qT3SJr1YbpzgyZl+Kbljnw4XBX66s3A+6twZ o7fTtJvmYotl0Ddrxc9bA/cyWGwZhpVqiBiiyauMosP1JWNu6s32E9HdBCiF7XHkbkLo 11BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=5e5aUZJ1JW82rL0/ADiueuC9jcXipnAnqhrwmBfdqfw=; b=lSJW/U6chVjHvlhO8DlRdliOQJMesFWLGezJXbP9pgVVZBoDReYCpGA2e8RyfPXW6j zeXyMk4y9ueLkGBVMS0UBZGsYyVMhbpo3M+6GN0flmcSxot9VqtQ8co/Au7sL2gwipDg H8HW16/zrhXW8C5oFnu6GJIOdegm43Tlgc2I6VRDs5jDZTe41HZddJflWtqlt+AE83WM N7eLXEcIXjJeMOvIjhCrmNb2st1FhuMhDxsUT30XGwgKEXOvCm+VBZKpQm6HbBGZcYuw UBhnDF5Eot04GQTDFj0FEGwfW9LGiRi2dWxyDorjohSQuW6MD7n/iGApA8GLSk0q5rym 58RA== X-Gm-Message-State: ALQs6tCOD5gICsgLlem+XRNzBtuBfRHg36b0LfSC4Hdv6Iu1lPpflk1F W9/CvR8jg1+z8CzrrF3sC1SH/2C3mwXBqSeuYgc= X-Google-Smtp-Source: AIpwx49LFG5mTELbX5nQp8bnpcGbHRlLYa/f8LT8a5XJqWXSm88v2eR5ZVnRZt7hU2h4Lx1a/IX13V883rs6eaHTBmU= X-Received: by 2002:aca:3857:: with SMTP id f84-v6mr6558138oia.254.1522747422131; Tue, 03 Apr 2018 02:23:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Tue, 3 Apr 2018 02:23:41 -0700 (PDT) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> From: Martin Thomson Date: Tue, 3 Apr 2018 19:23:41 +1000 Message-ID: Subject: Re: Implicitly opened streams and exposing stream IDs To: Marten Seemann Cc: Lucas Pardue , 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, 03 Apr 2018 09:23:46 -0000 Creation isn't an observable action, so we need to use observable actions to drive what the spec says. So that would seem to be equivalent to restoring implicit open in my mind. Which - for the record - I was a proponent of. But you don't need to convince me :) As you say, the observable difference is in whether sending MAX_STREAM_DATA on stream N is permitted once stream N+4 has been opened. (And similar such things.) I found the rather strident arguments in favour of dropping implicit open convincing, in the sense that a strict requirement for in order creation was onerous for those who want to parallelize stream consumption. But it's entirely possible that that could be dealt with by saying that the streams are still created in order, but used out of order. I don't know. Those who argued for a lifting of the requirement should weigh in. On Tue, Apr 3, 2018 at 6:40 PM, Marten Seemann wrote: > Hi Martin, > > I don't think delayed stream usage is a problem here. To be precise, what I > mean is not opening the stream (as in actually sending a frame on this > stream), but creation of the stream. So all I want is to REQUIRE here is > that peers create streams in order. > > There's an important difference in how the receiving peer is allowed to act. > Assume for example the receiver wants to grant a higher flow control limit > than it advertised during the handshake: > > If streams MUST be created in order, the receiver can send a MAX_STREAM_DATA > for streams N and N+4 as soon as it receives a frame for N+4. > If streams only SHOULD be created in order, sending a MAX_STREAM_DATA for > stream N (after receiving a frame for N+4) will cause a connection error, if > the sender decided to skip stream N. > > I'm not saying that this is an important use case, but this example shows > that implementations *only* have the two options for handling out of order > streams described in my last email *if* we require in order stream creation. > > I'd therefore suggest to change the text in the spec to something like this: > "Endpoints MUST create the send side of streams for each type in order". > > Best, > Marten > > On Tue, Apr 3, 2018 at 2:28 PM Martin Thomson > wrote: >> >> Requiring in-order opening is harder than it sounds. Say you have a >> multithreaded application that is initiating requests. The usual >> process is something like: >> >> s = connection.OpenStream() >> s.Write(request.Headers.Encode()) >> >> That is, there is time between acquisition of the stream and its use. >> Do that with enough concurrency and you end up having to add late >> binding of stream identifiers to streams, which complicates the design >> of the stack considerably. It also complicates usage because now >> there is a period where s.Id() returns an undefined result. >> >> Alternatively, you could track the highest stream ID on which data has >> been sent and send an empty, offset 0 STREAM frame rather than create >> a gap. >> >> Or, you could decide that a MUST here is unenforceable (even more so >> than the flow control limits one) and just wantonly ignore that >> requirement if this race condition happens. While it is in theory >> possible to catch someone in a violation, it requires some interesting >> conditions (like zero packet loss). >> >> BTW, I also wish to make it possible to avoid relying on specific >> stream IDs for special functions. I hadn't considered opening order >> as a way to do that though and had assumed that we'd use an in-stream >> header for that. I don't think that makes the complexity worse, or at >> least no worse than having to deal with different frame types for >> different functions. >> >> >> On Tue, Apr 3, 2018 at 5:10 PM, Marten Seemann >> wrote: >> > Hello, >> > >> > Sure, the application could deal with it by starting every stream with >> > some >> > kind of header, to signal what kind of stream type this is. I'm not sure >> > if >> > I like this solution, since it creates additional complexity, and it is >> > only >> > necessary because we removed a useful feature from the spec. >> > What did we actually gain from removing implicit stream opening from the >> > protocol? As far as I can see, we were able to relax the requirement >> > "endpoints MUST open the send side of streams for each type in order" to >> > "endpoints SHOULD open the send side of streams for each type in order". >> > This might seem nice from a conceptual viewpoint, but honestly, I don't >> > really see why anyone would actually want to do this. I think the main >> > argument against the MUST was that it's not enforceable anyway, but this >> > applies to a lot of other MUSTs in the spec as well (e.g. that flow >> > control >> > limits can't be decreased). >> > >> > The fix for this is straightforward: We should REQUIRE a peer to open >> > streams in order. How the receiver handles out of order streams then is >> > an >> > implementation and API decision. I see two ways that an implementation >> > could >> > reasonably deal with this: >> > >> > Return streams in the order they are received, e.g. return N+4 before N, >> > if >> > packets are reordered. >> > Return streams ordered by stream ID, i.e. return first N and then N+4 if >> > a >> > frame for N+4 is received. >> > >> > This way, we wouldn't need to reintroduce implicitly opened streams, but >> > leave this up to implementations. I should have named this thread >> > differently, if only I had realized this earlier ;) >> > >> > Regards, >> > Marten >> > >> > On Mon, Apr 2, 2018 at 7:05 PM Lucas Pardue >> > wrote: >> >> >> >> Hi Marten, >> >> >> >> Would Stream headers fix this problem? I.e. anything that requires >> >> special >> >> behaviour other than "bulk data" has some bytes of of magic at the >> >> start of >> >> the stream. >> >> >> >> Regards >> >> Lucas >> >> ________________________________________ >> >> From: QUIC [quic-bounces@ietf.org] on behalf of Marten Seemann >> >> [martenseemann@gmail.com] >> >> Sent: 02 April 2018 12:43 >> >> To: QUIC WG >> >> Subject: Implicitly opened streams and exposing stream IDs >> >> >> >> Recently, the implicit opening of streams (i.e. that when a receiver >> >> receives a frame for stream N+4, it can assume that stream N was >> >> already >> >> opened, but the packet might have been reordered) was removed from the >> >> draft. I think this change has some consequences that we haven't >> >> discussed >> >> so far. >> >> >> >> For the purpose of writing some pseudocode, I'm assuming a QUIC API >> >> that >> >> provides an AcceptStream() method, but the conclusions will be the same >> >> for >> >> a callback-based API. >> >> >> >> * If QUIC has implicit stream opening, AcceptStream() would return >> >> the >> >> streams in order (and if a frame opening stream N+4 is received before >> >> stream n is opened, AcceptStream() will first return stream N and then >> >> stream N+4). >> >> * Without implicit stream opening, AcceptStream() just returns >> >> whatever stream is received first. Streams might be returned in >> >> arbitrary >> >> order, if the peer doesn't open streams consecutively or if packets are >> >> reordered. >> >> >> >> Now imagine an application protocol where the first unidirectional >> >> stream >> >> opened by the client is a control stream, and all higher unidirectional >> >> streams are data streams. The application on the server side needs to >> >> find >> >> out which stream is the control stream, because it needs to be handled >> >> separately. >> >> >> >> With implicit stream opening, the server code would be: >> >> >> >> control_stream = AcceptStream() // is guaranteed to open the first >> >> stream >> >> // handle the control stream >> >> while true: >> >> stream = AcceptStream() >> >> // handle the data stream >> >> >> >> and without implicit stream opening: >> >> >> >> while true: >> >> stream = AcceptStream() >> >> if stream.ID() == kControlStreamID: >> >> // handle the control stream >> >> else: >> >> // handle the data stream >> >> >> >> In this case, after accepting a stream, we first have to check the >> >> stream >> >> ID, since there's no guarantee if the control stream will actually be >> >> received first. >> >> >> >> For this stream mapping, it seems like the removal of implicitly opened >> >> streams implies that QUIC has to expose stream IDs to the application >> >> layer. >> >> I'm not sure if this was intended when making the change, especially >> >> since >> >> we're considering to change HQ such that it doesn't rely on QUIC stream >> >> IDs >> >> any more. >> >> We only manage to avoid the problem described here in our HTTP mapping, >> >> because the HTTP control streams are unidirectional and the request >> >> streams >> >> are bidirectional, and can therefore be told apart by their >> >> directionality. >> >> However, as a general transport protocol, other applications built on >> >> top of >> >> QUIC will have to find some way to deal with it. >> >> >> >> >> >> ----------------------------- >> >> http://www.bbc.co.uk >> >> This e-mail (and any attachments) is confidential and >> >> may contain personal views which are not the views of the BBC unless >> >> specifically stated. >> >> If you have received it in >> >> error, please delete it from your system. >> >> Do not use, copy or disclose the >> >> information in any way nor act in reliance on it and notify the sender >> >> immediately. >> >> Please note that the BBC monitors e-mails >> >> sent or received. >> >> Further communication will signify your consent to >> >> this. >> >> ----------------------------- From nobody Tue Apr 3 05:07:33 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E0C1250B8 for ; Tue, 3 Apr 2018 05:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRsQumb-4jbl for ; Tue, 3 Apr 2018 05:07:30 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D401204DA for ; Tue, 3 Apr 2018 05:07:30 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id d50so11432792qtc.0 for ; Tue, 03 Apr 2018 05:07:30 -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:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=As9RvhdL9j3Z1/k5xiTugEqGubNAZ6BC92HFq9AYKWY=; b=vlsqV9OBfq1Z4+8WNm749rOKsExPuzNM7NCs3vceI+9Hm2Lh8lBMrvyS7WKZ76wUCJ 22NwXzM0Sw5yjjXY3R9I7NatIL5ZKTsGZ2NxrN9oxysYScRX8a2sIdoqIsebhy9fnAPa UDSaA/D5GymHeLx3gqd3rVrid7wsFVjl6LVgVqHyly7diRMLEuDLQf6AjLfbrYusVwDW wMGyWbqKq4s4dE2B4rrFwHOsigXBcT4NWJQwvvuq+S2ZLNDuIWFKpqZfAf8gTsYkLotg P05JdihsLoEPFhQ29pcLRamkBocggfrARJ9esfUVcC/YdIYUGBPkTkujFjMPrsHPUhXh fCdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=As9RvhdL9j3Z1/k5xiTugEqGubNAZ6BC92HFq9AYKWY=; b=rnIr2fztj39MSQb1IxzpVa9u7jDYFScCuipYTI2iRMupcyd9f6s/4MBHm5Rs82ehlF 996dLOnz7jyeUJEjzW7mEXEhTRfQIpNOg2dg0j09dmXtZ/36GTJfCkLkmCDOh9+6P82y H6X03qboG89kaRqAwt+D4GB+QhFTw1TMkFpmVgw1G9ESEVdS+BZozxdyw0HLGYhvKOZ0 b5wbDvMLH9ExC32VkGwqROqTJLRdfdM8le0lgqebefBqizL/cTpPigILJCDRD90RWLya 4UeZctIWgEsa9n4Z3Ja9E2vl7jLzlNClIl2leTDU4C8+vRNgG6KJ7ZysnzJ2nfGIPaa5 KT7Q== X-Gm-Message-State: ALQs6tDbQTkmboU8VNF+XZ91TVw8Nig5KcPQ0ByBl3vQvZrYCPe1Z2j4 6WH1VB11AOsxnxuJ8G9oYtadsUkr X-Google-Smtp-Source: AIpwx4/qK1vbi7lIh8ACTwgWLL9aBJXbkgfx4WSQBAb6GofXlKKIka4ccj57Y2lvI6k80K8GNxZnDw== X-Received: by 10.200.112.218 with SMTP id g26mr19039287qtp.14.1522757249189; Tue, 03 Apr 2018 05:07:29 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id q25sm1954483qkj.71.2018.04.03.05.07.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 05:07:28 -0700 (PDT) Date: Tue, 3 Apr 2018 08:07:18 -0400 From: Dmitri Tikhonov To: Martin Thomson Cc: Marten Seemann , Lucas Pardue , QUIC WG Subject: Re: Implicitly opened streams and exposing stream IDs Message-ID: <20180403120717.GA1695@ubuntu-dmitri> Mail-Followup-To: Martin Thomson , Marten Seemann , Lucas Pardue , QUIC WG References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> 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, 03 Apr 2018 12:07:32 -0000 On Tue, Apr 03, 2018 at 05:28:21PM +1000, Martin Thomson wrote: > Requiring in-order opening is harder than it sounds. Some more discussion here: https://github.com/quicwg/base-drafts/issues/634 - Dmitri. From nobody Tue Apr 3 06:47:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A54012E8EF for ; Tue, 3 Apr 2018 06:47:41 -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, 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 (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 Nvbcjku3qAF8 for ; Tue, 3 Apr 2018 06:47:38 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0134.outbound.protection.outlook.com [104.47.36.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81DB412DB6E for ; Tue, 3 Apr 2018 06:47:38 -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=ymlhx3ewmrLiv0aEkjgn2PA+W3kKzl9r33OseJE7UFs=; b=GejB9aeme1xUWW2VFU35+Z4R1jTZ1VnucKW4l0AZpUl0+ofRoa/JmgbRPZuTCQmeGeCJ2ApyG7vrzL/GpOroXP8bVMXCNbD+5jaPH29Z4hp30h8oPA2TZMl6ZpPaGw2ru6iR0pFIhdCYOBVyh/uEUreiHHP/Jgordk4lCLcJ7n4= Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB1111.namprd21.prod.outlook.com (52.132.132.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Tue, 3 Apr 2018 13:47:36 +0000 Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::49f0:9e08:d65d:b0dc]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::49f0:9e08:d65d:b0dc%4]) with mapi id 15.20.0675.003; Tue, 3 Apr 2018 13:47:36 +0000 From: Nick Banks To: Dmitri Tikhonov , Martin Thomson CC: Marten Seemann , Lucas Pardue , QUIC WG Subject: RE: Implicitly opened streams and exposing stream IDs Thread-Topic: Implicitly opened streams and exposing stream IDs Thread-Index: AQHTynfdCfLv9t0HXUmEre41VboPZqPtYPOAgAE/04CAAAT5gIAATfAAgAAY1BA= Date: Tue, 3 Apr 2018 13:47:36 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> <20180403120717.GA1695@ubuntu-dmitri> In-Reply-To: <20180403120717.GA1695@ubuntu-dmitri> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-04-03T13:47:35.1435228Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:c::83] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB1111; 7:hLSVr5jiugN/vx40qi9TbBR16UQBNOwPiWQsHbGOvjIJDDPJTQzsS5n8gw9Oz5Yv1MJ/MG4FKPOPexOdRcEcZ/ophj8HS7hOuGfGkZtb+cXSGvDTigxdugM9wcA4xf2CyUG5S9ePwIxSWo5B807f7isbXCEJLQ7fIOQy1jUqOH93gFSblRJ4Brq7cBiKkvvZNXZJsBdIgzPDcum681gO4k5FDzMuJb8HYnWzXW2JNHmgVbP2njp/TERXCTJk7UtD; 20:zXHNP90GVI0duOI8jeSg8zgJg5d0la0M5FI9eIKcxO4tjF+tGWAJQaxB0DaMEJcqmBEyN/esC/q4XhGVUQT0lT0baaFiWWuhBVeBf+vt63erqLt7AmTTYlTmkftsLn2TV9uU/HCostpH62+A+HhYgJGmyppZDZ32jNjvaYmeFAA= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 614654de-bd4d-439b-8a54-08d5996975ba x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR2101MB1111; x-ms-traffictypediagnostic: DM5PR2101MB1111: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(85827821059158)(219752817060721)(127952516941037); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR2101MB1111; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB1111; x-forefront-prvs: 0631F0BC3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(39860400002)(346002)(366004)(376002)(13464003)(199004)(189003)(4326008)(6306002)(86362001)(25786009)(46003)(6436002)(33656002)(305945005)(6246003)(966005)(3280700002)(11346002)(14454004)(486005)(7736002)(486005)(68736007)(53936002)(476003)(86612001)(9686003)(106356001)(2906002)(74316002)(105586002)(446003)(99286004)(3660700001)(478600001)(55016002)(93886005)(81156014)(8676002)(6506007)(97736004)(8936002)(5250100002)(81166006)(53546011)(110136005)(54906003)(102836004)(10090500001)(5660300001)(76176011)(22452003)(316002)(6116002)(59450400001)(7696005)(39060400002)(8990500004)(2900100001)(186003)(229853002)(10290500003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1111; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Tm4UKrE4/tWmNhjJS61BwRQ4vmo9BKZqKtxc7XdDm9gGpJPq7tccEG00shjCdggNxigsTqcMYWM57srIF2G1Th4euDFz6sQfVT5a4p29+9bOKDWv1rQcnvVFahMPkvWFOBWTVi2xaqOG5puzU3aRlJ8Maxa/P3n+n3D9IlSD32OVmODq6jYAhzVRNsKZid2HrMrxLs1pKrn3p63fJD/BgHjju19f6ajzzRr9+v3ZfqsouLjp/aSIlfW1i/ifjPrC3CoBzFydE9GBROxdyY8YI+gFiu6k9Ty2Pbemft8JMDLGaeLcGpnws1+jnnk2WcMBC95roB7+GtKpp2oTNvYTLjhzCr0ppwZJAXMsIiokQJplM9rlTJY+aIa3qdRMGTv0Ej1qzFfdwhw69SstkBtZjIDZHTpxTnpImcei0N7ZeAw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 614654de-bd4d-439b-8a54-08d5996975ba X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2018 13:47:36.7627 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1111 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 03 Apr 2018 13:47:41 -0000 +1 for keeping the implicit opening of streams. It does greatly simplify the tracking of idle/opened/closed streams. Also I= agree that it simplifies the application layer (IMO), for things like HTTP= control stream(s). If all streams are just opened in order, then the appli= cation layer really doesn't need (though it can, if it wants to link inform= ation across streams) to care about stream ID at all. The only down side to= me about implicit stream opening is the attack surface. It only takes a fe= w bytes in a single packet from the peer to open all streams you allotted f= or them. But I still don't feel that is that big of a deal. Just don't allo= t for streams for the peer that you are willing to maintain at one time. To Martin's comment of "creation isn't an observable action" why do you say= that? I can't find the PR right now, but I thought there was a PR recently= that allows for sending the initial STREAM frame with offset=3D0 and lengt= h=3D0. That seems to be a way to directly indicate stream opening, and in m= y mind, make it an observable action. Thanks, - Nick -----Original Message----- From: QUIC On Behalf Of Dmitri Tikhonov Sent: Tuesday, April 3, 2018 5:07 AM To: Martin Thomson Cc: Marten Seemann ; Lucas Pardue ; QUIC WG Subject: Re: Implicitly opened streams and exposing stream IDs On Tue, Apr 03, 2018 at 05:28:21PM +1000, Martin Thomson wrote: > Requiring in-order opening is harder than it sounds. Some more discussion here: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub= .com%2Fquicwg%2Fbase-drafts%2Fissues%2F634&data=3D02%7C01%7Cnibanks%40micro= soft.com%7C8d1fc56b3fba4a97335308d5995b7d97%7C72f988bf86f141af91ab2d7cd011d= b47%7C1%7C0%7C636583540596473225&sdata=3D0b6u8%2FntdWlkQInAefy0%2BYOaLH3%2B= nEGmmUmVZ%2BjtmSo%3D&reserved=3D0 - Dmitri. From nobody Tue Apr 3 06:56:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1ACD1271DF for ; Tue, 3 Apr 2018 06:56:50 -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 Zc8iB72T3DwB for ; Tue, 3 Apr 2018 06:56:49 -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 7945012E8D9 for ; Tue, 3 Apr 2018 06:56:48 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id w12so19247249qti.4 for ; Tue, 03 Apr 2018 06:56:48 -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:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0FP001h43gFjHxtCr4Xt7qOVDlI+9A5Nlv+wRcKBYjM=; b=WRhSVDVMPdunNyrMjFOpzBOK2uK+HIeGQ7CWLcZx52HbSVv9RxKtBr2wly12FbBDtG JqwQji78YkupL8jWIaT4H7dk6MzyBpFEK5pu6jtveYIveuZPwutLbVRR9L76Yfo0HfUd 9cUkNcPv1/xL63OHt3iKnZltU1rHTkZy84FezsU4r83QILVnMTKWJ3nvOGKkIfegvTOJ 1o41jFU3H1hGFbhbR1qMZjQNRxuM3T/AiJtzcDS1W86UqtJT0pC4U1xHh8vJ0rxv4COt q23AMJyKxLB67I3B5j1tqgDVWBlWK5VEJtV6IwOAL4lQXVuTWxNm4Mdk4jMui/X8pq0E O6YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=0FP001h43gFjHxtCr4Xt7qOVDlI+9A5Nlv+wRcKBYjM=; b=eOCu0W+Kg4QCTCx0znkRdyPfUJoR6bz3PUWvgJb+TI9yYzmLlkBAG59RrRDS/j1fhh bLCsoo8FMtqQsfCT9/JVjUtk8cE5nqVQU5YcPJK79HMG9j6HHc9pIAVlppXKJL1Hhom2 5TBBwyiLTGdNiPxi17hKV1Xk0tfQ/Sj8V8BGov5mIC7olMsgE5UVWq4VrR6sXzMVvaUU Y/fxvarwW5Rqw/BaTRN06LIL5DjNHlRuc8GhjmDciNmlc4WPboGlKNjlrs0iR2Kp2seE 5miEbN097Js75Rwr6TBYdSaauslxR0/QvbAoTcsTyPEgdMhVH3xpBlmlumv81aLMrXzF a1yw== X-Gm-Message-State: ALQs6tBWcNx8EqNXRrZJrrEp4UdjzjDPZqeimPS1Y8kkGKI5UAzmmIOP HJZBcshhwo3f0rvq6xN1vKwMrg== X-Google-Smtp-Source: AIpwx48taPihLtfq+HgSrEUparUZzIu7PAzZyTrYrvnKsfLEQI5gZ7HlfNU7sVNYV1zIxdkrUnHt/A== X-Received: by 10.200.48.135 with SMTP id v7mr20305860qta.296.1522763807612; Tue, 03 Apr 2018 06:56:47 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id z24sm2442217qtz.66.2018.04.03.06.56.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 06:56:47 -0700 (PDT) Date: Tue, 3 Apr 2018 09:56:45 -0400 From: Dmitri Tikhonov To: Nick Banks Cc: Martin Thomson , Marten Seemann , Lucas Pardue , QUIC WG Subject: Re: Implicitly opened streams and exposing stream IDs Message-ID: <20180403135644.GC1695@ubuntu-dmitri> Mail-Followup-To: Nick Banks , Martin Thomson , Marten Seemann , Lucas Pardue , QUIC WG References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> <20180403120717.GA1695@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, 03 Apr 2018 13:56:51 -0000 On Tue, Apr 03, 2018 at 01:47:36PM +0000, Nick Banks wrote: > +1 for keeping the implicit opening of streams. > > It does greatly simplify the tracking of idle/opened/closed streams. I don't see how this is a simplification. You will need a "set" data structure of some sort in both cases: A. Implicit opening. Opened streams can be tracked with a single number -- *but* closed streams need to be tracked one by one (using a set or a hash). B. Explicit opening. Opened streams are tracked using a hash. One can argue that (B) is actually simpler. - Dmitri. From nobody Tue Apr 3 07:00:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF53612E9D9 for ; Tue, 3 Apr 2018 07:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMZZDc1Rj8xw for ; Tue, 3 Apr 2018 07:00:12 -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 47CDC12DA4A for ; Tue, 3 Apr 2018 07:00:12 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id g7so6466600qkm.1 for ; Tue, 03 Apr 2018 07:00: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:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=H1c9sU2oqh2gs6emfu1TFsOw7iCSALWzchYaV9Bx2nE=; b=rgKAfro4LP/E5+OvmbmTMVICr+kfyszX9WH4utIKSccPn0KQ8d5fZfZ0jZ+GCMEkQp kKjBwkGzPU+IBzzaZDAEr7anDOgA/4s58yaiVYwc6Vzs6Z10owql/SFAMZneFbNZyWTd Fe35R7kZtUtIenT1CSLtTMDSj9lCUMLDSrbo+JO097PPKvrksCaxivVzm3SFo7ASoHyi KJG9SFLmgt7tufKC2l63sQK364/PJVLnAkXFE2wGpQLJT13SYEgEp3cILaLRZmAQnctH G8iXlwbFJBEV55b1xs2cYzzUQfIsEJLQzK2IKgDGbJZMrYCcbD70vVRK4IG8/77qWIKm nR6w== 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:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=H1c9sU2oqh2gs6emfu1TFsOw7iCSALWzchYaV9Bx2nE=; b=B35p1599aK224VbYLNTol6eCk+hBaNI2QU5iIYzLETlMQiYpXk51pKpzseYT9kjCZG BSLnzohLpensHZtWIwosJaUZ1YZahku3+DKDDxuV6MBhagYRI+7VgY7PXxTg+1dgKX2i evAkohqk7ourKDgNa/+GLf1hUYQcrzAmlr49vBQ2D7jyGAbAUawmzVBln42sXfSCsXOr ZTDZy0h2ERakMdTO64LiKwdSRMlNcgZuWQcXmuwDgJLMO0QeUPVXABdNpIL65zD8b2/n /oZn6EEkkD2gf+fC7E8VgucoTFPy2qFpd71KH/fubpzBdfK+QGtuJ7zja+apCD3ajao3 p/fQ== X-Gm-Message-State: ALQs6tCAHs0Ew2hVNzY84cYP+XJURkpwXBEFDTWNv8gLjSiQTx8l9rfZ 8zNtQGjOAtPP1HbPGrrR2RlFmxWs X-Google-Smtp-Source: AIpwx49O2FBdpJ+qX1lL2bwYV4EFn4ugOXRR+4Ms1GayAVR6y6AxAT6H7VTro+sY2Pykbw2jaUi5+w== X-Received: by 10.55.103.4 with SMTP id b4mr18446252qkc.138.1522764011457; Tue, 03 Apr 2018 07:00:11 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id d199sm2041456qke.90.2018.04.03.07.00.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 07:00:11 -0700 (PDT) Date: Tue, 3 Apr 2018 10:00:09 -0400 From: Dmitri Tikhonov To: Marten Seemann , QUIC WG Subject: Re: Implicitly opened streams and exposing stream IDs Message-ID: <20180403140009.GD1695@ubuntu-dmitri> Mail-Followup-To: Marten Seemann , QUIC WG References: <20180402174810.GA2015@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180402174810.GA2015@ubuntu-dmitri> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 14:00:14 -0000 I feel I am in some sort of discussion hole -- where was it first discussed to get rid of relying on Stream IDs in the application layer? I'd like to get some background. -Dmitri. On Mon, Apr 02, 2018 at 01:48:10PM -0400, Dmitri Tikhonov wrote: > On Mon, Apr 02, 2018 at 11:43:23AM +0000, Marten Seemann wrote: > > In this case, after accepting a stream, we first have to check the stream > > ID, since there's no guarantee if the control stream will actually be > > received first. > > > > For this stream mapping, it seems like the removal of implicitly opened > > streams implies that QUIC has to expose stream IDs to the application > > layer. > > I don't see a problem with that -- HTTP is the application layer, and > the draft specifies that streams 2 and 3 are the control streams. > > > I'm not sure if this was intended when making the change, especially > > since we're considering to change HQ such that it doesn't rely on QUIC > > stream IDs any more. > > Are you referring to a specific pull request or an issue on GitHub? > (I must have missed it.) > > - Dmitri. From nobody Tue Apr 3 07:02:35 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A4112DA4A for ; Tue, 3 Apr 2018 07:02:33 -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, 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 (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 3c4TeerKhvws for ; Tue, 3 Apr 2018 07:02:30 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B8F1201F8 for ; Tue, 3 Apr 2018 07:02:30 -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=5pzy4hPmTU3kqv9/4Wd9RtvAi+va4QWDInCbcLTrSUE=; b=FdIyxQtJ/HRQbWJw7SZqXXrc/P7QY2QRaAy3jXEmA/i8aVBWmEBF3eUTs2zfFNgP3sONubAIE0woh0xzm7YsD8ihEUC8ucSxjAGksCosDV1imGX0WnmupCANfkhJ61PQcV9bSQrq+xwtX0ndBiqbU9bZgFfdUYq/IdgBxGF7B/M= Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB0918.namprd21.prod.outlook.com (52.132.132.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Tue, 3 Apr 2018 14:02:28 +0000 Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::49f0:9e08:d65d:b0dc]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::49f0:9e08:d65d:b0dc%4]) with mapi id 15.20.0675.003; Tue, 3 Apr 2018 14:02:28 +0000 From: Nick Banks To: Dmitri Tikhonov CC: Martin Thomson , Marten Seemann , Lucas Pardue , QUIC WG Subject: RE: Implicitly opened streams and exposing stream IDs Thread-Topic: Implicitly opened streams and exposing stream IDs Thread-Index: AQHTynfdCfLv9t0HXUmEre41VboPZqPtYPOAgAE/04CAAAT5gIAATfAAgAAY1BCAAAXBgIAAAVeA Date: Tue, 3 Apr 2018 14:02:28 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> <20180403120717.GA1695@ubuntu-dmitri> <20180403135644.GC1695@ubuntu-dmitri> In-Reply-To: <20180403135644.GC1695@ubuntu-dmitri> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-04-03T14:02:27.1274377Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:c::83] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0918; 7:CSfzysndz7nmmBa8oU2FH3m3aIU0jmXKIoRZTcSQ07GLFQxwWJ70VwQEpwLrS9zUCRsODzjp1KgF0y7gs4Kjf4re90NwKpvOSG+weZWYr9OEXUFNWDPc8u//0SYHjAP2Kwg/ARob5eQxWFRz8+PVY0sdmSj3FVQ/aGsgeU2kAyKkFL6dh4E/aEFH+ZmFociwrVAmxhkurNl3LSZF293+fSORGk/+0M5TtzSSdiaBYz9Id2UR3SpqxjAt472oBSn3; 20:hFkMgwLaJCsTclaGJTJEKdIbvvGrUT+ELISLhvQVCxQrsMjyDE2TvLpIQKeiU3bQwerikQb7dvf0i6FvJ5S7w7drsGPZmnWrrmBvpoYlVigXLVJSrWS1kSR4bsPVuh37K0X5UnPpG0Hh84Rw/3WwlnwjKIee/DN2j0vTsz8uf8c= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f4d03e53-a41a-4466-0442-08d5996b895c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR2101MB0918; x-ms-traffictypediagnostic: DM5PR2101MB0918: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(127952516941037); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR2101MB0918; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0918; x-forefront-prvs: 0631F0BC3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(346002)(39380400002)(39860400002)(189003)(199004)(13464003)(10090500001)(2900100001)(3660700001)(81156014)(25786009)(6506007)(7736002)(486005)(8936002)(53546011)(186003)(10290500003)(3280700002)(6916009)(486005)(476003)(6246003)(106356001)(93886005)(53936002)(46003)(86362001)(81166006)(86612001)(2906002)(8990500004)(14454004)(105586002)(54906003)(478600001)(6116002)(7696005)(76176011)(11346002)(102836004)(33656002)(316002)(9686003)(39060400002)(99286004)(4326008)(55016002)(305945005)(229853002)(6436002)(446003)(5660300001)(68736007)(5250100002)(97736004)(22452003)(74316002)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0918; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: HHMMP+AQK9XamyqdsmPTlHWBT1w6ILDg58TwBKq0sR0eLnNLQuG04OjKukgEQLn6mEcN1wtupU8LjV4mCWUGZzn/Ay/5h0mUq5h/pp7EZ1qfEFedxq6OAswZRydyWrIOEdSYyCuBBFjJeW5Qhhejay0vZxzHJ0wbbeZ954tAhiHM5yMui5E2VCYM28yj87lm7T2hj102HrafwwavM7rpNp+raNdZrl9OOpTKXaIna9I2XNCmVbyLz836U/ymcgfIpTlVvDdhw4Vagl0XZ3/svg4F0d6b1DtjC+2lpJGw5H54xFfV/rpTUt4k9eT/3JsRzER9QNU7dGfCvCB0YN50e5bXx5DGRv5EPXtSBt07zdrVjZmMgdpD96vx0RLX/NbjKHPQ3fw+I0XmSKqy0lc9V7SB9uecl9lYLcOTl2tVX3M= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f4d03e53-a41a-4466-0442-08d5996b895c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2018 14:02:28.6801 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0918 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 03 Apr 2018 14:02:33 -0000 For implicit opening, you only need to track the following, and you know th= e state of all stream IDs: - Set of all currently opened stream objects - Largest stream ID ever opened For explicit opening, since the streams below the largest stream ID ever op= ened, may never have been opened, you need to additionally track the stream= IDs that have been closed (or inversely the set of stream IDs that have ev= er been opened). - Nick -----Original Message----- From: Dmitri Tikhonov =20 Sent: Tuesday, April 3, 2018 6:57 AM To: Nick Banks Cc: Martin Thomson ; Marten Seemann ; Lucas Pardue ; QUIC WG Subject: Re: Implicitly opened streams and exposing stream IDs On Tue, Apr 03, 2018 at 01:47:36PM +0000, Nick Banks wrote: > +1 for keeping the implicit opening of streams. >=20 > It does greatly simplify the tracking of idle/opened/closed streams. I don't see how this is a simplification. You will need a "set" data struc= ture of some sort in both cases: A. Implicit opening. Opened streams can be tracked with a single number -- *but* closed streams need to be tracked one by one (using a set or a hash). B. Explicit opening. Opened streams are tracked using a hash. One can argue that (B) is actually simpler. - Dmitri. From nobody Tue Apr 3 07:05:09 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A439E128961 for ; Tue, 3 Apr 2018 07:05:07 -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, 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 (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 vOgc9bzJEx_1 for ; Tue, 3 Apr 2018 07:05:05 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0095.outbound.protection.outlook.com [104.47.34.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB23124D37 for ; Tue, 3 Apr 2018 07:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xfsI628x/D9GS6uT7MN1QznCX0BPV6evAbNtJLyl23E=; b=oVHnG27z071M6Tji8hPgG5UtLnHDn6h5VzVupbLEFQDt3Hah+S3fmWS/j1ojWSb5CX3NwJkOyq+xXHMBd+iXWgh0S/zPFPaBHgoutYDxNhhTyC6jOWx0R0FsNpwjp3xlPVL73s6yRr0sh5x4/9s7PwCS09SuH2+XSENMANHdLoc= Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB1048.namprd21.prod.outlook.com (52.132.128.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Tue, 3 Apr 2018 14:05:04 +0000 Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::49f0:9e08:d65d:b0dc]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::49f0:9e08:d65d:b0dc%4]) with mapi id 15.20.0675.003; Tue, 3 Apr 2018 14:05:04 +0000 From: Nick Banks To: Dmitri Tikhonov , Marten Seemann , QUIC WG Subject: RE: Implicitly opened streams and exposing stream IDs Thread-Topic: Implicitly opened streams and exposing stream IDs Thread-Index: AQHTynfdCfLv9t0HXUmEre41VboPZqPtwJiAgAFSn4CAAADB4A== Date: Tue, 3 Apr 2018 14:05:04 +0000 Message-ID: References: <20180402174810.GA2015@ubuntu-dmitri> <20180403140009.GD1695@ubuntu-dmitri> In-Reply-To: <20180403140009.GD1695@ubuntu-dmitri> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-04-03T14:05:03.1692713Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:c::83] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB1048; 7:EqGTEqbcJVxRs8NxjsP5tb6IfD46zw7j0B7r8aJdF19yPrtk+Fah/gHK3B6G8wRk9w7G0Zu8D/t0o08EKyb3HeiUBPdVJve+ko81R8VHfvD5UY8HJisPl1kFOXw1QJKZeWgAHkbEWpUjHAWJlg65uEmb2NLSlIKLE0QllCi6z7BOGwaiBooInp+Q8Oqq7rIRpgyHYOG8StmTAf20j5h64kWiyrVrQf1OLflZ65VGaFv0+1Zw6Pymxf7njv3JLotA; 20:QNBJKYG4nanMUmeWY7vZa9LeKzquynMA+/26WbUPUsn3+8g7hAG0DpUibmBpMq/ckuXnI+SjYceKK/pj1lNcjQKCilGwnjv2pG436TpKiYtPbJKtFy1r19v/BQRMizPjHe812GJBoAd3LENRm7oHlNRCOxveeXouQuXFhUoTCNc= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 36dfc382-175f-4634-bd4d-08d5996be647 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR2101MB1048; x-ms-traffictypediagnostic: DM5PR2101MB1048: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231221)(944501327)(52105095)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR2101MB1048; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB1048; x-forefront-prvs: 0631F0BC3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(346002)(396003)(39380400002)(189003)(199004)(13464003)(22452003)(105586002)(3660700001)(316002)(86362001)(33656002)(74316002)(97736004)(305945005)(25786009)(110136005)(478600001)(7736002)(14454004)(10290500003)(8990500004)(10090500001)(86612001)(229853002)(55016002)(186003)(6436002)(8936002)(46003)(486005)(486005)(2906002)(11346002)(2900100001)(106356001)(53936002)(9686003)(5660300001)(68736007)(476003)(8676002)(446003)(76176011)(99286004)(81166006)(39060400002)(5250100002)(6116002)(3280700002)(6506007)(53546011)(6246003)(102836004)(7696005)(81156014)(59450400001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1048; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: GOxt0KmjpPcEJoCEq97CBv/S9MnPP3dm2OuoDQvqwQDPcRjlXgyEq6bpFgwJ8xR5fgGzr4DrBEPClf9RUuEkyXPlYFwP4MAdW22JCOfd00SohR95lUgSSCOpoU+35VbPzFT9rX3dJk/kFIICZUq2Zc1vFbxPLFdcxT4m1oS6hRCSQ0TgY6ZeHjh2LK/TCbEK3Y2nLJWUbhCkrS1h1Gx+qZy/GN8BXHjnnvFo3ltgvzHqpYSAahoyLA0KDY+NHLdoZdrcUCE5wkDx+gGsNbzgjRLFrNnABxrQR4vE3tFAMLYGMo1qp94wXWKTOqCsF65mKTELo2MAHgOzb9sOcVTUo1suhoFtpqsMrjEBCyPm9u3vyOHeVwT76Iuyt5u0I0NXTc1jeTyUjoaoaE/q6YeIQDtesfTqjMD3IX5nxVoxUiA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 36dfc382-175f-4634-bd4d-08d5996be647 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2018 14:05:04.5653 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1048 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 03 Apr 2018 14:05:08 -0000 As to requiring the application rely on stream IDs, I was referring to Mart= en's first email that started this thread: " For this stream mapping, it seems like the removal of implicitly opened s= treams implies that QUIC has to expose stream IDs to the application layer.= I'm not sure if this was intended when making the change, especially since= we're considering to change HQ such that it doesn't rely on QUIC stream ID= s any more." I agree with this statement. For application protocols where they specific = the "first stream" as the control stream, if you guarantee the first stream= the application layer gets is always the first ordered stream, by ID, then= they don't need to know the ID. Otherwise, then need to get the stream's I= D to do the enforcement themselves. - Nick -----Original Message----- From: QUIC On Behalf Of Dmitri Tikhonov Sent: Tuesday, April 3, 2018 7:00 AM To: Marten Seemann ; QUIC WG Subject: Re: Implicitly opened streams and exposing stream IDs I feel I am in some sort of discussion hole -- where was it first discussed= to get rid of relying on Stream IDs in the application layer? I'd like to= get some background. -Dmitri. On Mon, Apr 02, 2018 at 01:48:10PM -0400, Dmitri Tikhonov wrote: > On Mon, Apr 02, 2018 at 11:43:23AM +0000, Marten Seemann wrote: > > In this case, after accepting a stream, we first have to check the=20 > > stream ID, since there's no guarantee if the control stream will=20 > > actually be received first. > >=20 > > For this stream mapping, it seems like the removal of implicitly=20 > > opened streams implies that QUIC has to expose stream IDs to the=20 > > application layer. >=20 > I don't see a problem with that -- HTTP is the application layer, and=20 > the draft specifies that streams 2 and 3 are the control streams. >=20 > > I'm not sure if this was intended when making the change, especially=20 > > since we're considering to change HQ such that it doesn't rely on=20 > > QUIC stream IDs any more. >=20 > Are you referring to a specific pull request or an issue on GitHub? > (I must have missed it.) >=20 > - Dmitri. From nobody Tue Apr 3 07:07:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4C212E9DA for ; Tue, 3 Apr 2018 07:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 be3My8e4vsHm for ; Tue, 3 Apr 2018 07:07:17 -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 C9ABF12E891 for ; Tue, 3 Apr 2018 07:07:16 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id w23so11186087qtn.3 for ; Tue, 03 Apr 2018 07:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=gibfM8/71Z6QK+IZo7l1eTi19RDfktXeo9+SZkemhcU=; b=ZBj75tSQYro3JrIju9IcrBMpyj/V+06BZRqlPvFdHSotG+uDopHKGnTdT7wznl6NIj RqpRLpuBI/tR/eR230fRSUTcOspCiAV/wb62sm3luHfthQIRvBI64G0V7A25jssiKI1D WbzfhzUOrZQuxdwe2LFLgL2TxhS00WSMM8hX/lQ2NRsCe2DiiRC5NLpQZK50bClYt5f7 Y1mPAJbE5yzP6YdXssNGoxxDqcaosQ6e4US9Dpse2zi+FaQDitUBAE/CtTlvBHW9GnbD DU38RJUi6Xjuy+Ks8NV/geDD1wwgTSb1O/s2kfmYupnXq3D+f3CCfw7PClnEn8V0S5aa hwcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=gibfM8/71Z6QK+IZo7l1eTi19RDfktXeo9+SZkemhcU=; b=LLByrRM5azjLdmO3VCn1iOt3ja0c5hMXWsuGkEVdiGPxuZJqDLU0YP2XeeOPgwPjIg EUx26KzCO2v8AZuaNCdxARCtsUO7iaHvOoh/SJxcTv24HL2Nr+GJM3YoaB7FbRCCk3oo mrs4OpmZ6e0nEUOfipJgsTr7s203cI9bicTe1GDlKR92aCdmQdPpOjoJNJEoVo582IMp 6qqRhqJeJyYBdMnYlFm4w4x2ArFmpN/1VAHl97qj5a8ER83KsgXig4rvZ7H3mM9RG3+m RNB8T0estpk1U87Wa3NcbFlZ8s1txEi74mRoJrKmksGLdPgCt5XUqFSzGD/XWTVCZSNg sT1g== X-Gm-Message-State: ALQs6tDx3ZM0i2UB2MEn1E6mOLVk2VI5aMrH2/vL4z5EO+9qOqS+li0u W819BlirXepL86kueINzwqOlPA== X-Google-Smtp-Source: AIpwx486CPSZm/6CPzaO3+s9SnBZ9V3YByfoNJ90aCgT31SVI9VEISrIFn/8YYlgbfygDS0Ji83uVQ== X-Received: by 10.237.41.194 with SMTP id o60mr20165117qtd.197.1522764435769; Tue, 03 Apr 2018 07:07:15 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id h11sm1511968qtp.38.2018.04.03.07.07.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 07:07:15 -0700 (PDT) Date: Tue, 3 Apr 2018 10:07:13 -0400 From: Dmitri Tikhonov To: Nick Banks Cc: Martin Thomson , Marten Seemann , Lucas Pardue , QUIC WG Subject: Re: Implicitly opened streams and exposing stream IDs Message-ID: <20180403140712.GE1695@ubuntu-dmitri> Mail-Followup-To: Nick Banks , Martin Thomson , Marten Seemann , Lucas Pardue , QUIC WG References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> <20180403120717.GA1695@ubuntu-dmitri> <20180403135644.GC1695@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, 03 Apr 2018 14:07:19 -0000 On Tue, Apr 03, 2018 at 02:02:28PM +0000, Nick Banks wrote: > For implicit opening, you only need to track the following, and you > know the state of all stream IDs: > > - Set of all currently opened stream objects > - Largest stream ID ever opened > > For explicit opening, since the streams below the largest stream ID > ever opened, may never have been opened, you need to additionally > track the stream IDs that have been closed (or inversely the set of > stream IDs that have ever been opened). Ah yes, that's true -- I remember adding this code now. The tracking is simpler with implicit stream opening. - Dmitri. From nobody Tue Apr 3 07:22:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0381277BB for ; Tue, 3 Apr 2018 07:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3s_S_ET4nu1 for ; Tue, 3 Apr 2018 07:22:24 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9589B124D68 for ; Tue, 3 Apr 2018 07:22:24 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id o205so18768192qke.3 for ; Tue, 03 Apr 2018 07:22: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:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=JBXEoQeKHKGcO8BnZTPgz2OcatpeoJ5iAtkT/8uMSro=; b=J//CP5r1pysn4Pb6+aQzrSijPT6sG4QO0oLudMPwfGuIwC8HYaW6pdsdydCEqHkYrL KG/9JlJl+4MRfspwPY3mcbMHst+6BUowWkwbalHDZ+lkYoJ9mndVoF0h0gYOGNlB3OUS FKZByTK05rrJm4ib5nyXXhNE4u8I25WRvuTOTP2BACQ206fmSzSQGwDsXT5GI12zGUXx 9Isunhk1WHHjPO41moAZoHTVB7CzeDFUmR6Fjp8NQsVgbLOSn9+3aXUSeK5kgSGkDwIW drrAWbeEb0Snu1gai1yjN6Ho9bxOgyTTyizVeToTe4iSW0rXlDDhOk2gL0tR90Lwgjhd ujNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=JBXEoQeKHKGcO8BnZTPgz2OcatpeoJ5iAtkT/8uMSro=; b=AVddXwG5FsI30g/Xu6Mm5BiJqWmUlIV3btm/Jc7KqDvU6dsMevMOIMB2SVrhQizm8y 9W78RA5kJNXAXtqgNYvzPO0dsGLTtAStwBPT5iketd6ws6NiSUQcaABSA8M5cShdyWpp lFjAA7xnfD5Wv5ewp2zkESBsfIQ4aFjcAoFTx1bHT6b9OjTYOb9zTFkR8sZzkQELov5V hoF9Kr4204GF4yrSqKmBi9y/KPGHe6H4q908VBCCUtJhIIo4GYQsX5zkgS+v8X1Dim3u 7ut3+urd3Lc/E0ulTlkpLZpE8HX0GjH1n4fDWgJv+mZ9KhBPHvstw4FPe8Nq1CbanWRH TWaA== X-Gm-Message-State: ALQs6tBHFVGcg5wWvWhl7VxwB0gse/vOq61jZRqgdpeD2Sm4lPck5dUe GaeC84Et2BD6kFNSpVu8kovtDg== X-Google-Smtp-Source: AIpwx493uGk0/1YY2JE363LyIWOYqSIcPOF7JqaZOpYGTw5eBh8G1BFU+23K2UYw/vcqZn8+TTDw4A== X-Received: by 10.55.82.9 with SMTP id g9mr19236297qkb.313.1522765343727; Tue, 03 Apr 2018 07:22:23 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id 12sm2067222qkf.64.2018.04.03.07.22.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 07:22:23 -0700 (PDT) Date: Tue, 3 Apr 2018 10:22:21 -0400 From: Dmitri Tikhonov To: Nick Banks Cc: Marten Seemann , QUIC WG Subject: Re: Implicitly opened streams and exposing stream IDs Message-ID: <20180403142220.GF1695@ubuntu-dmitri> Mail-Followup-To: Nick Banks , Marten Seemann , QUIC WG References: <20180402174810.GA2015@ubuntu-dmitri> <20180403140009.GD1695@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, 03 Apr 2018 14:22:26 -0000 On Tue, Apr 03, 2018 at 02:05:04PM +0000, Nick Banks wrote: > As to requiring the application rely on stream IDs, I was referring to Marten's first email that started this thread: > > " For this stream mapping, it seems like the removal of implicitly > opened streams implies that QUIC has to expose stream IDs to the > application layer. I'm not sure if this was intended when making the > change, especially since we're considering to change HQ such that it > doesn't rely on QUIC stream IDs any more." I think I found it: https://github.com/quicwg/base-drafts/issues/910 Thank you. > I agree with this statement. For application protocols where they > specific the "first stream" as the control stream, if you guarantee the > first stream the application layer gets is always the first ordered > stream, by ID, then they don't need to know the ID. Otherwise, then > need to get the stream's ID to do the enforcement themselves. I agree with the implication (no implicit open -> need Stream IDs), but I do not have a problem with the implication itself. I think exposing Stream IDs is fine -- I will comment elsewhere in this thread. - Dmitri. From nobody Tue Apr 3 07:27:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF5B124D68 for ; Tue, 3 Apr 2018 07:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6pfzsNeAXAX for ; Tue, 3 Apr 2018 07:27:39 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A861271DF for ; Tue, 3 Apr 2018 07:27:39 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id o205so18789242qke.3 for ; Tue, 03 Apr 2018 07:27:39 -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:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=1EBfzUGuWRqG1nFng7x+cFvQov3i0NhLISogVYOqYTc=; b=Cbdnb9dOsWYah2qSDW9i3fz5zLvSJmVRb9506I32xdXUiuvYS9wrmMPZg1sm6Y0yXa PFYr287K5waDA8eUawaFKvU11Gj/Q4p+/TMErW6/BtTwinLvIfKHKQK0Z4rYRxRynENF /j15a9L0W1dkoJgbSEsn3b/epCIMyWhVBNCjee+4yoOC9wV9aSbS0apCUyr2kDAyW0Un Ylf0Zulh+dENo+Aib5BkRAJMcBQ7Dudnhfd63wDBFq5YasuXUbkKEnTZ4zrNYYMdsvxU 6wjcneg43G3TZRnG++IPTvS4VW+i8FPVXkr5+1V3ZWWChuexZdn5xp9oG9mEVwsRf78x icaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=1EBfzUGuWRqG1nFng7x+cFvQov3i0NhLISogVYOqYTc=; b=TgIgTxRjHz+hNPjdaTnRNUKzxAWKZnFTQlDVMBvnWyzarHtBLftG2vWRQ8M/M89jSo Hb4LcxbTEvNvO01M95mPfB359tLtxplmkgz5Hl8z7ys6oIqRnseRVZUH5baEM/hBE0ZV 1Kot8EIyGth6z3RhNY0uJWKvqufyJnG2gCyEe5vgRWdsSTt2flamlQ2/spu9jnFNKmr5 XGhZnCaGxn3QyQP5XTh3cxtuqcGMqGOg5yoa60LyI/+jBYrzu8S8b7PYw3y3DrX6iH/G /1IlIXaIi7Uw4fs2+ZSp5TwHSUOhv1BgNOiVsNCrvQFBgxiTH2qlLIHzYKBWrwdQaCvv MY7g== X-Gm-Message-State: ALQs6tCt495RQIwdDTM037OXxA9Zjasg3c7QTgfTMZtM2t6Q4KHV2iJz 4uXe32380nSIXB3kq2Ps6DAbLQ== X-Google-Smtp-Source: AIpwx4+hzNhYInRuD8y0SX9YefzBMcpMALx7YTaBdUuyPDLDw3pjJQ49m7lKVLxRvSlug9VqC+1RzQ== X-Received: by 10.233.222.68 with SMTP id s65mr17885994qkf.177.1522765658560; Tue, 03 Apr 2018 07:27:38 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id g14sm2421988qtk.71.2018.04.03.07.27.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 07:27:38 -0700 (PDT) Date: Tue, 3 Apr 2018 10:27:36 -0400 From: Dmitri Tikhonov To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= Cc: Martin Thomson , Marten Seemann , Lucas Pardue , QUIC WG Subject: Re: Implicitly opened streams and exposing stream IDs Message-ID: <20180403142736.GG1695@ubuntu-dmitri> Mail-Followup-To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , Martin Thomson , Marten Seemann , Lucas Pardue , QUIC WG References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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, 03 Apr 2018 14:27:42 -0000 On Tue, Apr 03, 2018 at 12:50:16AM -0700, Mikkel Fahnøe Jørgensen wrote: > Opening strictly in order (whether required or not) reduces those problems, > but it also severely constrains the application. For example you cannot > send a stream id internally to a subsystem and ask it to produce data once > ready to do so. You need to invent a complex mapping that is difficult to > coordinate in a distributed system. It is much simpler to deal with the > stream id’s directly. With multi-path you could even have multiple hosts > managing a single connection, and if not, you could still do it with proper > address mapping. > > So implicit streams and strict opening order might simplify very simple > problems, but also make very hard problems even harder. +1. Very well put. > Also, the entire idea of linearising QUIC seems to go against the spirit of > independent non-blocking streams. +1. (HoL!) > Still, having a maximum stream ID is very useful in limiting the resources > that must be managed. Note that QUIC does have it -- MAX_STREAM_ID. The in-order stream creation is unenforceable; faking it on the receiver side introduces head-of-line blocking. As long as the incoming stream has ID smaller than MAX_STREAM_ID, there is no reason not to handle the stream immediately. - Dmitri. From nobody Tue Apr 3 11:56:17 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E35712EA76 for ; Tue, 3 Apr 2018 11:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfYMSUGsExUq for ; Tue, 3 Apr 2018 11:56:13 -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 918E312EA64 for ; Tue, 3 Apr 2018 11:56:13 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id l3so23298073iog.0 for ; Tue, 03 Apr 2018 11:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0JCap35S6lRAwSMrXvIL9dSKzaxF0cXVk9CcN8e0hX8=; b=mzzfWyM0JzBwMQYqZCQZNew8WeMn5dQ3zXjXiRQGi/F22BmLY3aLedexBkT5y9y6xa 2XUn8hCJXWkDpqwt933pyOy/qsVnGmDhfm1Td3Sdqb4l5Xr4xBf2OTcxgOc4wbvtDQMp tmportfA3iNomVn7rJn97z2+CVEHH1qHgBL4CimpR++gjomT/amPReFN2y5Ze4SBlW3k 6xSPFN8n+6OmkpsSXkHp431i1AUnL4X5iy46FvO/xGVTDGzCm2DvY/a92DoofXtY5bLi P0Dy2farOtbSLmNEu56eN2ySDxHOjX8J4G1oE3uVPPXhLn5fvdm8lMcvTKS90x4P7bpi 0EUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0JCap35S6lRAwSMrXvIL9dSKzaxF0cXVk9CcN8e0hX8=; b=QWhVSzy9h3h4Q2IISATN6mkinPvWnyciLQb8geENfcM/JUqea4POFRyopEAP+UCCns K28oj6XeC8OiVRAfmIvNuLHxqslalxDb5D/dyxCoDLfUr6jlNstdzKSMIMdj5edG0hYM 411Ih4RP52rTuVbJadoQ61STsBOQSNq8w4MO53QeIpHncpoJ5wSjtc1DfKT9BfDQ0G0T a8YxS07KbIY9aj4QEslERlMKNPOaP5PjMBrsBuv5ISKnz9VQgxZt+Y4c/coaAeqq+cPP fgYgLxemluFWw56wcmJbjZqegztMWGw6k8o/dGULC0qz195ghWtibWQxBNAu3KIM/sd2 ibSg== X-Gm-Message-State: AElRT7Fm8z8f4/tcDd/GC0FhGlMSklB7eiOzOF2gkTMr4bHjsmJTjMag ejWgRMQT0lT+TRWTahLz8IHOoyBMleQykG7CiPBonw== X-Google-Smtp-Source: AIpwx49cDaffn+UWPuA2hH6OrZ1x6XCF2FEPrC1S30j75sQ9lKiO+cpwMiuYsapshwkrBo1fHkV7tcfefHSv7cY41sE= X-Received: by 10.107.222.18 with SMTP id v18mr14264098iog.212.1522781772629; Tue, 03 Apr 2018 11:56:12 -0700 (PDT) MIME-Version: 1.0 References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> <20180403120717.GA1695@ubuntu-dmitri> <20180403135644.GC1695@ubuntu-dmitri> <20180403140712.GE1695@ubuntu-dmitri> In-Reply-To: <20180403140712.GE1695@ubuntu-dmitri> From: Ian Swett Date: Tue, 03 Apr 2018 18:56:01 +0000 Message-ID: Subject: Re: Implicitly opened streams and exposing stream IDs To: Nick Banks , Martin Thomson , Marten Seemann , Lucas Pardue , IETF QUIC WG Content-Type: multipart/alternative; boundary="f403043ce430a1a3220568f642a6" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 03 Apr 2018 18:56:16 -0000 --f403043ce430a1a3220568f642a6 Content-Type: text/plain; charset="UTF-8" I don't like implicitly opened streams, for the reasons above and I'd prefer to avoid relying on implicit anything in QUIC. However, I hadn't considered ordering of stream opening as a way to avoid exposing stream id. It's interesting, though I think it's probably easier to just expose Stream ID. On Tue, Apr 3, 2018 at 10:07 AM Dmitri Tikhonov wrote: > On Tue, Apr 03, 2018 at 02:02:28PM +0000, Nick Banks wrote: > > For implicit opening, you only need to track the following, and you > > know the state of all stream IDs: > > > > - Set of all currently opened stream objects > > - Largest stream ID ever opened > > > > For explicit opening, since the streams below the largest stream ID > > ever opened, may never have been opened, you need to additionally > > track the stream IDs that have been closed (or inversely the set of > > stream IDs that have ever been opened). > As discussed on the issue, the tracking data structure is the same, but the state of the stream is slightly different. In one case, you have a marker for 'not yet open'(maybe a null as the value in your hashmap) and in the other case it's open and writable. To avoid allocating a large amount of memory with a small number of bytes, one may want to not create a stream object until it's actually needed. That would prevent writing, but as we've said, it's not necessary implementations support writing on implicitly opened streams. Chrome does this today with stream tracking, see: https://cs.chromium.org/chromium/src/net/quic/core/quic_session.cc?sq=package:chromium&l=845 > > Ah yes, that's true -- I remember adding this code now. > > The tracking is simpler with implicit stream opening. > > - Dmitri. > > --f403043ce430a1a3220568f642a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't like implicitly opened streams, for the reason= s above and I'd prefer to avoid relying on implicit anything in QUIC.= =C2=A0 However, I hadn't considered ordering of stream opening as a way= to avoid exposing stream id.=C2=A0 It's interesting, though I think it= 's probably easier to just expose Stream ID.

On Tue, Apr 3, 2018 at 10:07 AM Dmitri Tikhonov &= lt;dtikhonov@litespeedtech.c= om> wrote:
https://cs.chromium.org/chromiu= m/src/net/quic/core/quic_session.cc?sq=3Dpackage:chromium&l=3D845
=C2=A0

Ah yes, that's true -- I remember adding this code now.

The tracking is simpler with implicit stream opening.

=C2=A0 - Dmitri.

--f403043ce430a1a3220568f642a6-- From nobody Tue Apr 3 17:20:24 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A54E1241F3 for ; Tue, 3 Apr 2018 17:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFBOvENr9wGA for ; Tue, 3 Apr 2018 17:20:21 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5491205F0 for ; Tue, 3 Apr 2018 17:20:21 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id v194-v6so25201912itb.0 for ; Tue, 03 Apr 2018 17:20:21 -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=/FTCRuDXr7i3YCeb4zLfqHSPL5DpLQGTkd72w6kLCeE=; b=eWlWe+bXTzuh2dTMVMEgnYnC7nMVyArYSkJuPlDFlvM2hnr9rRsyWAynRS8COtNjDh swJHzv+4h9UFChe8UKrUUhktJVlSE65tsbViN8RG9QUdxBxm6vAg1NoxxQLQscUHGU6l InCKd5JlV7WZARkYL/E77twJ3Lc8vtKiBL9tvesBLpLVsxBPv6t3LFWakmXxxmhI7zdV L9kaDWrcG9vHiLN74bEJxe4dei1foHcYiI6eGXSVdyyeONP+3P4Od3O5RcXX4YU+rtjw HukWCIMMV8SvezEr+HdNNVI3nF9dNJsMR6HLXUHmCV3xbBW/zZhAX5oi+UABmceU5D6O cpAQ== 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=/FTCRuDXr7i3YCeb4zLfqHSPL5DpLQGTkd72w6kLCeE=; b=tgp2IrcrKPVJfAp9DSweLNOw1av1QFN8AvoMOD3km87WbG9F4ttmIaydiRb7qpvJbY UTc9qIUCiTF2Dru/qL5/REyjNUudae6fUlwgpS9kHza0/QWAA7ff/9GF6XKlCvXEIVRp 6gw3TqT5plZ1K7lK9/CBqDiz26rIc0Ttg+8lOnzw+uozY4egtROsrC4QFBbugufrhGDW 4+g+SjgUdJb5O6WPT4qEqj0dZJHdfZXWC8V73i+Hxrt5iJ54O9rzSeNuExAYq6pC71tP 5ZkmpGmhjzYxqdSc9+6u2FQDJ75/QIayoWH10ijYH6BjqZPXYCboUIEUXI7ZU9gT7+HP tENg== X-Gm-Message-State: ALQs6tDgeibKkZeGiPvsa5w7toWmHXJ6GyRDGJmHS/2GbJp2AJECUJH/ YPk0S2fOrtvLc8jZhWDx/RWS15jDd37W8a9OmZfyG1QnhxI= X-Google-Smtp-Source: AIpwx4+GCloe6vPpQHHnAQDpVsQfaU0dhh0eOHIrcMYkHsMQDu4ctayGfAVevEMGzHTQ1+CwRLdkSI7CSVhpcoV1X7U= X-Received: by 2002:a24:618f:: with SMTP id s137-v6mr7749575itc.40.1522801220148; Tue, 03 Apr 2018 17:20:20 -0700 (PDT) MIME-Version: 1.0 From: Ian Swett Date: Wed, 04 Apr 2018 00:20:08 +0000 Message-ID: Subject: UDP send costs in Linux To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000caebbf0568fac9ec" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 00:20:23 -0000 --000000000000caebbf0568fac9ec Content-Type: text/plain; charset="UTF-8" One challenge with QUIC at the moment is the increased CPU cost of sending UDP packets vs TCP payloads. I've seen this across every platform Google has deployed QUIC on, so it's a widespread issue. Here's an excellent presentation on what's causing the increased CPU consumption on Linux from Willem de Bruijn(UDP starts on slide 9). http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf And while you're thinking of CPU usage, it's worth looking at the presentation on timing wheel based packet pacing(which is minimum release time based) and is ideal for QUIC(and TCP for that matter): https://conferences.sigcomm.org/sigcomm/2017/files/program/ts-9-4-carousel.pdf -Ian --000000000000caebbf0568fac9ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One challenge with QUIC at the moment is the increased CPU= cost of sending UDP packets vs TCP payloads.=C2=A0 I've seen this acro= ss every platform Google has deployed QUIC on, so it's a widespread iss= ue.

Here's an excellent presentation on what's c= ausing the increased CPU consumption on Linux from=C2=A0Willem de Bruijn(UD= P starts on slide 9).

And while yo= u're thinking of CPU usage, it's worth looking at the presentation = on timing wheel based packet pacing(which is minimum release time based) an= d is ideal for QUIC(and TCP for that matter):=C2=A0https://= conferences.sigcomm.org/sigcomm/2017/files/program/ts-9-4-carousel.pdf<= /div>

-Ian
--000000000000caebbf0568fac9ec-- From nobody Tue Apr 3 19:50:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE2212946D for ; Tue, 3 Apr 2018 19:50:37 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=qlRxBTS9; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Poei2XLf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbmYKGN10KxQ for ; Tue, 3 Apr 2018 19:50:36 -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 31D111289B0 for ; Tue, 3 Apr 2018 19:50:36 -0700 (PDT) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w342nD6l022353; Tue, 3 Apr 2018 19:50:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=O4edPnMptyFisse2fTshiAalvyCQ/enH79CL0qpxatM=; b=qlRxBTS9rNhqAwVmH7pYwQC1MSZUcyE/tlI7mPbd25S3rixUauvpNyA42VMm4YpJgHEV rQjJU2ZPZDpaXNd5dLQ0guIPJzriimzSnqTi3l6NRu9qgSFzB9vsE8atTq5LxlMLt2A+ Mm9d6CpRigD4G6ig1lWeRZ0pyg2djKOVAsg= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2h4m8h86yh-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 03 Apr 2018 19:50:34 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 3 Apr 2018 22:50:33 -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=O4edPnMptyFisse2fTshiAalvyCQ/enH79CL0qpxatM=; b=Poei2XLf6wOST4+yGrPvqubXPJ+0c66nXq8aUpxTyXu7iUo3HWTSlh3aodZSEO+EGq+50NbBQ8L2a2AAFhWd1TFt9LnyOL8bmzy/QOUTalmhW4f8DkeyTCgbnUIxbPWWqDPdJAIq62fhtY8N/JIFnm/eZo6j5w9RwjRDQi1fEwE= Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1517.namprd15.prod.outlook.com (10.173.235.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.631.10; Wed, 4 Apr 2018 02:50:31 +0000 Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126%17]) with mapi id 15.20.0631.013; Wed, 4 Apr 2018 02:50:31 +0000 From: Subodh Iyengar To: Ian Swett , IETF QUIC WG Subject: Re: UDP send costs in Linux Thread-Topic: UDP send costs in Linux Thread-Index: AQHTy6rd/yijFMm6G0acwigUqceJdaPv5xg8 Date: Wed, 4 Apr 2018 02:50:31 +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:d273] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1517; 7:9+9SM8RTiiFCZSxcGpuqo8CDW7TNXxHBK0eGzbCtQfSUIv9osNBX2PJyPKtzvx/zSqSJW4FotsttERIFSWQVd92fjTbQyNHrjDHNitZHxKqEXvLUuzqaM8tmwjIe4CMbF6ryH48nTZS7+1HjqjzWhAdOj0XM3A/4b5AUF6sw3UtP+vCUK0+OMKVBifA7fr0CGLbTbZFaEBvBnUBUXqdGKqy60Ge40SLIggYSWqu0XuUL5lZfiGtnL0kqQ/92PRnZ; 20:0ApLdUFyaFi2PdUUIPNZW9egRW3KBoUt7ayOMC34+sahVu13snWbDsFgwsoJ8GzI3rSqU36GG1yGCuAbNItHHGT0aot/HtgTQqS3rK+zJMJlN6T188LCB0YrU4mg8YhjFft5KDyoeb5ukUFc9ShiG7wbgZxeS8DnDnq5gAnF9Bc= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 3e351d57-2e91-4f16-0412-08d599d6d4f3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1517; x-ms-traffictypediagnostic: MWHPR15MB1517: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(9452136761055); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(11241501184)(944501327)(52105095)(3002001)(93006095)(93001095)(10201501046)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR15MB1517; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1517; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(346002)(366004)(376002)(396003)(39380400002)(39860400002)(189003)(199004)(6506007)(8936002)(86362001)(14454004)(105586002)(25786009)(81166006)(606006)(81156014)(478600001)(5660300001)(966005)(476003)(97736004)(19627405001)(8676002)(55016002)(54896002)(9686003)(229853002)(2900100001)(76176011)(3660700001)(11346002)(33656002)(5250100002)(186003)(99286004)(6436002)(2906002)(446003)(6246003)(6116002)(7696005)(110136005)(3280700002)(316002)(7736002)(46003)(106356001)(53546011)(102836004)(6306002)(74316002)(68736007)(6606003)(236005)(53936002)(486006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1517; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: skaqOTuPGilOHPVpo0m3Btk6JriDKiZnma9azkk1nkvKLN5tdp3BZhk+yJBfKy0EBehPM9/Bw602TJ5ABzkBa/QvEkUHy1DhiTm4h0PRMi6SDqTK1PUxG5eUGa4skrWTlj7CnFOusKQ+fqZ4OZ9nV2jrkJev7DW2TvOf2E+RDA4Dd8kYYxOMpPK4I8H9KPaR+k/ZF54Ewuh/RavwfQvaSoT7zA5p00W6ySRjwudX5SUzE2bfYPt7j+r1AYQ/JWxw0uxOyoV0QS9JXccf0mEs3YqAadUX6IW4PEhOjjB+YZcNAQGYU7kmnrunS9fRID91Q9VoyNp01SqotuqK6ANQiRlXEoV988k/qQU0jvdo1DYuQN2tegUDL1w8arUPmfFizgydIUB6SQF2wvuPdmS7CWm7jlPoBhddCJ0YibziB/k= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB18215781CA00A71CF1AD0137B6A40MWHPR15MB1821namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3e351d57-2e91-4f16-0412-08d599d6d4f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 02:50:31.5977 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1517 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-03_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 02:50:38 -0000 --_000_MWHPR15MB18215781CA00A71CF1AD0137B6A40MWHPR15MB1821namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for sharing this Ian. This definitely matches some of the observations we've seen as well in the = UDP write path. Some of the other paths that we saw that added overhead was= the route table lookup in linux udp stack. Connected UDP sockets did amort= ize that. I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is there = any indication of the timeline for these patches to make it to linux? Would= be happy to try any of these out to help iron out the API. Subodh ________________________________ From: QUIC on behalf of Ian Swett Sent: Tuesday, April 3, 2018 5:20:08 PM To: IETF QUIC WG Subject: UDP send costs in Linux One challenge with QUIC at the moment is the increased CPU cost of sending = UDP packets vs TCP payloads. I've seen this across every platform Google h= as deployed QUIC on, so it's a widespread issue. Here's an excellent presentation on what's causing the increased CPU consum= ption on Linux from Willem de Bruijn(UDP starts on slide 9). http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf And while you're thinking of CPU usage, it's worth looking at the presentat= ion on timing wheel based packet pacing(which is minimum release time based= ) and is ideal for QUIC(and TCP for that matter): https://conferences.sigco= mm.org/sigcomm/2017/files/program/ts-9-4-carousel.pdf -Ian --_000_MWHPR15MB18215781CA00A71CF1AD0137B6A40MWHPR15MB1821namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for sharing this Ian.


This definitely matches some of t= he observations we've seen as well in the UDP write path. Some of the other= paths that we saw that added overhead was the route table lookup in linux = udp stack. Connected UDP sockets did amortize that.


I'm looking forward to a smarter = sendmmsg with GSO and zero copy. Is there any indication of the timeline fo= r these patches to make it to linux? Would be happy to try any of these out= to help iron out the API.


Subodh

From: QUIC <quic-bounces= @ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf= .org>
Sent: Tuesday, April 3, 2018 5:20:08 PM
To: IETF QUIC WG
Subject: UDP send costs in Linux
 
One challenge with QUIC at the moment is the increased CPU= cost of sending UDP packets vs TCP payloads.  I've seen this across e= very platform Google has deployed QUIC on, so it's a widespread issue.

Here's an excellent presentation on what's causing the increased CPU c= onsumption on Linux from Willem de Bruijn(UDP starts on slide 9).

And while you're thinking of CPU usage, it's worth looking at the pres= entation on timing wheel based packet pacing(which is minimum release time = based) and is ideal for QUIC(and TCP for that matter): https://conferences.sigcomm.org/sigcomm/2017/files/pro= gram/ts-9-4-carousel.pdf

-Ian
--_000_MWHPR15MB18215781CA00A71CF1AD0137B6A40MWHPR15MB1821namp_-- From nobody Tue Apr 3 19:50:45 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D448E129C6A for ; Tue, 3 Apr 2018 19:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522810237; bh=pMKzvxuYp57/VJsj8Ep10936tKb2KgMm95jO9NeZuxI=; h=From:Subject:Date:References:In-Reply-To:To:To; b=VIpqgARFqFLUpRCSS+aasU+kuBpM2rPjMeeB1ZdtJeVXLiIrom3YYN5IF4AlLee5L yACvhE100aqgkI9x28A0DNnMCjwhZSKHdcQDTClesx4UhfJ03Cs9YYOlA6yTZ4RXI5 4q2d3Yes3fxNm+TT9APZ1kDKCIdTk+E+OGgVMYeI= X-Mailbox-Line: From subodh@fb.com Tue Apr 3 19:50:37 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AF5128961; Tue, 3 Apr 2018 19:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522810237; bh=WPWxE2ZauYAu9SnkD/OIt8Ef0ldgfHRBhXEpJLexBaI=; h=From:Subject:Date:References:In-Reply-To:To:To; b=GzaWLN0EZO3dXFn3clU8SK1JfFWmFhmjXhz6zQAKwGmXGeVT3Czl4WTHcW0XuQMew 6BJMTcilcI5H+DJlJaFoNNrD70m9B+48z9+OKEvsiv4LCOQQhGmrd7zqk3mwqXXx5B /srFNVJSl1WHdYjOpZpJ6eq+B/teb3j5Z4QElHNI= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA31128D2E for ; Tue, 3 Apr 2018 19:50:37 -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 (1024-bit key) header.d=fb.com header.b=qlRxBTS9; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Poei2XLf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rynMHDNeUWGh for ; Tue, 3 Apr 2018 19:50:35 -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 48DBD128961 for ; Tue, 3 Apr 2018 19:50:35 -0700 (PDT) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w342nD6l022353; Tue, 3 Apr 2018 19:50:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=O4edPnMptyFisse2fTshiAalvyCQ/enH79CL0qpxatM=; b=qlRxBTS9rNhqAwVmH7pYwQC1MSZUcyE/tlI7mPbd25S3rixUauvpNyA42VMm4YpJgHEV rQjJU2ZPZDpaXNd5dLQ0guIPJzriimzSnqTi3l6NRu9qgSFzB9vsE8atTq5LxlMLt2A+ Mm9d6CpRigD4G6ig1lWeRZ0pyg2djKOVAsg= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2h4m8h86yh-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 03 Apr 2018 19:50:34 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 3 Apr 2018 22:50:33 -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=O4edPnMptyFisse2fTshiAalvyCQ/enH79CL0qpxatM=; b=Poei2XLf6wOST4+yGrPvqubXPJ+0c66nXq8aUpxTyXu7iUo3HWTSlh3aodZSEO+EGq+50NbBQ8L2a2AAFhWd1TFt9LnyOL8bmzy/QOUTalmhW4f8DkeyTCgbnUIxbPWWqDPdJAIq62fhtY8N/JIFnm/eZo6j5w9RwjRDQi1fEwE= Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1517.namprd15.prod.outlook.com (10.173.235.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.631.10; Wed, 4 Apr 2018 02:50:31 +0000 Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126%17]) with mapi id 15.20.0631.013; Wed, 4 Apr 2018 02:50:31 +0000 From: Subodh Iyengar Subject: Re: UDP send costs in Linux Thread-Topic: UDP send costs in Linux Thread-Index: AQHTy6rd/yijFMm6G0acwigUqceJdaPv5xg8 Date: Wed, 4 Apr 2018 02:50:31 +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:d273] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1517; 7:9+9SM8RTiiFCZSxcGpuqo8CDW7TNXxHBK0eGzbCtQfSUIv9osNBX2PJyPKtzvx/zSqSJW4FotsttERIFSWQVd92fjTbQyNHrjDHNitZHxKqEXvLUuzqaM8tmwjIe4CMbF6ryH48nTZS7+1HjqjzWhAdOj0XM3A/4b5AUF6sw3UtP+vCUK0+OMKVBifA7fr0CGLbTbZFaEBvBnUBUXqdGKqy60Ge40SLIggYSWqu0XuUL5lZfiGtnL0kqQ/92PRnZ; 20:0ApLdUFyaFi2PdUUIPNZW9egRW3KBoUt7ayOMC34+sahVu13snWbDsFgwsoJ8GzI3rSqU36GG1yGCuAbNItHHGT0aot/HtgTQqS3rK+zJMJlN6T188LCB0YrU4mg8YhjFft5KDyoeb5ukUFc9ShiG7wbgZxeS8DnDnq5gAnF9Bc= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 3e351d57-2e91-4f16-0412-08d599d6d4f3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1517; x-ms-traffictypediagnostic: MWHPR15MB1517: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(9452136761055); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(11241501184)(944501327)(52105095)(3002001)(93006095)(93001095)(10201501046)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR15MB1517; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1517; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(346002)(366004)(376002)(396003)(39380400002)(39860400002)(189003)(199004)(6506007)(8936002)(86362001)(14454004)(105586002)(25786009)(81166006)(606006)(81156014)(478600001)(5660300001)(966005)(476003)(97736004)(19627405001)(8676002)(55016002)(54896002)(9686003)(229853002)(2900100001)(76176011)(3660700001)(11346002)(33656002)(5250100002)(186003)(99286004)(6436002)(2906002)(446003)(6246003)(6116002)(7696005)(110136005)(3280700002)(316002)(7736002)(46003)(106356001)(53546011)(102836004)(6306002)(74316002)(68736007)(6606003)(236005)(53936002)(486006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1517; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: skaqOTuPGilOHPVpo0m3Btk6JriDKiZnma9azkk1nkvKLN5tdp3BZhk+yJBfKy0EBehPM9/Bw602TJ5ABzkBa/QvEkUHy1DhiTm4h0PRMi6SDqTK1PUxG5eUGa4skrWTlj7CnFOusKQ+fqZ4OZ9nV2jrkJev7DW2TvOf2E+RDA4Dd8kYYxOMpPK4I8H9KPaR+k/ZF54Ewuh/RavwfQvaSoT7zA5p00W6ySRjwudX5SUzE2bfYPt7j+r1AYQ/JWxw0uxOyoV0QS9JXccf0mEs3YqAadUX6IW4PEhOjjB+YZcNAQGYU7kmnrunS9fRID91Q9VoyNp01SqotuqK6ANQiRlXEoV988k/qQU0jvdo1DYuQN2tegUDL1w8arUPmfFizgydIUB6SQF2wvuPdmS7CWm7jlPoBhddCJ0YibziB/k= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB18215781CA00A71CF1AD0137B6A40MWHPR15MB1821namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3e351d57-2e91-4f16-0412-08d599d6d4f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 02:50:31.5977 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1517 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-03_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe To: Ian Swett To: IETF QUIC WG Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 02:50:38 -0000 --_000_MWHPR15MB18215781CA00A71CF1AD0137B6A40MWHPR15MB1821namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for sharing this Ian. This definitely matches some of the observations we've seen as well in the = UDP write path. Some of the other paths that we saw that added overhead was= the route table lookup in linux udp stack. Connected UDP sockets did amort= ize that. I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is there = any indication of the timeline for these patches to make it to linux? Would= be happy to try any of these out to help iron out the API. Subodh ________________________________ From: QUIC on behalf of Ian Swett Sent: Tuesday, April 3, 2018 5:20:08 PM To: IETF QUIC WG Subject: UDP send costs in Linux One challenge with QUIC at the moment is the increased CPU cost of sending = UDP packets vs TCP payloads. I've seen this across every platform Google h= as deployed QUIC on, so it's a widespread issue. Here's an excellent presentation on what's causing the increased CPU consum= ption on Linux from Willem de Bruijn(UDP starts on slide 9). http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf And while you're thinking of CPU usage, it's worth looking at the presentat= ion on timing wheel based packet pacing(which is minimum release time based= ) and is ideal for QUIC(and TCP for that matter): https://conferences.sigco= mm.org/sigcomm/2017/files/program/ts-9-4-carousel.pdf -Ian --_000_MWHPR15MB18215781CA00A71CF1AD0137B6A40MWHPR15MB1821namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for sharing this Ian.


This definitely matches some of t= he observations we've seen as well in the UDP write path. Some of the other= paths that we saw that added overhead was the route table lookup in linux = udp stack. Connected UDP sockets did amortize that.


I'm looking forward to a smarter = sendmmsg with GSO and zero copy. Is there any indication of the timeline fo= r these patches to make it to linux? Would be happy to try any of these out= to help iron out the API.


Subodh

From: QUIC <quic-bounces= @ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf= ..org>
Sent: Tuesday, April 3, 2018 5:20:08 PM
To: IETF QUIC WG
Subject: UDP send costs in Linux
 
One challenge with QUIC at the moment is the increased CPU= cost of sending UDP packets vs TCP payloads.  I've seen this across e= very platform Google has deployed QUIC on, so it's a widespread issue.

Here's an excellent presentation on what's causing the increased CPU c= onsumption on Linux from Willem de Bruijn(UDP starts on slide 9).

And while you're thinking of CPU usage, it's worth looking at the pres= entation on timing wheel based packet pacing(which is minimum release time = based) and is ideal for QUIC(and TCP for that matter): https://conferences.sigcomm.org/sigcomm/2017/files/pro= gram/ts-9-4-carousel.pdf

-Ian
--_000_MWHPR15MB18215781CA00A71CF1AD0137B6A40MWHPR15MB1821namp_-- From nobody Tue Apr 3 21:58:29 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B99E126DC2 for ; Tue, 3 Apr 2018 21:58:28 -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=1uylKuQ2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RsCmfFef Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2KfvsuAWHn0 for ; Tue, 3 Apr 2018 21:58:25 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2894124234 for ; Tue, 3 Apr 2018 21:58:24 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 25AD8214F3; Wed, 4 Apr 2018 00:58:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 04 Apr 2018 00:58:24 -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; s=fm2; bh=c8N7it/eB+Y/2re1muosSP4f6YKvL HmRwL9N8mCdI30=; b=1uylKuQ2xVhzdImgN/Ya/MgGrKWNselIVliiR58Zz8DdK rGIUDUB+Z/MD6zh3y7uxqM7ct2u6pxTe+H02R+97ufOXQal1TfIhj+jUhzvz6ueh sjAUJrpghowSG1BIOg2WE/g1jmDICP6Qq7h9dUUOKboFutbW0veqK3XoM/r5TgTz gbj9yE8rD7uE5EFLmK7I74AON/TYeISs6IZncTzl28RXZqBiLSQnK4B3lP/f8Fmb b1AEInvx0Q4RElhMcIlbCRj3YHPnY5xJaNCMjoihfYAEwh46EHQUZvcPhnWfGTcM zn1AJy4NKlmb2vWE/qfNKSaIRKpI4vxWkY3cejaHg== 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; s=fm2; bh=c8N7it /eB+Y/2re1muosSP4f6YKvLHmRwL9N8mCdI30=; b=RsCmfFefLRViBgD2tMV6KH 2E3V/w5hyjR2mYDdHlbwpoe27OyeCDeqConQT8/nYhk7j90P+FhFkLEQ6kcUh+/s DM5FWX3yzT1AwFEiN3YkBcrK1cv8g9oQ6GrtANW/o9g3VbasIoL6EZuTiKmv2FjW BGfDoChPrRIDXeVumGw4jw/sGy9TypjzLLzqeirpVJ3Y9HTeho5WeYnixTuJeEKj xYH9QHCU6UdIBF5I/eZNIk4l3q9hJcwEPC5XNub0Fh08LeyblIg5enfQ25tSqO2X IjMtaqTSFWMzk31lJEplOQ6ck32NuGFrkqg9WbbCeaEvOPjDOVnjSEANnM1GejnQ == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id D66BAE43BE; Wed, 4 Apr 2018 00:58:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Getting to consensus on packet number encryption From: Mark Nottingham In-Reply-To: Date: Wed, 4 Apr 2018 14:58:20 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 04:58:28 -0000 Hi everyone, The editors have told your chairs that this issue is starting to block = progress on other aspects of QUIC. Coming to consensus on it soon (i.e., = before Stockholm, if possible) would be good. It looks like this thread has come to a natural pause. Reading through = it, I think we agree there are some unpleasant tradeoffs here, but so = far we have only one concrete proposal -- PR#1079. My AU$.05 - While we're chartered to produce a protocol that's encrypted = as much as operational concerns allow, and that privacy is a natural = extension of that (especially in light of RFC7258 and RFC6973), there is = no *requirement* that we produce a protocol that is able to be = accelerated by hardware. That being the case, I think we need to ask ourselves if we believe that = inclusion of PR#1079 will significantly inhibit deployment of the = protocol. Based on the discussion so far, that doesn't seem to be the = case, but I'd be interested to hear what others think. If we can get to consensus to incorporate the PR, and folks come back = later with a more hardware-friendly replacement that doesn't change the = Invariants or increase linkability, I suspect the WG will be amenable to = that. What do folks think? Cheers, > On 29 Mar 2018, at 11:39 am, Ian Swett = wrote: >=20 > Thanks for the nice summary Jana. >=20 > As much as I'd love to have easier crypto HW acceleration, I've ended = up arriving at the same conclusion. I don't want to bite off the work = to do proper multipath in QUIC v1, which I think is the only other = reasonable option of those Christian outlined. >=20 > If someone comes up with a way to transform packet number to make it = non-linkable, but doesn't have the downside of making hardware offload = difficult, then I'm open to it. But we've been talking about this for 2 = months without any notable improvements over Martin's PR. >=20 > Given we never talk about any issue only once in QUIC, I'm sure this = will come up again, but for the time being I think #1079 is the best = option we have. >=20 >=20 >=20 > On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar = wrote: > A few quick thoughts as I catch up on this thread. >=20 > I spent some time last week working through a design using multiple PN = spaces, and it is quite doable. I suspect we'll head towards multiple PN = spaces as we consider multipath in the future. That said, there is = complexity (as Christian notes). This complexity may be warranted when = doing multipath in v2 or later, but I'm not convinced that this is = necessary as a design primitive for QUICv1.=20 >=20 > We may want to creatively use the PN bits in v2, say to encode a path = ID and a PN, for multipath. We want to retain flexibility in these bits = going into v2. We've used encryption to ensure that we don't lose = flexibility elsewhere in the header, and it follows that we should use = PNE to retain flexibility in these bits as well. (Simplicity of design = is the other value in using PNE, since handling migration linkability is = non-trivial without it.) >=20 > This leaves the question of HW acceleration being at loggerheads with = the design in PR #1079. First, I expect that the primary benefit of = acceleration will be in DC environments. Yes, there are some gains to be = had in serving the public Internet as well, but I'm unconvinced that = this is the driving use case for hardware acceleration. I understand = that others may disagree with me here. >=20 > AFAIK, QUIC has not been used in DC environments yet. I expect there = are other things in the protocol that we'd want to change as we gain = experience deploying QUIC in DCs. Spinning up a new version to try QUIC = within DCs is not only appropriate, I would recommend it. This allows = for rapid iterations internally, and the experience can drive subsequent = changes to QUIC. It's what *I* would do if I was to deploy QUIC inside a = DC. >=20 > So, in short, I think we should go ahead with PR# 1079. This ensures = that future versions are guaranteed the flexibility to change the PN = bits for better support of HW acceleration or multipath or = what-have-you. >=20 > - jana >=20 > On Mar 26, 2018 9:41 AM, "Christian Huitema" = wrote: >=20 > On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote: >> Looking at = https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_archit= ecture it seems to imply a large range of server, desktop and mobile = chips all have a CPU instruction set available to do AES acceleration = and other similar operations (other instruction sets are also = available). >>=20 >> If we are considering the AES instructions then it looks like it is = (or at least will be in the near future) a sizeable proportion of the = public internet have it to be used. >>=20 >=20 > Certainly, but that's not the current debate. PR #1079 is fully = compatible with use of the AES instructions. The issue of the debate is = that the mechanism in PR #1079 required double buffering, first encrypt = the payload, then use the result of the encryption to encrypt the PN. = This is not an issue in a software implementation that can readily = access all bytes of the packet from memory, but it may be an issue in = some hardware implementations that are designed to do just one pass over = the data. >=20 >=20 > -- Christian Huitema >=20 >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 3 22:59:10 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A84512785F for ; Tue, 3 Apr 2018 22:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x8GN55y7QCl for ; Tue, 3 Apr 2018 22:58:59 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id BCAE912DA42 for ; Tue, 3 Apr 2018 22:58:58 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w345wm4E017853; Wed, 4 Apr 2018 07:58:48 +0200 Date: Wed, 4 Apr 2018 07:58:48 +0200 From: Willy Tarreau To: Mark Nottingham Cc: IETF QUIC WG , Lars Eggert Subject: Re: Getting to consensus on packet number encryption Message-ID: <20180404055848.GA17563@1wt.eu> References: <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 05:59:08 -0000 Hi Mark, On Wed, Apr 04, 2018 at 02:58:20PM +1000, Mark Nottingham wrote: > My AU$.05 - While we're chartered to produce a protocol that's encrypted as > much as operational concerns allow, and that privacy is a natural extension > of that (especially in light of RFC7258 and RFC6973), there is no > *requirement* that we produce a protocol that is able to be accelerated by > hardware. IMHO it's important to keep in mind that what cannot be accelerated by hardware is also subject to severe limitations in terms of software-based processing. For example anti-ddos solutions are critical for operations everywhere nowadays, and the more unreadable the protocol becomes on the wire, the lower amount of protection such third-party components will be able to provide. And it's just an example. Also, I note that 36 years after TCP was published, many of us still find ourselves launching tcpdump or wireshark every single day to debug protocol-level issues, or at least to be able to say who's right and who's wrong in a conversation to try to spot the root cause of an issue. I already expressed my real dislike (not to say disgust) for protocol elements encryption for these various reasons and I'm well aware that my view is generally not shared here. I tend to consider that a properly working protocol is more important to maintain the internet in good health and resilient than adding some elements which supposedly will make it harder to guess what people are doing while their devices spread their cookies to all ads providers and "like" buttons, are infected with malware picking their clear text conversations, and some authorities are decrypting communications by forcing keys directly on their devices. In the end we're just being more selective about who has access to their activity. BTW, you know the saying, there are two types of people, those how believe their conversations have never been intercepted, and those who think they know where it happened ;-) Now a last concern about performance : sure, processors do provide AES instructions, but these ones are not that fast, perform a single round, and need to run in loops (10 rounds for AES-128 if my memory serves me right). I just tried here on a Xeon E5-2680 at 2.5 GHz. This machine is able to classify 14.88 million incoming packets per second on a single core (10G line rate). But it only performs 42 million AES-128-CBC per second and the other modes are even slower. So having to process even a single AES operation per packet just to know whether or not it is valid for a session will definitely come with a significant cost on some such machines, by representing 1/3 of the processing time budget. And to this we must add all the low-level processing that will not be offloadable to the hardware anymore! At the very least if we're going to encrypt the protocol and want to be CPU-friendly, it would be nice to perform a single AES round (4-6 cycles approx on modern CPUs with the suitable instruction set). It will definitely not reduce privacy but will at least make the future internet faster than by using full AES. It will not make it work better though. Just my two cents, Willy From nobody Wed Apr 4 01:16:30 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E53D1201FA for ; Wed, 4 Apr 2018 01:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN-xWPaVExSp for ; Wed, 4 Apr 2018 01:16:27 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF8D124205 for ; Wed, 4 Apr 2018 01:16:26 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id 188-v6so18460718oih.8 for ; Wed, 04 Apr 2018 01:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ujLT00HOlJAcCCZurQhHFp6CY2JuoZdLnb+AfQg/CNc=; b=F2yEC9EQ9XEdaeJxwz+SiDa9RkpvW30Ox6PjRsKgLdfzCYqoJcQD+yXrRK8NpQfP+W H91cWWdZwynoyoACaxxqNGxE0fDrSu5iuGsbDVFxPqa7HLIiORs7OJLHRdMG4LPGPGDE 7qo7cqYS11FdvfY3lvtHeQly+SYTdWbA+mp17hIA2lfqoQd6Q6wz68plYGcuNFpEMy/r vjzdf/iBbdBBoQyetmJpo83iQb6IoTCaxWud/S0sMCEYA8zV9kl4MFBgYs0l2yWW0q0Z LYpnP5YDf7PuGpC/1zYH2Hz17iIriuILbd56u7SSN8+xf6of+ywJVChCSf2+MRXnqWq5 PHtQ== 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=ujLT00HOlJAcCCZurQhHFp6CY2JuoZdLnb+AfQg/CNc=; b=XCguiPrdwVclP0qOnNT8XHJcdaQRKUL347ywBTGmOOcuQ43QK8NRwCoqH/gdJ9I+ke McML9hrMqpumgnWO70nJyB6wKIjfjCBswnaE59vhM+6r4FIw1/m9zKKaCNNrnOWlaO0a IyIVN2C2yl2jU4Wymz3U0Dt6OwsWL/XwaR/vKQHZaJLM8nRWncH91yoIB3rUFJWTJarN 3iYNQtooio8cMJkfskzi8iRY3YZvrsUb/S1S8tw4EIh2F4FlxVqtw963mi1225oraMbi q19Tklf9l6fpDXN+W295hfD3HRAYc5Z6T95qu6EZw4pTgG5F8cSJyuEirnVjSggY0VIk HHEA== X-Gm-Message-State: ALQs6tADgNW6H7+lMcHAG21oWhS9NxEFTScR7gQNyuEnzhh+ek+Rm4jT RR+1K7r/1TIDJfYaZZJ4JgPgYvS2HsfvkBbeyeIeYy5V X-Google-Smtp-Source: AIpwx48kGFIEhkSGPwnyH/pr3x4/VPQ4sRSiBAT24rk/vuPZ3c84HzIPkseXC342yVVTVgywtTCNJdLmWKxYrwbbVxk= X-Received: by 2002:aca:5e86:: with SMTP id s128-v6mr9775131oib.346.1522829785790; Wed, 04 Apr 2018 01:16:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 01:16:24 -0700 (PDT) From: Martin Thomson Date: Wed, 4 Apr 2018 18:16:24 +1000 Message-ID: Subject: Extension frames 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, 04 Apr 2018 08:16:29 -0000 It seems like there was some enthusiasm back in Melbourne for extension frames, and later for the design that Victor proposed. I've updated my PR to include Victor's design, plus changes that address comments that were received, from Christian in particular. Please take a look: https://github.com/quicwg/base-drafts/pull/1068 I think that this reflects where we got to. Sorry for having this take so long to get to this point. I hope that it was worth the wait. From nobody Wed Apr 4 03:27:11 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051D712711A for ; Wed, 4 Apr 2018 03:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlXO7ulixI1t for ; Wed, 4 Apr 2018 03:27:07 -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 AB6B5126DEE for ; Wed, 4 Apr 2018 03:27:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 40GMZw5zhmzMpZX; Wed, 4 Apr 2018 12:27:04 +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 ofpZof03n3tH; Wed, 4 Apr 2018 12:27:03 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.24] (i577BCE70.versanet.de [87.123.206.112]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 4 Apr 2018 12:27:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Getting to consensus on packet number encryption From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> Date: Wed, 4 Apr 2018 12:27:00 +0200 Cc: IETF QUIC WG , Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3445.5.20) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 10:27:10 -0000 Hi Mark, without intending to state a technical opinion, I think I need to = disagree with your assessment of the situation. Please see below. > Am 04.04.2018 um 06:58 schrieb Mark Nottingham : >=20 > Hi everyone, >=20 > The editors have told your chairs that this issue is starting to block = progress on other aspects of QUIC. Coming to consensus on it soon (i.e., = before Stockholm, if possible) would be good. >=20 > It looks like this thread has come to a natural pause. Reading through = it, I think we agree there are some unpleasant tradeoffs here, but so = far we have only one concrete proposal -- PR#1079. The other proposal is to use a random offset that can/should be changed = when the connection ID is changed. Which is mostly inline with what the = draft currently says. >=20 > My AU$.05 - While we're chartered to produce a protocol that's = encrypted as much as operational concerns allow, I don=E2=80=99t think this is what the charter say. The charter says = "Providing always-secure transport, using TLS 1.3 by default.=E2=80=9C = plus another paragraph that talks about TLS1.3. It does not spell out = the desire of some individual to =E2=80=9Eencrypt as much as = possible=E2=80=9C.=20 > and that privacy is a natural extension of that (especially in light = of RFC7258 and RFC6973), there is no *requirement* that we produce a = protocol that is able to be accelerated by hardware. Not there is no requirement that the protocol need to be accelerated by = hardware. However, not all requirement are listed in the charter. We as = a group have to define the requirement. However, there is of course an = implicit requirement for all work in the IEFT that is must be deployable = and serve the needs of those people who want to deploy it. >=20 > That being the case, I think we need to ask ourselves if we believe = that inclusion of PR#1079 will significantly inhibit deployment of the = protocol. Based on the discussion so far, that doesn't seem to be the = case, but I'd be interested to hear what others think. Here my assessment is also different. There are multiple people that = have raised concerns that this could hinder deployment. >=20 > If we can get to consensus to incorporate the PR, and folks come back = later with a more hardware-friendly replacement that doesn't change the = Invariants or increase linkability, I suspect the WG will be amenable to = that. I don=E2=80=99t think to just go with what we have even though there are = concerns, is the right approach and definitely not the approach that was = chosen for other proposals. In the sake of getting version v1 out = quickly, I would think that not incorporating another change that does = not have consensus is the proposer approach. Mirja >=20 > What do folks think? >=20 > Cheers, >=20 >=20 >> On 29 Mar 2018, at 11:39 am, Ian Swett = wrote: >>=20 >> Thanks for the nice summary Jana. >>=20 >> As much as I'd love to have easier crypto HW acceleration, I've ended = up arriving at the same conclusion. I don't want to bite off the work = to do proper multipath in QUIC v1, which I think is the only other = reasonable option of those Christian outlined. >>=20 >> If someone comes up with a way to transform packet number to make it = non-linkable, but doesn't have the downside of making hardware offload = difficult, then I'm open to it. But we've been talking about this for 2 = months without any notable improvements over Martin's PR. >>=20 >> Given we never talk about any issue only once in QUIC, I'm sure this = will come up again, but for the time being I think #1079 is the best = option we have. >>=20 >>=20 >>=20 >> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar = wrote: >> A few quick thoughts as I catch up on this thread. >>=20 >> I spent some time last week working through a design using multiple = PN spaces, and it is quite doable. I suspect we'll head towards multiple = PN spaces as we consider multipath in the future. That said, there is = complexity (as Christian notes). This complexity may be warranted when = doing multipath in v2 or later, but I'm not convinced that this is = necessary as a design primitive for QUICv1.=20 >>=20 >> We may want to creatively use the PN bits in v2, say to encode a path = ID and a PN, for multipath. We want to retain flexibility in these bits = going into v2. We've used encryption to ensure that we don't lose = flexibility elsewhere in the header, and it follows that we should use = PNE to retain flexibility in these bits as well. (Simplicity of design = is the other value in using PNE, since handling migration linkability is = non-trivial without it.) >>=20 >> This leaves the question of HW acceleration being at loggerheads with = the design in PR #1079. First, I expect that the primary benefit of = acceleration will be in DC environments. Yes, there are some gains to be = had in serving the public Internet as well, but I'm unconvinced that = this is the driving use case for hardware acceleration. I understand = that others may disagree with me here. >>=20 >> AFAIK, QUIC has not been used in DC environments yet. I expect there = are other things in the protocol that we'd want to change as we gain = experience deploying QUIC in DCs. Spinning up a new version to try QUIC = within DCs is not only appropriate, I would recommend it. This allows = for rapid iterations internally, and the experience can drive subsequent = changes to QUIC. It's what *I* would do if I was to deploy QUIC inside a = DC. >>=20 >> So, in short, I think we should go ahead with PR# 1079. This ensures = that future versions are guaranteed the flexibility to change the PN = bits for better support of HW acceleration or multipath or = what-have-you. >>=20 >> - jana >>=20 >> On Mar 26, 2018 9:41 AM, "Christian Huitema" = wrote: >>=20 >> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote: >>> Looking at = https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_archit= ecture it seems to imply a large range of server, desktop and mobile = chips all have a CPU instruction set available to do AES acceleration = and other similar operations (other instruction sets are also = available). >>>=20 >>> If we are considering the AES instructions then it looks like it is = (or at least will be in the near future) a sizeable proportion of the = public internet have it to be used. >>>=20 >>=20 >> Certainly, but that's not the current debate. PR #1079 is fully = compatible with use of the AES instructions. The issue of the debate is = that the mechanism in PR #1079 required double buffering, first encrypt = the payload, then use the result of the encryption to encrypt the PN. = This is not an issue in a software implementation that can readily = access all bytes of the packet from memory, but it may be an issue in = some hardware implementations that are designed to do just one pass over = the data. >>=20 >>=20 >> -- Christian Huitema >>=20 >>=20 >>=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Wed Apr 4 05:54:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB239127444 for ; Wed, 4 Apr 2018 05:54:13 -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 lYeZv9tX-Ans for ; Wed, 4 Apr 2018 05:54:12 -0700 (PDT) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1629412741D for ; Wed, 4 Apr 2018 05:54:12 -0700 (PDT) Received: by mail-qk0-x243.google.com with SMTP id o205so22303864qke.3 for ; Wed, 04 Apr 2018 05:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KUQd+qIM1UNa0yoN3Sl7wHAYTKxLInt9hDVj1bAxbzI=; b=WsQMaTXnUyPvaBPw/c/PiUtUepVSb/9oMIOGnhN6zjAwD8cF5KDniaiyi58pn9jhpw zfBHO4R8n+h60LhqD8FrulNNalUMBfqNZ4m7Wk4BDpBnMJKFhiUrCpsGz222aHurdaM7 lTd7I9NOnis91o+jhg9AJrQlFDMEgLhZ5vkz6+2l6hr2voYQN296VNhDvNb7Qp6e0Nd1 CNKt9k6OLUBemu/S48mc9hqHELBJ9N3yu/mPY9C5Mmr90JNRGVJCxIXxDlJwtFIS4qLs Zzxau8gxwsedgMJf7I9JQ3dDz9WQWdyg2DIzh6T/5ASUiEJ5ZfTNvgiEHszQyrsNxKUw w33w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=KUQd+qIM1UNa0yoN3Sl7wHAYTKxLInt9hDVj1bAxbzI=; b=eQJVa9VcypOZ3MTTfUjOdwtEfgKW5vac4ybH4M0rVN6ZGbseGs23dRFLOdfEPdm4Cv W5ltWniz/7Ab9bvOkvuYukYhw9ZiH9Z/L06GgenK+0X8oKGglwFEiKXIWcu+h0AwO2CS a9IHLGaKW7ocFvDPK3nlLtgRD8dVvtBK2aLID2dKpD1K7Cr24LFcn5fFR4e9hCDflXJK 3vpS5oFni6ZHLar82rfkKvQRiNSF2dSVAAfHA+QpKk0BuAxJMbSSgea6Nn34RC3zH9ub 0s6qAxEbOxKpuBGS0IeU7RdU8J+Pfgwm1vlncxjsUUJ8jhoXTN3HSn4TvIvK4VXWVXCU 3rRw== X-Gm-Message-State: ALQs6tDxYqrh4NuZ8tKDzwP2lNg66wBfKKtQjLgOKjl7Ap7f3OG/R/lG Wxe/A9rj2uUVl92ArP2Go895Ig== X-Google-Smtp-Source: AIpwx49fIiomxY4ewMyLYWOe11cz27s35pp2xvEaRRXf1VDCzzdGorZCvI7vuKGkzAtsHGj3FROA/w== X-Received: by 10.55.167.203 with SMTP id q194mr12808838qke.97.1522846451002; Wed, 04 Apr 2018 05:54:11 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id q3sm3973077qke.93.2018.04.04.05.54.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 05:54:10 -0700 (PDT) Date: Wed, 4 Apr 2018 08:54:06 -0400 From: Dmitri Tikhonov To: Willy Tarreau Cc: Mark Nottingham , Lars Eggert , IETF QUIC WG Subject: Re: Getting to consensus on packet number encryption Message-ID: <20180404125405.GA12306@ubuntu-dmitri> Mail-Followup-To: Willy Tarreau , Mark Nottingham , Lars Eggert , IETF QUIC WG References: <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <20180404055848.GA17563@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180404055848.GA17563@1wt.eu> 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, 04 Apr 2018 12:54:14 -0000 On Wed, Apr 04, 2018 at 07:58:48AM +0200, Willy Tarreau wrote: > I already expressed my real dislike (not to say disgust) for protocol > elements encryption for these various reasons and I'm well aware that > my view is generally not shared here. I tend to consider that a properly > working protocol is more important to maintain the internet in good health > and resilient than adding some elements which supposedly will make it > harder to guess what people are doing while their devices spread their > cookies to all ads providers and "like" buttons, are infected with malware > picking their clear text conversations, and some authorities are decrypting > communications by forcing keys directly on their devices. In the end we're > just being more selective about who has access to their activity. BTW, you > know the saying, there are two types of people, those how believe their > conversations have never been intercepted, and those who think they know > where it happened ;-) +1. > Now a last concern about performance : sure, processors do provide AES > instructions, but these ones are not that fast, perform a single round, > and need to run in loops (10 rounds for AES-128 if my memory serves me > right). For hosting providers, more CPU cycles means using more hardware. In other words, money. This could have an impact on the adoption of QUIC. - Dmitri. From nobody Wed Apr 4 05:54:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5038812741D for ; Wed, 4 Apr 2018 05:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va8-La13Cw0s for ; Wed, 4 Apr 2018 05:54:33 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6198D1275FD for ; Wed, 4 Apr 2018 05:54:33 -0700 (PDT) Received: from mail-ot0-f177.google.com (mail-ot0-f177.google.com [74.125.82.177]) by linode64.ducksong.com (Postfix) with ESMTPSA id CAB683A042 for ; Wed, 4 Apr 2018 08:54:32 -0400 (EDT) Received: by mail-ot0-f177.google.com with SMTP id m22-v6so23154064otf.10 for ; Wed, 04 Apr 2018 05:54:32 -0700 (PDT) X-Gm-Message-State: ALQs6tDvEZi+IKoA5mbtsBnj4tPXp/n7qyx44EsNlwCnaDkiNigKJ3FO 0WWUTV50cBmmHLVAyGbPSr3+lYgxy/QRTp01dY4= X-Google-Smtp-Source: AIpwx48dAC1wKfBGStCx8ZsrIAcNJ2IupsPxv90LrnjbLMoyf1HAW6rptjAc4PHb0MXDFEB5Q0wf4IDUjwW2umU+wqg= X-Received: by 2002:a9d:4494:: with SMTP id v20-v6mr2124406ote.397.1522846472551; Wed, 04 Apr 2018 05:54:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.70.23 with HTTP; Wed, 4 Apr 2018 05:54:32 -0700 (PDT) In-Reply-To: <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> From: Patrick McManus Date: Wed, 4 Apr 2018 08:54:32 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Getting to consensus on packet number encryption To: Mark Nottingham Cc: IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="0000000000000b44380569055347" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 12:54:36 -0000 --0000000000000b44380569055347 Content-Type: text/plain; charset="UTF-8" I think its time to move forward with 1079. btw I think its wrong to characterize this as perf vs privacy - its cpu vs bandwidth, the privacy is a must have. 1079 costs cpu (both in hw and sw) and in my mind it really competes with either a multipath-pn-scheme (which we'll table for v2) or a one pass scheme with a new nonce rather than making the packet number do double duty. The latter is bandwidth tax and I'd rather pay the cpu cost. The only serious alternative to me is to take the timeline hit and work out multiple packet number spaces for v1 (which are likely part of multipath anyhow). -P On Wed, Apr 4, 2018 at 12:58 AM, Mark Nottingham wrote: > Hi everyone, > > The editors have told your chairs that this issue is starting to block > progress on other aspects of QUIC. Coming to consensus on it soon (i.e., > before Stockholm, if possible) would be good. > > It looks like this thread has come to a natural pause. Reading through it, > I think we agree there are some unpleasant tradeoffs here, but so far we > have only one concrete proposal -- PR#1079. > > My AU$.05 - While we're chartered to produce a protocol that's encrypted > as much as operational concerns allow, and that privacy is a natural > extension of that (especially in light of RFC7258 and RFC6973), there is no > *requirement* that we produce a protocol that is able to be accelerated by > hardware. > > That being the case, I think we need to ask ourselves if we believe that > inclusion of PR#1079 will significantly inhibit deployment of the protocol. > Based on the discussion so far, that doesn't seem to be the case, but I'd > be interested to hear what others think. > > If we can get to consensus to incorporate the PR, and folks come back > later with a more hardware-friendly replacement that doesn't change the > Invariants or increase linkability, I suspect the WG will be amenable to > that. > > What do folks think? > > Cheers, > > > > On 29 Mar 2018, at 11:39 am, Ian Swett ietf.org> wrote: > > > > Thanks for the nice summary Jana. > > > > As much as I'd love to have easier crypto HW acceleration, I've ended up > arriving at the same conclusion. I don't want to bite off the work to do > proper multipath in QUIC v1, which I think is the only other reasonable > option of those Christian outlined. > > > > If someone comes up with a way to transform packet number to make it > non-linkable, but doesn't have the downside of making hardware offload > difficult, then I'm open to it. But we've been talking about this for 2 > months without any notable improvements over Martin's PR. > > > > Given we never talk about any issue only once in QUIC, I'm sure this > will come up again, but for the time being I think #1079 is the best option > we have. > > > > > > > > On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar wrote: > > A few quick thoughts as I catch up on this thread. > > > > I spent some time last week working through a design using multiple PN > spaces, and it is quite doable. I suspect we'll head towards multiple PN > spaces as we consider multipath in the future. That said, there is > complexity (as Christian notes). This complexity may be warranted when > doing multipath in v2 or later, but I'm not convinced that this is > necessary as a design primitive for QUICv1. > > > > We may want to creatively use the PN bits in v2, say to encode a path ID > and a PN, for multipath. We want to retain flexibility in these bits going > into v2. We've used encryption to ensure that we don't lose flexibility > elsewhere in the header, and it follows that we should use PNE to retain > flexibility in these bits as well. (Simplicity of design is the other value > in using PNE, since handling migration linkability is non-trivial without > it.) > > > > This leaves the question of HW acceleration being at loggerheads with > the design in PR #1079. First, I expect that the primary benefit of > acceleration will be in DC environments. Yes, there are some gains to be > had in serving the public Internet as well, but I'm unconvinced that this > is the driving use case for hardware acceleration. I understand that others > may disagree with me here. > > > > AFAIK, QUIC has not been used in DC environments yet. I expect there are > other things in the protocol that we'd want to change as we gain experience > deploying QUIC in DCs. Spinning up a new version to try QUIC within DCs is > not only appropriate, I would recommend it. This allows for rapid > iterations internally, and the experience can drive subsequent changes to > QUIC. It's what *I* would do if I was to deploy QUIC inside a DC. > > > > So, in short, I think we should go ahead with PR# 1079. This ensures > that future versions are guaranteed the flexibility to change the PN bits > for better support of HW acceleration or multipath or what-have-you. > > > > - jana > > > > On Mar 26, 2018 9:41 AM, "Christian Huitema" > wrote: > > > > On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote: > >> Looking at https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_ > AMD_x86_architecture it seems to imply a large range of server, desktop > and mobile chips all have a CPU instruction set available to do AES > acceleration and other similar operations (other instruction sets are also > available). > >> > >> If we are considering the AES instructions then it looks like it is (or > at least will be in the near future) a sizeable proportion of the public > internet have it to be used. > >> > > > > Certainly, but that's not the current debate. PR #1079 is fully > compatible with use of the AES instructions. The issue of the debate is > that the mechanism in PR #1079 required double buffering, first encrypt the > payload, then use the result of the encryption to encrypt the PN. This is > not an issue in a software implementation that can readily access all bytes > of the packet from memory, but it may be an issue in some hardware > implementations that are designed to do just one pass over the data. > > > > > > -- Christian Huitema > > > > > > > > -- > Mark Nottingham https://www.mnot.net/ > > --0000000000000b44380569055347 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think its time to move forward with 1079.

btw I think its wrong to characterize this as perf vs priva= cy - its cpu vs bandwidth, the privacy is a must have.

<= /div>
1079 costs cpu (both in hw and sw) and in my mind it really compe= tes with either a multipath-pn-scheme (which we'll table for v2) or a o= ne pass scheme with a new nonce rather than making the packet number do dou= ble duty. The latter is bandwidth tax and I'd rather pay the cpu cost.<= /div>

The only serious alternative to me is to take the = timeline hit and work out multiple packet number spaces for v1 (which are l= ikely part of multipath anyhow).

-P
=

O= n Wed, Apr 4, 2018 at 12:58 AM, Mark Nottingham <mnot@mnot.net> = wrote:
Hi everyone,

The editors have told your chairs that this issue is starting to block prog= ress on other aspects of QUIC. Coming to consensus on it soon (i.e., before= Stockholm, if possible) would be good.

It looks like this thread has come to a natural pause. Reading through it, = I think we agree there are some unpleasant tradeoffs here, but so far we ha= ve only one concrete proposal -- PR#1079.

My AU$.05 - While we're chartered to produce a protocol that's encr= ypted as much as operational concerns allow, and that privacy is a natural = extension of that (especially in light of RFC7258 and RFC6973), there is no= *requirement* that we produce a protocol that is able to be accelerated by= hardware.

That being the case, I think we need to ask ourselves if we believe that in= clusion of PR#1079 will significantly inhibit deployment of the protocol. B= ased on the discussion so far, that doesn't seem to be the case, but I&= #39;d be interested to hear what others think.

If we can get to consensus to incorporate the PR, and folks come back later= with a more hardware-friendly replacement that doesn't change the Inva= riants or increase linkability, I suspect the WG will be amenable to that.<= br>
What do folks think?

Cheers,


> On 29 Mar 2018, at 11:39 am, Ian Swett <ianswett=3D40google.com@dmarc.ietf.org> wro= te:
>
> Thanks for the nice summary Jana.
>
> As much as I'd love to have easier crypto HW acceleration, I'v= e ended up arriving at the same conclusion.=C2=A0 I don't want to bite = off the work to do proper multipath in QUIC v1, which I think is the only o= ther reasonable option of those Christian outlined.
>
> If someone comes up with a way to transform packet number to make it n= on-linkable, but doesn't have the downside of making hardware offload d= ifficult, then I'm open to it.=C2=A0 But we've been talking about t= his for 2 months without any notable improvements over Martin's PR.
>
> Given we never talk about any issue only once in QUIC, I'm sure th= is will come up again, but for the time being I think #1079 is the best opt= ion we have.
>
>
>
> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar <jri.ietf@gmail.com> wrote:
> A few quick thoughts as I catch up on this thread.
>
> I spent some time last week working through a design using multiple PN= spaces, and it is quite doable. I suspect we'll head towards multiple = PN spaces as we consider multipath in the future. That said, there is compl= exity (as Christian notes). This complexity may be warranted when doing mul= tipath in v2 or later, but I'm not convinced that this is necessary as = a design primitive for QUICv1.
>
> We may want to creatively use the PN bits in v2, say to encode a path = ID and a PN, for multipath. We want to retain flexibility in these bits goi= ng into v2. We've used encryption to ensure that we don't lose flex= ibility elsewhere in the header, and it follows that we should use PNE to r= etain flexibility in these bits as well. (Simplicity of design is the other= value in using PNE, since handling migration linkability is non-trivial wi= thout it.)
>
> This leaves the question of HW acceleration being at loggerheads with = the design in PR #1079. First, I expect that the primary benefit of acceler= ation will be in DC environments. Yes, there are some gains to be had in se= rving the public Internet as well, but I'm unconvinced that this is the= driving use case for hardware acceleration. I understand that others may d= isagree with me here.
>
> AFAIK, QUIC has not been used in DC environments yet. I expect there a= re other things in the protocol that we'd want to change as we gain exp= erience deploying QUIC in DCs. Spinning up a new version to try QUIC within= DCs is not only appropriate, I would recommend it. This allows for rapid i= terations internally, and the experience can drive subsequent changes to QU= IC. It's what *I* would do if I was to deploy QUIC inside a DC.
>
> So, in short, I think we should go ahead with PR# 1079. This ensures t= hat future versions are guaranteed the flexibility to change the PN bits fo= r better support of HW acceleration or multipath or what-have-you.
>
> - jana
>
> On Mar 26, 2018 9:41 AM, "Christian Huitema" <huitema@huitema.net> wrote:
>
> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote:<= br> >> Looking at = https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x= 86_architecture it seems to imply a large range of server, desktop and = mobile chips all have a CPU instruction set available to do AES acceleratio= n and other similar operations (other instruction sets are also available).=
>>
>> If we are considering the AES instructions then it looks like it i= s (or at least will be in the near future) a sizeable proportion of the pub= lic internet have it to be used.
>>
>
> Certainly, but that's not the current debate. PR #1079 is fully co= mpatible with use of the AES instructions. The issue of the debate is that = the mechanism in PR #1079 required double buffering, first encrypt the payl= oad, then use the result of the encryption to encrypt the PN. This is not a= n issue in a software implementation that can readily access all bytes of t= he packet from memory, but it may be an issue in some hardware implementati= ons that are designed to do just one pass over the data.
>
>
> -- Christian Huitema
>
>
>

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


--0000000000000b44380569055347-- From nobody Wed Apr 4 06:11:11 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0FF1289B0 for ; Wed, 4 Apr 2018 06:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfe1yVYFsi7J for ; Wed, 4 Apr 2018 06:11:06 -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 0663E127333 for ; Wed, 4 Apr 2018 06:11:06 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id m83so26261614ioi.8 for ; Wed, 04 Apr 2018 06:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W4O5XNvU9C6PAWsBKfN/Dz6Zx/DnejLe5WdXRb9npKI=; b=Jxg8ak2BiqyH++x/I9RfQejzYza3UnPq15Xl0+kzM3Ty0uHWGutxtjFoM1o1BhFnRM qRe2rs2X0TDBokNxPkOrzau8vkhuJUGr25N2yczYAmGbVMMLKYdIqWbAVNschAKJnsJe xvvyBeBYKOEC1I9C7acfLrsEg4aDwgAkgtAkXajmsDrGfYOaJzzEtrCds2P7vk87XFcG 9rNa4IqdA4HdRFuuiHVFx3ccFBjUvf9MBvT30uMsKbommfhnwesYm1pk3LIfjbQDYkyy uCcgzbevzgG+/r9dHgbQQqNXXT1xtZr33b215fsa5c4k9W9429wJjZVNNFqmhJB7IiYF YECQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W4O5XNvU9C6PAWsBKfN/Dz6Zx/DnejLe5WdXRb9npKI=; b=dR9wrwFR0zVUDM6DQj5o4TBkTWqG4X8F+Eoc5krvHqaZj5q4IOzVIkTPzh8v3llKvx YZx0jAHuEDqJxgi92JJl2Xb9rasAV/9R/orx6dUKGrCD28quUF8HF/lv4MoJ0qaMjlpW yTpp8etH1hbdgEPZemsi1SBOSePKm6V+amgFss74JLiUN1n0ngRzJx88KqXsMcO4Koyc dXUVOuZkQ+xrG2N2Z6uIlUbebvvc9K7DJB71oEC8/0/LgwTX0zqWIJIph+F32Y/ypsly CO7rKkRMLjUCJs1UFAP2mT42GZSpxnJYu+/LBWa5dvg02TiiEx16gKaq9r0oyLeVZ9o5 ZiRw== X-Gm-Message-State: ALQs6tAkYMlWSXNE/TERxG+dhbB09BqHp8r1Kt/ZEvfB/nURchED0Xyi oGde3V+Vjcgsh8EUPfg0IHTQtBmz81gDXd3UcZeanA== X-Google-Smtp-Source: AIpwx4+wswoNIcBXpJI1WWIWLCGhMjx63FCw8yysHxlufFey/N66XhqNPBo1M068gbOd2ExFnHUxhQghqilNyTk2M6Y= X-Received: by 10.107.12.202 with SMTP id 71mr16011999iom.63.1522847465141; Wed, 04 Apr 2018 06:11:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Wed, 04 Apr 2018 13:10:53 +0000 Message-ID: Subject: Re: UDP send costs in Linux To: Subodh Iyengar Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113fc42c3588bd0569058ea4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 13:11:08 -0000 --001a113fc42c3588bd0569058ea4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I hope some of these patches will be available soon, but I'm not sure if soon is a month or 6. On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar wrote: > Thanks for sharing this Ian. > > > This definitely matches some of the observations we've seen as well in th= e > UDP write path. Some of the other paths that we saw that added overhead w= as > the route table lookup in linux udp stack. Connected UDP sockets did > amortize that. > > > I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is ther= e > any indication of the timeline for these patches to make it to linux? Wou= ld > be happy to try any of these out to help iron out the API. > > > Subodh > ------------------------------ > *From:* QUIC on behalf of Ian Swett > > *Sent:* Tuesday, April 3, 2018 5:20:08 PM > *To:* IETF QUIC WG > *Subject:* UDP send costs in Linux > > One challenge with QUIC at the moment is the increased CPU cost of sendin= g > UDP packets vs TCP payloads. I've seen this across every platform Google > has deployed QUIC on, so it's a widespread issue. > > Here's an excellent presentation on what's causing the increased CPU > consumption on Linux from Willem de Bruijn(UDP starts on slide 9). > http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf > > And while you're thinking of CPU usage, it's worth looking at the > presentation on timing wheel based packet pacing(which is minimum release > time based) and is ideal for QUIC(and TCP for that matter): > https://conferences.sigcomm.org/sigcomm/2017/files/program/ts-9-4-carouse= l.pdf > > > -Ian > --001a113fc42c3588bd0569058ea4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I hope some of these patches will be available soon, but I= 'm not sure if soon is a month or 6.

On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar <subodh@fb.com> wrote:

Thanks for sharing this Ian.


This definitely matches some of t= he observations we've seen as well in the UDP write path. Some of the o= ther paths that we saw that added overhead was the route table lookup in li= nux udp stack. Connected UDP sockets did amortize that.


I'm looking forward to a smar= ter sendmmsg with GSO and zero copy. Is there any indication of the timelin= e for these patches to make it to linux? Would be happy to try any of these= out to help iron out the API.


Subodh

From: = QUIC <quic-bo= unces@ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@d= marc.ietf..org>
Sent: Tuesday, April 3, 2018 5:20:08 PM
To: IETF QUIC WG
Subject: UDP send costs in Linux
=C2=A0
One challenge with QUIC at the moment is the increased CPU= cost of sending UDP packets vs TCP payloads.=C2=A0 I've seen this acro= ss every platform Google has deployed QUIC on, so it's a widespread iss= ue.

Here's an excellent presentation on what's causing the increas= ed CPU consumption on Linux from=C2=A0Willem de Bruijn(UDP starts on slide = 9).

And while you're thinking of CPU usage, it's worth looking at = the presentation on timing wheel based packet pacing(which is minimum relea= se time based) and is ideal for QUIC(and TCP for that matter):=C2=A0https://conferences.sigcomm.or= g/sigcomm/2017/files/program/ts-9-4-carousel.pdf

-Ian
--001a113fc42c3588bd0569058ea4-- From nobody Wed Apr 4 07:02:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D275127522 for ; Wed, 4 Apr 2018 07:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 KYJVujwy8vBG for ; Wed, 4 Apr 2018 07:02:10 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176611205D3 for ; Wed, 4 Apr 2018 07:02:10 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id p126-v6so2679533ybg.8 for ; Wed, 04 Apr 2018 07:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ekNqahNByWHH0PDAJA42hPMhwZ9U7fYUMJmlxi8VSM0=; b=g5TAyD/+u6oevQejGacYb42HJ16VetSvWEIMGuHyg4BPgfCziV2ne/jZwgeRSQxJ1r mk9GgASpe3LoNDHy2hJW2lA5gXXiy4sdg7hleC3hhmLsJ1V76qqv1x1JLVHp5Cl+dpuq WGMAT8rOw/twbwMZJw9C26ia1EIZ1Dc1sCthB3Bk/I/ErclCG+5YfZlXRPf3XdDWykD5 662tzoZ22FXubKxag9ko3rzmSEFqJ5cjQZVNgs1MRMrCvH/OQw6v1HXKLVTy1+HJZrQy PH23oRKjHgd+BUddJClsyIHJVhocVxmrz3QEb95KvebDLI5e8aV9EWxgz+JocFEQUUrZ bpRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=ekNqahNByWHH0PDAJA42hPMhwZ9U7fYUMJmlxi8VSM0=; b=KJwfNwVLz9P9032EoHjpKfU3+zeKIDOb5wjDFWoXwgamYOUp6KuVLZDYUiZipNMyMM SZhCwrtvi3PfoNUmntQNdvfh7rBm8KKOFqgxQiyHsspWLwbmTx+sZxa+DZzl/QvlHk0Z K32rkXKo97lVtAdqHzMrzX2HN7Gmv/KVUs18PEP3V09csQL/tC961R790VRJuXK2v8Sv 0ndSylQ7ISOYWrKE2uqKSycmAADRRvIBJDFHcQG951PGjGkuJWFuOmH5+TZYujyGFXOD K7fcakt24BpZZsLOrSFpqQbdwjkpymwIFN8OM7DTG0dXl1Zo8JOenIShXZ9DZlzZcZXW E4vg== X-Gm-Message-State: ALQs6tDg6uaWD+onw2ky0sU/pL4xMMcC8DfW798n/c0zxTFKbWYIy1EZ 0Ai8+f2gjwKvIwUCR2iRdxCEdiZsE09WhQew36s= X-Google-Smtp-Source: AIpwx4+HLRoTui/mw30itvNcXyq4NW4Ap1o6qzgIadvs/cklHPrR8y8kQqkJj53y7tvmzfnMQaB8RcaFoo4AoFFrB0M= X-Received: by 10.129.199.13 with SMTP id m13mr1992259ywi.279.1522850528848; Wed, 04 Apr 2018 07:02:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:e757:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 07:02:08 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> From: Spencer Dawkins at IETF Date: Wed, 4 Apr 2018 09:02:08 -0500 Message-ID: Subject: Re: Getting to consensus on packet number encryption To: Patrick McManus Cc: Mark Nottingham , Lars Eggert , IETF QUIC WG Content-Type: multipart/alternative; boundary="089e0821fc0cd16f630569064425" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 14:02:12 -0000 --089e0821fc0cd16f630569064425 Content-Type: text/plain; charset="UTF-8" It's my intention to let the QUIC working group be the QUIC working group most of the time between now and Montreal. Having said that ... On Wed, Apr 4, 2018 at 7:54 AM, Patrick McManus wrote: > I think its time to move forward with 1079. > > btw I think its wrong to characterize this as perf vs privacy - its cpu vs > bandwidth, the privacy is a must have. > > 1079 costs cpu (both in hw and sw) and in my mind it really competes with > either a multipath-pn-scheme (which we'll table for v2) or a one pass > scheme with a new nonce rather than making the packet number do double > duty. The latter is bandwidth tax and I'd rather pay the cpu cost. > > The only serious alternative to me is to take the timeline hit and work > out multiple packet number spaces for v1 (which are likely part of > multipath anyhow). > This makes sense to me (as an individual, which doesn't actually matter), but does prod me to ask whether people are fairly confident that if multipath needs multiple packet number spaces, that this is something that could be added after QUICv1. Thanks, Spencer, as curious responsible AD --089e0821fc0cd16f630569064425 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's my intention to let the QUIC working group be the= QUIC working group most of the time between now and Montreal. Having said = that ...

On Wed, A= pr 4, 2018 at 7:54 AM, Patrick McManus <pmcmanus@mozilla.com> wrote:
I think= its time to move forward with 1079.

btw I think i= ts wrong to characterize this as perf vs privacy - its cpu vs bandwidth, th= e privacy is a must have.

1079 costs cpu (bot= h in hw and sw) and in my mind it really competes with either a multipath-p= n-scheme (which we'll table for v2) or a one pass scheme with a new non= ce rather than making the packet number do double duty. The latter is bandw= idth tax and I'd rather pay the cpu cost.

The = only serious alternative to me is to take the timeline hit and work out mul= tiple packet number spaces for v1 (which are likely part of multipath anyho= w).

This makes sense to me (as = an individual, which doesn't actually matter), but does prod me to ask = whether people are fairly confident that if multipath needs multiple packet= number spaces, that this is something that could be added after QUICv1.=C2= =A0

Thanks,

Spencer, as c= urious responsible AD=C2=A0
--089e0821fc0cd16f630569064425-- From nobody Wed Apr 4 07:18:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A05012D574 for ; Wed, 4 Apr 2018 07:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 IA4pRu0bpUne for ; Wed, 4 Apr 2018 07:18:33 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 9C51712D0C3 for ; Wed, 4 Apr 2018 07:18:33 -0700 (PDT) Received: from mail-ot0-f179.google.com (mail-ot0-f179.google.com [74.125.82.179]) by linode64.ducksong.com (Postfix) with ESMTPSA id 04EDF3A060 for ; Wed, 4 Apr 2018 10:18:32 -0400 (EDT) Received: by mail-ot0-f179.google.com with SMTP id h55-v6so21973301ote.9 for ; Wed, 04 Apr 2018 07:18:32 -0700 (PDT) X-Gm-Message-State: ALQs6tC3zuyAar3QLiXzjDnMPagiJuUV4MT3eu2+YLOaCyihCWy+JwlE IjV2bLTWt5VgodMrY36WF0QQtrma13h3foQ4wMM= X-Google-Smtp-Source: AIpwx4/nil1bpcuUjyaoye4j9g/UKbHmfCunlRcmw8k5DH5ST19oFXvxo0YqGw/DRVNJvXqKLgicoVJ4vm/0D8B1vhY= X-Received: by 2002:a9d:285d:: with SMTP id h29-v6mr10450655otd.205.1522851511710; Wed, 04 Apr 2018 07:18:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.70.23 with HTTP; Wed, 4 Apr 2018 07:18:31 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> From: Patrick McManus Date: Wed, 4 Apr 2018 10:18:31 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Getting to consensus on packet number encryption To: Spencer Dawkins at IETF Cc: Patrick McManus , Mark Nottingham , Lars Eggert , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000066b9a70569067f12" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 14:18:35 -0000 --00000000000066b9a70569067f12 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 4, 2018 at 10:02 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > This makes sense to me (as an individual, which doesn't actually matter), > but does prod me to ask whether people are fairly confident that if > multipath needs multiple packet number spaces, that this is something that > could be added after QUICv1. > > imo yes, we could add them in v2 without runinng afoul of the invariants. --00000000000066b9a70569067f12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 4, 2018 at 10:02 AM, Spencer Dawkins at IETF <= spencerdawkins.ietf@gmail.com> wrote:
This makes sense to me (as an individua= l, which doesn't actually matter), but does prod me to ask whether peop= le are fairly confident that if multipath needs multiple packet number spac= es, that this is something that could be added after QUICv1.=C2=A0

imo yes, we could add t= hem in v2 without runinng afoul of the invariants.

--00000000000066b9a70569067f12-- From nobody Wed Apr 4 07:32:14 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE8B126CBF for ; Wed, 4 Apr 2018 07:32:13 -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 wU6-8nvLNmvY for ; Wed, 4 Apr 2018 07:32:03 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4DF12DDD2 for ; Wed, 4 Apr 2018 07:32:03 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id EB5E7340D70; Wed, 4 Apr 2018 16:32:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.23163); Wed, 4 Apr 2018 16:32:00 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 4 Apr 2018 16:32:00 +0200 (CEST) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50607958; Wed, 04 Apr 2018 16:32:00 +0200 From: Brian Trammell (IETF) Message-Id: <2DB3AC71-89B1-425C-8128-E673D34B7AFA@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_E8D71B99-62DC-4529-B485-A05896A0965E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Getting to consensus on packet number encryption Date: Wed, 4 Apr 2018 16:31:59 +0200 In-Reply-To: <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> Cc: Lars Eggert To: IETF QUIC WG , Mark Nottingham References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 14:32:13 -0000 --Apple-Mail=_E8D71B99-62DC-4529-B485-A05896A0965E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Mark, all, IMO the decision as to whether packet number encryption is the right = thing to do depends on the design we settle on for multipath, which I = know is not very helpful with respect to "we need to make a decision = now": - If we end up with a multipath design with a single PN space across all = subflows for a given MP connection -- a design which does have very nice = properties -- then PN encryption seems to be mandatory to prevent = trivial linkability across subflows. - If we end up with a multipath design that provides multipath as layer = 4.5 sitting atop multiple layer 4 connections (a la MP-TCP), then PN = encryption is potentially nice to have for ossification prevention, but = isn't very useful for much else AFAICT. The fact that I believe the PN encryption question in V1 depends on a = design choice in a V2 feature indicates that my opinion should logically = be that PN encryption is not necessary for V1, but that we should work = on improving what we have in #1079 to make it possible to easily offload = to hardware, as a V2 feature. Of course, it's more complicated than that, because isn't it always. Way = more detail below (or just read draft-hardie-path-signals)... Why encrypt packet numbers? --------------------------- There are three broad justifications I've seen in the discussion to date = for packet number encryption: (1) "we're chartered to produce a protocol that's encrypted as much as = operational concerns allow" -- like Mirja, I don't read the charter this = way, though I acknowledge that might be a minority view. "Encrypt all = the things" is a very nice organizing principle for work on QUIC, but = without understanding (and coming to consensus to) the reasons *why* we = want to encrypt the things, it is as useful a principle as "QUIC should = be as blue as possible". So we should talk about why we want to encrypt the PN: (2) Ossification prevention. There seems to be rough consensus in the WG = that exposing packet numbers will necessarily add them to the = "descriptive invariants" -- i.e. parts of the wire image that we have = not promised to keep the same but that will become difficult to change = in future versions. I believe this more on some days, and less on others. On the one hand, most of the ossification that has happened to TCP's = internal machinery happened because middleboxes could actually provide = some perceived value to at least the person who approved the purchase, = by understanding, reacting to, and modifying seq and ack numbers as well = as tracking state. The QUIC packet number alone does not provide enough = of a surface for middleboxes to do very much with it without breaking = the protocol in ways that would become immediately apparent during = testing. On the other hand, naive attempts to apply TCP thinking to QUIC could = lead to on-path breakage driven by PN inspection, and the built-in = fallback to TCP could mask some of the issues this causes. (cf. Happy = Eyeballs, which makes IPv6 migration less disruptive, also makes it less = successful -- something like 10% of the Alexa top million sites that = "support IPv6" from a DNS standpoint don't really accept connections). Certainly, PN encryption is the conceptually simplest way to obfuscate = PN behavior, if we decide that it is necessary for us to obfuscate the = PN in V1 in order to preserve the ability to deploy PN encryption in V2. (3) Linkability prevention. IMO this is only really relevant in a = multipath situation, where the multipath design uses a single packet = number space across all subflows (as noted above). Unintentional (on the = part of the client) NAT rebinding in the presence of a server CID is = already trivially linkable, and not particularly sophisticated traffic = analysis in the middle can build small anonymity groups for migration = based on timing alone, so PN encryption doesn't help much in the case = that a rebinding might happen without client permission. (#include = "brian_is_a_traffic_analysis_nihilist.md") I actually find a fourth, more abstract reason more compelling than any = of these: (4) The path should only get to see stuff that's explicitly meant for = the path. The packet number, with its present semantics, has no explicit = utility for on-path devices. (It might have *implicit* utility for = on-path devices, which I address below.) Why not encrypt packet numbers? ------------------------------- There are similarly two broad justifications for not encrypting packet = numbers: (1) Performance and scalability. Encrypting and decrypting packet = numbers takes additional CPU, and two-pass encryption lends itself = poorly to encryption offload. It's difficult to make judgements based on this without a more detailed = performance analysis. There are lots of things that might make QUIC slow = -- an assumption in kernel UDP interfaces that UDP doesn't have to be = fast, for instance -- and in the spirit of engineering we should address = these in the order of their performance impact, based to the extent = possible on real measurements of actual prototypes of the mechanisms = proposed. I recognize the tension between QUIC's design principle of = transport-as-continuous-experiment and the desire of people who make = chips to have a draft protocol they can implement offload for as early = as possible, and the tension between the flexibility that userspace = implementation affords and the restrictions on what is easy to do in = hardware. I also recognize that some of the people who would deploy = QUIC might not if it means they have to scale their backends = multiplicatively due to increased CPU requirements of a non-offloadable = protocol. Hence I think we should work to make something like 1079 more = offloadable. (2) Utility to on-path devices. The path can use the packet number for = various forms of classification (i.e., "is this probably QUIC?") and = state tracking ("does this look like a valid packet for a flow I know = about?"), as well as passive measurement and diagnostic purposes (i.e., = for one-point upstream loss and reordering measurement, as well as for = rejecting loss and reordered spin edges with a single spin bit). I'm not sure any of these are really good uses of a cleartext packet = number. In each of these cases a cleartext packet happens to share some = properties with the ideal signals for each particular task. We should decide for each of these cases whether they are important, = then design specific signals for each of them. The spin bit + VEC = discussed in London for passive latency measurement (and to be described = in an individual draft we'll submit shortly for consideration for = adoption) is one example of this. Passive RTT measurement can also be = achieved with a cleartext PN and PN echo, but the spin+VEC has superior = measurability characteristics as well as superior efficiency. = Examination of other uses might lead us to add a signal back to the wire = image that counts up kind of like a packet number, but need not = necessarily be tied to the number the transport uses for its own = internals. (Or, as above, tl;dr, see draft-hardie-path-signals) Cheers, Brian > On 4 Apr 2018, at 06:58, Mark Nottingham wrote: >=20 > Hi everyone, >=20 > The editors have told your chairs that this issue is starting to block = progress on other aspects of QUIC. Coming to consensus on it soon (i.e., = before Stockholm, if possible) would be good. >=20 > It looks like this thread has come to a natural pause. Reading through = it, I think we agree there are some unpleasant tradeoffs here, but so = far we have only one concrete proposal -- PR#1079. >=20 > My AU$.05 - While we're chartered to produce a protocol that's = encrypted as much as operational concerns allow, and that privacy is a = natural extension of that (especially in light of RFC7258 and RFC6973), = there is no *requirement* that we produce a protocol that is able to be = accelerated by hardware. >=20 > That being the case, I think we need to ask ourselves if we believe = that inclusion of PR#1079 will significantly inhibit deployment of the = protocol. Based on the discussion so far, that doesn't seem to be the = case, but I'd be interested to hear what others think. >=20 > If we can get to consensus to incorporate the PR, and folks come back = later with a more hardware-friendly replacement that doesn't change the = Invariants or increase linkability, I suspect the WG will be amenable to = that. >=20 > What do folks think? >=20 > Cheers, --Apple-Mail=_E8D71B99-62DC-4529-B485-A05896A0965E 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlrE4d8ACgkQihK3vwvq RqOgdQ/8CKrdxr1DTriUEIJdFv8AWbIc56ocroG/nSw5RDEhHoiYgVpnKU3TM/26 4yrUcgL6WRoyksEpEiMoj8jVIfSUB74thKI2xH3QVUywGzNAX44LDxptVJt9/tWo RX9wRTJRuY+hvUUkG1wlEFsi7afUL8DfDV9CZsif6I7KH31njrAUIk29LL6brvn4 bCxyq/vYrlFSjvkL9oIYup0Z0YnolZjSBE1h2wEDITo0BuvLF5qKRMdbMIzTaCcd aWQn9hxOnX9p4jIYu8xqIcWd6kHwJPEEPw+Y13B7K4t6IPDJSG29bB9cI0VdIM9W wjE+PxfjWdnq+Kkt5oJ4jQF0yyRIIFKhiTC/2y8C+CFS9p/v6DPeOqhCcXvKvXzm UpW4Ay80s4wGIHO9l4AdREBaVoQ2c/AaTzsmJgYtYEHnKiiWMxMbVyDvNkjvfAzL TJ3LiWjLfFIYpbEARwoqgpJguI5rmMQDxm0uUg7QGf7Dxora37X2sgSs8iMpvdjC LE2+PkPuKiJFndOEORNnhePXu+H8RubPde56XJDlhuqpM4u+TyCjpRf+NFbyXow3 TEq+NUzAkzIsijycX6m0aZAf3Qi9N5y0UeWq52VnPr+yCs+AF549c32exR6aRJ79 5TQSBm+3R1uCyam51OH5TfPNikSUKxMU6saTnPTWn0ZaB0tjZZg= =ly9k -----END PGP SIGNATURE----- --Apple-Mail=_E8D71B99-62DC-4529-B485-A05896A0965E-- From nobody Wed Apr 4 07:35:39 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6973F124D68 for ; Wed, 4 Apr 2018 07:35:36 -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 JCXxtiysiAeY for ; Wed, 4 Apr 2018 07:35:32 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 355F9126CBF for ; Wed, 4 Apr 2018 07:35:32 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F1B6234080D; Wed, 4 Apr 2018 16:35:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.23163); Wed, 4 Apr 2018 16:35:30 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 4 Apr 2018 16:35:30 +0200 (CEST) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50608583; Wed, 04 Apr 2018 16:35:30 +0200 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6E0A1422-2F60-4FF1-BD64-A6179752FC3F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Getting to consensus on packet number encryption Date: Wed, 4 Apr 2018 16:35:29 +0200 In-Reply-To: Cc: Mark Nottingham , Lars Eggert , IETF QUIC WG To: Patrick McManus References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 14:35:37 -0000 --Apple-Mail=_6E0A1422-2F60-4FF1-BD64-A6179752FC3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Patrick, > On 4 Apr 2018, at 14:54, Patrick McManus wrote: >=20 > btw I think its wrong to characterize this as perf vs privacy - its = cpu vs bandwidth, the privacy is a must have. I agree with your characterization here, but I'm curious as to what = aspect of privacy PN encryption guarantees. Is there something I'm = missing beyond rendering linkability vastly more difficult for multipath = flows with a single PN space? Thanks, cheers, Brian --Apple-Mail=_6E0A1422-2F60-4FF1-BD64-A6179752FC3F 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlrE4rEACgkQihK3vwvq RqMY4A//b/h+zy+l4cbUNQQxJaF0z4yQ4GAuKBdtfxgmegEfhgAm2oYoL9aT3O7w gI4+HuVQKO3m2TALuZlYCBh3eIAoZwtB9f/IkmELnqmIZs46WzVgGdqkhU9fFD4/ DJ+sIcUy3P/D1Yye3BmKXNk2kWaWrmU6ioL90/C1Yx32VMkVog6LQ4ZrY9y0eJ4D 6G7KpM0XsIKYVNeuaXFc2tLSCOn8b47pQiYaDsc0+MFWkDxjhD8bVKtGa7KQWODy Pyj0h4apQmpICo8cQ8E706nVoJlhVr7pAgSbHb2tCnom3X/Vxbi1RaGx7nKdgdAu as1WBZkn5g6+1avq0BPuhmcuOhjHcn44ZZzI+NwZhdfp5l+gxaM4Pe2tuR0J4Q0z YaP1KfkEGurB6gfVd6BdEkc3pwdNkSvHupODTQHndiG4FhUbVH/oZhvevVOXXTJM w67gBZBBTsSZ3nXXcr2+9ujZqWUTKQ34Y1Azwok9imUBO4Cs4/cjDWMF7Ug5wJxX 4xtXSqVhwU8sCJE8fbfkYjq2Hz3dMYAZIUuUWdDZDXhHmf8IRZjC7l6h3+XG5CvA qpL6TfyTU5DJhsOLs7dtnOfEEAOSXQSHI32E+/GbKkaJdcSP32iKS470nnNmW24X DWWi6s8DwTmyo7T8YRat+KVwRFzaqz0etJgefmL2Jau3EYrK8+s= =B3yq -----END PGP SIGNATURE----- --Apple-Mail=_6E0A1422-2F60-4FF1-BD64-A6179752FC3F-- From nobody Wed Apr 4 07:40:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCB912D88A for ; Wed, 4 Apr 2018 07:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 MYTFkbi4_VjZ for ; Wed, 4 Apr 2018 07:40:17 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id C7A4F12D86E for ; Wed, 4 Apr 2018 07:40:16 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by linode64.ducksong.com (Postfix) with ESMTPSA id 646C63A064 for ; Wed, 4 Apr 2018 10:40:16 -0400 (EDT) Received: by mail-oi0-f50.google.com with SMTP id 188-v6so19434129oih.8 for ; Wed, 04 Apr 2018 07:40:16 -0700 (PDT) X-Gm-Message-State: AElRT7Ea1BXMHr7jo4cCgnIjvtNM62+zqo+CR0GVwFPNWEIKIHHJrffc dnvj/DJLl4kc5PUrHtLilfISR4ie+t+PiBm6O5s= X-Google-Smtp-Source: AIpwx4+wlcro4weRHLaBcCfuMDhlb2aVV1EXAe6D7Qsla3V0fKbu6e0ZaGd9alXZU8OB7ITz6SHVyRh9k4oqaswUS/M= X-Received: by 2002:aca:b2c3:: with SMTP id b186-v6mr5622782oif.337.1522852816117; Wed, 04 Apr 2018 07:40:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.70.23 with HTTP; Wed, 4 Apr 2018 07:40:15 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> From: Patrick McManus Date: Wed, 4 Apr 2018 10:40:15 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Getting to consensus on packet number encryption To: "Brian Trammell (IETF)" Cc: Patrick McManus , Mark Nottingham , Lars Eggert , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000002664d5056906cdd1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 14:40:19 -0000 --0000000000002664d5056906cdd1 Content-Type: text/plain; charset="UTF-8" it is about linkability, but in v1 for mobility (which I wouldn't call multipath but ymmv). On Wed, Apr 4, 2018 at 10:35 AM, Brian Trammell (IETF) wrote: > hi Patrick, > > > On 4 Apr 2018, at 14:54, Patrick McManus wrote: > > > > btw I think its wrong to characterize this as perf vs privacy - its cpu > vs bandwidth, the privacy is a must have. > > I agree with your characterization here, but I'm curious as to what aspect > of privacy PN encryption guarantees. Is there something I'm missing beyond > rendering linkability vastly more difficult for multipath flows with a > single PN space? > > Thanks, cheers, > > Brian > > --0000000000002664d5056906cdd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
it is about linkability, but in v1 for mobility (whic= h I wouldn't call multipath but ymmv).



On Wed, = Apr 4, 2018 at 10:35 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
hi Patrick,

> On 4 Apr 2018, at 14:54, Patrick McManus <pmcmanus@mozilla.com> wrote:
>
> btw I think its wrong to characterize this as perf vs privacy - its cp= u vs bandwidth, the privacy is a must have.

I agree with your characterization here, but I'm curious as to w= hat aspect of privacy PN encryption guarantees. Is there something I'm = missing beyond rendering linkability vastly more difficult for multipath fl= ows with a single PN space?

Thanks, cheers,

Brian


--0000000000002664d5056906cdd1-- From nobody Wed Apr 4 07:43:08 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8353412D958 for ; Wed, 4 Apr 2018 07:43:06 -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 hIELhm_A0r3Z for ; Wed, 4 Apr 2018 07:43:04 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3078212D94F for ; Wed, 4 Apr 2018 07:43:04 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F2241340552; Wed, 4 Apr 2018 16:43:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.26146); Wed, 4 Apr 2018 16:43:02 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 4 Apr 2018 16:43:02 +0200 (CEST) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50609752; Wed, 04 Apr 2018 16:43:02 +0200 From: "Brian Trammell (IETF)" Message-Id: <79C7DEB4-ED9E-49A7-A8BE-875495DB86A6@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_BA28BDB4-0D4A-4B74-BFBA-ADC0D40CFEF1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Getting to consensus on packet number encryption Date: Wed, 4 Apr 2018 16:43:01 +0200 In-Reply-To: Cc: Lars Eggert , Mark Nottingham , IETF QUIC WG To: Patrick McManus References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 14:43:06 -0000 --Apple-Mail=_BA28BDB4-0D4A-4B74-BFBA-ADC0D40CFEF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ah, ok. So intentional mobility, as opposed to unintentional = rebinding... Thanks, got it. (Won't argue the philosophical question of = whether that's multipath or not. :) ) Cheers, Brian > On 4 Apr 2018, at 16:40, Patrick McManus wrote: >=20 > it is about linkability, but in v1 for mobility (which I wouldn't call = multipath but ymmv). >=20 >=20 >=20 > On Wed, Apr 4, 2018 at 10:35 AM, Brian Trammell (IETF) = wrote: > hi Patrick, >=20 > > On 4 Apr 2018, at 14:54, Patrick McManus = wrote: > > > > btw I think its wrong to characterize this as perf vs privacy - its = cpu vs bandwidth, the privacy is a must have. >=20 > I agree with your characterization here, but I'm curious as to what = aspect of privacy PN encryption guarantees. Is there something I'm = missing beyond rendering linkability vastly more difficult for multipath = flows with a single PN space? >=20 > Thanks, cheers, >=20 > Brian >=20 >=20 --Apple-Mail=_BA28BDB4-0D4A-4B74-BFBA-ADC0D40CFEF1 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlrE5HUACgkQihK3vwvq RqMjYBAAx6qMTeWiVk3KOeH+TdWorAQFrt+4bmkvq39w8xwS4FCItA9iWDU4i1x9 QYXNw0VKvr1w6ztIpWY54bGVauDNhIt+9/dK+vpatlc6w1Eo9vA/RHVFc2a37zup d7+Hd+5itHEvldEIaZwT5HGL5FG371aCeO392bpPV7B+tURAH55l4+6h4N235mPr lNBpM4MAxKey6kJvCkfYDdT6lVq1kWLvHomz8VJf7w3qGepgcQ6b2pGyGVxjSi7j VrVk7c4wHJmrk3mNfMCx7D1UQHi5EsdzulvxN6um43pQOQ2mdQK7qsrT+Qdf2cyQ +qPTbMCh2OfCIoFD8XuWmd5p1z8pzjn5/xNveiF4pGGoVx79REuQ7yE9hzQwAc0E SyPuHlhYhTj5jx0k/mAPRUrSwngssXCg60DY7gjlZ3TPCKNv5ajEa0xdbIq65r2Z GvHq6+zx9AKHri++ry+ksI4DL9F/u/M92i9t/9vGYfO4mj/1moIH7axuvqfpZGTb BUmkmIVMJkzGLiClKnPizEh1kA5RWbMTlkAitAzhvT0YtIO1JwgAcPWsze/x6Z+n ZXMOrLmfHaNLV77GWAKpHmfe8/eqrxb3OIPieJqLj0WQ5gH1by5852lxB7r/BZCo JhT51R/ruwC4JO8sj5PzqdUF9yBHf1u4GsXlhvwZ8AqzKaboiEI= =HIV1 -----END PGP SIGNATURE----- --Apple-Mail=_BA28BDB4-0D4A-4B74-BFBA-ADC0D40CFEF1-- From nobody Wed Apr 4 08:33:05 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8437B12DA3E for ; Wed, 4 Apr 2018 08:33:03 -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, UNPARSEABLE_RELAY=0.001] autolearn=unavailable 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 VV0NCW-F_NWz for ; Wed, 4 Apr 2018 08:33:00 -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 EBDE512DA0A for ; Wed, 4 Apr 2018 08:32:59 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id h143-v6so28701166ita.4 for ; Wed, 04 Apr 2018 08:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=aTyqhELuVKSysofcwoyosAhA84iAj62sjx6gmHV/dbE=; b=VIDm+YjYuT4H/kqpoMoJlsSVHhch7y1fx4ylY17ESlm5GdMK+A9sY8BBtOZP0ee++W 0yMeqpr3gquxt+uVBbdBLep1Srqte5BTY/qRHUCraI2Rit0nUp5kKS7Xqu7jg1SHuvAM 1Vhw9xjKXUV/ZBnQXwIxYdLWJggfMNL4Fbm7zAubJNckgu6O5+N4d4sOY/wFKfppyGb6 CoTtKHsxIu4GE+OO9xEdBaBmFRtr47dZVcIETetKw5E4lvwIsTaJm/HaMF361Xuiuu4K aQs7x8CXzQQ3Q5Qa61ZRfLgjL9/ON5u5HvzXVK3wsQ/B2Z1J6AKHvTfJtTaI7F11oycm ZFTQ== 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=aTyqhELuVKSysofcwoyosAhA84iAj62sjx6gmHV/dbE=; b=cTUQXOYGYCfagG5p4GqSUsZ0+O+N2fhdOH0ZfxewSR4LknXIkk9VSa0/VzVFikFQKH qC5xieP8I1RHtY10K1GzKgDO8/p+DhIXx5GbrrAQ/4/WN0DygH9NFvKHJ8alQ6qkFjQO /0QxcPFrFFvfX/LbKSqbDtOTQOYx8iMLf7qe0JdtV+dRwJaiBFvYFg4ZpjqnDVEkUBeI ECCQXRBdEXbP6mVGK7R42PvuexQ8TLp7FF24fHb4yPDkA5Coc2B0+pFA0Ze1Qe84TG/R X/bugMAmltYeSMaWmxki5bItydLj/DI8rsI9X78baLfTTFO2aPQUg3z/+kmU0B6Ec5k/ P/NA== X-Gm-Message-State: ALQs6tCPyrHYbiyX8d8VTv9jy6d6SFv4s+MXENVnU3/BTUYawdIjSqTm prCvY+MgEcTjYxOHyXAtqBlvWx567azLpQuUy2jw8A== X-Google-Smtp-Source: AIpwx4/ERgy0GVTes83al1WtvUuRq7msBGC+iPcaQS97ai0MimgxDmgjNWYA804oGYmjltl2EVh/mIMxDV76Top6UtI= X-Received: by 2002:a24:7088:: with SMTP id f130-v6mr9856271itc.39.1522855979244; Wed, 04 Apr 2018 08:32:59 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Apr 2018 08:32:58 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 4 Apr 2018 08:32:58 -0700 Message-ID: Subject: Re: UDP send costs in Linux To: Ian Swett , Subodh Iyengar Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000afe04c05690789c5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 15:33:03 -0000 --000000000000afe04c05690789c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have no data to add on the Linux UDP stack, but another issue is the lack of netmap support in cloud hosting environments. I have not yet been working with this, but have looked into the problem and asked around. netmap is default in FreeBSD and optional in Linux. But neither works efficiently without a hypervisor patch that is also available for netmap. With support for netmap, the user space application can send directly to the network adapter with very little overhead. There is also dpdk and some other interfaces that might be slightly faster but more vendor specific. Assuming an application has access to optimized netmap, the only hurdle is address lookup, but if the application also manages that, or at least does the caching, there shouldn=E2=80=99t be much in the way of OS interference. Of course, netmap blocks the entire network stack, so no PING or SSH. CloudFlare added a netmap patch so only some traffic would be routed fra the network interface to netmap, and netmap also supports efficient packet forwarding to the OS or other applications. None of this works well in general, but for a cloud host that can be bootet automatically and destroyed rather than serviced, there is some opportunity= . but only if cloud service providers starts adding support their supported images and hypervisors. Not sure if any are working on this now. Mikkel On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc.ietf.= org) wrote: I hope some of these patches will be available soon, but I'm not sure if soon is a month or 6. On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar wrote: > Thanks for sharing this Ian. > > > This definitely matches some of the observations we've seen as well in th= e > UDP write path. Some of the other paths that we saw that added overhead w= as > the route table lookup in linux udp stack. Connected UDP sockets did > amortize that. > > > I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is ther= e > any indication of the timeline for these patches to make it to linux? Wou= ld > be happy to try any of these out to help iron out the API. > > > Subodh > ------------------------------ > *From:* QUIC on behalf of Ian Swett > > *Sent:* Tuesday, April 3, 2018 5:20:08 PM > *To:* IETF QUIC WG > *Subject:* UDP send costs in Linux > > One challenge with QUIC at the moment is the increased CPU cost of sendin= g > UDP packets vs TCP payloads. I've seen this across every platform Google > has deployed QUIC on, so it's a widespread issue. > > Here's an excellent presentation on what's causing the increased CPU > consumption on Linux from Willem de Bruijn(UDP starts on slide 9). > http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf > > And while you're thinking of CPU usage, it's worth looking at the > presentation on timing wheel based packet pacing(which is minimum release > time based) and is ideal for QUIC(and TCP for that matter): > https://conferences.sigcomm.org/sigcomm/2017/files/program/ts-9-4-carouse= l.pdf > > > -Ian > --000000000000afe04c05690789c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I have no data to ad= d on the Linux UDP stack, but another issue is the lack of netmap support i= n cloud hosting environments.
I have not yet been working with this, but have looked int= o the problem and asked around.

netmap is default in FreeBSD and optional in Linux. But neither = works efficiently without a hypervisor patch that is also available for net= map. With support for netmap, the user space application can send directly = to the network adapter with very little overhead. There is also dpdk and so= me other interfaces that might be slightly faster but more vendor specific.=

Assuming an applicat= ion has access to optimized netmap, the only hurdle is address lookup, but = if the application also manages that, or at least does the caching, there s= houldn=E2=80=99t be much in the way of OS interference.

Of course, netmap blocks the entire netw= ork stack, so no PING or SSH. CloudFlare added a netmap patch so only some = traffic would be routed fra the network interface to netmap, and netmap als= o supports efficient packet forwarding to the OS or other applications.

None of this works well = in general, but for a cloud host that can be bootet automatically and destr= oyed rather than serviced, there is some opportunity.

but only if cloud service providers starts= adding support their supported images and hypervisors. Not sure if any are= working on this now.


Mikkel<= /div>


On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc.= ietf.org) wrote:

I hope some of these patches will be available soon, but I'm not sure if soon is a month or 6.

On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar <subodh@fb.com> wrote:

Thanks for sharing this Ian.


This definitely matches some of the observations we've seen as well in the UDP write path. Some of the other paths that we saw that added overhead was the route table lookup in linux udp stack. Connected UDP sockets did amortize that.


I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is there any indication of the timeline for these patches to make it to linux? Would be happy to try any of these out to help iron out the API.


Subodh

From: = QUIC <quic-bo= unces@ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf..org>
Sent: Tuesday, April 3, 2018 5:20:08 PM
To: IETF QUIC WG
Subject: UDP send costs in Linux
=C2=A0
One challenge with QUIC at the moment is the increased CPU cost of sending UDP packets vs TCP payloads.=C2=A0 I've seen this across every platform Google has deployed QUIC on, so it's a widespread issue.

Here's an excellent presentation on what's causing the increased CPU consumption on Linux from=C2=A0Willem de Bruijn(UDP starts on slide 9).

And while you're thinking of CPU usage, it's worth looking at the presentation on timing wheel based packet pacing(which is minimum release time based) and is ideal for QUIC(and TCP for that matter):=C2=A0https://c= onferences.sigcomm.org/sigcomm/2017/files/program/ts-9-4-carousel.pdf

-Ian
--000000000000afe04c05690789c5-- From nobody Wed Apr 4 08:33:09 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8400612DA28 for ; Wed, 4 Apr 2018 08:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522855983; bh=8HQGO8zKGzn3ztxvaNWPxW0H6RT75JvPNFS4fQnSQPI=; h=From:In-Reply-To:References:Date:Subject:Cc:To:To; b=JyiFqnVrmLT7eqQVulwPV5CxT7urXkgUBG9quzzJPbI9EfAMTEOVLHuYGoeXhORvn xv27lmo1OBmNFB4DobEqS96/YZTWfquaBHGbpmXb8LFOdMA4TPOjJjYRVMy5rcdoBv OuDxwtbZF2Sr4162O8VHvCBTLbtWCGAnPz2r70FU= X-Mailbox-Line: From mikkelfj@gmail.com Wed Apr 4 08:33:03 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0A712DA24 for ; Wed, 4 Apr 2018 08:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522855983; bh=dWEAzcrGXjlsq7kb4w4moRAsfAK4w6IOuQUAc0jq2Eg=; h=From:In-Reply-To:References:Date:Subject:Cc:To:To; b=ocdkh7joRtCUNor5WpdyCacp5sjYGYUieTq+FHbgtAc0TQEU72+olvrdB7bXRqPEO cLYA+FBgnpaneFsVvMpoSLxWfw6l9pAP9YzkqE89bfLbFwnILbqqQv4kMxYt/XsV/X 6Hu86TsI8gVtyJ7grhhkE58C+I0BxoMR015gUF+M= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2406B12DA28 for ; Wed, 4 Apr 2018 08:33:03 -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, 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 3AeY0epwXtdK for ; Wed, 4 Apr 2018 08:33:00 -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 5236C12DA24 for ; Wed, 4 Apr 2018 08:33:00 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id b5-v6so17889005itj.1 for ; Wed, 04 Apr 2018 08:33:00 -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=aTyqhELuVKSysofcwoyosAhA84iAj62sjx6gmHV/dbE=; b=VIDm+YjYuT4H/kqpoMoJlsSVHhch7y1fx4ylY17ESlm5GdMK+A9sY8BBtOZP0ee++W 0yMeqpr3gquxt+uVBbdBLep1Srqte5BTY/qRHUCraI2Rit0nUp5kKS7Xqu7jg1SHuvAM 1Vhw9xjKXUV/ZBnQXwIxYdLWJggfMNL4Fbm7zAubJNckgu6O5+N4d4sOY/wFKfppyGb6 CoTtKHsxIu4GE+OO9xEdBaBmFRtr47dZVcIETetKw5E4lvwIsTaJm/HaMF361Xuiuu4K aQs7x8CXzQQ3Q5Qa61ZRfLgjL9/ON5u5HvzXVK3wsQ/B2Z1J6AKHvTfJtTaI7F11oycm ZFTQ== 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=aTyqhELuVKSysofcwoyosAhA84iAj62sjx6gmHV/dbE=; b=m/u6dCgsZhIX/YXQsKaej91z+fHWK3ObTdgvPSAn1eolANvxKfkqxCjV3EFxRdkZw9 2wOil9S9iHkAxBczbFNqPPOPp3QAzQxKBRHoHfdb39DC4XKFS23rIhcXccSdDwnSZEKv DW9FpEBVnGmVasICbbbTpcnqaQmN0rBdUVSvLBRegtxGhOEhc5D+KFl+kQSJT712WAzH Tti1ZKW56Bxw0NJN5ADciCUTrRkegp64r4kxqygLQdjctEMtp6Y2Ad6VCsrkAUq3TGB+ 19wr7U/C8OE5CVPH02JWTNZ4EK12xFvbMNUg3zGwJkFSg6tMuHXiRmJUQUh3jPfedlY1 DPYA== X-Gm-Message-State: ALQs6tAMsEcibuuAQWCJtEFENk66QORTRDTRidTRH3TuuJt/pWgUk2ZG 9BhtDda+ko3HLozGAYKJ/AE9ky1qUdz2Nt//98F3WQ== X-Google-Smtp-Source: AIpwx4/ERgy0GVTes83al1WtvUuRq7msBGC+iPcaQS97ai0MimgxDmgjNWYA804oGYmjltl2EVh/mIMxDV76Top6UtI= X-Received: by 2002:a24:7088:: with SMTP id f130-v6mr9856271itc.39.1522855979244; Wed, 04 Apr 2018 08:32:59 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Apr 2018 08:32:58 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 4 Apr 2018 08:32:58 -0700 Message-ID: Subject: Re: UDP send costs in Linux Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000afe04c05690789c5" To: Ian Swett To: Subodh Iyengar Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 15:33:04 -0000 --000000000000afe04c05690789c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have no data to add on the Linux UDP stack, but another issue is the lack of netmap support in cloud hosting environments. I have not yet been working with this, but have looked into the problem and asked around. netmap is default in FreeBSD and optional in Linux. But neither works efficiently without a hypervisor patch that is also available for netmap. With support for netmap, the user space application can send directly to the network adapter with very little overhead. There is also dpdk and some other interfaces that might be slightly faster but more vendor specific. Assuming an application has access to optimized netmap, the only hurdle is address lookup, but if the application also manages that, or at least does the caching, there shouldn=E2=80=99t be much in the way of OS interference. Of course, netmap blocks the entire network stack, so no PING or SSH. CloudFlare added a netmap patch so only some traffic would be routed fra the network interface to netmap, and netmap also supports efficient packet forwarding to the OS or other applications. None of this works well in general, but for a cloud host that can be bootet automatically and destroyed rather than serviced, there is some opportunity= .. but only if cloud service providers starts adding support their supported images and hypervisors. Not sure if any are working on this now. Mikkel On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc.ietf.= org) wrote: I hope some of these patches will be available soon, but I'm not sure if soon is a month or 6. On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar wrote: > Thanks for sharing this Ian. > > > This definitely matches some of the observations we've seen as well in th= e > UDP write path. Some of the other paths that we saw that added overhead w= as > the route table lookup in linux udp stack. Connected UDP sockets did > amortize that. > > > I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is ther= e > any indication of the timeline for these patches to make it to linux? Wou= ld > be happy to try any of these out to help iron out the API. > > > Subodh > ------------------------------ > *From:* QUIC on behalf of Ian Swett > > *Sent:* Tuesday, April 3, 2018 5:20:08 PM > *To:* IETF QUIC WG > *Subject:* UDP send costs in Linux > > One challenge with QUIC at the moment is the increased CPU cost of sendin= g > UDP packets vs TCP payloads. I've seen this across every platform Google > has deployed QUIC on, so it's a widespread issue. > > Here's an excellent presentation on what's causing the increased CPU > consumption on Linux from Willem de Bruijn(UDP starts on slide 9). > http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf > > And while you're thinking of CPU usage, it's worth looking at the > presentation on timing wheel based packet pacing(which is minimum release > time based) and is ideal for QUIC(and TCP for that matter): > https://conferences.sigcomm.org/sigcomm/2017/files/program/ts-9-4-carouse= l.pdf > > > -Ian > --000000000000afe04c05690789c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I have no data to ad= d on the Linux UDP stack, but another issue is the lack of netmap support i= n cloud hosting environments.
I have not yet been working with this, but have looked int= o the problem and asked around.

netmap is default in FreeBSD and optional in Linux. But neither = works efficiently without a hypervisor patch that is also available for net= map. With support for netmap, the user space application can send directly = to the network adapter with very little overhead. There is also dpdk and so= me other interfaces that might be slightly faster but more vendor specific.=

Assuming an applicat= ion has access to optimized netmap, the only hurdle is address lookup, but = if the application also manages that, or at least does the caching, there s= houldn=E2=80=99t be much in the way of OS interference.

Of course, netmap blocks the entire netw= ork stack, so no PING or SSH. CloudFlare added a netmap patch so only some = traffic would be routed fra the network interface to netmap, and netmap als= o supports efficient packet forwarding to the OS or other applications.

None of this works well = in general, but for a cloud host that can be bootet automatically and destr= oyed rather than serviced, there is some opportunity.

but only if cloud service providers starts= adding support their supported images and hypervisors. Not sure if any are= working on this now.


Mikkel<= /div>


On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc.= ietf.org) wrote:

I hope some of these patches will be available soon, but I'm not sure if soon is a month or 6.

On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar <subodh@fb.com> wrote:

Thanks for sharing this Ian.


This definitely matches some of the observations we've seen as well in the UDP write path. Some of the other paths that we saw that added overhead was the route table lookup in linux udp stack. Connected UDP sockets did amortize that.


I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is there any indication of the timeline for these patches to make it to linux? Would be happy to try any of these out to help iron out the API.


Subodh

From: = QUIC <quic-bo= unces@ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf..org>
Sent: Tuesday, April 3, 2018 5:20:08 PM
To: IETF QUIC WG
Subject: UDP send costs in Linux
=C2=A0
One challenge with QUIC at the moment is the increased CPU cost of sending UDP packets vs TCP payloads.=C2=A0 I've seen this across every platform Google has deployed QUIC on, so it's a widespread issue.

Here's an excellent presentation on what's causing the increased CPU consumption on Linux from=C2=A0Willem de Bruijn(UDP starts on slide 9).

And while you're thinking of CPU usage, it's worth looking at the presentation on timing wheel based packet pacing(which is minimum release time based) and is ideal for QUIC(and TCP for that matter):=C2=A0https://c= onferences.sigcomm.org/sigcomm/2017/files/program/ts-9-4-carousel.pdf

-Ian
--000000000000afe04c05690789c5-- From nobody Wed Apr 4 09:28:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555AD127978 for ; Wed, 4 Apr 2018 09:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.589 X-Spam-Level: X-Spam-Status: No, score=0.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOXfjqRfoaej for ; Wed, 4 Apr 2018 09:28:49 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF025120724 for ; Wed, 4 Apr 2018 09:28:48 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id m22-v6so23974592otf.10 for ; Wed, 04 Apr 2018 09:28:48 -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=o/UKnXq8LGgjByp3g7WRuBhEDe+BTRj+KwyoaArl/+o=; b=u7iknLhy5RCkW2HQJa30NFclDyMEVwqeXMDN18D+XebBKeDBSI+B0dhiauRO5El5m7 1gLBp+TGd8GtN0KeWNnnRXSpbryuEvHr8/TgTQ8qN0K0T3iognz7XH562OqSmnXxv14D Xf5dcYewixAUK6olfFupXzdo9xU57Bg0CUpCCra481vrgBwlWcPEsQtCi8qA4OmxDvOa I5J6d63JrQz3LOd8SJGleE/3o0veAqkv8OH1WuFJV/t2aEb/XgMraEML15IRURqFoh3z 0dSYuZM3mwVpp8vuyjdGN0rHzZo+vnmcAXgFuiUmkeUMP3y++m/gxJuXcR3aw6zc2gnS vIuQ== 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=o/UKnXq8LGgjByp3g7WRuBhEDe+BTRj+KwyoaArl/+o=; b=nRgpubTIW5Hek/zskzQhpNux65i9FXK9r8OHPieUVaAo57NlP8Co/WtkPz6djoeUrD rOzWmVnYpqb9gXWQrulTTnWzUTO7Qj2qOJaTln68PkdnhPJMoB+8GNA9kDHHfjvMZP4H vQ1tgN/Ym6lXMj9/edcTbgd3qe/Lrk56vg6h7fuRtqSq9mkjOdgDBcYtzOZQsIvrXVAo CO9aSg549fzS7lQcJcZRSSQrjG6/ASZVfGBSWZ49dkbDdVrJeBq/mND6aGnyYoji7sKs ijl4bNUt10nkPj63k1r3Nm1kSgmSUdjreAa1aOq8bfjHzEq4ojiturGRUr+K0/JRmmJj thcA== X-Gm-Message-State: AElRT7GDchIz2GQAabGPNSsx2pBgkZ5gJJ9OxQdZI2U0IiItbZ6ITbIr Y3AEe6BVc4oLcK2epme0kNR71TrG1CG3YjpRBNE= X-Google-Smtp-Source: AIpwx49YJTNM+HGE9ttmaCRPaKidPEdT6a7CfVbfcD0jOht5rcA7/hz3nRM1anINdqusYeDfUx53BIr5Z1kbE/66WgY= X-Received: by 2002:a9d:4a52:: with SMTP id d18-v6mr11962675otj.380.1522859328227; Wed, 04 Apr 2018 09:28:48 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 09:28:47 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 4 Apr 2018 12:28:47 -0400 X-Google-Sender-Auth: A7-t4T3n-A-3qZPwIkhvgklotpo Message-ID: Subject: Re: UDP send costs in Linux To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Ian Swett , Subodh Iyengar , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000004d4ca20569085173" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 16:28:51 -0000 --0000000000004d4ca20569085173 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would not worry too much at this point. The reason we want to be able to work at the application level is backwards compatibility. It has to be possible to deploy QUIC on any machine even without OS support or it won't be deployable. It does not have to be performant on every platform. If people are using QUIC, whatever needs to be moved into the kernel for performance reasons will move there. On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I have no data to add on the Linux UDP stack, but another issue is the > lack of netmap support in cloud hosting environments. > I have not yet been working with this, but have looked into the problem > and asked around. > > netmap is default in FreeBSD and optional in Linux. But neither works > efficiently without a hypervisor patch that is also available for netmap. > With support for netmap, the user space application can send directly to > the network adapter with very little overhead. There is also dpdk and som= e > other interfaces that might be slightly faster but more vendor specific. > > Assuming an application has access to optimized netmap, the only hurdle i= s > address lookup, but if the application also manages that, or at least doe= s > the caching, there shouldn=E2=80=99t be much in the way of OS interferenc= e. > > Of course, netmap blocks the entire network stack, so no PING or SSH. > CloudFlare added a netmap patch so only some traffic would be routed fra > the network interface to netmap, and netmap also supports efficient packe= t > forwarding to the OS or other applications. > > None of this works well in general, but for a cloud host that can be > bootet automatically and destroyed rather than serviced, there is some > opportunity. > > but only if cloud service providers starts adding support their supported > images and hypervisors. Not sure if any are working on this now. > > > Mikkel > > > On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc. > ietf.org) wrote: > > I hope some of these patches will be available soon, but I'm not sure if > soon is a month or 6. > > On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar wrote: > >> Thanks for sharing this Ian. >> >> >> This definitely matches some of the observations we've seen as well in >> the UDP write path. Some of the other paths that we saw that added overh= ead >> was the route table lookup in linux udp stack. Connected UDP sockets did >> amortize that. >> >> >> I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is >> there any indication of the timeline for these patches to make it to lin= ux? >> Would be happy to try any of these out to help iron out the API. >> >> >> Subodh >> ------------------------------ >> *From:* QUIC on behalf of Ian Swett >> >> *Sent:* Tuesday, April 3, 2018 5:20:08 PM >> *To:* IETF QUIC WG >> *Subject:* UDP send costs in Linux >> >> One challenge with QUIC at the moment is the increased CPU cost of >> sending UDP packets vs TCP payloads. I've seen this across every platfo= rm >> Google has deployed QUIC on, so it's a widespread issue. >> >> Here's an excellent presentation on what's causing the increased CPU >> consumption on Linux from Willem de Bruijn(UDP starts on slide 9). >> http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf >> >> And while you're thinking of CPU usage, it's worth looking at the >> presentation on timing wheel based packet pacing(which is minimum releas= e >> time based) and is ideal for QUIC(and TCP for that matter): >> https://conferences.sigcomm.org/sigcomm/2017/ >> files/program/ts-9-4-carousel.pdf >> >> >> -Ian >> > --0000000000004d4ca20569085173 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I w= ould not worry too much at this point.

The reason we want to be able to work at the application leve= l is backwards compatibility. It has to be possible to deploy QUIC on any m= achine even without OS support or it won't be deployable.

It does not have to be performant on e= very platform. If people are using QUIC, whatever needs to be moved into th= e kernel for performance reasons will move there.




On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e J=C3=B8rg= ensen <mikkelfj@gmail.com> wrote:
<= div id=3D"m_1651742879505555491bloop_customfont" style=3D"font-family:Helve= tica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto= ">I have no data to add on the Linux UDP stack, but another issue is the la= ck of netmap support in cloud hosting environments.
I have not yet = been working with this, but have looked into the problem and asked around.<= /div>

netmap is default in FreeBSD and optional in Linux. = But neither works efficiently without a hypervisor patch that is also avail= able for netmap. With support for netmap, the user space application can se= nd directly to the network adapter with very little overhead. There is also= dpdk and some other interfaces that might be slightly faster but more vend= or specific.

Assuming an application has access to o= ptimized netmap, the only hurdle is address lookup, but if the application = also manages that, or at least does the caching, there shouldn=E2=80=99t be= much in the way of OS interference.

Of course, netmap= blocks the entire network stack, so no PING or SSH. CloudFlare added a net= map patch so only some traffic would be routed fra the network interface to= netmap, and netmap also supports efficient packet forwarding to the OS or = other applications.

None of this works well in general= , but for a cloud host that can be bootet automatically and destroyed rathe= r than serviced, there is some opportunity.

but only if cloud service providers st= arts adding support their supported images and hypervisors. Not sure if any= are working on this now.


Mikkel


On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.c= om@dmarc.ietf.org) wrote:

I hope some of these patches will be available soon, but I'm not sure if soon is a month or 6.

On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar <subodh@fb.com>= ; wrote:

Thanks for sharing this Ian.


This definitely matches some of the observations we've seen as well in the UDP write path. Some of the other paths that we saw that added overhead was the route table lookup in linux udp stack. Connected UDP sockets did amortize that.


I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is there any indication of the timeline for these patches to make it to linux? Would be happy to try any of these out to help iron out the API.


Subodh

From: QUIC <quic-bounces@ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf..org>
Sent: Tuesday, April 3, 2018 5:20:08 PM
To: IETF QUIC WG
Subject: UDP send costs in Linux
=C2=A0
One challenge with QUIC at the moment is the increased CPU cost of sending UDP packets vs TCP payloads.=C2=A0 I've seen this across every platform Google has deployed QUIC on, so it's a widespread issue.

Here's an excellent presentation on what's causing the increased CPU consumption on Linux from=C2=A0Willem de Bruijn(UDP starts on slide 9).

And while you're thinking of CPU usage, it's worth looking at the presentation on timing wheel based packet pacing(which is minimum release time based) and is ideal for QUIC(and TCP for that matter):=C2=A0https://c= onferences.sigcomm.org/sigcomm/2017/files/program/ts-9-4-carousel= .pdf

-Ian

--0000000000004d4ca20569085173-- From nobody Wed Apr 4 09:28:58 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E83ED127978 for ; Wed, 4 Apr 2018 09:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522859331; bh=AhwsDCrXAvfxBeGMgALwB+g4kZqVtYnB1SIrMRztsb4=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc:Cc; b=RHlrL2Pa2k8UHL3YAfMjTrWUDG6GzY6DS6MmNhSBkZ2CMHFc8RXYWxI4nZKHplez0 74O9yZox4Y65gBJMF92k1Qt2KtiDsu7CYBaRyYopr5Gg6xgCypbwRzNbBryMRKfOEj sQlTFPJM6+H1rZlqj1wOO5Rw1JZX41rW97W/leOA= X-Mailbox-Line: From hallam@gmail.com Wed Apr 4 09:28:51 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7290127869; Wed, 4 Apr 2018 09:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522859331; bh=LzYlDDVXEkgljbV9c5mpESnL5yNJsOdJNAcrJB0D61Y=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc:Cc; b=HpBUtJoOUhRNqvuhVgVb2ntGxE4I6+P9XY1SrgIcbL01E3RAPDpOK7CIgoEhYZ7Am RbQiNuZ37ECFwudb8uIQNSlbuTGyovuiAFpoT5ZxvqnRH8HTLTkc7Nlu6Orm3+WCgO YsWaLMjg0JgRGsCsubyUS6wkm/T+JXxzqvPhKqzc= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E8F120724 for ; Wed, 4 Apr 2018 09:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.589 X-Spam-Level: X-Spam-Status: No, score=0.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoESNZDzJFgv for ; Wed, 4 Apr 2018 09:28:49 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6CA5127869 for ; Wed, 4 Apr 2018 09:28:48 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id n40-v6so23988658otd.3 for ; Wed, 04 Apr 2018 09:28:48 -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=o/UKnXq8LGgjByp3g7WRuBhEDe+BTRj+KwyoaArl/+o=; b=u7iknLhy5RCkW2HQJa30NFclDyMEVwqeXMDN18D+XebBKeDBSI+B0dhiauRO5El5m7 1gLBp+TGd8GtN0KeWNnnRXSpbryuEvHr8/TgTQ8qN0K0T3iognz7XH562OqSmnXxv14D Xf5dcYewixAUK6olfFupXzdo9xU57Bg0CUpCCra481vrgBwlWcPEsQtCi8qA4OmxDvOa I5J6d63JrQz3LOd8SJGleE/3o0veAqkv8OH1WuFJV/t2aEb/XgMraEML15IRURqFoh3z 0dSYuZM3mwVpp8vuyjdGN0rHzZo+vnmcAXgFuiUmkeUMP3y++m/gxJuXcR3aw6zc2gnS vIuQ== 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=o/UKnXq8LGgjByp3g7WRuBhEDe+BTRj+KwyoaArl/+o=; b=XbhRRpMPFe92qPSmPxYJgFj3DBNn1amvsiDuBWqTQ/IHMSxWJWik6CPt92zZwzukHS +kbud6hSYGuEy4M9Vlt+u1KG/fM5hVljvDVKLdsWtMKQoYQ0VC3R9TTpW/X3Mgg9ixJs zIrBz9IwQloWaT/9VaOK/VKUOomXcgxK2chzwXI+jqkatcFoaBz7Rd4+aJ8lnrWTj7tx X7Kh2GEGTpnUmJZ9ACHRpDgxjm1bhNiKmxBiUXWH1SZQm5XqXsLtR8fUfc4HgmWReChP SrAtDa3VrPvoT7AZ7E22SC2XkApjE4+sClQjegIKfepnQhWTsT+smWNoj/vCNSwJZ7HQ vjxQ== X-Gm-Message-State: AElRT7EWDV4jpatR+6zxQ6PDkP+8IeYoTtfWsdK+c4fPk50+QQAcb8xP xmeiE86KmrQtfcFB99l9lEsTj3eYwDJqB9cABQ8= X-Google-Smtp-Source: AIpwx49YJTNM+HGE9ttmaCRPaKidPEdT6a7CfVbfcD0jOht5rcA7/hz3nRM1anINdqusYeDfUx53BIr5Z1kbE/66WgY= X-Received: by 2002:a9d:4a52:: with SMTP id d18-v6mr11962675otj.380.1522859328227; Wed, 04 Apr 2018 09:28:48 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 09:28:47 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 4 Apr 2018 12:28:47 -0400 X-Google-Sender-Auth: A7-t4T3n-A-3qZPwIkhvgklotpo Message-ID: Subject: Re: UDP send costs in Linux To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Content-Type: multipart/alternative; boundary="0000000000004d4ca20569085173" Cc: Ian Swett Cc: Subodh Iyengar Cc: IETF QUIC WG Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 16:28:52 -0000 --0000000000004d4ca20569085173 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would not worry too much at this point. The reason we want to be able to work at the application level is backwards compatibility. It has to be possible to deploy QUIC on any machine even without OS support or it won't be deployable. It does not have to be performant on every platform. If people are using QUIC, whatever needs to be moved into the kernel for performance reasons will move there. On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I have no data to add on the Linux UDP stack, but another issue is the > lack of netmap support in cloud hosting environments. > I have not yet been working with this, but have looked into the problem > and asked around. > > netmap is default in FreeBSD and optional in Linux. But neither works > efficiently without a hypervisor patch that is also available for netmap. > With support for netmap, the user space application can send directly to > the network adapter with very little overhead. There is also dpdk and som= e > other interfaces that might be slightly faster but more vendor specific. > > Assuming an application has access to optimized netmap, the only hurdle i= s > address lookup, but if the application also manages that, or at least doe= s > the caching, there shouldn=E2=80=99t be much in the way of OS interferenc= e. > > Of course, netmap blocks the entire network stack, so no PING or SSH. > CloudFlare added a netmap patch so only some traffic would be routed fra > the network interface to netmap, and netmap also supports efficient packe= t > forwarding to the OS or other applications. > > None of this works well in general, but for a cloud host that can be > bootet automatically and destroyed rather than serviced, there is some > opportunity. > > but only if cloud service providers starts adding support their supported > images and hypervisors. Not sure if any are working on this now. > > > Mikkel > > > On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc. > ietf.org) wrote: > > I hope some of these patches will be available soon, but I'm not sure if > soon is a month or 6. > > On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar wrote: > >> Thanks for sharing this Ian. >> >> >> This definitely matches some of the observations we've seen as well in >> the UDP write path. Some of the other paths that we saw that added overh= ead >> was the route table lookup in linux udp stack. Connected UDP sockets did >> amortize that. >> >> >> I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is >> there any indication of the timeline for these patches to make it to lin= ux? >> Would be happy to try any of these out to help iron out the API. >> >> >> Subodh >> ------------------------------ >> *From:* QUIC on behalf of Ian Swett >> >> *Sent:* Tuesday, April 3, 2018 5:20:08 PM >> *To:* IETF QUIC WG >> *Subject:* UDP send costs in Linux >> >> One challenge with QUIC at the moment is the increased CPU cost of >> sending UDP packets vs TCP payloads. I've seen this across every platfo= rm >> Google has deployed QUIC on, so it's a widespread issue. >> >> Here's an excellent presentation on what's causing the increased CPU >> consumption on Linux from Willem de Bruijn(UDP starts on slide 9). >> http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf >> >> And while you're thinking of CPU usage, it's worth looking at the >> presentation on timing wheel based packet pacing(which is minimum releas= e >> time based) and is ideal for QUIC(and TCP for that matter): >> https://conferences.sigcomm.org/sigcomm/2017/ >> files/program/ts-9-4-carousel.pdf >> >> >> -Ian >> > --0000000000004d4ca20569085173 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I w= ould not worry too much at this point.

The reason we want to be able to work at the application leve= l is backwards compatibility. It has to be possible to deploy QUIC on any m= achine even without OS support or it won't be deployable.

It does not have to be performant on e= very platform. If people are using QUIC, whatever needs to be moved into th= e kernel for performance reasons will move there.




On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e J=C3=B8rg= ensen <mikkelfj@gmail.com> wrote:
<= div id=3D"m_1651742879505555491bloop_customfont" style=3D"font-family:Helve= tica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto= ">I have no data to add on the Linux UDP stack, but another issue is the la= ck of netmap support in cloud hosting environments.
I have not yet = been working with this, but have looked into the problem and asked around.<= /div>

netmap is default in FreeBSD and optional in Linux. = But neither works efficiently without a hypervisor patch that is also avail= able for netmap. With support for netmap, the user space application can se= nd directly to the network adapter with very little overhead. There is also= dpdk and some other interfaces that might be slightly faster but more vend= or specific.

Assuming an application has access to o= ptimized netmap, the only hurdle is address lookup, but if the application = also manages that, or at least does the caching, there shouldn=E2=80=99t be= much in the way of OS interference.

Of course, netmap= blocks the entire network stack, so no PING or SSH. CloudFlare added a net= map patch so only some traffic would be routed fra the network interface to= netmap, and netmap also supports efficient packet forwarding to the OS or = other applications.

None of this works well in general= , but for a cloud host that can be bootet automatically and destroyed rathe= r than serviced, there is some opportunity.

but only if cloud service providers st= arts adding support their supported images and hypervisors. Not sure if any= are working on this now.


Mikkel


On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.c= om@dmarc.ietf.org) wrote:

I hope some of these patches will be available soon, but I'm not sure if soon is a month or 6.

On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar <subodh@fb.com>= ; wrote:

Thanks for sharing this Ian.


This definitely matches some of the observations we've seen as well in the UDP write path. Some of the other paths that we saw that added overhead was the route table lookup in linux udp stack. Connected UDP sockets did amortize that.


I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is there any indication of the timeline for these patches to make it to linux? Would be happy to try any of these out to help iron out the API.


Subodh

From: QUIC <quic-bounces@ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf..org>
Sent: Tuesday, April 3, 2018 5:20:08 PM
To: IETF QUIC WG
Subject: UDP send costs in Linux
=C2=A0
One challenge with QUIC at the moment is the increased CPU cost of sending UDP packets vs TCP payloads.=C2=A0 I've seen this across every platform Google has deployed QUIC on, so it's a widespread issue.

Here's an excellent presentation on what's causing the increased CPU consumption on Linux from=C2=A0Willem de Bruijn(UDP starts on slide 9).

And while you're thinking of CPU usage, it's worth looking at the presentation on timing wheel based packet pacing(which is minimum release time based) and is ideal for QUIC(and TCP for that matter):=C2=A0https://c= onferences.sigcomm.org/sigcomm/2017/files/program/ts-9-4-carousel= ..pdf

-Ian

--0000000000004d4ca20569085173-- From nobody Wed Apr 4 10:57:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B1C12D779 for ; Wed, 4 Apr 2018 10:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522864649; bh=23+wXo1YEQpHG1QP2RyLEpec7LDRpIbcPoGHQpDJBmE=; h=From:To:Subject:Date:References:In-Reply-To:Cc:Cc:Cc; b=u5AC4sQtE9vV9lZlY7LSMaLeTIuzo7wF6XEvSwVYcs6tKgt74w+TvyE/9N/XT/0FT qVZncf4KSfkL750/3mRYw8AZbUW6v3VRS2Z9DHK8kuRe0MDJdDY5M3XCFFRgs8O5po otRPl6bAWOm4HmPIOBbR2U2U941hW8ZYcZWYP/oo= X-Mailbox-Line: From pravb@microsoft.com Wed Apr 4 10:57:29 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0750A129C6E; Wed, 4 Apr 2018 10:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522864649; bh=23+wXo1YEQpHG1QP2RyLEpec7LDRpIbcPoGHQpDJBmE=; h=From:To:Subject:Date:References:In-Reply-To:Cc:Cc:Cc; b=u5AC4sQtE9vV9lZlY7LSMaLeTIuzo7wF6XEvSwVYcs6tKgt74w+TvyE/9N/XT/0FT qVZncf4KSfkL750/3mRYw8AZbUW6v3VRS2Z9DHK8kuRe0MDJdDY5M3XCFFRgs8O5po otRPl6bAWOm4HmPIOBbR2U2U941hW8ZYcZWYP/oo= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E1412AF84 for ; Wed, 4 Apr 2018 10:57:28 -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 (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 bEgluOj11zl2 for ; Wed, 4 Apr 2018 10:57:25 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on071d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::71d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF81129C6E for ; Wed, 4 Apr 2018 10:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=23+wXo1YEQpHG1QP2RyLEpec7LDRpIbcPoGHQpDJBmE=; b=oBeeUWpYDQwOrnhagtTYdQFNXH4klW9bZ7HD2SdGyEiCnP4QpUT09DwiovQpHq7vlpebwjECsN4bWxnO93+4LslH/MOB+Zy1hUEdjxkGn1Y9xJN4LNkKQxuqyAhQ8YZLLGds8gza3+NkSxgwP+UgAuyFKxGbcxKBoDI1PxmbAJw= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0280.namprd21.prod.outlook.com (10.173.193.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 17:57:23 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 17:57:23 +0000 From: Praveen Balasubramanian To: Phillip Hallam-Baker , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= Subject: RE: UDP send costs in Linux Thread-Topic: UDP send costs in Linux Thread-Index: AQHTy6q+3JsicRIxhkabCq/gojpid6Pv6A6AgACtVICAACezAIAAD5iAgAAXAKA= Date: Wed, 4 Apr 2018 17:57:22 +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:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0280; 7:B6jF4JioNq6WAfpbfQJqTF4j4p4BppF+kMctuwp8WKbhUM6j5zG/jUkuktTIkhHJyCAdiQDcWqWcZOA6diq5xY0cSNz2brtpxwfv8lbLmYBxcFYP+ky+Db9L4CQrsGmqHhZZWLK0uTsky4HBZ63WSJSlWPUXa4ePJKxjeqnbL7tAfo4uvPHPeITAOpn8YZUwyOLN3rSpDybFGLM0iwcSyDZIUMW9fwElBJQv0D1DyArR7n2p7H2rVCzWuzOWI3cF; 20:jPAldTD8BG80LgDn/2QRPZLxqKvMEiu3Z9gMKULcdflTPZgGaoZ2cfCy9LYm6OUkz/ehovJFk+KKi1F/tIpXYNw3N35tQA0/IU3F2i+vwOvSMEscFPJpdAUTaDL7tmQIhRXhEZMSq/3IfY+HiIU/o+2Si9J2ZX/utBTOkGAdc6U= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8e9258f4-1e1e-4618-5105-08d59a55849a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0280; x-ms-traffictypediagnostic: CY4PR21MB0280: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(9452136761055)(189930954265078)(85827821059158)(67672495146484)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231221)(944501327)(52105095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0280; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0280; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(39860400002)(346002)(39380400002)(199004)(189003)(2900100001)(39060400002)(6246003)(53936002)(186003)(46003)(97736004)(11346002)(446003)(476003)(99286004)(86362001)(86612001)(25786009)(19609705001)(10290500003)(966005)(478600001)(606006)(3660700001)(10090500001)(4326008)(2906002)(8990500004)(3280700002)(68736007)(8936002)(8676002)(106356001)(105586002)(9686003)(55016002)(14454004)(54896002)(6306002)(81156014)(5250100002)(81166006)(6436002)(93886005)(7736002)(236005)(316002)(33656002)(22452003)(7696005)(76176011)(229853002)(6116002)(486006)(59450400001)(102836004)(6506007)(53546011)(74316002)(5660300001)(110136005)(54906003)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0280; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: pv4Lv0ARfLZqnPepQvN/DcsLoMk/G8qOMuibTCbAW/G1U9J5s87JXrJz1kH/AgJp6ttBQ3xD0E/6fHte1dRHOlCW18/NKfb8nc09w0xktwSkwxk6A0JwA5x6BIyq1Tkj5ACcnXzVSYaBiGyNOMKQwUNJe3Ex3wlqjYLJ4caDoSKwbJKesKAkBB6mncxnTjjUnDUcDoyL9rRNZLsvth03lejfJ+8MTpXemvLwF6HIhwnjR3TyFAohaydQ7jP8v3pyWFd/kb2rJG9Z1SDhco+AyHrLhQtpMYQ6k8aKf28LQzKY2ax/QeUWwfgxta5wRJIG0/UpM6OfVDvRAb71J1/632XLs4vmbn58pxvL516/ssYz5EEGq9EAxoMp0z/rmGDv7A67XDNTiE+Qyx00sLGGYOMFLMkmH7B9F2E5vzPh5yA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB06302D6BC1865A5889759548B6A40CY4PR21MB0630namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8e9258f4-1e1e-4618-5105-08d59a55849a X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 17:57:22.9535 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0280 Cc: Subodh Iyengar Cc: IETF QUIC WG Cc: Ian Swett Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 17:57:29 -0000 --_000_CY4PR21MB06302D6BC1865A5889759548B6A40CY4PR21MB0630namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIG5lZWQgdG8gd29ycnkgaXMgbm90IG9uIHRoZSBjbGllbnQgc2lkZSDigJMgYXQgbGVhc3Qg bm90IGltbWVkaWF0ZWx5LiA4MDIuMTFhZCwgODAyLjExYXgsIGFuZCA1RyBMVEUgd2lsbCBicmlu ZyBHaWdhYml0IHJhdGVzIHRvIGNsaWVudCBzaWRlIHNvIGl0IGlzIGNlcnRhaW5seSBnb2luZyB0 byBiZWNvbWUgYSBwcm9ibGVtIGxvbmdlciB0ZXJtLg0KDQpUaGUgY3VycmVudCB3b3JyeSBpcyBv biB0aGUgc2VydmVyIHNpZGUuIEEgbGFyZ2UgcGFydCBvZiB0aGUgd29yayB3ZSBkbyBpcyBwZXJm b3JtYW5jZSBvcHRpbWl6YXRpb24gb2YgdGhlIG5ldHdvcmsgc3RhY2suIEdvb2dsZeKAmXMgU2ln Y29tbSBRVUlDIHBhcGVyIHNob3dzIGEgMnggQ1BVIGluY3JlYXNlIGdvaW5nIGZyb20gVENQIHRv IFFVSUMuIE1vc3Qgd2ViIHNlcnZpY2VzIHdpbGwgTk9UIGJlIGFibGUgdG8gbWFrZSB0aGF0IHRy YWRlIG9mZiB0byBnZXQgbGF0ZW5jeSBpbXByb3ZlbWVudHMgZm9yIDkwdGggcGVyY2VudGlsZS4N Cg0KSU1PIGltcHJvdmluZyBVRFAgcGVyZm9ybWFuY2UgYW5kIGhhcmR3YXJlIG9mZmxvYWRzIGFy ZSBhYnNvbHV0ZWx5IGEgbmVjZXNzaXR5IGZvciBRVUlDIHRvIGJlY29tZSB3aWRlbHkgYWRvcHRl ZCAobm90IGp1c3QgYnkgdGhlIGJpZ2dlc3QgY29ycG9yYXRpb25zIHdpdGggYSBsYXJnZSBidWRn ZXQpLiBXZSBoYXZlIHdvcmsgdW5kZXIgd2F5IG9uIGJvdGggdGhlc2UgZnJvbnRzIGFuZCBJIGFt IHZlcnkgaGFwcHkgdG8gc2VlIExpbnV4IGFsc28gaW52ZXN0aW5nIGhlcmUgaW4gcHJlcGFyYXRp b24gZm9yIHdoYXTigJlzIGNvbWluZy4gV2UgbmVlZCB0byBkbyBvdXIgYmVzdCBkZW1vY3JhdGl6 ZSB0aGlzIHRlY2hub2xvZ3kgLSBtdWx0aXBsZSBpbXBsZW1lbnRhdGlvbnMgYW5kIHBlcmZvcm1h bmNlIHdpbGwgYm90aCBwbGF5IGEgYmlnIHJvbGUuDQoNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWxsaXAgSGFsbGFtLUJha2VyDQpT ZW50OiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTggOToyOSBBTQ0KVG86IE1pa2tlbCBGYWhuw7hl IErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT4NCkNjOiBTdWJvZGggSXllbmdhciA8c3Vi b2RoQGZiLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IElhbiBTd2V0dCA8aWFu c3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFVEUCBzZW5k IGNvc3RzIGluIExpbnV4DQoNCkkgd291bGQgbm90IHdvcnJ5IHRvbyBtdWNoIGF0IHRoaXMgcG9p bnQuDQoNClRoZSByZWFzb24gd2Ugd2FudCB0byBiZSBhYmxlIHRvIHdvcmsgYXQgdGhlIGFwcGxp Y2F0aW9uIGxldmVsIGlzIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LiBJdCBoYXMgdG8gYmUgcG9z c2libGUgdG8gZGVwbG95IFFVSUMgb24gYW55IG1hY2hpbmUgZXZlbiB3aXRob3V0IE9TIHN1cHBv cnQgb3IgaXQgd29uJ3QgYmUgZGVwbG95YWJsZS4NCg0KSXQgZG9lcyBub3QgaGF2ZSB0byBiZSBw ZXJmb3JtYW50IG9uIGV2ZXJ5IHBsYXRmb3JtLiBJZiBwZW9wbGUgYXJlIHVzaW5nIFFVSUMsIHdo YXRldmVyIG5lZWRzIHRvIGJlIG1vdmVkIGludG8gdGhlIGtlcm5lbCBmb3IgcGVyZm9ybWFuY2Ug cmVhc29ucyB3aWxsIG1vdmUgdGhlcmUuDQoNCg0KDQoNCk9uIFdlZCwgQXByIDQsIDIwMTggYXQg MTE6MzIgQU0sIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxt YWlsdG86bWlra2VsZmpAZ21haWwuY29tPj4gd3JvdGU6DQpJIGhhdmUgbm8gZGF0YSB0byBhZGQg b24gdGhlIExpbnV4IFVEUCBzdGFjaywgYnV0IGFub3RoZXIgaXNzdWUgaXMgdGhlIGxhY2sgb2Yg bmV0bWFwIHN1cHBvcnQgaW4gY2xvdWQgaG9zdGluZyBlbnZpcm9ubWVudHMuDQpJIGhhdmUgbm90 IHlldCBiZWVuIHdvcmtpbmcgd2l0aCB0aGlzLCBidXQgaGF2ZSBsb29rZWQgaW50byB0aGUgcHJv YmxlbSBhbmQgYXNrZWQgYXJvdW5kLg0KDQpuZXRtYXAgaXMgZGVmYXVsdCBpbiBGcmVlQlNEIGFu ZCBvcHRpb25hbCBpbiBMaW51eC4gQnV0IG5laXRoZXIgd29ya3MgZWZmaWNpZW50bHkgd2l0aG91 dCBhIGh5cGVydmlzb3IgcGF0Y2ggdGhhdCBpcyBhbHNvIGF2YWlsYWJsZSBmb3IgbmV0bWFwLiBX aXRoIHN1cHBvcnQgZm9yIG5ldG1hcCwgdGhlIHVzZXIgc3BhY2UgYXBwbGljYXRpb24gY2FuIHNl bmQgZGlyZWN0bHkgdG8gdGhlIG5ldHdvcmsgYWRhcHRlciB3aXRoIHZlcnkgbGl0dGxlIG92ZXJo ZWFkLiBUaGVyZSBpcyBhbHNvIGRwZGsgYW5kIHNvbWUgb3RoZXIgaW50ZXJmYWNlcyB0aGF0IG1p Z2h0IGJlIHNsaWdodGx5IGZhc3RlciBidXQgbW9yZSB2ZW5kb3Igc3BlY2lmaWMuDQoNCkFzc3Vt aW5nIGFuIGFwcGxpY2F0aW9uIGhhcyBhY2Nlc3MgdG8gb3B0aW1pemVkIG5ldG1hcCwgdGhlIG9u bHkgaHVyZGxlIGlzIGFkZHJlc3MgbG9va3VwLCBidXQgaWYgdGhlIGFwcGxpY2F0aW9uIGFsc28g bWFuYWdlcyB0aGF0LCBvciBhdCBsZWFzdCBkb2VzIHRoZSBjYWNoaW5nLCB0aGVyZSBzaG91bGRu 4oCZdCBiZSBtdWNoIGluIHRoZSB3YXkgb2YgT1MgaW50ZXJmZXJlbmNlLg0KDQpPZiBjb3Vyc2Us IG5ldG1hcCBibG9ja3MgdGhlIGVudGlyZSBuZXR3b3JrIHN0YWNrLCBzbyBubyBQSU5HIG9yIFNT SC4gQ2xvdWRGbGFyZSBhZGRlZCBhIG5ldG1hcCBwYXRjaCBzbyBvbmx5IHNvbWUgdHJhZmZpYyB3 b3VsZCBiZSByb3V0ZWQgZnJhIHRoZSBuZXR3b3JrIGludGVyZmFjZSB0byBuZXRtYXAsIGFuZCBu ZXRtYXAgYWxzbyBzdXBwb3J0cyBlZmZpY2llbnQgcGFja2V0IGZvcndhcmRpbmcgdG8gdGhlIE9T IG9yIG90aGVyIGFwcGxpY2F0aW9ucy4NCg0KTm9uZSBvZiB0aGlzIHdvcmtzIHdlbGwgaW4gZ2Vu ZXJhbCwgYnV0IGZvciBhIGNsb3VkIGhvc3QgdGhhdCBjYW4gYmUgYm9vdGV0IGF1dG9tYXRpY2Fs bHkgYW5kIGRlc3Ryb3llZCByYXRoZXIgdGhhbiBzZXJ2aWNlZCwgdGhlcmUgaXMgc29tZSBvcHBv cnR1bml0eS4NCg0KYnV0IG9ubHkgaWYgY2xvdWQgc2VydmljZSBwcm92aWRlcnMgc3RhcnRzIGFk ZGluZyBzdXBwb3J0IHRoZWlyIHN1cHBvcnRlZCBpbWFnZXMgYW5kIGh5cGVydmlzb3JzLiBOb3Qg c3VyZSBpZiBhbnkgYXJlIHdvcmtpbmcgb24gdGhpcyBub3cuDQoNCg0KTWlra2VsDQoNCg0KDQpP biA0IEFwcmlsIDIwMTggYXQgMTUuMTEuMTcsIElhbiBTd2V0dCAoaWFuc3dldHQ9NDBnb29nbGUu Y29tQGRtYXJjLmlldGYub3JnPG1haWx0bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0 Zi5vcmc+KSB3cm90ZToNCkkgaG9wZSBzb21lIG9mIHRoZXNlIHBhdGNoZXMgd2lsbCBiZSBhdmFp bGFibGUgc29vbiwgYnV0IEknbSBub3Qgc3VyZSBpZiBzb29uIGlzIGEgbW9udGggb3IgNi4NCg0K T24gVHVlLCBBcHIgMywgMjAxOCBhdCAxMDo1MCBQTSBTdWJvZGggSXllbmdhciA8c3Vib2RoQGZi LmNvbTxtYWlsdG86c3Vib2RoQGZiLmNvbT4+IHdyb3RlOg0KDQpUaGFua3MgZm9yIHNoYXJpbmcg dGhpcyBJYW4uDQoNCg0KDQpUaGlzIGRlZmluaXRlbHkgbWF0Y2hlcyBzb21lIG9mIHRoZSBvYnNl cnZhdGlvbnMgd2UndmUgc2VlbiBhcyB3ZWxsIGluIHRoZSBVRFAgd3JpdGUgcGF0aC4gU29tZSBv ZiB0aGUgb3RoZXIgcGF0aHMgdGhhdCB3ZSBzYXcgdGhhdCBhZGRlZCBvdmVyaGVhZCB3YXMgdGhl IHJvdXRlIHRhYmxlIGxvb2t1cCBpbiBsaW51eCB1ZHAgc3RhY2suIENvbm5lY3RlZCBVRFAgc29j a2V0cyBkaWQgYW1vcnRpemUgdGhhdC4NCg0KDQoNCkknbSBsb29raW5nIGZvcndhcmQgdG8gYSBz bWFydGVyIHNlbmRtbXNnIHdpdGggR1NPIGFuZCB6ZXJvIGNvcHkuIElzIHRoZXJlIGFueSBpbmRp Y2F0aW9uIG9mIHRoZSB0aW1lbGluZSBmb3IgdGhlc2UgcGF0Y2hlcyB0byBtYWtlIGl0IHRvIGxp bnV4PyBXb3VsZCBiZSBoYXBweSB0byB0cnkgYW55IG9mIHRoZXNlIG91dCB0byBoZWxwIGlyb24g b3V0IHRoZSBBUEkuDQoNCg0KDQpTdWJvZGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3Vu Y2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUu Y29tQGRtYXJjLmlldGYuLm9yZzxtYWlsdG86aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmll dGYuLm9yZz4+DQpTZW50OiBUdWVzZGF5LCBBcHJpbCAzLCAyMDE4IDU6MjA6MDggUE0NClRvOiBJ RVRGIFFVSUMgV0cNClN1YmplY3Q6IFVEUCBzZW5kIGNvc3RzIGluIExpbnV4DQoNCk9uZSBjaGFs bGVuZ2Ugd2l0aCBRVUlDIGF0IHRoZSBtb21lbnQgaXMgdGhlIGluY3JlYXNlZCBDUFUgY29zdCBv ZiBzZW5kaW5nIFVEUCBwYWNrZXRzIHZzIFRDUCBwYXlsb2Fkcy4gIEkndmUgc2VlbiB0aGlzIGFj cm9zcyBldmVyeSBwbGF0Zm9ybSBHb29nbGUgaGFzIGRlcGxveWVkIFFVSUMgb24sIHNvIGl0J3Mg YSB3aWRlc3ByZWFkIGlzc3VlLg0KDQpIZXJlJ3MgYW4gZXhjZWxsZW50IHByZXNlbnRhdGlvbiBv biB3aGF0J3MgY2F1c2luZyB0aGUgaW5jcmVhc2VkIENQVSBjb25zdW1wdGlvbiBvbiBMaW51eCBm cm9tIFdpbGxlbSBkZSBCcnVpam4oVURQIHN0YXJ0cyBvbiBzbGlkZSA5KS4NCmh0dHA6Ly92Z2Vy Lmtlcm5lbC5vcmcvbmV0Y29uZjIwMTdfZmlsZXMvcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBk ZjxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw JTNBJTJGJTJGdmdlci5rZXJuZWwub3JnJTJGbmV0Y29uZjIwMTdfZmlsZXMlMkZyeF9oYXJkZW5p bmdfYW5kX3VkcF9nc28ucGRmJmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3 QzEwM2E2ZTgxZjM2ODRjNjczODI2MDhkNTlhNDkyYzJlJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMSU3QzYzNjU4NDU2MTQ0OTg3MjkzNSZzZGF0YT1GUGUwbVM1YUcl MkI4OCUyRlNYdklWU08zeVduWGg5dE9oUWZLa0g2WG5RRHh2RSUzRCZyZXNlcnZlZD0wPg0KDQpB bmQgd2hpbGUgeW91J3JlIHRoaW5raW5nIG9mIENQVSB1c2FnZSwgaXQncyB3b3J0aCBsb29raW5n IGF0IHRoZSBwcmVzZW50YXRpb24gb24gdGltaW5nIHdoZWVsIGJhc2VkIHBhY2tldCBwYWNpbmco d2hpY2ggaXMgbWluaW11bSByZWxlYXNlIHRpbWUgYmFzZWQpIGFuZCBpcyBpZGVhbCBmb3IgUVVJ QyhhbmQgVENQIGZvciB0aGF0IG1hdHRlcik6IGh0dHBzOi8vY29uZmVyZW5jZXMuc2lnY29tbS5v cmcvc2lnY29tbS8yMDE3L2ZpbGVzL3Byb2dyYW0vdHMtOS00LWNhcm91c2VsLi5wZGY8aHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ1cmxkZWZlbnNlLnByb29mcG9pbnQuY29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0cHMtM0FfX2Nv bmZlcmVuY2VzLnNpZ2NvbW0ub3JnX3NpZ2NvbW1fMjAxN19maWxlc19wcm9ncmFtX3RzLTJEOS0y RDQtMkRjYXJvdXNlbC5wZGYlMjZkJTNERHdNRmFRJTI2YyUzRDVWRDBSVHRObFRoM3ljZDQxYjNN VXclMjZyJTNEaDNKdTlFQlM3bUh0d2ctd0F5TjdmUSUyNm0lM0R0Z2doZ3ZGa3BzN2pZYUZOZE55 WkJORmYwZXBWeEZaYk9HaGh5YkZ3UGlFJTI2cyUzRDg3Z09HZnozUzBsTGJ3OGp5LWx6M005dlBH Q2hrbWd0aUpWelV4Yk1mdlklMjZlJTNEJmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0 LmNvbSU3QzEwM2E2ZTgxZjM2ODRjNjczODI2MDhkNTlhNDkyYzJlJTdDNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjU4NDU2MTQ0OTg3MjkzNSZzZGF0YT1oU1hY dlRPRHZsakk2bmlCTG1NeEdVRlM5ZyUyRnFPaUhza1VjTmNnSHRFNmslM0QmcmVzZXJ2ZWQ9MD4N Cg0KLUlhbg0KDQo= --_000_CY4PR21MB06302D6BC1865A5889759548B6A40CY4PR21MB0630namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFt c29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhh dmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1M KTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5k aWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1z dHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnAubTE2NTE3NDI4Nzk1MDU1NTU0OTFhaXJtYWlsb24sIGxpLm0xNjUxNzQyODc5NTA1NTU1 NDkxYWlybWFpbG9uLCBkaXYubTE2NTE3NDI4Nzk1MDU1NTU0OTFhaXJtYWlsb24NCgl7bXNvLXN0 eWxlLW5hbWU6bV8xNjUxNzQyODc5NTA1NTU1NDkxYWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhv ZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbmVl ZCB0byB3b3JyeSBpcyBub3Qgb24gdGhlIGNsaWVudCBzaWRlIOKAkyBhdCBsZWFzdCBub3QgaW1t ZWRpYXRlbHkuIDgwMi4xMWFkLCA4MDIuMTFheCwgYW5kIDVHIExURSB3aWxsIGJyaW5nIEdpZ2Fi aXQgcmF0ZXMgdG8gY2xpZW50IHNpZGUgc28gaXQgaXMgY2VydGFpbmx5IGdvaW5nIHRvIGJlY29t ZSBhIHByb2JsZW0gbG9uZ2VyIHRlcm0uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGN1 cnJlbnQgd29ycnkgaXMgb24gdGhlIHNlcnZlciBzaWRlLiBBIGxhcmdlIHBhcnQgb2YgdGhlIHdv cmsgd2UgZG8gaXMgcGVyZm9ybWFuY2Ugb3B0aW1pemF0aW9uIG9mIHRoZSBuZXR3b3JrIHN0YWNr LiBHb29nbGXigJlzIFNpZ2NvbW0gUVVJQyBwYXBlciBzaG93cyBhIDJ4IENQVSBpbmNyZWFzZSBn b2luZyBmcm9tIFRDUCB0byBRVUlDLiBNb3N0IHdlYiBzZXJ2aWNlcyB3aWxsIE5PVCBiZSBhYmxl IHRvDQogbWFrZSB0aGF0IHRyYWRlIG9mZiB0byBnZXQgbGF0ZW5jeSBpbXByb3ZlbWVudHMgZm9y IDkwPHN1cD50aDwvc3VwPiBwZXJjZW50aWxlLiA8bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J TU8gPGk+aW1wcm92aW5nIFVEUCBwZXJmb3JtYW5jZSBhbmQgaGFyZHdhcmUgb2ZmbG9hZHMgYXJl IGFic29sdXRlbHkgYSBuZWNlc3NpdHkgZm9yIFFVSUMgdG8gYmVjb21lIHdpZGVseSBhZG9wdGVk PC9pPiAobm90IGp1c3QgYnkgdGhlIGJpZ2dlc3QmbmJzcDtjb3Jwb3JhdGlvbnMgd2l0aCBhIGxh cmdlIGJ1ZGdldCkuIFdlIGhhdmUgd29yayB1bmRlciB3YXkgb24gYm90aCB0aGVzZSBmcm9udHMg YW5kIEkgYW0gdmVyeQ0KIGhhcHB5IHRvIHNlZSBMaW51eCBhbHNvIGludmVzdGluZyBoZXJlIGlu IHByZXBhcmF0aW9uIGZvciB3aGF04oCZcyBjb21pbmcuIFdlIG5lZWQgdG8gZG8gb3VyIGJlc3Qg ZGVtb2NyYXRpemUgdGhpcyB0ZWNobm9sb2d5IC0gbXVsdGlwbGUgaW1wbGVtZW50YXRpb25zIGFu ZCBwZXJmb3JtYW5jZSB3aWxsIGJvdGggcGxheSBhIGJpZyByb2xlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYg T2YNCjwvYj5QaGlsbGlwIEhhbGxhbS1CYWtlcjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IEFwcmlsIDQsIDIwMTggOToyOSBBTTxicj4NCjxiPlRvOjwvYj4gTWlra2VsIEZhaG7DuGUgSsO4 cmdlbnNlbiAmbHQ7bWlra2VsZmpAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gU3Vib2Ro IEl5ZW5nYXIgJmx0O3N1Ym9kaEBmYi5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0 Zi5vcmcmZ3Q7OyBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFVEUCBzZW5kIGNvc3RzIGluIExpbnV4 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPkkgd291bGQgbm90IHdvcnJ5IHRvbyBtdWNoIGF0IHRoaXMgcG9pbnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5UaGUgcmVhc29uIHdlIHdhbnQgdG8gYmUgYWJsZSB0byB3b3JrIGF0IHRo ZSBhcHBsaWNhdGlvbiBsZXZlbCBpcyBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4gSXQgaGFzIHRv IGJlIHBvc3NpYmxlIHRvIGRlcGxveSBRVUlDIG9uIGFueSBtYWNoaW5lIGV2ZW4gd2l0aG91dCBP UyBzdXBwb3J0IG9yIGl0IHdvbid0IGJlIGRlcGxveWFibGUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JdCBk b2VzIG5vdCBoYXZlIHRvIGJlIHBlcmZvcm1hbnQgb24gZXZlcnkgcGxhdGZvcm0uIElmIHBlb3Bs ZSBhcmUgdXNpbmcgUVVJQywgd2hhdGV2ZXIgbmVlZHMgdG8gYmUgbW92ZWQgaW50byB0aGUga2Vy bmVsIGZvciBwZXJmb3JtYW5jZSByZWFzb25zIHdpbGwgbW92ZSB0aGVyZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFdlZCwgQXByIDQsIDIwMTggYXQgMTE6MzIgQU0sIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4g Jmx0OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5t aWtrZWxmakBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXYgaWQ9 Im1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaGF2ZSBubyBkYXRhIHRvIGFkZCBvbiB0aGUgTGlu dXggVURQIHN0YWNrLCBidXQgYW5vdGhlciBpc3N1ZSBpcyB0aGUgbGFjayBvZiBuZXRtYXAgc3Vw cG9ydCBpbiBjbG91ZCBob3N0aW5nIGVudmlyb25tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaGF2ZSBub3QgeWV0 IGJlZW4gd29ya2luZyB3aXRoIHRoaXMsIGJ1dCBoYXZlIGxvb2tlZCBpbnRvIHRoZSBwcm9ibGVt IGFuZCBhc2tlZCBhcm91bmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9Im1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPm5ldG1hcCBpcyBkZWZhdWx0 IGluIEZyZWVCU0QgYW5kIG9wdGlvbmFsIGluIExpbnV4LiBCdXQgbmVpdGhlciB3b3JrcyBlZmZp Y2llbnRseSB3aXRob3V0IGEgaHlwZXJ2aXNvciBwYXRjaCB0aGF0IGlzIGFsc28gYXZhaWxhYmxl IGZvciBuZXRtYXAuIFdpdGggc3VwcG9ydCBmb3IgbmV0bWFwLCB0aGUNCiB1c2VyIHNwYWNlIGFw cGxpY2F0aW9uIGNhbiBzZW5kIGRpcmVjdGx5IHRvIHRoZSBuZXR3b3JrIGFkYXB0ZXIgd2l0aCB2 ZXJ5IGxpdHRsZSBvdmVyaGVhZC4gVGhlcmUgaXMgYWxzbyBkcGRrIGFuZCBzb21lIG90aGVyIGlu dGVyZmFjZXMgdGhhdCBtaWdodCBiZSBzbGlnaHRseSBmYXN0ZXIgYnV0IG1vcmUgdmVuZG9yIHNw ZWNpZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xNjUxNzQy ODc5NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Bc3N1bWluZyBhbiBhcHBsaWNhdGlvbiBoYXMg YWNjZXNzIHRvIG9wdGltaXplZCBuZXRtYXAsIHRoZSBvbmx5IGh1cmRsZSBpcyBhZGRyZXNzIGxv b2t1cCwgYnV0IGlmIHRoZSBhcHBsaWNhdGlvbiBhbHNvIG1hbmFnZXMgdGhhdCwgb3IgYXQgbGVh c3QgZG9lcyB0aGUgY2FjaGluZywgdGhlcmUgc2hvdWxkbuKAmXQNCiBiZSBtdWNoIGluIHRoZSB3 YXkgb2YgT1MgaW50ZXJmZXJlbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0ibV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PZiBjb3Vyc2UsIG5l dG1hcCBibG9ja3MgdGhlIGVudGlyZSBuZXR3b3JrIHN0YWNrLCBzbyBubyBQSU5HIG9yIFNTSC4g Q2xvdWRGbGFyZSBhZGRlZCBhIG5ldG1hcCBwYXRjaCBzbyBvbmx5IHNvbWUgdHJhZmZpYyB3b3Vs ZCBiZSByb3V0ZWQgZnJhIHRoZSBuZXR3b3JrIGludGVyZmFjZSB0byBuZXRtYXAsDQogYW5kIG5l dG1hcCBhbHNvIHN1cHBvcnRzIGVmZmljaWVudCBwYWNrZXQgZm9yd2FyZGluZyB0byB0aGUgT1Mg b3Igb3RoZXIgYXBwbGljYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0ibV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Ob25lIG9mIHRoaXMg d29ya3Mgd2VsbCBpbiBnZW5lcmFsLCBidXQgZm9yIGEgY2xvdWQgaG9zdCB0aGF0IGNhbiBiZSBi b290ZXQgYXV0b21hdGljYWxseSBhbmQgZGVzdHJveWVkIHJhdGhlciB0aGFuIHNlcnZpY2VkLCB0 aGVyZSBpcyBzb21lIG9wcG9ydHVuaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0ibV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21m b250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCBvbmx5IGlmIGNsb3VkIHNlcnZpY2UgcHJv dmlkZXJzIHN0YXJ0cyBhZGRpbmcgc3VwcG9ydCB0aGVpciBzdXBwb3J0ZWQgaW1hZ2VzIGFuZCBo eXBlcnZpc29ycy4gTm90IHN1cmUgaWYgYW55IGFyZSB3b3JraW5nIG9uIHRoaXMgbm93LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9j dXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i bV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1 c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 Izg4ODg4OCI+TWlra2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXYgaWQ9Im1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX3NpZ25fMTUyMjg1NTQxODAw MDU0ODg2NCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTY1MTc0Mjg3OTUw NTU1NTQ5MWFpcm1haWxvbiI+T24gNCBBcHJpbCAyMDE4IGF0IDE1LjExLjE3LCBJYW4gU3dldHQg KDxhIGhyZWY9Im1haWx0bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5pYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+KSB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBob3BlIHNvbWUgb2YgdGhlc2UgcGF0Y2hlcyB3aWxsIGJlIGF2YWlsYWJsZSBz b29uLCBidXQgSSdtIG5vdCBzdXJlIGlmIHNvb24gaXMgYSBtb250aCBvciA2LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBcHIgMywgMjAxOCBh dCAxMDo1MCBQTSBTdWJvZGggSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1Ym9kaEBmYi5j b20iIHRhcmdldD0iX2JsYW5rIj5zdWJvZGhAZmIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXYgaWQ9Im1fMTY1MTc0Mjg3OTUwNTU1NTQ5MW1fLTI1NDc3NDA2 NzU1MjY2MzUyMGRpdnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPlRoYW5rcyBmb3Igc2hhcmluZyB0aGlzIElhbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UaGlzIGRlZmluaXRlbHkgbWF0Y2hl cyBzb21lIG9mIHRoZSBvYnNlcnZhdGlvbnMgd2UndmUgc2VlbiBhcyB3ZWxsIGluIHRoZSBVRFAg d3JpdGUgcGF0aC4gU29tZSBvZiB0aGUgb3RoZXIgcGF0aHMgdGhhdCB3ZSBzYXcgdGhhdCBhZGRl ZCBvdmVyaGVhZCB3YXMgdGhlIHJvdXRlIHRhYmxlIGxvb2t1cA0KIGluIGxpbnV4IHVkcCBzdGFj ay4gQ29ubmVjdGVkIFVEUCBzb2NrZXRzIGRpZCBhbW9ydGl6ZSB0aGF0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkknbSBsb29raW5nIGZv cndhcmQgdG8gYSBzbWFydGVyIHNlbmRtbXNnIHdpdGggR1NPIGFuZCB6ZXJvIGNvcHkuIElzIHRo ZXJlIGFueSBpbmRpY2F0aW9uIG9mIHRoZSB0aW1lbGluZSBmb3IgdGhlc2UgcGF0Y2hlcyB0byBt YWtlIGl0IHRvIGxpbnV4PyBXb3VsZCBiZSBoYXBweSB0byB0cnkgYW55DQogb2YgdGhlc2Ugb3V0 IHRvIGhlbHAgaXJvbiBvdXQgdGhlIEFQSS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5TdWJvZGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt YWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4N CjwvZGl2Pg0KPGRpdiBpZD0ibV8xNjUxNzQyODc5NTA1NTU1NDkxbV8tMjU0Nzc0MDY3NTUyNjYz NTIwZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiBR VUlDICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZndDsgb24gYmVoYWxmIG9mIElhbiBTd2V0dCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi4ub3JnIj5pYW5zd2V0dD00MGdv b2dsZS5jb21AZG1hcmMuaWV0Zi4ub3JnPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0 Ozxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAzLCAyMDE4IDU6MjA6MDggUE08YnI+ DQo8Yj5Ubzo8L2I+IElFVEYgUVVJQyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBVRFAgc2VuZCBj b3N0cyBpbiBMaW51eDwvc3Bhbj4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgY2hhbGxlbmdlIHdpdGggUVVJQyBhdCB0aGUg bW9tZW50IGlzIHRoZSBpbmNyZWFzZWQgQ1BVIGNvc3Qgb2Ygc2VuZGluZyBVRFAgcGFja2V0cyB2 cyBUQ1AgcGF5bG9hZHMuJm5ic3A7IEkndmUgc2VlbiB0aGlzIGFjcm9zcyBldmVyeSBwbGF0Zm9y bSBHb29nbGUgaGFzIGRlcGxveWVkIFFVSUMgb24sIHNvIGl0J3MgYSB3aWRlc3ByZWFkIGlzc3Vl Lg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlJ3Mg YW4gZXhjZWxsZW50IHByZXNlbnRhdGlvbiBvbiB3aGF0J3MgY2F1c2luZyB0aGUgaW5jcmVhc2Vk IENQVSBjb25zdW1wdGlvbiBvbiBMaW51eCBmcm9tJm5ic3A7V2lsbGVtIGRlIEJydWlqbihVRFAg c3RhcnRzIG9uIHNsaWRlIDkpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnZnZXIua2VybmVsLm9yZyUyRm5ldGNvbmYy MDE3X2ZpbGVzJTJGcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBkZiZhbXA7ZGF0YT0wMiU3QzAx JTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDMTAzYTZlODFmMzY4NGM2NzM4MjYwOGQ1OWE0OTJj MmUlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM2NTg0NTYx NDQ5ODcyOTM1JmFtcDtzZGF0YT1GUGUwbVM1YUclMkI4OCUyRlNYdklWU08zeVduWGg5dE9oUWZL a0g2WG5RRHh2RSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly92Z2Vy Lmtlcm5lbC5vcmcvbmV0Y29uZjIwMTdfZmlsZXMvcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBk ZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QW5kIHdoaWxlIHlvdSdyZSB0aGlua2luZyBvZiBDUFUgdXNhZ2UsIGl0J3Mgd29ydGggbG9v a2luZyBhdCB0aGUgcHJlc2VudGF0aW9uIG9uIHRpbWluZyB3aGVlbCBiYXNlZCBwYWNrZXQgcGFj aW5nKHdoaWNoIGlzIG1pbmltdW0gcmVsZWFzZSB0aW1lIGJhc2VkKSBhbmQgaXMgaWRlYWwgZm9y IFFVSUMoYW5kIFRDUCBmb3IgdGhhdCBtYXR0ZXIpOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX19jb25mZXJl bmNlcy5zaWdjb21tLm9yZ19zaWdjb21tXzIwMTdfZmlsZXNfcHJvZ3JhbV90cy0yRDktMkQ0LTJE Y2Fyb3VzZWwucGRmJTI2ZCUzRER3TUZhUSUyNmMlM0Q1VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JTI2 ciUzRGgzSnU5RUJTN21IdHdnLXdBeU43ZlElMjZtJTNEdGdnaGd2RmtwczdqWWFGTmROeVpCTkZm MGVwVnhGWmJPR2hoeWJGd1BpRSUyNnMlM0Q4N2dPR2Z6M1MwbExidzhqeS1sejNNOXZQR0Noa21n dGlKVnpVeGJNZnZZJTI2ZSUzRCZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQu Y29tJTdDMTAzYTZlODFmMzY4NGM2NzM4MjYwOGQ1OWE0OTJjMmUlN0M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTg0NTYxNDQ5ODcyOTM1JmFtcDtzZGF0YT1o U1hYdlRPRHZsakk2bmlCTG1NeEdVRlM5ZyUyRnFPaUhza1VjTmNnSHRFNmslM0QmYW1wO3Jlc2Vy dmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NvbmZlcmVuY2VzLnNpZ2NvbW0ub3JnL3Np Z2NvbW0vMjAxNy9maWxlcy9wcm9ncmFtL3RzLTktNC1jYXJvdXNlbC4ucGRmPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tSWFuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB06302D6BC1865A5889759548B6A40CY4PR21MB0630namp_-- From nobody Wed Apr 4 10:57:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB247129C6E for ; Wed, 4 Apr 2018 10:57:29 -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=unavailable 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 JJVeNtMaJCt5 for ; Wed, 4 Apr 2018 10:57:25 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on071c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::71c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59999126CD6 for ; Wed, 4 Apr 2018 10:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=23+wXo1YEQpHG1QP2RyLEpec7LDRpIbcPoGHQpDJBmE=; b=oBeeUWpYDQwOrnhagtTYdQFNXH4klW9bZ7HD2SdGyEiCnP4QpUT09DwiovQpHq7vlpebwjECsN4bWxnO93+4LslH/MOB+Zy1hUEdjxkGn1Y9xJN4LNkKQxuqyAhQ8YZLLGds8gza3+NkSxgwP+UgAuyFKxGbcxKBoDI1PxmbAJw= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0280.namprd21.prod.outlook.com (10.173.193.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 17:57:23 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 17:57:23 +0000 From: Praveen Balasubramanian To: Phillip Hallam-Baker , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: Subodh Iyengar , IETF QUIC WG , Ian Swett Subject: RE: UDP send costs in Linux Thread-Topic: UDP send costs in Linux Thread-Index: AQHTy6q+3JsicRIxhkabCq/gojpid6Pv6A6AgACtVICAACezAIAAD5iAgAAXAKA= Date: Wed, 4 Apr 2018 17:57:22 +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:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0280; 7:B6jF4JioNq6WAfpbfQJqTF4j4p4BppF+kMctuwp8WKbhUM6j5zG/jUkuktTIkhHJyCAdiQDcWqWcZOA6diq5xY0cSNz2brtpxwfv8lbLmYBxcFYP+ky+Db9L4CQrsGmqHhZZWLK0uTsky4HBZ63WSJSlWPUXa4ePJKxjeqnbL7tAfo4uvPHPeITAOpn8YZUwyOLN3rSpDybFGLM0iwcSyDZIUMW9fwElBJQv0D1DyArR7n2p7H2rVCzWuzOWI3cF; 20:jPAldTD8BG80LgDn/2QRPZLxqKvMEiu3Z9gMKULcdflTPZgGaoZ2cfCy9LYm6OUkz/ehovJFk+KKi1F/tIpXYNw3N35tQA0/IU3F2i+vwOvSMEscFPJpdAUTaDL7tmQIhRXhEZMSq/3IfY+HiIU/o+2Si9J2ZX/utBTOkGAdc6U= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8e9258f4-1e1e-4618-5105-08d59a55849a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0280; x-ms-traffictypediagnostic: CY4PR21MB0280: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(9452136761055)(189930954265078)(85827821059158)(67672495146484)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231221)(944501327)(52105095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0280; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0280; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(39860400002)(346002)(39380400002)(199004)(189003)(2900100001)(39060400002)(6246003)(53936002)(186003)(46003)(97736004)(11346002)(446003)(476003)(99286004)(86362001)(86612001)(25786009)(19609705001)(10290500003)(966005)(478600001)(606006)(3660700001)(10090500001)(4326008)(2906002)(8990500004)(3280700002)(68736007)(8936002)(8676002)(106356001)(105586002)(9686003)(55016002)(14454004)(54896002)(6306002)(81156014)(5250100002)(81166006)(6436002)(93886005)(7736002)(236005)(316002)(33656002)(22452003)(7696005)(76176011)(229853002)(6116002)(486006)(59450400001)(102836004)(6506007)(53546011)(74316002)(5660300001)(110136005)(54906003)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0280; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: pv4Lv0ARfLZqnPepQvN/DcsLoMk/G8qOMuibTCbAW/G1U9J5s87JXrJz1kH/AgJp6ttBQ3xD0E/6fHte1dRHOlCW18/NKfb8nc09w0xktwSkwxk6A0JwA5x6BIyq1Tkj5ACcnXzVSYaBiGyNOMKQwUNJe3Ex3wlqjYLJ4caDoSKwbJKesKAkBB6mncxnTjjUnDUcDoyL9rRNZLsvth03lejfJ+8MTpXemvLwF6HIhwnjR3TyFAohaydQ7jP8v3pyWFd/kb2rJG9Z1SDhco+AyHrLhQtpMYQ6k8aKf28LQzKY2ax/QeUWwfgxta5wRJIG0/UpM6OfVDvRAb71J1/632XLs4vmbn58pxvL516/ssYz5EEGq9EAxoMp0z/rmGDv7A67XDNTiE+Qyx00sLGGYOMFLMkmH7B9F2E5vzPh5yA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB06302D6BC1865A5889759548B6A40CY4PR21MB0630namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8e9258f4-1e1e-4618-5105-08d59a55849a X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 17:57:22.9535 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0280 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 17:57:30 -0000 --_000_CY4PR21MB06302D6BC1865A5889759548B6A40CY4PR21MB0630namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIG5lZWQgdG8gd29ycnkgaXMgbm90IG9uIHRoZSBjbGllbnQgc2lkZSDigJMgYXQgbGVhc3Qg bm90IGltbWVkaWF0ZWx5LiA4MDIuMTFhZCwgODAyLjExYXgsIGFuZCA1RyBMVEUgd2lsbCBicmlu ZyBHaWdhYml0IHJhdGVzIHRvIGNsaWVudCBzaWRlIHNvIGl0IGlzIGNlcnRhaW5seSBnb2luZyB0 byBiZWNvbWUgYSBwcm9ibGVtIGxvbmdlciB0ZXJtLg0KDQpUaGUgY3VycmVudCB3b3JyeSBpcyBv biB0aGUgc2VydmVyIHNpZGUuIEEgbGFyZ2UgcGFydCBvZiB0aGUgd29yayB3ZSBkbyBpcyBwZXJm b3JtYW5jZSBvcHRpbWl6YXRpb24gb2YgdGhlIG5ldHdvcmsgc3RhY2suIEdvb2dsZeKAmXMgU2ln Y29tbSBRVUlDIHBhcGVyIHNob3dzIGEgMnggQ1BVIGluY3JlYXNlIGdvaW5nIGZyb20gVENQIHRv IFFVSUMuIE1vc3Qgd2ViIHNlcnZpY2VzIHdpbGwgTk9UIGJlIGFibGUgdG8gbWFrZSB0aGF0IHRy YWRlIG9mZiB0byBnZXQgbGF0ZW5jeSBpbXByb3ZlbWVudHMgZm9yIDkwdGggcGVyY2VudGlsZS4N Cg0KSU1PIGltcHJvdmluZyBVRFAgcGVyZm9ybWFuY2UgYW5kIGhhcmR3YXJlIG9mZmxvYWRzIGFy ZSBhYnNvbHV0ZWx5IGEgbmVjZXNzaXR5IGZvciBRVUlDIHRvIGJlY29tZSB3aWRlbHkgYWRvcHRl ZCAobm90IGp1c3QgYnkgdGhlIGJpZ2dlc3QgY29ycG9yYXRpb25zIHdpdGggYSBsYXJnZSBidWRn ZXQpLiBXZSBoYXZlIHdvcmsgdW5kZXIgd2F5IG9uIGJvdGggdGhlc2UgZnJvbnRzIGFuZCBJIGFt IHZlcnkgaGFwcHkgdG8gc2VlIExpbnV4IGFsc28gaW52ZXN0aW5nIGhlcmUgaW4gcHJlcGFyYXRp b24gZm9yIHdoYXTigJlzIGNvbWluZy4gV2UgbmVlZCB0byBkbyBvdXIgYmVzdCBkZW1vY3JhdGl6 ZSB0aGlzIHRlY2hub2xvZ3kgLSBtdWx0aXBsZSBpbXBsZW1lbnRhdGlvbnMgYW5kIHBlcmZvcm1h bmNlIHdpbGwgYm90aCBwbGF5IGEgYmlnIHJvbGUuDQoNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWxsaXAgSGFsbGFtLUJha2VyDQpT ZW50OiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTggOToyOSBBTQ0KVG86IE1pa2tlbCBGYWhuw7hl IErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT4NCkNjOiBTdWJvZGggSXllbmdhciA8c3Vi b2RoQGZiLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IElhbiBTd2V0dCA8aWFu c3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFVEUCBzZW5k IGNvc3RzIGluIExpbnV4DQoNCkkgd291bGQgbm90IHdvcnJ5IHRvbyBtdWNoIGF0IHRoaXMgcG9p bnQuDQoNClRoZSByZWFzb24gd2Ugd2FudCB0byBiZSBhYmxlIHRvIHdvcmsgYXQgdGhlIGFwcGxp Y2F0aW9uIGxldmVsIGlzIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LiBJdCBoYXMgdG8gYmUgcG9z c2libGUgdG8gZGVwbG95IFFVSUMgb24gYW55IG1hY2hpbmUgZXZlbiB3aXRob3V0IE9TIHN1cHBv cnQgb3IgaXQgd29uJ3QgYmUgZGVwbG95YWJsZS4NCg0KSXQgZG9lcyBub3QgaGF2ZSB0byBiZSBw ZXJmb3JtYW50IG9uIGV2ZXJ5IHBsYXRmb3JtLiBJZiBwZW9wbGUgYXJlIHVzaW5nIFFVSUMsIHdo YXRldmVyIG5lZWRzIHRvIGJlIG1vdmVkIGludG8gdGhlIGtlcm5lbCBmb3IgcGVyZm9ybWFuY2Ug cmVhc29ucyB3aWxsIG1vdmUgdGhlcmUuDQoNCg0KDQoNCk9uIFdlZCwgQXByIDQsIDIwMTggYXQg MTE6MzIgQU0sIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxt YWlsdG86bWlra2VsZmpAZ21haWwuY29tPj4gd3JvdGU6DQpJIGhhdmUgbm8gZGF0YSB0byBhZGQg b24gdGhlIExpbnV4IFVEUCBzdGFjaywgYnV0IGFub3RoZXIgaXNzdWUgaXMgdGhlIGxhY2sgb2Yg bmV0bWFwIHN1cHBvcnQgaW4gY2xvdWQgaG9zdGluZyBlbnZpcm9ubWVudHMuDQpJIGhhdmUgbm90 IHlldCBiZWVuIHdvcmtpbmcgd2l0aCB0aGlzLCBidXQgaGF2ZSBsb29rZWQgaW50byB0aGUgcHJv YmxlbSBhbmQgYXNrZWQgYXJvdW5kLg0KDQpuZXRtYXAgaXMgZGVmYXVsdCBpbiBGcmVlQlNEIGFu ZCBvcHRpb25hbCBpbiBMaW51eC4gQnV0IG5laXRoZXIgd29ya3MgZWZmaWNpZW50bHkgd2l0aG91 dCBhIGh5cGVydmlzb3IgcGF0Y2ggdGhhdCBpcyBhbHNvIGF2YWlsYWJsZSBmb3IgbmV0bWFwLiBX aXRoIHN1cHBvcnQgZm9yIG5ldG1hcCwgdGhlIHVzZXIgc3BhY2UgYXBwbGljYXRpb24gY2FuIHNl bmQgZGlyZWN0bHkgdG8gdGhlIG5ldHdvcmsgYWRhcHRlciB3aXRoIHZlcnkgbGl0dGxlIG92ZXJo ZWFkLiBUaGVyZSBpcyBhbHNvIGRwZGsgYW5kIHNvbWUgb3RoZXIgaW50ZXJmYWNlcyB0aGF0IG1p Z2h0IGJlIHNsaWdodGx5IGZhc3RlciBidXQgbW9yZSB2ZW5kb3Igc3BlY2lmaWMuDQoNCkFzc3Vt aW5nIGFuIGFwcGxpY2F0aW9uIGhhcyBhY2Nlc3MgdG8gb3B0aW1pemVkIG5ldG1hcCwgdGhlIG9u bHkgaHVyZGxlIGlzIGFkZHJlc3MgbG9va3VwLCBidXQgaWYgdGhlIGFwcGxpY2F0aW9uIGFsc28g bWFuYWdlcyB0aGF0LCBvciBhdCBsZWFzdCBkb2VzIHRoZSBjYWNoaW5nLCB0aGVyZSBzaG91bGRu 4oCZdCBiZSBtdWNoIGluIHRoZSB3YXkgb2YgT1MgaW50ZXJmZXJlbmNlLg0KDQpPZiBjb3Vyc2Us IG5ldG1hcCBibG9ja3MgdGhlIGVudGlyZSBuZXR3b3JrIHN0YWNrLCBzbyBubyBQSU5HIG9yIFNT SC4gQ2xvdWRGbGFyZSBhZGRlZCBhIG5ldG1hcCBwYXRjaCBzbyBvbmx5IHNvbWUgdHJhZmZpYyB3 b3VsZCBiZSByb3V0ZWQgZnJhIHRoZSBuZXR3b3JrIGludGVyZmFjZSB0byBuZXRtYXAsIGFuZCBu ZXRtYXAgYWxzbyBzdXBwb3J0cyBlZmZpY2llbnQgcGFja2V0IGZvcndhcmRpbmcgdG8gdGhlIE9T IG9yIG90aGVyIGFwcGxpY2F0aW9ucy4NCg0KTm9uZSBvZiB0aGlzIHdvcmtzIHdlbGwgaW4gZ2Vu ZXJhbCwgYnV0IGZvciBhIGNsb3VkIGhvc3QgdGhhdCBjYW4gYmUgYm9vdGV0IGF1dG9tYXRpY2Fs bHkgYW5kIGRlc3Ryb3llZCByYXRoZXIgdGhhbiBzZXJ2aWNlZCwgdGhlcmUgaXMgc29tZSBvcHBv cnR1bml0eS4NCg0KYnV0IG9ubHkgaWYgY2xvdWQgc2VydmljZSBwcm92aWRlcnMgc3RhcnRzIGFk ZGluZyBzdXBwb3J0IHRoZWlyIHN1cHBvcnRlZCBpbWFnZXMgYW5kIGh5cGVydmlzb3JzLiBOb3Qg c3VyZSBpZiBhbnkgYXJlIHdvcmtpbmcgb24gdGhpcyBub3cuDQoNCg0KTWlra2VsDQoNCg0KDQpP biA0IEFwcmlsIDIwMTggYXQgMTUuMTEuMTcsIElhbiBTd2V0dCAoaWFuc3dldHQ9NDBnb29nbGUu Y29tQGRtYXJjLmlldGYub3JnPG1haWx0bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0 Zi5vcmc+KSB3cm90ZToNCkkgaG9wZSBzb21lIG9mIHRoZXNlIHBhdGNoZXMgd2lsbCBiZSBhdmFp bGFibGUgc29vbiwgYnV0IEknbSBub3Qgc3VyZSBpZiBzb29uIGlzIGEgbW9udGggb3IgNi4NCg0K T24gVHVlLCBBcHIgMywgMjAxOCBhdCAxMDo1MCBQTSBTdWJvZGggSXllbmdhciA8c3Vib2RoQGZi LmNvbTxtYWlsdG86c3Vib2RoQGZiLmNvbT4+IHdyb3RlOg0KDQpUaGFua3MgZm9yIHNoYXJpbmcg dGhpcyBJYW4uDQoNCg0KDQpUaGlzIGRlZmluaXRlbHkgbWF0Y2hlcyBzb21lIG9mIHRoZSBvYnNl cnZhdGlvbnMgd2UndmUgc2VlbiBhcyB3ZWxsIGluIHRoZSBVRFAgd3JpdGUgcGF0aC4gU29tZSBv ZiB0aGUgb3RoZXIgcGF0aHMgdGhhdCB3ZSBzYXcgdGhhdCBhZGRlZCBvdmVyaGVhZCB3YXMgdGhl IHJvdXRlIHRhYmxlIGxvb2t1cCBpbiBsaW51eCB1ZHAgc3RhY2suIENvbm5lY3RlZCBVRFAgc29j a2V0cyBkaWQgYW1vcnRpemUgdGhhdC4NCg0KDQoNCkknbSBsb29raW5nIGZvcndhcmQgdG8gYSBz bWFydGVyIHNlbmRtbXNnIHdpdGggR1NPIGFuZCB6ZXJvIGNvcHkuIElzIHRoZXJlIGFueSBpbmRp Y2F0aW9uIG9mIHRoZSB0aW1lbGluZSBmb3IgdGhlc2UgcGF0Y2hlcyB0byBtYWtlIGl0IHRvIGxp bnV4PyBXb3VsZCBiZSBoYXBweSB0byB0cnkgYW55IG9mIHRoZXNlIG91dCB0byBoZWxwIGlyb24g b3V0IHRoZSBBUEkuDQoNCg0KDQpTdWJvZGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3Vu Y2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUu Y29tQGRtYXJjLmlldGYuLm9yZzxtYWlsdG86aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmll dGYuLm9yZz4+DQpTZW50OiBUdWVzZGF5LCBBcHJpbCAzLCAyMDE4IDU6MjA6MDggUE0NClRvOiBJ RVRGIFFVSUMgV0cNClN1YmplY3Q6IFVEUCBzZW5kIGNvc3RzIGluIExpbnV4DQoNCk9uZSBjaGFs bGVuZ2Ugd2l0aCBRVUlDIGF0IHRoZSBtb21lbnQgaXMgdGhlIGluY3JlYXNlZCBDUFUgY29zdCBv ZiBzZW5kaW5nIFVEUCBwYWNrZXRzIHZzIFRDUCBwYXlsb2Fkcy4gIEkndmUgc2VlbiB0aGlzIGFj cm9zcyBldmVyeSBwbGF0Zm9ybSBHb29nbGUgaGFzIGRlcGxveWVkIFFVSUMgb24sIHNvIGl0J3Mg YSB3aWRlc3ByZWFkIGlzc3VlLg0KDQpIZXJlJ3MgYW4gZXhjZWxsZW50IHByZXNlbnRhdGlvbiBv biB3aGF0J3MgY2F1c2luZyB0aGUgaW5jcmVhc2VkIENQVSBjb25zdW1wdGlvbiBvbiBMaW51eCBm cm9tIFdpbGxlbSBkZSBCcnVpam4oVURQIHN0YXJ0cyBvbiBzbGlkZSA5KS4NCmh0dHA6Ly92Z2Vy Lmtlcm5lbC5vcmcvbmV0Y29uZjIwMTdfZmlsZXMvcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBk ZjxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw JTNBJTJGJTJGdmdlci5rZXJuZWwub3JnJTJGbmV0Y29uZjIwMTdfZmlsZXMlMkZyeF9oYXJkZW5p bmdfYW5kX3VkcF9nc28ucGRmJmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3 QzEwM2E2ZTgxZjM2ODRjNjczODI2MDhkNTlhNDkyYzJlJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMSU3QzYzNjU4NDU2MTQ0OTg3MjkzNSZzZGF0YT1GUGUwbVM1YUcl MkI4OCUyRlNYdklWU08zeVduWGg5dE9oUWZLa0g2WG5RRHh2RSUzRCZyZXNlcnZlZD0wPg0KDQpB bmQgd2hpbGUgeW91J3JlIHRoaW5raW5nIG9mIENQVSB1c2FnZSwgaXQncyB3b3J0aCBsb29raW5n IGF0IHRoZSBwcmVzZW50YXRpb24gb24gdGltaW5nIHdoZWVsIGJhc2VkIHBhY2tldCBwYWNpbmco d2hpY2ggaXMgbWluaW11bSByZWxlYXNlIHRpbWUgYmFzZWQpIGFuZCBpcyBpZGVhbCBmb3IgUVVJ QyhhbmQgVENQIGZvciB0aGF0IG1hdHRlcik6IGh0dHBzOi8vY29uZmVyZW5jZXMuc2lnY29tbS5v cmcvc2lnY29tbS8yMDE3L2ZpbGVzL3Byb2dyYW0vdHMtOS00LWNhcm91c2VsLi5wZGY8aHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ1cmxkZWZlbnNlLnByb29mcG9pbnQuY29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0cHMtM0FfX2Nv bmZlcmVuY2VzLnNpZ2NvbW0ub3JnX3NpZ2NvbW1fMjAxN19maWxlc19wcm9ncmFtX3RzLTJEOS0y RDQtMkRjYXJvdXNlbC5wZGYlMjZkJTNERHdNRmFRJTI2YyUzRDVWRDBSVHRObFRoM3ljZDQxYjNN VXclMjZyJTNEaDNKdTlFQlM3bUh0d2ctd0F5TjdmUSUyNm0lM0R0Z2doZ3ZGa3BzN2pZYUZOZE55 WkJORmYwZXBWeEZaYk9HaGh5YkZ3UGlFJTI2cyUzRDg3Z09HZnozUzBsTGJ3OGp5LWx6M005dlBH Q2hrbWd0aUpWelV4Yk1mdlklMjZlJTNEJmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0 LmNvbSU3QzEwM2E2ZTgxZjM2ODRjNjczODI2MDhkNTlhNDkyYzJlJTdDNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjU4NDU2MTQ0OTg3MjkzNSZzZGF0YT1oU1hY dlRPRHZsakk2bmlCTG1NeEdVRlM5ZyUyRnFPaUhza1VjTmNnSHRFNmslM0QmcmVzZXJ2ZWQ9MD4N Cg0KLUlhbg0KDQo= --_000_CY4PR21MB06302D6BC1865A5889759548B6A40CY4PR21MB0630namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFt c29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhh dmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1M KTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5k aWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1z dHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnAubTE2NTE3NDI4Nzk1MDU1NTU0OTFhaXJtYWlsb24sIGxpLm0xNjUxNzQyODc5NTA1NTU1 NDkxYWlybWFpbG9uLCBkaXYubTE2NTE3NDI4Nzk1MDU1NTU0OTFhaXJtYWlsb24NCgl7bXNvLXN0 eWxlLW5hbWU6bV8xNjUxNzQyODc5NTA1NTU1NDkxYWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhv ZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbmVl ZCB0byB3b3JyeSBpcyBub3Qgb24gdGhlIGNsaWVudCBzaWRlIOKAkyBhdCBsZWFzdCBub3QgaW1t ZWRpYXRlbHkuIDgwMi4xMWFkLCA4MDIuMTFheCwgYW5kIDVHIExURSB3aWxsIGJyaW5nIEdpZ2Fi aXQgcmF0ZXMgdG8gY2xpZW50IHNpZGUgc28gaXQgaXMgY2VydGFpbmx5IGdvaW5nIHRvIGJlY29t ZSBhIHByb2JsZW0gbG9uZ2VyIHRlcm0uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGN1 cnJlbnQgd29ycnkgaXMgb24gdGhlIHNlcnZlciBzaWRlLiBBIGxhcmdlIHBhcnQgb2YgdGhlIHdv cmsgd2UgZG8gaXMgcGVyZm9ybWFuY2Ugb3B0aW1pemF0aW9uIG9mIHRoZSBuZXR3b3JrIHN0YWNr LiBHb29nbGXigJlzIFNpZ2NvbW0gUVVJQyBwYXBlciBzaG93cyBhIDJ4IENQVSBpbmNyZWFzZSBn b2luZyBmcm9tIFRDUCB0byBRVUlDLiBNb3N0IHdlYiBzZXJ2aWNlcyB3aWxsIE5PVCBiZSBhYmxl IHRvDQogbWFrZSB0aGF0IHRyYWRlIG9mZiB0byBnZXQgbGF0ZW5jeSBpbXByb3ZlbWVudHMgZm9y IDkwPHN1cD50aDwvc3VwPiBwZXJjZW50aWxlLiA8bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J TU8gPGk+aW1wcm92aW5nIFVEUCBwZXJmb3JtYW5jZSBhbmQgaGFyZHdhcmUgb2ZmbG9hZHMgYXJl IGFic29sdXRlbHkgYSBuZWNlc3NpdHkgZm9yIFFVSUMgdG8gYmVjb21lIHdpZGVseSBhZG9wdGVk PC9pPiAobm90IGp1c3QgYnkgdGhlIGJpZ2dlc3QmbmJzcDtjb3Jwb3JhdGlvbnMgd2l0aCBhIGxh cmdlIGJ1ZGdldCkuIFdlIGhhdmUgd29yayB1bmRlciB3YXkgb24gYm90aCB0aGVzZSBmcm9udHMg YW5kIEkgYW0gdmVyeQ0KIGhhcHB5IHRvIHNlZSBMaW51eCBhbHNvIGludmVzdGluZyBoZXJlIGlu IHByZXBhcmF0aW9uIGZvciB3aGF04oCZcyBjb21pbmcuIFdlIG5lZWQgdG8gZG8gb3VyIGJlc3Qg ZGVtb2NyYXRpemUgdGhpcyB0ZWNobm9sb2d5IC0gbXVsdGlwbGUgaW1wbGVtZW50YXRpb25zIGFu ZCBwZXJmb3JtYW5jZSB3aWxsIGJvdGggcGxheSBhIGJpZyByb2xlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYg T2YNCjwvYj5QaGlsbGlwIEhhbGxhbS1CYWtlcjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IEFwcmlsIDQsIDIwMTggOToyOSBBTTxicj4NCjxiPlRvOjwvYj4gTWlra2VsIEZhaG7DuGUgSsO4 cmdlbnNlbiAmbHQ7bWlra2VsZmpAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gU3Vib2Ro IEl5ZW5nYXIgJmx0O3N1Ym9kaEBmYi5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0 Zi5vcmcmZ3Q7OyBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFVEUCBzZW5kIGNvc3RzIGluIExpbnV4 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPkkgd291bGQgbm90IHdvcnJ5IHRvbyBtdWNoIGF0IHRoaXMgcG9pbnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5UaGUgcmVhc29uIHdlIHdhbnQgdG8gYmUgYWJsZSB0byB3b3JrIGF0IHRo ZSBhcHBsaWNhdGlvbiBsZXZlbCBpcyBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4gSXQgaGFzIHRv IGJlIHBvc3NpYmxlIHRvIGRlcGxveSBRVUlDIG9uIGFueSBtYWNoaW5lIGV2ZW4gd2l0aG91dCBP UyBzdXBwb3J0IG9yIGl0IHdvbid0IGJlIGRlcGxveWFibGUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JdCBk b2VzIG5vdCBoYXZlIHRvIGJlIHBlcmZvcm1hbnQgb24gZXZlcnkgcGxhdGZvcm0uIElmIHBlb3Bs ZSBhcmUgdXNpbmcgUVVJQywgd2hhdGV2ZXIgbmVlZHMgdG8gYmUgbW92ZWQgaW50byB0aGUga2Vy bmVsIGZvciBwZXJmb3JtYW5jZSByZWFzb25zIHdpbGwgbW92ZSB0aGVyZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFdlZCwgQXByIDQsIDIwMTggYXQgMTE6MzIgQU0sIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4g Jmx0OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5t aWtrZWxmakBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXYgaWQ9 Im1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaGF2ZSBubyBkYXRhIHRvIGFkZCBvbiB0aGUgTGlu dXggVURQIHN0YWNrLCBidXQgYW5vdGhlciBpc3N1ZSBpcyB0aGUgbGFjayBvZiBuZXRtYXAgc3Vw cG9ydCBpbiBjbG91ZCBob3N0aW5nIGVudmlyb25tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaGF2ZSBub3QgeWV0 IGJlZW4gd29ya2luZyB3aXRoIHRoaXMsIGJ1dCBoYXZlIGxvb2tlZCBpbnRvIHRoZSBwcm9ibGVt IGFuZCBhc2tlZCBhcm91bmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9Im1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPm5ldG1hcCBpcyBkZWZhdWx0 IGluIEZyZWVCU0QgYW5kIG9wdGlvbmFsIGluIExpbnV4LiBCdXQgbmVpdGhlciB3b3JrcyBlZmZp Y2llbnRseSB3aXRob3V0IGEgaHlwZXJ2aXNvciBwYXRjaCB0aGF0IGlzIGFsc28gYXZhaWxhYmxl IGZvciBuZXRtYXAuIFdpdGggc3VwcG9ydCBmb3IgbmV0bWFwLCB0aGUNCiB1c2VyIHNwYWNlIGFw cGxpY2F0aW9uIGNhbiBzZW5kIGRpcmVjdGx5IHRvIHRoZSBuZXR3b3JrIGFkYXB0ZXIgd2l0aCB2 ZXJ5IGxpdHRsZSBvdmVyaGVhZC4gVGhlcmUgaXMgYWxzbyBkcGRrIGFuZCBzb21lIG90aGVyIGlu dGVyZmFjZXMgdGhhdCBtaWdodCBiZSBzbGlnaHRseSBmYXN0ZXIgYnV0IG1vcmUgdmVuZG9yIHNw ZWNpZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xNjUxNzQy ODc5NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Bc3N1bWluZyBhbiBhcHBsaWNhdGlvbiBoYXMg YWNjZXNzIHRvIG9wdGltaXplZCBuZXRtYXAsIHRoZSBvbmx5IGh1cmRsZSBpcyBhZGRyZXNzIGxv b2t1cCwgYnV0IGlmIHRoZSBhcHBsaWNhdGlvbiBhbHNvIG1hbmFnZXMgdGhhdCwgb3IgYXQgbGVh c3QgZG9lcyB0aGUgY2FjaGluZywgdGhlcmUgc2hvdWxkbuKAmXQNCiBiZSBtdWNoIGluIHRoZSB3 YXkgb2YgT1MgaW50ZXJmZXJlbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0ibV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PZiBjb3Vyc2UsIG5l dG1hcCBibG9ja3MgdGhlIGVudGlyZSBuZXR3b3JrIHN0YWNrLCBzbyBubyBQSU5HIG9yIFNTSC4g Q2xvdWRGbGFyZSBhZGRlZCBhIG5ldG1hcCBwYXRjaCBzbyBvbmx5IHNvbWUgdHJhZmZpYyB3b3Vs ZCBiZSByb3V0ZWQgZnJhIHRoZSBuZXR3b3JrIGludGVyZmFjZSB0byBuZXRtYXAsDQogYW5kIG5l dG1hcCBhbHNvIHN1cHBvcnRzIGVmZmljaWVudCBwYWNrZXQgZm9yd2FyZGluZyB0byB0aGUgT1Mg b3Igb3RoZXIgYXBwbGljYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0ibV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Ob25lIG9mIHRoaXMg d29ya3Mgd2VsbCBpbiBnZW5lcmFsLCBidXQgZm9yIGEgY2xvdWQgaG9zdCB0aGF0IGNhbiBiZSBi b290ZXQgYXV0b21hdGljYWxseSBhbmQgZGVzdHJveWVkIHJhdGhlciB0aGFuIHNlcnZpY2VkLCB0 aGVyZSBpcyBzb21lIG9wcG9ydHVuaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0ibV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21m b250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCBvbmx5IGlmIGNsb3VkIHNlcnZpY2UgcHJv dmlkZXJzIHN0YXJ0cyBhZGRpbmcgc3VwcG9ydCB0aGVpciBzdXBwb3J0ZWQgaW1hZ2VzIGFuZCBo eXBlcnZpc29ycy4gTm90IHN1cmUgaWYgYW55IGFyZSB3b3JraW5nIG9uIHRoaXMgbm93LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9j dXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i bV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1 c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 Izg4ODg4OCI+TWlra2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXYgaWQ9Im1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX3NpZ25fMTUyMjg1NTQxODAw MDU0ODg2NCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTY1MTc0Mjg3OTUw NTU1NTQ5MWFpcm1haWxvbiI+T24gNCBBcHJpbCAyMDE4IGF0IDE1LjExLjE3LCBJYW4gU3dldHQg KDxhIGhyZWY9Im1haWx0bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5pYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+KSB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBob3BlIHNvbWUgb2YgdGhlc2UgcGF0Y2hlcyB3aWxsIGJlIGF2YWlsYWJsZSBz b29uLCBidXQgSSdtIG5vdCBzdXJlIGlmIHNvb24gaXMgYSBtb250aCBvciA2LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBcHIgMywgMjAxOCBh dCAxMDo1MCBQTSBTdWJvZGggSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1Ym9kaEBmYi5j b20iIHRhcmdldD0iX2JsYW5rIj5zdWJvZGhAZmIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXYgaWQ9Im1fMTY1MTc0Mjg3OTUwNTU1NTQ5MW1fLTI1NDc3NDA2 NzU1MjY2MzUyMGRpdnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPlRoYW5rcyBmb3Igc2hhcmluZyB0aGlzIElhbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UaGlzIGRlZmluaXRlbHkgbWF0Y2hl cyBzb21lIG9mIHRoZSBvYnNlcnZhdGlvbnMgd2UndmUgc2VlbiBhcyB3ZWxsIGluIHRoZSBVRFAg d3JpdGUgcGF0aC4gU29tZSBvZiB0aGUgb3RoZXIgcGF0aHMgdGhhdCB3ZSBzYXcgdGhhdCBhZGRl ZCBvdmVyaGVhZCB3YXMgdGhlIHJvdXRlIHRhYmxlIGxvb2t1cA0KIGluIGxpbnV4IHVkcCBzdGFj ay4gQ29ubmVjdGVkIFVEUCBzb2NrZXRzIGRpZCBhbW9ydGl6ZSB0aGF0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkknbSBsb29raW5nIGZv cndhcmQgdG8gYSBzbWFydGVyIHNlbmRtbXNnIHdpdGggR1NPIGFuZCB6ZXJvIGNvcHkuIElzIHRo ZXJlIGFueSBpbmRpY2F0aW9uIG9mIHRoZSB0aW1lbGluZSBmb3IgdGhlc2UgcGF0Y2hlcyB0byBt YWtlIGl0IHRvIGxpbnV4PyBXb3VsZCBiZSBoYXBweSB0byB0cnkgYW55DQogb2YgdGhlc2Ugb3V0 IHRvIGhlbHAgaXJvbiBvdXQgdGhlIEFQSS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5TdWJvZGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt YWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4N CjwvZGl2Pg0KPGRpdiBpZD0ibV8xNjUxNzQyODc5NTA1NTU1NDkxbV8tMjU0Nzc0MDY3NTUyNjYz NTIwZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiBR VUlDICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZndDsgb24gYmVoYWxmIG9mIElhbiBTd2V0dCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi4ub3JnIj5pYW5zd2V0dD00MGdv b2dsZS5jb21AZG1hcmMuaWV0Zi4ub3JnPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0 Ozxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAzLCAyMDE4IDU6MjA6MDggUE08YnI+ DQo8Yj5Ubzo8L2I+IElFVEYgUVVJQyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBVRFAgc2VuZCBj b3N0cyBpbiBMaW51eDwvc3Bhbj4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgY2hhbGxlbmdlIHdpdGggUVVJQyBhdCB0aGUg bW9tZW50IGlzIHRoZSBpbmNyZWFzZWQgQ1BVIGNvc3Qgb2Ygc2VuZGluZyBVRFAgcGFja2V0cyB2 cyBUQ1AgcGF5bG9hZHMuJm5ic3A7IEkndmUgc2VlbiB0aGlzIGFjcm9zcyBldmVyeSBwbGF0Zm9y bSBHb29nbGUgaGFzIGRlcGxveWVkIFFVSUMgb24sIHNvIGl0J3MgYSB3aWRlc3ByZWFkIGlzc3Vl Lg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlJ3Mg YW4gZXhjZWxsZW50IHByZXNlbnRhdGlvbiBvbiB3aGF0J3MgY2F1c2luZyB0aGUgaW5jcmVhc2Vk IENQVSBjb25zdW1wdGlvbiBvbiBMaW51eCBmcm9tJm5ic3A7V2lsbGVtIGRlIEJydWlqbihVRFAg c3RhcnRzIG9uIHNsaWRlIDkpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnZnZXIua2VybmVsLm9yZyUyRm5ldGNvbmYy MDE3X2ZpbGVzJTJGcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBkZiZhbXA7ZGF0YT0wMiU3QzAx JTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDMTAzYTZlODFmMzY4NGM2NzM4MjYwOGQ1OWE0OTJj MmUlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM2NTg0NTYx NDQ5ODcyOTM1JmFtcDtzZGF0YT1GUGUwbVM1YUclMkI4OCUyRlNYdklWU08zeVduWGg5dE9oUWZL a0g2WG5RRHh2RSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly92Z2Vy Lmtlcm5lbC5vcmcvbmV0Y29uZjIwMTdfZmlsZXMvcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBk ZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QW5kIHdoaWxlIHlvdSdyZSB0aGlua2luZyBvZiBDUFUgdXNhZ2UsIGl0J3Mgd29ydGggbG9v a2luZyBhdCB0aGUgcHJlc2VudGF0aW9uIG9uIHRpbWluZyB3aGVlbCBiYXNlZCBwYWNrZXQgcGFj aW5nKHdoaWNoIGlzIG1pbmltdW0gcmVsZWFzZSB0aW1lIGJhc2VkKSBhbmQgaXMgaWRlYWwgZm9y IFFVSUMoYW5kIFRDUCBmb3IgdGhhdCBtYXR0ZXIpOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX19jb25mZXJl bmNlcy5zaWdjb21tLm9yZ19zaWdjb21tXzIwMTdfZmlsZXNfcHJvZ3JhbV90cy0yRDktMkQ0LTJE Y2Fyb3VzZWwucGRmJTI2ZCUzRER3TUZhUSUyNmMlM0Q1VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JTI2 ciUzRGgzSnU5RUJTN21IdHdnLXdBeU43ZlElMjZtJTNEdGdnaGd2RmtwczdqWWFGTmROeVpCTkZm MGVwVnhGWmJPR2hoeWJGd1BpRSUyNnMlM0Q4N2dPR2Z6M1MwbExidzhqeS1sejNNOXZQR0Noa21n dGlKVnpVeGJNZnZZJTI2ZSUzRCZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQu Y29tJTdDMTAzYTZlODFmMzY4NGM2NzM4MjYwOGQ1OWE0OTJjMmUlN0M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTg0NTYxNDQ5ODcyOTM1JmFtcDtzZGF0YT1o U1hYdlRPRHZsakk2bmlCTG1NeEdVRlM5ZyUyRnFPaUhza1VjTmNnSHRFNmslM0QmYW1wO3Jlc2Vy dmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NvbmZlcmVuY2VzLnNpZ2NvbW0ub3JnL3Np Z2NvbW0vMjAxNy9maWxlcy9wcm9ncmFtL3RzLTktNC1jYXJvdXNlbC4ucGRmPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tSWFuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB06302D6BC1865A5889759548B6A40CY4PR21MB0630namp_-- From nobody Wed Apr 4 11:06:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B549A12D775 for ; Wed, 4 Apr 2018 11:06:45 -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 DZPXfL0_5Zpy for ; Wed, 4 Apr 2018 11:06:43 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 B9B38126BFD for ; Wed, 4 Apr 2018 11:06:43 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id h26-v6so24320689otj.12 for ; Wed, 04 Apr 2018 11:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lnI1QlCOWPSzV9eMQd6EGRU0SRnvxu1l+anMEKW+kx0=; b=lRCX/guzMU7LTBrlZAwAUs9+iO8vEL/de3eTeRftugu6jVfBge8/qik5YbrsIGWOzv lx6VVievlx1UE8yMHaOrKoPMbzGuIt1rK9xI7sC6qPkL8krr8nMYCT57LImVQYHITj5o 4O1fGaKPXhIHg3noYAYiqJh1xunwnweUju/UW8o0Ccla8UajQlt+psu7CmR+rDT7wg/E BeK06RkFyYg+6Z8+q/fZipuAMDmImCsIs95akC232EzpnwrXi6373dLU0rBKMbQX1gvC G1Rh+GusvEAZT6CxYP4DFeJ1+jiKn8BgzShJFV7UfidQ4xrhY2eXgAXX0KQ2RFOd9ZF1 DMjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=lnI1QlCOWPSzV9eMQd6EGRU0SRnvxu1l+anMEKW+kx0=; b=sgccEhLzPRb1YljtfaTHaDj2sNVgjYma/80f2ucV28/hZfkogBGbFCCH2IEPbHHL27 gU1c4mDno91tInGdNXfEotS8Z+1+EN31DoWNUHQwPxQRxlicWj+MfC6/EzgSi2OjbhFm Qo0TkWGtjeZBvVY4u03AhijMF45jrzC2e5y+Sh/oAF1FCrH9+zMNo/63dFKwMWB1fpFy UNFBAh9I4yUiwS2Q13cszDukCD+U+mHVWX7oTWmegFMwhsgzo0WZ8VGi8TNao49yivDP dx7scaaAtYqXlvK78xp8m2vex+2FqYrzP5RfLtho2Tc76/RhWAOsVEyOMm4G+DiNZLuH OexA== X-Gm-Message-State: ALQs6tDAKSXixyD9dYMHWClhs5G6+hiC4rPFkOv6A1GHdt/iyf51N0qV VjK2dnxUWbOJnRCG6WhuogOp23eI/rrxQ5zAMSCtbg== X-Google-Smtp-Source: AIpwx48nmzSntQ+CqBTTjPBx5kkGOiA+p1WYN4d1bH5udoBcu+KbojjIA8CACNc65OdEnVdQpz+0Uw0G1rhO9yqty6g= X-Received: by 2002:a9d:fa1:: with SMTP id d30-v6mr10707794otd.18.1522865202804; Wed, 04 Apr 2018 11:06:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.139.174 with HTTP; Wed, 4 Apr 2018 11:06:12 -0700 (PDT) In-Reply-To: <2DB3AC71-89B1-425C-8128-E673D34B7AFA@trammell.ch> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <2DB3AC71-89B1-425C-8128-E673D34B7AFA@trammell.ch> From: Ted Hardie Date: Wed, 4 Apr 2018 11:06:12 -0700 Message-ID: Subject: Re: Getting to consensus on packet number encryption To: Brian Trammell Cc: IETF QUIC WG , Mark Nottingham , Lars Eggert Content-Type: multipart/alternative; boundary="000000000000743b33056909afef" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 18:06:46 -0000 --000000000000743b33056909afef Content-Type: text/plain; charset="UTF-8" On Wed, Apr 4, 2018 at 7:31 AM, Brian Trammell wrote: > > > Of course, it's more complicated than that, because isn't it always. Way > more detail below (or just read draft-hardie-path-signals)... > > Given the citation above, it is probably no surprise that I generally agree with Brian on this. There is one place where I think we probably would emphasize things slightly differently. For more on his take, see https://github.com/britram/draft-trammell-wire-image/blob/master/draft-trammell-wire-image.md which talks a good bit about the ossification issue that he touched on in his message here. My emphasis is slightly different: how much does this choice constrain the working group's later choices? From my take, making the choice to encrypt the packet number in v1 has the lesser set of constraints, because it is possible for later versions to add a path-visible signal of sequence numbers if we see a reason to do so. That set of sequence numbers might not be the same as those being used for protocol state mechanics by the endpoints, but that's okay as they wouldn't be serving the same purpose. Looking at Brian's text on the utility of sequences to observers: Utility to on-path devices. The path can use the packet number for various > forms of classification (i.e., "is this probably QUIC?") and state tracking > ("does this look like a valid packet for a flow I know about?"), as well as > passive measurement and diagnostic purposes (i.e., for one-point upstream > loss and reordering measurement, as well as for rejecting loss and > reordered spin edges with a single spin bit). > it seems pretty clear that the passive measurement and diagnostic purposes would work with fairly small sequence numbers, maybe even down to sizes small enough to make the linkability problem less scary. The other issues ("does this look like quic" and "does this look like a known flow") seem like they don't really require packet numbers or even deliberately exposed sequence numbers, just consistency. In other words, if we do anything to expose sequences, the wire image we engineer does not have to simply re-use the packet numbers used for protocol mechanics. It can focus on the message we want to send to the path instead. regards, Ted --000000000000743b33056909afef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 4, 2018 at 7:31 AM, Brian Trammell <ietf@tra= mmell.ch> wrote:


Of course, it's more complicated than that, because isn't it always= . Way more detail below (or just read draft-hardie-path-signals)...


Given the citation above, it is probab= ly no surprise that I generally agree with Brian on this.=C2=A0 There is on= e place where I think we probably would emphasize things slightly different= ly.=C2=A0 For more on his take, see=C2=A0 ht= tps://github.com/britram/draft-trammell-wire-image/blob/master/draft-tramme= ll-wire-image.md which talks a good bit about the ossification issue th= at he touched on in his message here.

My emphasis is slig= htly different:=C2=A0 how much does this choice constrain the working group= 's later choices?=C2=A0 From my take, making the choice to encrypt the = packet number in v1 has the lesser set of constraints, because it is possib= le for later versions to add a path-visible signal of sequence numbers if w= e see a reason to do so.=C2=A0 That set of sequence numbers might not be th= e same as those being used for protocol state mechanics by the endpoints, b= ut that's okay as they wouldn't be serving the same purpose.=C2=A0 = Looking at Brian's text on the utility of sequences to observers:
Utility to on-path devi= ces. The path can use the packet number for=20 various forms of classification (i.e., "is this probably QUIC?") = and=20 state tracking ("does this look like a valid packet for a flow I know= =20 about?"), as well as passive measurement and diagnostic purposes (i.e.= ,=20 for one-point upstream loss and reordering measurement, as well as for=20 rejecting loss and reordered spin edges with a single spin bit).

it seems pretty clear that the passive meas= urement and diagnostic purposes would work with fairly small sequence numbe= rs, maybe even down to sizes small enough to make the linkability problem l= ess scary.=C2=A0 The other issues ("does this look like quic" and= "does this look like a known flow") seem like they don't rea= lly require packet numbers or even deliberately exposed sequence numbers, j= ust consistency.=C2=A0=C2=A0 In other words, if we do anything to expose se= quences, the wire image we engineer does not have to simply re-use the pack= et numbers used for protocol mechanics. It can focus on the message we want= to send to the path instead.

regards,

=
Ted
--000000000000743b33056909afef-- From nobody Wed Apr 4 11:25:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58211126C3D for ; Wed, 4 Apr 2018 11:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=alumni-cmu-edu.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 YMCBtIykzCOq for ; Wed, 4 Apr 2018 11:25:07 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A8F1200C1 for ; Wed, 4 Apr 2018 11:25:07 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id v194-v6so28799293itb.0 for ; Wed, 04 Apr 2018 11:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cmu-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aOl+PIWCiPbgc8IyOhA2yBHfMm+iGXYulFm3D3/C/TA=; b=mNUccYjZJ8wpsF9Z1tL+u3IjDKd9/7rKdrAKGzGZ/LlZCbqyMq+h3jUlxNj0zuq16v ExxM/hLnvirTLFDZpVx698vuRBOeirL5JN2gAgXyOyZXWDLnsb9q2VG6R6n28J3xq6ys WPGsF0cNXb/IhV+IzhRs51mmOrcyKAwCa3Ot8q1hmpKy095xNnOs//1ZEkY9SSjRNWim dGIbCSzZVojPHGarNserSQwIgK4f0a3eVRI0vNKrdNJpax1zbAH/bpdWW2xIXQyk4UIN DPuUvMSjSBnZcHdi7ZdBpU/g1edATNaTBexwE9z1yLep1OjjfID5tNEFMuNOvTwCA46Q 42Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=aOl+PIWCiPbgc8IyOhA2yBHfMm+iGXYulFm3D3/C/TA=; b=NkrjobkBqtqs4u98HuKVM5a0ggRJ7yvOS0tzzafZq7DZrXg2D1MImIlBMG2ClbfUE4 2tcqBk+o46Qimba/QzuKybLLLOi1yfw34NW8VO9yZhgdwW4pRCXgqJG0aff0lpzc4J29 /r2QU3p7Wp9sYOBBDolhZ9u8GSpZnwsqfhE4U7q+HSTO08qnalc5JwMJ1oBjRNWS552d Me+u+gUYAJIQSTDYwIwMHfx9mUGk9jCYjVYyQibapsUyxnTvbD1JxFU9r0lLlzOAlJ3E D28oulB9Pj2XinBKiHYtVUq1rzoWl1XppHnR8RYYp5jsoqIu+41++lBj447F6RRx0pbm +Aeg== X-Gm-Message-State: ALQs6tDrO4mXb7deUrN2tHUM+UhAJb/vrIN5NoMUVk68JS9a/qurVMbU QIOoKWY0bjsPUnjwsmoUb+SkbA9z4UQHHgmDTkmBLA== X-Google-Smtp-Source: AIpwx4+LmUN0jTyyLMLDGrwtIio4XdfbNAjfS2W5e9yxYnYPoAunaLxiuxtTgdXJATPB67fcOG1QpC9Sdiwe5OH8D9w= X-Received: by 2002:a24:ec8:: with SMTP id 191-v6mr11374994ite.42.1522866306836; Wed, 04 Apr 2018 11:25:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.38.11 with HTTP; Wed, 4 Apr 2018 11:25:06 -0700 (PDT) In-Reply-To: References: From: Frederick Kautz Date: Wed, 4 Apr 2018 11:25:06 -0700 Message-ID: Subject: Re: UDP send costs in Linux To: Praveen Balasubramanian Cc: Phillip Hallam-Baker , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Ian Swett , Subodh Iyengar , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000004280cc056909f1d4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 18:25:11 -0000 --0000000000004280cc056909f1d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I apologize to anyone here who gets a repeat of this message, the mailing list ate my earlier reply because my mail provider changed my default email address during a transition. Here is the original message: I agree with this sentiment. If we see traction, then we should see better kernel support and offloading. It should be trivial to get this working in something like VPP which can use DPDK to hw offload, entirely skipping the kernel in the data path. There are also techniques to bypass the initial memory allocation in the kernel such as ebpf used by cilium and memif used by vpp. My main concern at this point would be with cloud native environments with limited hw offloading support. E.g. if we run in AWS or GCE, better kernel support will probably be necessary. On Wed, Apr 4, 2018 at 10:57 AM, Praveen Balasubramanian < pravb=3D40microsoft.com@dmarc.ietf.org> wrote: > The need to worry is not on the client side =E2=80=93 at least not immedi= ately. > 802.11ad, 802.11ax, and 5G LTE will bring Gigabit rates to client side so > it is certainly going to become a problem longer term. > > > > The current worry is on the server side. A large part of the work we do i= s > performance optimization of the network stack. Google=E2=80=99s Sigcomm Q= UIC paper > shows a 2x CPU increase going from TCP to QUIC. Most web services will NO= T > be able to make that trade off to get latency improvements for 90th > percentile. > > > > IMO *improving UDP performance and hardware offloads are absolutely a > necessity for QUIC to become widely adopted* (not just by the > biggest corporations with a large budget). We have work under way on both > these fronts and I am very happy to see Linux also investing here in > preparation for what=E2=80=99s coming. We need to do our best democratize= this > technology - multiple implementations and performance will both play a bi= g > role. > > > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Phillip > Hallam-Baker > *Sent:* Wednesday, April 4, 2018 9:29 AM > *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen > *Cc:* Subodh Iyengar ; IETF QUIC WG ; Ian > Swett > *Subject:* Re: UDP send costs in Linux > > > > I would not worry too much at this point. > > > > The reason we want to be able to work at the application level is > backwards compatibility. It has to be possible to deploy QUIC on any > machine even without OS support or it won't be deployable. > > > > It does not have to be performant on every platform. If people are using > QUIC, whatever needs to be moved into the kernel for performance reasons > will move there. > > > > > > > > > > On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > > I have no data to add on the Linux UDP stack, but another issue is the > lack of netmap support in cloud hosting environments. > > I have not yet been working with this, but have looked into the problem > and asked around. > > > > netmap is default in FreeBSD and optional in Linux. But neither works > efficiently without a hypervisor patch that is also available for netmap. > With support for netmap, the user space application can send directly to > the network adapter with very little overhead. There is also dpdk and som= e > other interfaces that might be slightly faster but more vendor specific. > > > > Assuming an application has access to optimized netmap, the only hurdle i= s > address lookup, but if the application also manages that, or at least doe= s > the caching, there shouldn=E2=80=99t be much in the way of OS interferenc= e. > > > > Of course, netmap blocks the entire network stack, so no PING or SSH. > CloudFlare added a netmap patch so only some traffic would be routed fra > the network interface to netmap, and netmap also supports efficient packe= t > forwarding to the OS or other applications. > > > > None of this works well in general, but for a cloud host that can be > bootet automatically and destroyed rather than serviced, there is some > opportunity. > > > > but only if cloud service providers starts adding support their supported > images and hypervisors. Not sure if any are working on this now. > > > > > > Mikkel > > > > > > On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc. > ietf.org) wrote: > > I hope some of these patches will be available soon, but I'm not sure if > soon is a month or 6. > > > > On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar wrote: > > Thanks for sharing this Ian. > > > > This definitely matches some of the observations we've seen as well in th= e > UDP write path. Some of the other paths that we saw that added overhead w= as > the route table lookup in linux udp stack. Connected UDP sockets did > amortize that. > > > > I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is ther= e > any indication of the timeline for these patches to make it to linux? Wou= ld > be happy to try any of these out to help iron out the API. > > > > Subodh > ------------------------------ > > *From:* QUIC on behalf of Ian Swett < > ianswett=3D40google.com@dmarc.ietf..org> > *Sent:* Tuesday, April 3, 2018 5:20:08 PM > *To:* IETF QUIC WG > *Subject:* UDP send costs in Linux > > > > One challenge with QUIC at the moment is the increased CPU cost of sendin= g > UDP packets vs TCP payloads. I've seen this across every platform Google > has deployed QUIC on, so it's a widespread issue. > > > > Here's an excellent presentation on what's causing the increased CPU > consumption on Linux from Willem de Bruijn(UDP starts on slide 9). > > http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf > > > > > And while you're thinking of CPU usage, it's worth looking at the > presentation on timing wheel based packet pacing(which is minimum release > time based) and is ideal for QUIC(and TCP for that matter): > https://conferences.sigcomm.org/sigcomm/2017/ > files/program/ts-9-4-carousel..pdf > > > > > -Ian > > > --0000000000004280cc056909f1d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I apologize to anyone here who gets a repeat of this messa= ge, the mailing list ate my earlier reply because my mail provider changed = my default email address during a transition. Here is the original message:=

I agree with this sentiment. If we see traction, then we shoul= d see better kernel support and offloading.=C2=A0

It should be trivial to get this working in something l= ike VPP which can use DPDK to hw offload, entirely skipping the kernel in t= he data path.=C2=A0

Ther= e are also techniques to bypass the initial memory allocation in the kernel= such as ebpf used by cilium and memif used by vpp.
=
My main concern at this point would be with clo= ud native environments with limited hw offloading support. E.g. if we run i= n AWS or GCE, better kernel support will probably be necessary.
=


O= n Wed, Apr 4, 2018 at 10:57 AM, Praveen Balasubramanian &= lt;pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

The need to worry is not on the client side =E2=80= =93 at least not immediately. 802.11ad, 802.11ax, and 5G LTE will bring Gig= abit rates to client side so it is certainly going to become a problem long= er term.

=C2=A0

The current worry is on the server side. A large par= t of the work we do is performance optimization of the network stack. Googl= e=E2=80=99s Sigcomm QUIC paper shows a 2x CPU increase going from TCP to QU= IC. Most web services will NOT be able to make that trade off to get latency improvements for 90th percen= tile.

=C2=A0

IMO improving UDP performance and hardware offloa= ds are absolutely a necessity for QUIC to become widely adopted (not ju= st by the biggest=C2=A0corporations with a large budget). We have work unde= r way on both these fronts and I am very happy to see Linux also investing here in preparation for what=E2=80=99s c= oming. We need to do our best democratize this technology - multiple implem= entations and performance will both play a big role.

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, April 4, 2018 9:29 AM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Cc: Subodh Iyengar <subodh@fb.com>; IETF QUIC WG <quic@ietf.org>; Ian Swett <ianswett=3D40google.com@dm= arc.ietf.org>
Subject: Re: UDP send costs in Linux

=C2=A0

I would not worry t= oo much at this point.

=C2=A0

The reason we want = to be able to work at the application level is backwards compatibility. It = has to be possible to deploy QUIC on any machine even without OS support or= it won't be deployable.

=C2=A0

It does not have to= be performant on every platform. If people are using QUIC, whatever needs = to be moved into the kernel for performance reasons will move there.=

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e = J=C3=B8rgensen <= mikkelfj@gmail.com> wrote:

I have no data to add on the Linux UDP stack, but= another issue is the lack of netmap support in cloud hosting environments.=

I have not yet been working with this, but have l= ooked into the problem and asked around.

=C2=A0

netmap is default in FreeBSD and optional in Linu= x. But neither works efficiently without a hypervisor patch that is also av= ailable for netmap. With support for netmap, the user space application can send directly to the network adapter with very = little overhead. There is also dpdk and some other interfaces that might be= slightly faster but more vendor specific.

=C2=A0

Assuming an application has access to optimized n= etmap, the only hurdle is address lookup, but if the application also manag= es that, or at least does the caching, there shouldn=E2=80=99t be much in the way of OS interference.

=C2=A0

Of course, netmap blocks the entire network stack= , so no PING or SSH. CloudFlare added a netmap patch so only some traffic w= ould be routed fra the network interface to netmap, and netmap also supports efficient packet forwarding to the OS or other ap= plications.

=C2=A0

None of this works well in general, but for a clo= ud host that can be bootet automatically and destroyed rather than serviced= , there is some opportunity.

=C2=A0

but only if cloud service providers starts adding su= pport their supported images and hypervisors. Not sure if any are working o= n this now.

=C2=A0

=C2=A0

Mikkel

=C2=A0

=C2=A0

On 4 April = 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc.ietf.org) wrote:

I hope some of these patches will be available soon,= but I'm not sure if soon is a month or 6.

=C2=A0

Thanks for sharing this Ian.

=C2=A0

This definitely matches some of the observations we've = seen as well in the UDP write path. Some of the other paths that we saw tha= t added overhead was the route table lookup in linux udp stack. Connected UDP sockets did amortize that.=

=C2=A0

I'm looking forward to a smarter sendmmsg with GSO and = zero copy. Is there any indication of the timeline for these patches to mak= e it to linux? Would be happy to try any of these out to help iron out the API.

=C2=A0

Subodh

From: QUIC <quic-bounces@ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf..org>
Sent: Tuesday, April 3, 2018 5:20:08 PM
To: IETF QUIC WG
Subject: UDP send costs in Linux

=C2=A0

One challenge with QUIC at the moment is the increas= ed CPU cost of sending UDP packets vs TCP payloads.=C2=A0 I've seen thi= s across every platform Google has deployed QUIC on, so it's a widespre= ad issue.

=C2=A0

Here's an excellent presentation on what's c= ausing the increased CPU consumption on Linux from=C2=A0Willem de Bruijn(UD= P starts on slide 9).

=C2=A0

And while you're thinking of CPU usage, it's= worth looking at the presentation on timing wheel based packet pacing(whic= h is minimum release time based) and is ideal for QUIC(and TCP for that mat= ter):=C2=A0https://conferences.sigcomm.org/si= gcomm/2017/files/program/ts-9-4-carousel..pdf

=C2=A0

-Ian

=C2=A0


--0000000000004280cc056909f1d4-- From nobody Wed Apr 4 11:25:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A4F127058 for ; Wed, 4 Apr 2018 11:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522866312; bh=ffDGN97FHwIwPXZC7MbtqhV/iJ63ci3NG3h7SqUnkWE=; h=In-Reply-To:References:From:Date:Subject:Cc:To; b=YJa8zrEyF/KX6C8/iwbSTbjM4iuaGBZBGD9PQq0TOiPKPz8QFDWsMs6SJ2w4L4A5H VGS/Zdj5539SMPN9UpFzEDQVD0pRA1PN/vvlhwqHD6aMEwhBLYoq6b3xFiwb+NDwin qWkjNmAo8icPbIVhBdsLKWnu5ZwxAoTEaT30ronM= X-Mailbox-Line: From ffk@alumni.cmu.edu Wed Apr 4 11:25:12 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFEC126C0F; Wed, 4 Apr 2018 11:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522866312; bh=71pR25Ting7y7gQpjwXEheyxcfxUEiwkUZKJotVrVRY=; h=In-Reply-To:References:From:Date:Subject:Cc:To; b=oN4JfhBrmoPkk+bL32eI0H+B+yFR4i1KCbb8pHscS5tGHgipYj3GvyejWG4YXwaSQ lG9ceg387e0FG6oRlsFcETHAL/70oRWmm/MBsSlUyfnS+lXBloGLdOQyohb/wBUvRk vvc5EzDID+OhkZYmYMjbu9/P/HhUetvepEnCFF0Q= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5584C1200C1 for ; Wed, 4 Apr 2018 11:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=alumni-cmu-edu.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 qGbi2UiDFpmV for ; Wed, 4 Apr 2018 11:25:08 -0700 (PDT) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BD9126C0F for ; Wed, 4 Apr 2018 11:25:07 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id 15-v6so18563160itl.1 for ; Wed, 04 Apr 2018 11:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cmu-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aOl+PIWCiPbgc8IyOhA2yBHfMm+iGXYulFm3D3/C/TA=; b=mNUccYjZJ8wpsF9Z1tL+u3IjDKd9/7rKdrAKGzGZ/LlZCbqyMq+h3jUlxNj0zuq16v ExxM/hLnvirTLFDZpVx698vuRBOeirL5JN2gAgXyOyZXWDLnsb9q2VG6R6n28J3xq6ys WPGsF0cNXb/IhV+IzhRs51mmOrcyKAwCa3Ot8q1hmpKy095xNnOs//1ZEkY9SSjRNWim dGIbCSzZVojPHGarNserSQwIgK4f0a3eVRI0vNKrdNJpax1zbAH/bpdWW2xIXQyk4UIN DPuUvMSjSBnZcHdi7ZdBpU/g1edATNaTBexwE9z1yLep1OjjfID5tNEFMuNOvTwCA46Q 42Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=aOl+PIWCiPbgc8IyOhA2yBHfMm+iGXYulFm3D3/C/TA=; b=rvqfF4aooIi2hfRxUtaeQ/k5hrH8wrEKkfDxpYrd0ujXsboUNcsfsvlzSmedIsKaLY gUD8tSyVvbvat3bWrwhxUSymYHcUQ2335t+dP21mULHZhmcyT12EMZWuusF7P55f9IZE umOQ96MraZj3pekfQPxvHgvWzFIN63dyA/clu0Fer1DqdHdsvlXMiUP0rDx2+OiuzoWi WzW7nIJGaP1HzkOTR3DrGSix2vaQEkUqHrKvXEFto8RW6oOEuQ5bBV1zCE/sW6DFuPRx 0UX/6SdBfsCWMLBRNw/eiTBzJT+SD7/vsTnw8XguYhMrk1d3n0fgqiv6X3mdwyuauwWi QzmQ== X-Gm-Message-State: ALQs6tDVyToiKXk0C1N7BHy0PTCxnVBeaT6QXbWfDBKOoDzkblgpH1eM pG6NhHAIlOFjUU60PEdwqf5An4rDlD6gDEEKMjjh2plQXFw= X-Google-Smtp-Source: AIpwx4+LmUN0jTyyLMLDGrwtIio4XdfbNAjfS2W5e9yxYnYPoAunaLxiuxtTgdXJATPB67fcOG1QpC9Sdiwe5OH8D9w= X-Received: by 2002:a24:ec8:: with SMTP id 191-v6mr11374994ite.42.1522866306836; Wed, 04 Apr 2018 11:25:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.38.11 with HTTP; Wed, 4 Apr 2018 11:25:06 -0700 (PDT) In-Reply-To: References: From: Frederick Kautz Date: Wed, 4 Apr 2018 11:25:06 -0700 Message-ID: Subject: Re: UDP send costs in Linux Cc: Phillip Hallam-Baker , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Ian Swett , Subodh Iyengar , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000004280cc056909f1d4" To: Praveen Balasubramanian Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 18:25:13 -0000 --0000000000004280cc056909f1d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I apologize to anyone here who gets a repeat of this message, the mailing list ate my earlier reply because my mail provider changed my default email address during a transition. Here is the original message: I agree with this sentiment. If we see traction, then we should see better kernel support and offloading. It should be trivial to get this working in something like VPP which can use DPDK to hw offload, entirely skipping the kernel in the data path. There are also techniques to bypass the initial memory allocation in the kernel such as ebpf used by cilium and memif used by vpp. My main concern at this point would be with cloud native environments with limited hw offloading support. E.g. if we run in AWS or GCE, better kernel support will probably be necessary. On Wed, Apr 4, 2018 at 10:57 AM, Praveen Balasubramanian < pravb=3D40microsoft.com@dmarc.ietf.org> wrote: > The need to worry is not on the client side =E2=80=93 at least not immedi= ately. > 802.11ad, 802.11ax, and 5G LTE will bring Gigabit rates to client side so > it is certainly going to become a problem longer term. > > > > The current worry is on the server side. A large part of the work we do i= s > performance optimization of the network stack. Google=E2=80=99s Sigcomm Q= UIC paper > shows a 2x CPU increase going from TCP to QUIC. Most web services will NO= T > be able to make that trade off to get latency improvements for 90th > percentile. > > > > IMO *improving UDP performance and hardware offloads are absolutely a > necessity for QUIC to become widely adopted* (not just by the > biggest corporations with a large budget). We have work under way on both > these fronts and I am very happy to see Linux also investing here in > preparation for what=E2=80=99s coming. We need to do our best democratize= this > technology - multiple implementations and performance will both play a bi= g > role. > > > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Phillip > Hallam-Baker > *Sent:* Wednesday, April 4, 2018 9:29 AM > *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen > *Cc:* Subodh Iyengar ; IETF QUIC WG ; Ian > Swett > *Subject:* Re: UDP send costs in Linux > > > > I would not worry too much at this point. > > > > The reason we want to be able to work at the application level is > backwards compatibility. It has to be possible to deploy QUIC on any > machine even without OS support or it won't be deployable. > > > > It does not have to be performant on every platform. If people are using > QUIC, whatever needs to be moved into the kernel for performance reasons > will move there. > > > > > > > > > > On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > > I have no data to add on the Linux UDP stack, but another issue is the > lack of netmap support in cloud hosting environments. > > I have not yet been working with this, but have looked into the problem > and asked around. > > > > netmap is default in FreeBSD and optional in Linux. But neither works > efficiently without a hypervisor patch that is also available for netmap. > With support for netmap, the user space application can send directly to > the network adapter with very little overhead. There is also dpdk and som= e > other interfaces that might be slightly faster but more vendor specific. > > > > Assuming an application has access to optimized netmap, the only hurdle i= s > address lookup, but if the application also manages that, or at least doe= s > the caching, there shouldn=E2=80=99t be much in the way of OS interferenc= e. > > > > Of course, netmap blocks the entire network stack, so no PING or SSH. > CloudFlare added a netmap patch so only some traffic would be routed fra > the network interface to netmap, and netmap also supports efficient packe= t > forwarding to the OS or other applications. > > > > None of this works well in general, but for a cloud host that can be > bootet automatically and destroyed rather than serviced, there is some > opportunity. > > > > but only if cloud service providers starts adding support their supported > images and hypervisors. Not sure if any are working on this now. > > > > > > Mikkel > > > > > > On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc. > ietf.org) wrote: > > I hope some of these patches will be available soon, but I'm not sure if > soon is a month or 6. > > > > On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar wrote: > > Thanks for sharing this Ian. > > > > This definitely matches some of the observations we've seen as well in th= e > UDP write path. Some of the other paths that we saw that added overhead w= as > the route table lookup in linux udp stack. Connected UDP sockets did > amortize that. > > > > I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is ther= e > any indication of the timeline for these patches to make it to linux? Wou= ld > be happy to try any of these out to help iron out the API. > > > > Subodh > ------------------------------ > > *From:* QUIC on behalf of Ian Swett < > ianswett=3D40google.com@dmarc.ietf..org> > *Sent:* Tuesday, April 3, 2018 5:20:08 PM > *To:* IETF QUIC WG > *Subject:* UDP send costs in Linux > > > > One challenge with QUIC at the moment is the increased CPU cost of sendin= g > UDP packets vs TCP payloads. I've seen this across every platform Google > has deployed QUIC on, so it's a widespread issue. > > > > Here's an excellent presentation on what's causing the increased CPU > consumption on Linux from Willem de Bruijn(UDP starts on slide 9). > > http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf > > > > > And while you're thinking of CPU usage, it's worth looking at the > presentation on timing wheel based packet pacing(which is minimum release > time based) and is ideal for QUIC(and TCP for that matter): > https://conferences.sigcomm.org/sigcomm/2017/ > files/program/ts-9-4-carousel..pdf > > > > > -Ian > > > --0000000000004280cc056909f1d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I apologize to anyone here who gets a repeat of this messa= ge, the mailing list ate my earlier reply because my mail provider changed = my default email address during a transition. Here is the original message:=

I agree with this sentiment. If we see traction, then we shoul= d see better kernel support and offloading.=C2=A0

It should be trivial to get this working in something l= ike VPP which can use DPDK to hw offload, entirely skipping the kernel in t= he data path.=C2=A0

Ther= e are also techniques to bypass the initial memory allocation in the kernel= such as ebpf used by cilium and memif used by vpp.
=
My main concern at this point would be with clo= ud native environments with limited hw offloading support. E.g. if we run i= n AWS or GCE, better kernel support will probably be necessary.
=


O= n Wed, Apr 4, 2018 at 10:57 AM, Praveen Balasubramanian &= lt;pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

The need to worry is not on the client side =E2=80= =93 at least not immediately. 802.11ad, 802.11ax, and 5G LTE will bring Gig= abit rates to client side so it is certainly going to become a problem long= er term.

=C2=A0

The current worry is on the server side. A large par= t of the work we do is performance optimization of the network stack. Googl= e=E2=80=99s Sigcomm QUIC paper shows a 2x CPU increase going from TCP to QU= IC. Most web services will NOT be able to make that trade off to get latency improvements for 90th percen= tile.

=C2=A0

IMO improving UDP performance and hardware offloa= ds are absolutely a necessity for QUIC to become widely adopted (not ju= st by the biggest=C2=A0corporations with a large budget). We have work unde= r way on both these fronts and I am very happy to see Linux also investing here in preparation for what=E2=80=99s c= oming. We need to do our best democratize this technology - multiple implem= entations and performance will both play a big role.

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, April 4, 2018 9:29 AM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Cc: Subodh Iyengar <subodh@fb.com>; IETF QUIC WG <quic@ietf.org>; Ian Swett <ianswett=3D40google.com@dm= arc.ietf.org>
Subject: Re: UDP send costs in Linux

=C2=A0

I would not worry t= oo much at this point.

=C2=A0

The reason we want = to be able to work at the application level is backwards compatibility. It = has to be possible to deploy QUIC on any machine even without OS support or= it won't be deployable.

=C2=A0

It does not have to= be performant on every platform. If people are using QUIC, whatever needs = to be moved into the kernel for performance reasons will move there.=

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e = J=C3=B8rgensen <= mikkelfj@gmail.com> wrote:

I have no data to add on the Linux UDP stack, but= another issue is the lack of netmap support in cloud hosting environments.=

I have not yet been working with this, but have l= ooked into the problem and asked around.

=C2=A0

netmap is default in FreeBSD and optional in Linu= x. But neither works efficiently without a hypervisor patch that is also av= ailable for netmap. With support for netmap, the user space application can send directly to the network adapter with very = little overhead. There is also dpdk and some other interfaces that might be= slightly faster but more vendor specific.

=C2=A0

Assuming an application has access to optimized n= etmap, the only hurdle is address lookup, but if the application also manag= es that, or at least does the caching, there shouldn=E2=80=99t be much in the way of OS interference.

=C2=A0

Of course, netmap blocks the entire network stack= , so no PING or SSH. CloudFlare added a netmap patch so only some traffic w= ould be routed fra the network interface to netmap, and netmap also supports efficient packet forwarding to the OS or other ap= plications.

=C2=A0

None of this works well in general, but for a clo= ud host that can be bootet automatically and destroyed rather than serviced= , there is some opportunity.

=C2=A0

but only if cloud service providers starts adding su= pport their supported images and hypervisors. Not sure if any are working o= n this now.

=C2=A0

=C2=A0

Mikkel

=C2=A0

=C2=A0

On 4 April = 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc.ietf.org) wrote:

I hope some of these patches will be available soon,= but I'm not sure if soon is a month or 6.

=C2=A0

Thanks for sharing this Ian.

=C2=A0

This definitely matches some of the observations we've = seen as well in the UDP write path. Some of the other paths that we saw tha= t added overhead was the route table lookup in linux udp stack. Connected UDP sockets did amortize that.=

=C2=A0

I'm looking forward to a smarter sendmmsg with GSO and = zero copy. Is there any indication of the timeline for these patches to mak= e it to linux? Would be happy to try any of these out to help iron out the API.

=C2=A0

Subodh

From: QUIC <quic-bounces@ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf..org>
Sent: Tuesday, April 3, 2018 5:20:08 PM
To: IETF QUIC WG
Subject: UDP send costs in Linux

=C2=A0

One challenge with QUIC at the moment is the increas= ed CPU cost of sending UDP packets vs TCP payloads.=C2=A0 I've seen thi= s across every platform Google has deployed QUIC on, so it's a widespre= ad issue.

=C2=A0

Here's an excellent presentation on what's c= ausing the increased CPU consumption on Linux from=C2=A0Willem de Bruijn(UD= P starts on slide 9).

=C2=A0

And while you're thinking of CPU usage, it's= worth looking at the presentation on timing wheel based packet pacing(whic= h is minimum release time based) and is ideal for QUIC(and TCP for that mat= ter):=C2=A0https://conferences.sigcomm.org/si= gcomm/2017/files/program/ts-9-4-carousel..pdf

=C2=A0

-Ian

=C2=A0


--0000000000004280cc056909f1d4-- From nobody Wed Apr 4 11:32:00 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B1E12D77D for ; Wed, 4 Apr 2018 11:31:58 -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, UNPARSEABLE_RELAY=0.001] autolearn=unavailable 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 UN2CgWMCS7hr for ; Wed, 4 Apr 2018 11:31:55 -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 1019E12D775 for ; Wed, 4 Apr 2018 11:31:55 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id h143-v6so29436199ita.4 for ; Wed, 04 Apr 2018 11:31:55 -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=aDMQsQm1FTYWJqVQxbNTH9k0rA8RcHrNn5Geao/PYEI=; b=ZLEKsPundtdCC0HCr9T7oVn5purnZs/bhYOWNuURT1NFZ8huhhYIYb3kFXLzNd5Lzt VHqfv8VhE4j7LStwIfaFeide8lVDgyCgw/KDbXTkVsU9NHFADk40xP/MGd9eGXgSkBsN lN1QUV9RvH/ghoUum5rw0teiG9GELXoCE8AGqirSpM0OcW8E/lP/oG7qTouXsSAS50lL ZpwrarAY9H6r9QsrG22MSOeA8hYWo4hwO8wNFcZegRUL2I9RajBdOzjXqIgXBVgGdLD4 CWD7FVPS5F1NnSWIblswOTmI05VI74wkIPV0RrA+koQR1HJOuHyMpaLuVcsNlDWi8ZH7 /djw== 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=aDMQsQm1FTYWJqVQxbNTH9k0rA8RcHrNn5Geao/PYEI=; b=AMB4PGjqELW7sQ5T+cI36y2stwke35sRarNev0bhhyh0PuaBrRz+QoYpvI0zfAYsuf DpL1YNA+uw8AmqZOJ33QB/apc5XSjv4omMx9O61/VpPTcboJH38AFe+g9f26RuKqppIl X/qJmgPunef+1I8Lq3Qgy9ubu0r7zCtHn06pBkf17cU4zK5KU4oULwzRfjAusUO6YjB5 08kAXmT8dFIwkI4zoExcmjRGuhRBgnezLmwzxnUhixRwyQ40FO/t7qTjkTd1KKI2B1Tj 01uqn9CCfpJPXhBC3F5XTFGHtyUgnqmA6xzWml/CUTx7dxMWJfj4Llijwz/Pt/NE3vvS NGtg== X-Gm-Message-State: ALQs6tAnaCyq1Rfd6tVAvYeGFy19haAU8+fHJaRNmKOG1FPc5uS6jGB6 xnidca++uOmV0ulg3PrIa7aHwxCkC0S+npnw6BrbEA== X-Google-Smtp-Source: AIpwx49fPksLdd/o3PflnAnBvVZK3YGjP4PbjX6nxkDs2Kw9ZqSod9OYV9vuFExhKxdlDR9nQuUyu1SkMec2xMCiR/s= X-Received: by 2002:a24:5085:: with SMTP id m127-v6mr11154872itb.118.1522866714373; Wed, 04 Apr 2018 11:31:54 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Apr 2018 20:31:53 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 4 Apr 2018 20:31:53 +0200 Message-ID: Subject: Re: UDP send costs in Linux To: Frederick Kautz , Praveen Balasubramanian Cc: Phillip Hallam-Baker , IETF QUIC WG , Ian Swett , Subodh Iyengar Content-Type: multipart/alternative; boundary="0000000000008cf2d805690a093e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 18:31:59 -0000 --0000000000008cf2d805690a093e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Got it before, but the reason why netmap and DPDK is important in contrast to kernel support is the very rich application interfaces that a custom user space QUIC implementation provides. Spending the next 10 years discussing epoll vs poll for QUIC is not going to cut it. OS support that makes it easier to use netmap and friends concurrently with other network traffic would be welcome though. Question is what hardware offload support can be given to a custom QUIC implementation, but one thing that comes to mind is pre-decryption on netmap where the OS first intercepts the packet and forwards the decrypted and DoS filtered packet to the app which then handles all the detailed framing, ACK, pacing etc. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 4 April 2018 at 20.25.07, Frederick Kautz (fkautz@alumni.cmu.edu) wrote: I apologize to anyone here who gets a repeat of this message, the mailing list ate my earlier reply because my mail provider changed my default email address during a transition. Here is the original message: I agree with this sentiment. If we see traction, then we should see better kernel support and offloading. It should be trivial to get this working in something like VPP which can use DPDK to hw offload, entirely skipping the kernel in the data path. There are also techniques to bypass the initial memory allocation in the kernel such as ebpf used by cilium and memif used by vpp. My main concern at this point would be with cloud native environments with limited hw offloading support. E.g. if we run in AWS or GCE, better kernel support will probably be necessary. On Wed, Apr 4, 2018 at 10:57 AM, Praveen Balasubramanian < pravb=3D40microsoft.com@dmarc.ietf.org> wrote: > The need to worry is not on the client side =E2=80=93 at least not immedi= ately. > 802.11ad, 802.11ax, and 5G LTE will bring Gigabit rates to client side so > it is certainly going to become a problem longer term. > > > > The current worry is on the server side. A large part of the work we do i= s > performance optimization of the network stack. Google=E2=80=99s Sigcomm Q= UIC paper > shows a 2x CPU increase going from TCP to QUIC. Most web services will NO= T > be able to make that trade off to get latency improvements for 90th > percentile. > > > > IMO *improving UDP performance and hardware offloads are absolutely a > necessity for QUIC to become widely adopted* (not just by the > biggest corporations with a large budget). We have work under way on both > these fronts and I am very happy to see Linux also investing here in > preparation for what=E2=80=99s coming. We need to do our best democratize= this > technology - multiple implementations and performance will both play a bi= g > role. > > > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of* Phillip > Hallam-Baker > *Sent:* Wednesday, April 4, 2018 9:29 AM > *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen > *Cc:* Subodh Iyengar ; IETF QUIC WG ; Ian > Swett > *Subject:* Re: UDP send costs in Linux > > > > I would not worry too much at this point. > > > > The reason we want to be able to work at the application level is > backwards compatibility. It has to be possible to deploy QUIC on any > machine even without OS support or it won't be deployable. > > > > It does not have to be performant on every platform. If people are using > QUIC, whatever needs to be moved into the kernel for performance reasons > will move there. > > > > > > > > > > On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > > I have no data to add on the Linux UDP stack, but another issue is the > lack of netmap support in cloud hosting environments. > > I have not yet been working with this, but have looked into the problem > and asked around. > > > > netmap is default in FreeBSD and optional in Linux. But neither works > efficiently without a hypervisor patch that is also available for netmap. > With support for netmap, the user space application can send directly to > the network adapter with very little overhead. There is also dpdk and som= e > other interfaces that might be slightly faster but more vendor specific. > > > > Assuming an application has access to optimized netmap, the only hurdle i= s > address lookup, but if the application also manages that, or at least doe= s > the caching, there shouldn=E2=80=99t be much in the way of OS interferenc= e. > > > > Of course, netmap blocks the entire network stack, so no PING or SSH. > CloudFlare added a netmap patch so only some traffic would be routed fra > the network interface to netmap, and netmap also supports efficient packe= t > forwarding to the OS or other applications. > > > > None of this works well in general, but for a cloud host that can be > bootet automatically and destroyed rather than serviced, there is some > opportunity. > > > > but only if cloud service providers starts adding support their supported > images and hypervisors. Not sure if any are working on this now. > > > > > > Mikkel > > > > > > On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc. > ietf.org) wrote: > > I hope some of these patches will be available soon, but I'm not sure if > soon is a month or 6. > > > > On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar wrote: > > Thanks for sharing this Ian. > > > > This definitely matches some of the observations we've seen as well in th= e > UDP write path. Some of the other paths that we saw that added overhead w= as > the route table lookup in linux udp stack. Connected UDP sockets did > amortize that. > > > > I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is ther= e > any indication of the timeline for these patches to make it to linux? Wou= ld > be happy to try any of these out to help iron out the API. > > > > Subodh > ------------------------------ > > *From:* QUIC on behalf of Ian Swett < > ianswett=3D40google.com@dmarc.ietf..org> > *Sent:* Tuesday, April 3, 2018 5:20:08 PM > *To:* IETF QUIC WG > *Subject:* UDP send costs in Linux > > > > One challenge with QUIC at the moment is the increased CPU cost of sendin= g > UDP packets vs TCP payloads. I've seen this across every platform Google > has deployed QUIC on, so it's a widespread issue. > > > > Here's an excellent presentation on what's causing the increased CPU > consumption on Linux from Willem de Bruijn(UDP starts on slide 9). > > http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf > > > > > And while you're thinking of CPU usage, it's worth looking at the > presentation on timing wheel based packet pacing(which is minimum release > time based) and is ideal for QUIC(and TCP for that matter): > https://conferences.sigcomm.org/sigcomm/2017/ > files/program/ts-9-4-carousel..pdf > > > > > -Ian > > > --0000000000008cf2d805690a093e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Got it before, but t= he reason why netmap and DPDK is important in contrast to kernel support is= the very rich application interfaces that a custom user space QUIC impleme= ntation provides. Spending the next 10 years discussing epoll vs poll for Q= UIC is not going to cut it.

OS support that makes it easier to use netmap and friends concurrent= ly with other network traffic would be welcome though.
Question is what hardware offload= support can be given to a custom QUIC implementation, but one thing that c= omes to mind is pre-decryption on netmap where the OS first intercepts the = packet and forwards the decrypted and DoS filtered packet to the app which = then handles all the detailed framing, ACK, pacing etc.

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


On 4 April 2018 at 20.25.0= 7, Frederick Kautz (fkautz@alumni.= cmu.edu) wrote:

=
I apologize to anyone here who gets a repeat of this message, the mailing list ate my earlier reply because my mail provider changed my default email address during a transition. Here is the original message:

I agree with this sentiment. If we see traction, then we should see better kernel support and offloading.=C2=A0

It should be trivial to get this working in something like VPP which can use DPDK to hw offload, entirely skipping the kernel in the data path.=C2=A0

There are also techniques to bypass the initial memory allocation in the kernel such as ebpf used by cilium and memif used by vpp.

My main concern at this point would be with cloud native environments with limited hw offloading support. E.g. if we run in AWS or GCE, better kernel support will probably be necessary.


On Wed, Apr 4, 2018 at 10:57 AM, Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.o= rg> wrote:

The need to worry is not on the client side =E2=80= =93 at least not immediately. 802.11ad, 802.11ax, and 5G LTE will bring Gigabit rates to client side so it is certainly going to become a problem longer term.

=C2=A0

The current worry is on the server side. A large part of the work we do is performance optimization of the network stack. Google=E2=80=99s Sigcomm QUIC paper shows a 2x CPU increase going from TCP to QUIC. Most web services will NOT be able to make that trade off to get latency improvements for 90th percentile.

=C2=A0

IMO improving UDP performance and hardware offloads are absolutely a necessity for QUIC to become widely adopted (not just by the biggest=C2=A0corporations with a large budget). We have work under way on both these fronts and I am very happy to see Linux also investing here in preparation for what=E2=80=99s coming. We need to do our best democratize this technology - multiple implementations and performance will both play a big role.

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of= Phillip Hallam-Baker
Sent: Wednesday, April 4, 2018 9:29 AM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Cc: Subodh Iyengar <subodh@fb.com>; IETF QUIC WG <quic@ietf.org>; Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
Subject: Re: UDP send costs in Linux

=C2=A0

I would not worry too much at this point.

=C2=A0

The reason we want to be able to work at the application level is backwards compatibility. It has to be possible to deploy QUIC on any machine even without OS support or it won't be deployable.

=C2=A0

It does not have to be performant on every platform. If people are using QUIC, whatever needs to be moved into the kernel for performance reasons will move there.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <= mikkelfj@gmail.com> wrote:

I have no data to add on the Linux UDP stack, but another issue is the lack of netmap support in cloud hosting environments.

I have not yet been working with this, but have looked into the problem and asked around.

=C2=A0

netmap is default in FreeBSD and optional in Linux. But neither works efficiently without a hypervisor patch that is also available for netmap. With support for netmap, the user space application can send directly to the network adapter with very little overhead. There is also dpdk and some other interfaces that might be slightly faster but more vendor specific.

=C2=A0

Assuming an application has access to optimized netmap, the only hurdle is address lookup, but if the application also manages that, or at least does the caching, there shouldn=E2=80=99t be much in the way of OS interference.

=C2=A0

Of course, netmap blocks the entire network stack, so no PING or SSH. CloudFlare added a netmap patch so only some traffic would be routed fra the network interface to netmap, and netmap also supports efficient packet forwarding to the OS or other applications.

=C2=A0

None of this works well in general, but for a cloud host that can be bootet automatically and destroyed rather than serviced, there is some opportunity.

=C2=A0

but only if cloud service providers starts adding support their supported images and hypervisors. Not sure if any are working on this now.

=C2=A0

=C2=A0

Mikkel

=C2=A0

=C2=A0

On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc.ietf= .org) wrote:

I hope some of these patches will be available soon, but I'm not sure if soon is a month or 6.

=C2=A0

On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar <subodh@fb.com>= ; wrote:

Thanks for sharing this Ian.

=C2=A0

This definitely matches some of the observations we've seen as well in the UDP write path. Some of the other paths that we saw that added overhead was the route table lookup in linux udp stack. Connected UDP sockets did amortize that.

=C2=A0

I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is there any indication of the timeline for these patches to make it to linux? Would be happy to try any of these out to help iron out the API.

=C2=A0

Subodh

From: QUIC <quic-bounces@ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf..o= rg>
Sent: Tuesday, April 3, 2018 5:20:08 PM
To: IETF QUIC WG
Subject: UDP send costs in Linux

=C2=A0

One challenge with QUIC at the moment is the increased CPU cost of sending UDP packets vs TCP payloads.=C2=A0 I've seen this across every platform Google has deployed QUIC on, so it's a widespread issue.

=C2=A0

Here's an excellent presentation on what's causing the increased CPU consumption on Linux from=C2=A0Willem de Bruijn(UDP starts on slide 9).

=C2=A0

And while you're thinking of CPU usage, it's worth looking at the presentation on timing wheel based packet pacing(which is minimum release time based) and is ideal for QUIC(and TCP for that matter):=C2=A0https://confer= ences.sigcomm.org/sigcomm/2017/files/program/ts-9-4-carousel..pdf

=C2=A0

-Ian

=C2=A0


--0000000000008cf2d805690a093e-- From nobody Wed Apr 4 11:32:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 028AA12D7E4 for ; Wed, 4 Apr 2018 11:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522866719; bh=FxUpBHwa2klQByMv3UaHQFolXVYqvVa9/5ifJ098Fow=; h=From:In-Reply-To:References:Date:Subject:Cc:To:To; b=ESwOfxxmIufR3K4FivMyk4xq6cqpbXb3sXUjLmG0os6934+us8Qw9NWc5agmZa7Le 9xVaaR8fJ42djAdrMMoj9SCHtO4HeT/p2ctwtOK9gWcjLOrQ90zlfTIs/mHduADk34 th1MQ4RvzfrIjutL/zM5wuisZRILn0A8pYi/odNc= X-Mailbox-Line: From mikkelfj@gmail.com Wed Apr 4 11:31:58 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8809D126C0F; Wed, 4 Apr 2018 11:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522866718; bh=r6dpbQVnxo9zrCVCDeofV9lWXSuUPNIFS0vo8ErSX0c=; h=From:In-Reply-To:References:Date:Subject:Cc:To:To; b=i4pmn8/xO+3k6KI2CuVJc3KAOPImdeZMP3qr5xUavRzye6WT1XtjvGmnS3AHeGXPs JdV+CE2J4dNzEeHbji0a1yD68ln0xWUkHyYRd68XMmqj8lFGScrRXusDLBJ0AZ9b1N jJRdSsPE1XqADtCeZBgde44PFCDcsnTgZCK+tBfQ= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A78612D77B for ; Wed, 4 Apr 2018 11:31:58 -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, 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 85PVmDE1wwfp for ; Wed, 4 Apr 2018 11:31:55 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E908126C0F for ; Wed, 4 Apr 2018 11:31:55 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 142-v6so29411358itl.5 for ; Wed, 04 Apr 2018 11:31:55 -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=aDMQsQm1FTYWJqVQxbNTH9k0rA8RcHrNn5Geao/PYEI=; b=ZLEKsPundtdCC0HCr9T7oVn5purnZs/bhYOWNuURT1NFZ8huhhYIYb3kFXLzNd5Lzt VHqfv8VhE4j7LStwIfaFeide8lVDgyCgw/KDbXTkVsU9NHFADk40xP/MGd9eGXgSkBsN lN1QUV9RvH/ghoUum5rw0teiG9GELXoCE8AGqirSpM0OcW8E/lP/oG7qTouXsSAS50lL ZpwrarAY9H6r9QsrG22MSOeA8hYWo4hwO8wNFcZegRUL2I9RajBdOzjXqIgXBVgGdLD4 CWD7FVPS5F1NnSWIblswOTmI05VI74wkIPV0RrA+koQR1HJOuHyMpaLuVcsNlDWi8ZH7 /djw== 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=aDMQsQm1FTYWJqVQxbNTH9k0rA8RcHrNn5Geao/PYEI=; b=b9yvqP/Zlq0oDOemA1u80Qcqbp24//QASYrGrZxubHLLlucp4l2M2OyRq3q8fDxROd oARAODyyFBqxCmRMXFCu33N9xoHO2+PFZrkHHGrpp5yUSZ+XYXzODWYSKFk/4luhD7Ik FiXKBdIN5ojypkVzFMRWfuxx8BOYQUJ9VWP1WlDKOZGk5CSFuB5y8w86xV8hcSgc86HC 9A0Qan8mgse4s1HPp5lRsJAyJz33s5w0L3D7YB7m+KsPTEgvrsSQOge+ESX4l43eEkhO 2rhqYk6rMj5Y6iLEzCjOlgQZWz6r6DsZ/lLhLL3S6wpFhNmPXFrVJIQWdMji1Pxb6kNo tvWw== X-Gm-Message-State: ALQs6tAP8Iyl206sy0NlFgop1FCeIhNEpLeTi7dc8o9ggXBG+Q3qSPOw Rm1bUbWWqNGxXIyzhx6eYXQy+mFicVm4vfcVRgU= X-Google-Smtp-Source: AIpwx49fPksLdd/o3PflnAnBvVZK3YGjP4PbjX6nxkDs2Kw9ZqSod9OYV9vuFExhKxdlDR9nQuUyu1SkMec2xMCiR/s= X-Received: by 2002:a24:5085:: with SMTP id m127-v6mr11154872itb.118.1522866714373; Wed, 04 Apr 2018 11:31:54 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Apr 2018 20:31:53 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 4 Apr 2018 20:31:53 +0200 Message-ID: Subject: Re: UDP send costs in Linux Cc: Phillip Hallam-Baker , IETF QUIC WG , Ian Swett , Subodh Iyengar Content-Type: multipart/alternative; boundary="0000000000008cf2d805690a093e" To: Frederick Kautz To: Praveen Balasubramanian Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 18:31:59 -0000 --0000000000008cf2d805690a093e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Got it before, but the reason why netmap and DPDK is important in contrast to kernel support is the very rich application interfaces that a custom user space QUIC implementation provides. Spending the next 10 years discussing epoll vs poll for QUIC is not going to cut it. OS support that makes it easier to use netmap and friends concurrently with other network traffic would be welcome though. Question is what hardware offload support can be given to a custom QUIC implementation, but one thing that comes to mind is pre-decryption on netmap where the OS first intercepts the packet and forwards the decrypted and DoS filtered packet to the app which then handles all the detailed framing, ACK, pacing etc. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 4 April 2018 at 20.25.07, Frederick Kautz (fkautz@alumni.cmu.edu) wrote: I apologize to anyone here who gets a repeat of this message, the mailing list ate my earlier reply because my mail provider changed my default email address during a transition. Here is the original message: I agree with this sentiment. If we see traction, then we should see better kernel support and offloading. It should be trivial to get this working in something like VPP which can use DPDK to hw offload, entirely skipping the kernel in the data path. There are also techniques to bypass the initial memory allocation in the kernel such as ebpf used by cilium and memif used by vpp. My main concern at this point would be with cloud native environments with limited hw offloading support. E.g. if we run in AWS or GCE, better kernel support will probably be necessary. On Wed, Apr 4, 2018 at 10:57 AM, Praveen Balasubramanian < pravb=3D40microsoft.com@dmarc.ietf.org> wrote: > The need to worry is not on the client side =E2=80=93 at least not immedi= ately. > 802.11ad, 802.11ax, and 5G LTE will bring Gigabit rates to client side so > it is certainly going to become a problem longer term. > > > > The current worry is on the server side. A large part of the work we do i= s > performance optimization of the network stack. Google=E2=80=99s Sigcomm Q= UIC paper > shows a 2x CPU increase going from TCP to QUIC. Most web services will NO= T > be able to make that trade off to get latency improvements for 90th > percentile. > > > > IMO *improving UDP performance and hardware offloads are absolutely a > necessity for QUIC to become widely adopted* (not just by the > biggest corporations with a large budget). We have work under way on both > these fronts and I am very happy to see Linux also investing here in > preparation for what=E2=80=99s coming. We need to do our best democratize= this > technology - multiple implementations and performance will both play a bi= g > role. > > > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of* Phillip > Hallam-Baker > *Sent:* Wednesday, April 4, 2018 9:29 AM > *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen > *Cc:* Subodh Iyengar ; IETF QUIC WG ; Ian > Swett > *Subject:* Re: UDP send costs in Linux > > > > I would not worry too much at this point. > > > > The reason we want to be able to work at the application level is > backwards compatibility. It has to be possible to deploy QUIC on any > machine even without OS support or it won't be deployable. > > > > It does not have to be performant on every platform. If people are using > QUIC, whatever needs to be moved into the kernel for performance reasons > will move there. > > > > > > > > > > On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > > I have no data to add on the Linux UDP stack, but another issue is the > lack of netmap support in cloud hosting environments. > > I have not yet been working with this, but have looked into the problem > and asked around. > > > > netmap is default in FreeBSD and optional in Linux. But neither works > efficiently without a hypervisor patch that is also available for netmap. > With support for netmap, the user space application can send directly to > the network adapter with very little overhead. There is also dpdk and som= e > other interfaces that might be slightly faster but more vendor specific. > > > > Assuming an application has access to optimized netmap, the only hurdle i= s > address lookup, but if the application also manages that, or at least doe= s > the caching, there shouldn=E2=80=99t be much in the way of OS interferenc= e. > > > > Of course, netmap blocks the entire network stack, so no PING or SSH. > CloudFlare added a netmap patch so only some traffic would be routed fra > the network interface to netmap, and netmap also supports efficient packe= t > forwarding to the OS or other applications. > > > > None of this works well in general, but for a cloud host that can be > bootet automatically and destroyed rather than serviced, there is some > opportunity. > > > > but only if cloud service providers starts adding support their supported > images and hypervisors. Not sure if any are working on this now. > > > > > > Mikkel > > > > > > On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc. > ietf.org) wrote: > > I hope some of these patches will be available soon, but I'm not sure if > soon is a month or 6. > > > > On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar wrote: > > Thanks for sharing this Ian. > > > > This definitely matches some of the observations we've seen as well in th= e > UDP write path. Some of the other paths that we saw that added overhead w= as > the route table lookup in linux udp stack. Connected UDP sockets did > amortize that. > > > > I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is ther= e > any indication of the timeline for these patches to make it to linux? Wou= ld > be happy to try any of these out to help iron out the API. > > > > Subodh > ------------------------------ > > *From:* QUIC on behalf of Ian Swett < > ianswett=3D40google.com@dmarc.ietf..org> > *Sent:* Tuesday, April 3, 2018 5:20:08 PM > *To:* IETF QUIC WG > *Subject:* UDP send costs in Linux > > > > One challenge with QUIC at the moment is the increased CPU cost of sendin= g > UDP packets vs TCP payloads. I've seen this across every platform Google > has deployed QUIC on, so it's a widespread issue. > > > > Here's an excellent presentation on what's causing the increased CPU > consumption on Linux from Willem de Bruijn(UDP starts on slide 9). > > http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf > > > > > And while you're thinking of CPU usage, it's worth looking at the > presentation on timing wheel based packet pacing(which is minimum release > time based) and is ideal for QUIC(and TCP for that matter): > https://conferences.sigcomm.org/sigcomm/2017/ > files/program/ts-9-4-carousel..pdf > > > > > -Ian > > > --0000000000008cf2d805690a093e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Got it before, but t= he reason why netmap and DPDK is important in contrast to kernel support is= the very rich application interfaces that a custom user space QUIC impleme= ntation provides. Spending the next 10 years discussing epoll vs poll for Q= UIC is not going to cut it.

OS support that makes it easier to use netmap and friends concurrent= ly with other network traffic would be welcome though.
Question is what hardware offload= support can be given to a custom QUIC implementation, but one thing that c= omes to mind is pre-decryption on netmap where the OS first intercepts the = packet and forwards the decrypted and DoS filtered packet to the app which = then handles all the detailed framing, ACK, pacing etc.

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


On 4 April 2018 at 20.25.0= 7, Frederick Kautz (fkautz@alumni.= cmu.edu) wrote:

=
I apologize to anyone here who gets a repeat of this message, the mailing list ate my earlier reply because my mail provider changed my default email address during a transition. Here is the original message:

I agree with this sentiment. If we see traction, then we should see better kernel support and offloading.=C2=A0

It should be trivial to get this working in something like VPP which can use DPDK to hw offload, entirely skipping the kernel in the data path.=C2=A0

There are also techniques to bypass the initial memory allocation in the kernel such as ebpf used by cilium and memif used by vpp.

My main concern at this point would be with cloud native environments with limited hw offloading support. E.g. if we run in AWS or GCE, better kernel support will probably be necessary.


On Wed, Apr 4, 2018 at 10:57 AM, Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.o= rg> wrote:

The need to worry is not on the client side =E2=80= =93 at least not immediately. 802.11ad, 802.11ax, and 5G LTE will bring Gigabit rates to client side so it is certainly going to become a problem longer term.

=C2=A0

The current worry is on the server side. A large part of the work we do is performance optimization of the network stack. Google=E2=80=99s Sigcomm QUIC paper shows a 2x CPU increase going from TCP to QUIC. Most web services will NOT be able to make that trade off to get latency improvements for 90th percentile.

=C2=A0

IMO improving UDP performance and hardware offloads are absolutely a necessity for QUIC to become widely adopted (not just by the biggest=C2=A0corporations with a large budget). We have work under way on both these fronts and I am very happy to see Linux also investing here in preparation for what=E2=80=99s coming. We need to do our best democratize this technology - multiple implementations and performance will both play a big role.

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of= Phillip Hallam-Baker
Sent: Wednesday, April 4, 2018 9:29 AM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Cc: Subodh Iyengar <subodh@fb.com>; IETF QUIC WG <quic@ietf.org>; Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
Subject: Re: UDP send costs in Linux

=C2=A0

I would not worry too much at this point.

=C2=A0

The reason we want to be able to work at the application level is backwards compatibility. It has to be possible to deploy QUIC on any machine even without OS support or it won't be deployable.

=C2=A0

It does not have to be performant on every platform. If people are using QUIC, whatever needs to be moved into the kernel for performance reasons will move there.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <= mikkelfj@gmail.com> wrote:

I have no data to add on the Linux UDP stack, but another issue is the lack of netmap support in cloud hosting environments.

I have not yet been working with this, but have looked into the problem and asked around.

=C2=A0

netmap is default in FreeBSD and optional in Linux. But neither works efficiently without a hypervisor patch that is also available for netmap. With support for netmap, the user space application can send directly to the network adapter with very little overhead. There is also dpdk and some other interfaces that might be slightly faster but more vendor specific.

=C2=A0

Assuming an application has access to optimized netmap, the only hurdle is address lookup, but if the application also manages that, or at least does the caching, there shouldn=E2=80=99t be much in the way of OS interference.

=C2=A0

Of course, netmap blocks the entire network stack, so no PING or SSH. CloudFlare added a netmap patch so only some traffic would be routed fra the network interface to netmap, and netmap also supports efficient packet forwarding to the OS or other applications.

=C2=A0

None of this works well in general, but for a cloud host that can be bootet automatically and destroyed rather than serviced, there is some opportunity.

=C2=A0

but only if cloud service providers starts adding support their supported images and hypervisors. Not sure if any are working on this now.

=C2=A0

=C2=A0

Mikkel

=C2=A0

=C2=A0

On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc.ietf= ..org) wrote:

I hope some of these patches will be available soon, but I'm not sure if soon is a month or 6.

=C2=A0

On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar <subodh@fb.com>= ; wrote:

Thanks for sharing this Ian.

=C2=A0

This definitely matches some of the observations we've seen as well in the UDP write path. Some of the other paths that we saw that added overhead was the route table lookup in linux udp stack. Connected UDP sockets did amortize that.

=C2=A0

I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is there any indication of the timeline for these patches to make it to linux? Would be happy to try any of these out to help iron out the API.

=C2=A0

Subodh

From: QUIC <quic-bounces@ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf..o= rg>
Sent: Tuesday, April 3, 2018 5:20:08 PM
To: IETF QUIC WG
Subject: UDP send costs in Linux

=C2=A0

One challenge with QUIC at the moment is the increased CPU cost of sending UDP packets vs TCP payloads.=C2=A0 I've seen this across every platform Google has deployed QUIC on, so it's a widespread issue.

=C2=A0

Here's an excellent presentation on what's causing the increased CPU consumption on Linux from=C2=A0Willem de Bruijn(UDP starts on slide 9).

=C2=A0

And while you're thinking of CPU usage, it's worth looking at the presentation on timing wheel based packet pacing(which is minimum release time based) and is ideal for QUIC(and TCP for that matter):=C2=A0https://confer= ences.sigcomm.org/sigcomm/2017/files/program/ts-9-4-carousel..pdf

=C2=A0

-Ian

=C2=A0


--0000000000008cf2d805690a093e-- From nobody Wed Apr 4 11:33:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D970A12D775 for ; Wed, 4 Apr 2018 11:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29zTbjuKLssJ for ; Wed, 4 Apr 2018 11:33: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 AD151126C0F for ; Wed, 4 Apr 2018 11:33:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 40GZNL27WGz15NYJ; Wed, 4 Apr 2018 20:33:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2N0-cOU7kSZ; Wed, 4 Apr 2018 20:33:37 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.24] (i577BCE70.versanet.de [87.123.206.112]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 4 Apr 2018 20:33:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Getting to consensus on packet number encryption From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Wed, 4 Apr 2018 20:33:35 +0200 Cc: Brian Trammell , Lars Eggert , Mark Nottingham , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <15157F08-4DBF-45E9-A1DD-C071EDDE7792@tik.ee.ethz.ch> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <2DB3AC71-89B1-425C-8128-E673D34B7AFA@trammell.ch> To: Ted Hardie X-Mailer: Apple Mail (2.3445.5.20) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 18:33:42 -0000 Hi Ted, based on what you say here, I=E2=80=99d like to further pick on an = important point > Am 04.04.2018 um 20:06 schrieb Ted Hardie : >=20 > My emphasis is slightly different: how much does this choice = constrain the working group's later choices? =46rom my take, making the = choice to encrypt the packet number in v1 has the lesser set of = constraints, because it is possible for later versions to add a = path-visible signal of sequence numbers if we see a reason to do so. = That set of sequence numbers might not be the same as those being used = for protocol state mechanics by the endpoints, but that's okay as they = wouldn't be serving the same purpose. =20 Currently the PN is used for a least two different purposes: 1) = congestion control/retransmissions and as 2) input for the decryption. = For the first purpose, the PN would not need to be in the wire image and = could just be part of the encrypted payload. I guess the main reason = that we use the same bits for both purposed is to save bits... While you say, we can still add an unencrypted PN for a third purpose = (measurements), it is also possible to add any time later (in a new = version or with extension frames) a separate PN for 1 to the fully = encrypted part of the packet that is independent of the exposed packet = number (in case that gets ossified and does not address the needs of the = quic transport machinery anymore).=20 So even if the exposed PN gets ossified, I think we still have ways to = handle that. However, the question is, do we want to burn the bits and = complexity now, or later when we might (or might not) figure out that it = is needed? Mirja From nobody Wed Apr 4 11:38:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40CD1243F6 for ; Wed, 4 Apr 2018 11:38:50 -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 (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qc0Ke9PK4YuX for ; Wed, 4 Apr 2018 11:38:48 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0114.outbound.protection.outlook.com [104.47.33.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6383F12D7E2 for ; Wed, 4 Apr 2018 11:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Xsvan8QKseYbALf/0Db0MfsRS+fJhRS0i3CD0EuMrAA=; b=P/vRwYeBvUO3xtFKy9XgjHt5lOoKW6/eHO4zYH71Aj/hSRZh+M0YJB3ahsY4JZSfrBwIfdhOn47A9VvxXOLa2bk4fY4U0PWupcqK64Gq4qUHk1IsczT3M4ZAe0uAKC3XBVPcWovH/0Ma3jPAsETwOffK9lrVkkYqR11dlraM02g= Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1902.namprd08.prod.outlook.com (10.169.39.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.631.10; Wed, 4 Apr 2018 18:38:18 +0000 Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0631.013; Wed, 4 Apr 2018 18:38:18 +0000 From: Mike Bishop To: Mark Nottingham , IETF QUIC WG CC: Lars Eggert Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GX7TDeC7pGjkeFqjSFMKBzEaPw3fmw Date: Wed, 4 Apr 2018 18:38:18 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> In-Reply-To: <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:5a28:a406:22db:ce8f:90d0] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR08MB1902; 7:pCTBAqaFXGB3MMATMkzGM9v0RP29PUgvd8K0KcG/SS+25sMzF2JDCNREt3JhN/jxC9YoHcm9gTCZlrQ/X7Tdxw8U2I29LGt2ekDDWbs9sLFEq5MdYUFwOx1BCpGuxjRpqvC9crIlHdKG/3VGAGmJIOBWsinWzqEVg8d+Rr5Nek9ZeNSKuiDXT6v2RjGXU0c9HoAUjAXoXBOmOxFdEobWf0IMPPpu9YANIBsi+k36Y/geEt4fQQup+cwCZkLqxU1f x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 114c5cbb-77d1-4b00-1bd7-08d59a5b3c3e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1902; x-ms-traffictypediagnostic: SN1PR08MB1902: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(192374486261705)(85827821059158)(100405760836317)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231221)(944501327)(52105095)(6041310)(20161123560045)(20161123564045)(20161123558120)(2016111802025)(20161123562045)(6043046)(6072148)(201708071742011); SRVR:SN1PR08MB1902; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1902; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(39380400002)(39830400003)(396003)(53754006)(199004)(189003)(51914003)(13464003)(7736002)(6116002)(3660700001)(3280700002)(186003)(74482002)(478600001)(305945005)(14454004)(105586002)(229853002)(68736007)(4326008)(316002)(25786009)(74316002)(33656002)(110136005)(2906002)(966005)(99286004)(2900100001)(561944003)(106356001)(55016002)(53936002)(76176011)(7696005)(6506007)(6436002)(53546011)(5660300001)(59450400001)(6246003)(102836004)(9686003)(93886005)(476003)(11346002)(6306002)(46003)(81166006)(446003)(486006)(8936002)(86362001)(97736004)(8676002)(5250100002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1902; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: Up/9USCIift2De3fF5I2dKaXA7pxkMjVMUzd3PYrXwskUNy/0YuODk7i1ZtX4kLGfemRifR2qZNtZ0fCsG6Qyz2adVyxDQHPbtgFdBwlDC7thyLdsj4Wudm+oeby10InGe+drH86TGq9v2vplYGtHEu8l3c9RmHyo8fgmEyeJ4VRY5WXu0+UtIYjKYVwUUuFClo52W26gzg7DZPBjqmxKR09QyKimEcfMryc84AHV406ygVBIPjJhaexlG7WL37yk8ZXtPM3nloYx2DjlCuFcUcsfd0bBZDIQhTarwqMqp89O50H3zx0Y09Ade3XL965bkkP/ruWxzOx84PXN5vX+3yrHZhjrpi8hXoVcxBl1yiYP6w86br9Gbvq6pJNM5NTABZiSLGDTRZMbNNsotvGn/94S44fHk1kNTVqwsseGF8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 114c5cbb-77d1-4b00-1bd7-08d59a5b3c3e X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 18:38:18.3072 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1902 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 18:38:51 -0000 At this point, I think we have multiple paths forward, pun intended. (1) - Packet number encryption. #1079's challenges have been amply discuss= ed, though it's not the only possibility in this space. (2) - Per-CID offset for obfuscation. Rather than specifying a packet numb= er gap, specify a number that will be added to the actual packet number for= any frames sent with that CID. This allows the path to observe, per CID, = monotonically-increasing packet numbers without necessarily being able to r= ecover the true packet number. (3) - Status quo. Problems I'm wrestling with: - Specification holes. With my editor's hat only half-on (since I'm not an= editor on this particular document), I'll note that there are a number of = thorny issues with (3) in the current drafts that just go away if packet nu= mbers are encrypted. The current obfuscation method, packet number gaps, s= imply does not play well with the connection migration design we chose. Ga= ps assume a continuous monotonic progression through CIDs which are never u= sed again once you've ever seen a packet with the next CID, and don't accom= modate the possibility that you might be using different CIDs on different = paths at the same time for probing. This is the driving issue at the momen= t -- if the WG chooses (3), we then need to run these other issues to groun= d, which will not be quick. - Linkability. With (2), if an observer sees the beginning of the connecti= on, they can figure out the offset for that CID, then track the packet numb= er as long as that CID is in use, then make a fairly accurate guess about t= he offset of the next CID they see, if they're able to otherwise correlate = them. There is some correlation that can be made by the fact that one CID = disappears and another one appears on (potentially) the same 4-tuple, of co= urse. (1) might let an implementation mask that by using more than one CID= at once to blur the boundaries a little bit, but (2) would make that attem= pt obvious because the middlebox would be able to observe gaps that neatly = fit the other CID's observed packet counts. - "Helpfulness." With TCP, we see boxes that try to "help" by correcting p= ackets which appear to be out of order. The principle we've followed so fa= r is that we want to leave all transport-related activities in the end host= s, and we actively don't want "helpful" middle devices, because when such a= device sees a gap (because some packet was sent on a different path) it in= terprets it either as loss or as something that needs to trigger corrective= action on its part. This only gets worse when we move from migration supp= ort to full multipath. That's what forced MP-TCP into a per-path sequence = number in addition to a global sequence number. I think we'd prefer to avo= id having both in QUIC. (2) exposes the same increasing sequence to middle= boxes, inviting them to attempt helpfulness in the same way, and likely cre= ating the same problems that MP-TCP encountered. - Cost. (1) fundamentally consumes more CPU, and that's a drawback. There= have been workarounds proposed to the offload problem (e.g. pre-compute an= d throw away some of the encryption so that the hardware doesn't have to do= two passes), but it fundamentally costs more CPU and is harder to offload.= This in turn means more CapEx for those who would deploy QUIC on the serv= er side, with the risk of slower adoption as a result. When you get right down to it, I'm sympathetic to the cost argument, but it= doesn't outweigh the other two. A given server can (I presume) sustain dr= amatically more Telnet connections than it can SSH connections, but people = who advocate continuing to use Telnet for that reason are roundly ridiculed= . SSH has a different, better security profile and those differences justi= fy the cost. TCP versus QUIC seems similar. As a result, I believe that the reasonable path forward must be (1). Not n= ecessarily in the form of #1079 -- if there's a more offload-friendly or CP= U-efficient way to do it, I'm all for it. But let's start there and move f= orward. If a path signal becomes necessary, that's a separate discussion. -----Original Message----- From: QUIC On Behalf Of Mark Nottingham Sent: Tuesday, April 3, 2018 9:58 PM To: IETF QUIC WG Cc: Lars Eggert Subject: Getting to consensus on packet number encryption Hi everyone, The editors have told your chairs that this issue is starting to block prog= ress on other aspects of QUIC. Coming to consensus on it soon (i.e., before= Stockholm, if possible) would be good. It looks like this thread has come to a natural pause. Reading through it, = I think we agree there are some unpleasant tradeoffs here, but so far we ha= ve only one concrete proposal -- PR#1079. My AU$.05 - While we're chartered to produce a protocol that's encrypted as= much as operational concerns allow, and that privacy is a natural extensio= n of that (especially in light of RFC7258 and RFC6973), there is no *requir= ement* that we produce a protocol that is able to be accelerated by hardwar= e. That being the case, I think we need to ask ourselves if we believe that in= clusion of PR#1079 will significantly inhibit deployment of the protocol. B= ased on the discussion so far, that doesn't seem to be the case, but I'd be= interested to hear what others think. If we can get to consensus to incorporate the PR, and folks come back later= with a more hardware-friendly replacement that doesn't change the Invarian= ts or increase linkability, I suspect the WG will be amenable to that. What do folks think? Cheers, > On 29 Mar 2018, at 11:39 am, Ian Swett wrote: >=20 > Thanks for the nice summary Jana. >=20 > As much as I'd love to have easier crypto HW acceleration, I've ended up = arriving at the same conclusion. I don't want to bite off the work to do p= roper multipath in QUIC v1, which I think is the only other reasonable opti= on of those Christian outlined. >=20 > If someone comes up with a way to transform packet number to make it non-= linkable, but doesn't have the downside of making hardware offload difficul= t, then I'm open to it. But we've been talking about this for 2 months wit= hout any notable improvements over Martin's PR. >=20 > Given we never talk about any issue only once in QUIC, I'm sure this will= come up again, but for the time being I think #1079 is the best option we = have. >=20 >=20 >=20 > On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar wrote: > A few quick thoughts as I catch up on this thread. >=20 > I spent some time last week working through a design using multiple PN sp= aces, and it is quite doable. I suspect we'll head towards multiple PN spac= es as we consider multipath in the future. That said, there is complexity (= as Christian notes). This complexity may be warranted when doing multipath = in v2 or later, but I'm not convinced that this is necessary as a design pr= imitive for QUICv1.=20 >=20 > We may want to creatively use the PN bits in v2, say to encode a path ID = and a PN, for multipath. We want to retain flexibility in these bits going = into v2. We've used encryption to ensure that we don't lose flexibility els= ewhere in the header, and it follows that we should use PNE to retain flexi= bility in these bits as well. (Simplicity of design is the other value in u= sing PNE, since handling migration linkability is non-trivial without it.) >=20 > This leaves the question of HW acceleration being at loggerheads with the= design in PR #1079. First, I expect that the primary benefit of accelerati= on will be in DC environments. Yes, there are some gains to be had in servi= ng the public Internet as well, but I'm unconvinced that this is the drivin= g use case for hardware acceleration. I understand that others may disagree= with me here. >=20 > AFAIK, QUIC has not been used in DC environments yet. I expect there are = other things in the protocol that we'd want to change as we gain experience= deploying QUIC in DCs. Spinning up a new version to try QUIC within DCs is= not only appropriate, I would recommend it. This allows for rapid iteratio= ns internally, and the experience can drive subsequent changes to QUIC. It'= s what *I* would do if I was to deploy QUIC inside a DC. >=20 > So, in short, I think we should go ahead with PR# 1079. This ensures that= future versions are guaranteed the flexibility to change the PN bits for b= etter support of HW acceleration or multipath or what-have-you. >=20 > - jana >=20 > On Mar 26, 2018 9:41 AM, "Christian Huitema" wrote: >=20 > On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote: >> Looking at https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_A= MD_x86_architecture it seems to imply a large range of server, desktop and = mobile chips all have a CPU instruction set available to do AES acceleratio= n and other similar operations (other instruction sets are also available). >>=20 >> If we are considering the AES instructions then it looks like it is (or = at least will be in the near future) a sizeable proportion of the public in= ternet have it to be used. >>=20 >=20 > Certainly, but that's not the current debate. PR #1079 is fully compatibl= e with use of the AES instructions. The issue of the debate is that the mec= hanism in PR #1079 required double buffering, first encrypt the payload, th= en use the result of the encryption to encrypt the PN. This is not an issue= in a software implementation that can readily access all bytes of the pack= et from memory, but it may be an issue in some hardware implementations tha= t are designed to do just one pass over the data. >=20 >=20 > -- Christian Huitema >=20 >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Apr 4 11:39:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC42C12DA49 for ; Wed, 4 Apr 2018 11:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522867184; bh=khgfVSEJRM8pIHAfbETpjTGTb1J8T7lJ2j2MquPDM9I=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To; b=wvh8vwIJK4OiAxabyG8VKxIvMg+JPpNsGTRfMmhfvPmp5BOVB4JF1+XHzZCNs2nba Y3+xi8ZtO2vNRvo/PzIH+lS0R1qcjlbw246Lzt4yCBYFWhogkby60Y/gznh9n32foo rnrY06MSy31StMDDhXzzxdQbH1JAgUi5p2SRBnpk= X-Mailbox-Line: From pravb@microsoft.com Wed Apr 4 11:39:44 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8175512D7F2; Wed, 4 Apr 2018 11:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522867184; bh=khgfVSEJRM8pIHAfbETpjTGTb1J8T7lJ2j2MquPDM9I=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To; b=wvh8vwIJK4OiAxabyG8VKxIvMg+JPpNsGTRfMmhfvPmp5BOVB4JF1+XHzZCNs2nba Y3+xi8ZtO2vNRvo/PzIH+lS0R1qcjlbw246Lzt4yCBYFWhogkby60Y/gznh9n32foo rnrY06MSy31StMDDhXzzxdQbH1JAgUi5p2SRBnpk= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C9612D7F8 for ; Wed, 4 Apr 2018 11:39:44 -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 (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 XfZCy-eSNptg for ; Wed, 4 Apr 2018 11:39:41 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on071c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe41::71c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B4C12D7F2 for ; Wed, 4 Apr 2018 11:39:39 -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=khgfVSEJRM8pIHAfbETpjTGTb1J8T7lJ2j2MquPDM9I=; b=mUurlC1eRs3SonTLzAgIlcyQQttKyGueW82VLrObLyoOnu5J8bdEsmfZ2NolX2/n5jysqpz4Wf9qkez25EeUdnzHku/0oDsXtTKjOoTIu7X4JZpU4bGNe3xrYVupESx1xfBYzymCYQ0oi6mpAdXB8G73UBmTLI70sEhK6/lXja4= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0775.namprd21.prod.outlook.com (10.173.192.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.2; Wed, 4 Apr 2018 18:39:36 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 18:39:36 +0000 From: Praveen Balasubramanian CC: Subodh Iyengar , Ian Swett , Phillip Hallam-Baker , IETF QUIC WG Subject: RE: UDP send costs in Linux Thread-Topic: UDP send costs in Linux Thread-Index: AQHTy6q+3JsicRIxhkabCq/gojpid6Pv6A6AgACtVICAACezAIAAD5iAgAAXAKCAAAmAAIAAAeWAgAABOKA= Date: Wed, 4 Apr 2018 18:39:36 +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:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0775; 7:b9N1+wxcssvoo8jvI9hE/ziY1xsQE5XfT6oQoXJC3XwA7ndrndn+pgdqmyVDSP34wfSByAnWwRUu587QxDb/pMYdPsRPDiBrB0kd33NJeD8pVv5pyfWswXYBCtKi2Ks9oG3/HGV4fdD3u56GnnBPhMeq7/tQ16Reo7s80hyiWX76yziBNuh0zX7qnI+3dxAUeN8DXkSESBQacqzXQfl2QsEoS9Sn2T0uZTArAqbcSFL+9wD8EpuRoqXMgzxDACdG; 20:OWYZPB2t9v6REO+cPojVv36KUlA4WD8986qdtFmsmYhCA5EInIglg6kQ16hgFv2PcOT5c1usfp1dcNr8zbu3qHULOmX9Q412aFofRgoMQUqbxP6LpgpIQruvBFXu1w91CB55ney1hVx4vi7Y1ItA/1M7AV6v4xvw/YiVKtyf11Y= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ad50b01f-7c4d-4896-bb5b-08d59a5b6a9d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0775; x-ms-traffictypediagnostic: CY4PR21MB0775: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(9452136761055)(189930954265078)(85827821059158)(67672495146484)(211936372134217)(153496737603132)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0775; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0775; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(346002)(376002)(396003)(366004)(45534002)(199004)(189003)(6246003)(33656002)(46003)(478600001)(53546011)(229853002)(59450400001)(476003)(6506007)(7736002)(102836004)(10090500001)(5250100002)(68736007)(8990500004)(97736004)(446003)(4326008)(11346002)(74316002)(25786009)(105586002)(5660300001)(7696005)(76176011)(81166006)(3660700001)(14454004)(19609705001)(2900100001)(316002)(2906002)(86612001)(54906003)(93886005)(86362001)(10290500003)(81156014)(22452003)(8676002)(110136005)(606006)(3280700002)(9686003)(99286004)(106356001)(186003)(55016002)(8936002)(6116002)(53936002)(6306002)(236005)(54896002)(2171002)(6436002)(790700001)(486006)(39060400002)(966005)(733005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0775; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: J2w1aE/VN1B7y+HmihCEF/TkkQichqJTfZoyos+HGQ8/6PliLltMI+Ei/OmuIiap1ozNym1k261REV3emS50gGcoBnvsoGawoixPV5uzgg9y3CbbC2LuNjb/cLCpov+BkGg3cPwTQBeMxqjruCIBQaMQ5kWhn7dOr8YTK7WO+rR+tk8t054V4WJNU+JjCHWrSPaqxCUWHOhYxCniMr7i/Qz8tmXoLB51GwzhU+kE7j/y5SFfdXo2rWWm0h4QEBfZZjZn4aCHZ4SZXebISCUriNx/9nvetfCHWZRrzmjKydA2KUbpAxnWddV5yKqwrbPbdWnovur3yIMib9upphAWX1XTUuAuv9rxJ/YjpLTEEZeMnwQ9yhpdqePt2ylDZGXWm3d/BEkQEWZyWbTvb00Pw8shJKtl/rCUxGc/COJRqqY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630F5F8DD480E168A8F97CDB6A40CY4PR21MB0630namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ad50b01f-7c4d-4896-bb5b-08d59a5b6a9d X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 18:39:36.2835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0775 To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= To: Frederick Kautz To: Praveen Balasubramanian Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 18:39:45 -0000 --_000_CY4PR21MB0630F5F8DD480E168A8F97CDB6A40CY4PR21MB0630namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGFyZHdhcmUgc3VwcG9ydCBpcyBub3Qgb3J0aG9nb25hbCB0byBEUERLIGFuZCBrZXJuZWwgYnlw YXNzIGV2ZW4gdXNlciBtb2RlIGNhbiB0YWtlIGFkdmFudGFnZSBvZiBpdC4gRFBESyBoYXMgYSBs b3Qgb2Ygb3RoZXIgaXNzdWVzIGluY2x1ZGluZyBubyBiYXR0bGUgaGFyZGVuZWQgVENQSVAgc3Rh Y2tzLiBJTU8gd2UgbmVlZCB0byBtYWtlIHByb2dyZXNzIG9uIGJldHRlciBwZXJmb3JtYW5jZSBy ZWdhcmRsZXNzIG9mIHVzZXIgb3Iga2VybmVsIGltcGxlbWVudGF0aW9ucy4gRXNwZWNpYWxseSBm b3IgY2xpZW50IGRldmljZXMgdXNlciBzcGFjZSBpbXBsZW1lbnRhdGlvbnMgY2Fubm90IGJlIGdp dmVuIGRpcmVjdCBoYXJkd2FyZSBhY2Nlc3MgZm9yIHNlY3VyaXR5IHJlYXNvbnMuIEZvciBjbG91 ZCBWTXMgdGhlcmUgaXMgU1ItSU9WIGZvciBkaXJlY3QgaGFyZHdhcmUgYWNjZXNzIHdoaWNoIGlz IG5vdyBzdXBwb3J0ZWQgYnkgbW9yZSBhbmQgbW9yZSBjbG91ZCBwcm92aWRlcnMuDQoNCkZyb206 IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtrZWwg RmFobsO4ZSBKw7hyZ2Vuc2VuDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTggMTE6MzIg QU0NClRvOiBGcmVkZXJpY2sgS2F1dHogPGZrYXV0ekBhbHVtbmkuY211LmVkdT47IFByYXZlZW4g QmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+DQpD YzogU3Vib2RoIEl5ZW5nYXIgPHN1Ym9kaEBmYi5jb20+OyBJYW4gU3dldHQgPGlhbnN3ZXR0QGdv b2dsZS5jb20+OyBQaGlsbGlwIEhhbGxhbS1CYWtlciA8cGhpbGxAaGFsbGFtYmFrZXIuY29tPjsg SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFVEUCBzZW5kIGNvc3Rz IGluIExpbnV4DQoNCkdvdCBpdCBiZWZvcmUsIGJ1dCB0aGUgcmVhc29uIHdoeSBuZXRtYXAgYW5k IERQREsgaXMgaW1wb3J0YW50IGluIGNvbnRyYXN0IHRvIGtlcm5lbCBzdXBwb3J0IGlzIHRoZSB2 ZXJ5IHJpY2ggYXBwbGljYXRpb24gaW50ZXJmYWNlcyB0aGF0IGEgY3VzdG9tIHVzZXIgc3BhY2Ug UVVJQyBpbXBsZW1lbnRhdGlvbiBwcm92aWRlcy4gU3BlbmRpbmcgdGhlIG5leHQgMTAgeWVhcnMg ZGlzY3Vzc2luZyBlcG9sbCB2cyBwb2xsIGZvciBRVUlDIGlzIG5vdCBnb2luZyB0byBjdXQgaXQu DQoNCk9TIHN1cHBvcnQgdGhhdCBtYWtlcyBpdCBlYXNpZXIgdG8gdXNlIG5ldG1hcCBhbmQgZnJp ZW5kcyBjb25jdXJyZW50bHkgd2l0aCBvdGhlciBuZXR3b3JrIHRyYWZmaWMgd291bGQgYmUgd2Vs Y29tZSB0aG91Z2guDQpRdWVzdGlvbiBpcyB3aGF0IGhhcmR3YXJlIG9mZmxvYWQgc3VwcG9ydCBj YW4gYmUgZ2l2ZW4gdG8gYSBjdXN0b20gUVVJQyBpbXBsZW1lbnRhdGlvbiwgYnV0IG9uZSB0aGlu ZyB0aGF0IGNvbWVzIHRvIG1pbmQgaXMgcHJlLWRlY3J5cHRpb24gb24gbmV0bWFwIHdoZXJlIHRo ZSBPUyBmaXJzdCBpbnRlcmNlcHRzIHRoZSBwYWNrZXQgYW5kIGZvcndhcmRzIHRoZSBkZWNyeXB0 ZWQgYW5kIERvUyBmaWx0ZXJlZCBwYWNrZXQgdG8gdGhlIGFwcCB3aGljaCB0aGVuIGhhbmRsZXMg YWxsIHRoZSBkZXRhaWxlZCBmcmFtaW5nLCBBQ0ssIHBhY2luZyBldGMuDQoNCktpbmQgUmVnYXJk cywNCk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCg0KDQpPbiA0IEFwcmlsIDIwMTggYXQgMjAu MjUuMDcsIEZyZWRlcmljayBLYXV0eiAoZmthdXR6QGFsdW1uaS5jbXUuZWR1PG1haWx0bzpma2F1 dHpAYWx1bW5pLmNtdS5lZHU+KSB3cm90ZToNCkkgYXBvbG9naXplIHRvIGFueW9uZSBoZXJlIHdo byBnZXRzIGEgcmVwZWF0IG9mIHRoaXMgbWVzc2FnZSwgdGhlIG1haWxpbmcgbGlzdCBhdGUgbXkg ZWFybGllciByZXBseSBiZWNhdXNlIG15IG1haWwgcHJvdmlkZXIgY2hhbmdlZCBteSBkZWZhdWx0 IGVtYWlsIGFkZHJlc3MgZHVyaW5nIGEgdHJhbnNpdGlvbi4gSGVyZSBpcyB0aGUgb3JpZ2luYWwg bWVzc2FnZToNCg0KSSBhZ3JlZSB3aXRoIHRoaXMgc2VudGltZW50LiBJZiB3ZSBzZWUgdHJhY3Rp b24sIHRoZW4gd2Ugc2hvdWxkIHNlZSBiZXR0ZXIga2VybmVsIHN1cHBvcnQgYW5kIG9mZmxvYWRp bmcuDQoNCkl0IHNob3VsZCBiZSB0cml2aWFsIHRvIGdldCB0aGlzIHdvcmtpbmcgaW4gc29tZXRo aW5nIGxpa2UgVlBQIHdoaWNoIGNhbiB1c2UgRFBESyB0byBodyBvZmZsb2FkLCBlbnRpcmVseSBz a2lwcGluZyB0aGUga2VybmVsIGluIHRoZSBkYXRhIHBhdGguDQoNClRoZXJlIGFyZSBhbHNvIHRl Y2huaXF1ZXMgdG8gYnlwYXNzIHRoZSBpbml0aWFsIG1lbW9yeSBhbGxvY2F0aW9uIGluIHRoZSBr ZXJuZWwgc3VjaCBhcyBlYnBmIHVzZWQgYnkgY2lsaXVtIGFuZCBtZW1pZiB1c2VkIGJ5IHZwcC4N Cg0KTXkgbWFpbiBjb25jZXJuIGF0IHRoaXMgcG9pbnQgd291bGQgYmUgd2l0aCBjbG91ZCBuYXRp dmUgZW52aXJvbm1lbnRzIHdpdGggbGltaXRlZCBodyBvZmZsb2FkaW5nIHN1cHBvcnQuIEUuZy4g aWYgd2UgcnVuIGluIEFXUyBvciBHQ0UsIGJldHRlciBrZXJuZWwgc3VwcG9ydCB3aWxsIHByb2Jh Ymx5IGJlIG5lY2Vzc2FyeS4NCltodHRwczovL3NzbC5nc3RhdGljLmNvbS91aS92MS9pY29ucy9t YWlsL2ltYWdlcy9jbGVhcmRvdC5naWZdDQoNCg0KT24gV2VkLCBBcHIgNCwgMjAxOCBhdCAxMDo1 NyBBTSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFy Yy5pZXRmLm9yZzxtYWlsdG86cHJhdmI9NDBtaWNyb3NvZnQuLmNvbUBkbWFyYy5pZXRmLm9yZz4+ IHdyb3RlOg0KVGhlIG5lZWQgdG8gd29ycnkgaXMgbm90IG9uIHRoZSBjbGllbnQgc2lkZSDigJMg YXQgbGVhc3Qgbm90IGltbWVkaWF0ZWx5LiA4MDIuMTFhZCwgODAyLjExYXgsIGFuZCA1RyBMVEUg d2lsbCBicmluZyBHaWdhYml0IHJhdGVzIHRvIGNsaWVudCBzaWRlIHNvIGl0IGlzIGNlcnRhaW5s eSBnb2luZyB0byBiZWNvbWUgYSBwcm9ibGVtIGxvbmdlciB0ZXJtLg0KDQpUaGUgY3VycmVudCB3 b3JyeSBpcyBvbiB0aGUgc2VydmVyIHNpZGUuIEEgbGFyZ2UgcGFydCBvZiB0aGUgd29yayB3ZSBk byBpcyBwZXJmb3JtYW5jZSBvcHRpbWl6YXRpb24gb2YgdGhlIG5ldHdvcmsgc3RhY2suIEdvb2ds ZeKAmXMgU2lnY29tbSBRVUlDIHBhcGVyIHNob3dzIGEgMnggQ1BVIGluY3JlYXNlIGdvaW5nIGZy b20gVENQIHRvIFFVSUMuIE1vc3Qgd2ViIHNlcnZpY2VzIHdpbGwgTk9UIGJlIGFibGUgdG8gbWFr ZSB0aGF0IHRyYWRlIG9mZiB0byBnZXQgbGF0ZW5jeSBpbXByb3ZlbWVudHMgZm9yIDkwdGggcGVy Y2VudGlsZS4NCg0KSU1PIGltcHJvdmluZyBVRFAgcGVyZm9ybWFuY2UgYW5kIGhhcmR3YXJlIG9m ZmxvYWRzIGFyZSBhYnNvbHV0ZWx5IGEgbmVjZXNzaXR5IGZvciBRVUlDIHRvIGJlY29tZSB3aWRl bHkgYWRvcHRlZCAobm90IGp1c3QgYnkgdGhlIGJpZ2dlc3QgY29ycG9yYXRpb25zIHdpdGggYSBs YXJnZSBidWRnZXQpLiBXZSBoYXZlIHdvcmsgdW5kZXIgd2F5IG9uIGJvdGggdGhlc2UgZnJvbnRz IGFuZCBJIGFtIHZlcnkgaGFwcHkgdG8gc2VlIExpbnV4IGFsc28gaW52ZXN0aW5nIGhlcmUgaW4g cHJlcGFyYXRpb24gZm9yIHdoYXTigJlzIGNvbWluZy4gV2UgbmVlZCB0byBkbyBvdXIgYmVzdCBk ZW1vY3JhdGl6ZSB0aGlzIHRlY2hub2xvZ3kgLSBtdWx0aXBsZSBpbXBsZW1lbnRhdGlvbnMgYW5k IHBlcmZvcm1hbmNlIHdpbGwgYm90aCBwbGF5IGEgYmlnIHJvbGUuDQoNCg0KRnJvbTogUVVJQyBb bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn Pl0gT24gQmVoYWxmIE9mIFBoaWxsaXAgSGFsbGFtLUJha2VyDQpTZW50OiBXZWRuZXNkYXksIEFw cmlsIDQsIDIwMTggOToyOSBBTQ0KVG86IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tl bGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPj4NCkNjOiBTdWJvZGggSXll bmdhciA8c3Vib2RoQGZiLmNvbTxtYWlsdG86c3Vib2RoQGZiLmNvbT4+OyBJRVRGIFFVSUMgV0cg PHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PjsgSWFuIFN3ZXR0IDxpYW5zd2V0 dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5p ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogVURQIHNlbmQgY29zdHMgaW4gTGludXgNCg0KSSB3b3Vs ZCBub3Qgd29ycnkgdG9vIG11Y2ggYXQgdGhpcyBwb2ludC4NCg0KVGhlIHJlYXNvbiB3ZSB3YW50 IHRvIGJlIGFibGUgdG8gd29yayBhdCB0aGUgYXBwbGljYXRpb24gbGV2ZWwgaXMgYmFja3dhcmRz IGNvbXBhdGliaWxpdHkuIEl0IGhhcyB0byBiZSBwb3NzaWJsZSB0byBkZXBsb3kgUVVJQyBvbiBh bnkgbWFjaGluZSBldmVuIHdpdGhvdXQgT1Mgc3VwcG9ydCBvciBpdCB3b24ndCBiZSBkZXBsb3lh YmxlLg0KDQpJdCBkb2VzIG5vdCBoYXZlIHRvIGJlIHBlcmZvcm1hbnQgb24gZXZlcnkgcGxhdGZv cm0uIElmIHBlb3BsZSBhcmUgdXNpbmcgUVVJQywgd2hhdGV2ZXIgbmVlZHMgdG8gYmUgbW92ZWQg aW50byB0aGUga2VybmVsIGZvciBwZXJmb3JtYW5jZSByZWFzb25zIHdpbGwgbW92ZSB0aGVyZS4N Cg0KDQoNCg0KT24gV2VkLCBBcHIgNCwgMjAxOCBhdCAxMTozMiBBTSwgTWlra2VsIEZhaG7DuGUg SsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+ PiB3cm90ZToNCkkgaGF2ZSBubyBkYXRhIHRvIGFkZCBvbiB0aGUgTGludXggVURQIHN0YWNrLCBi dXQgYW5vdGhlciBpc3N1ZSBpcyB0aGUgbGFjayBvZiBuZXRtYXAgc3VwcG9ydCBpbiBjbG91ZCBo b3N0aW5nIGVudmlyb25tZW50cy4NCkkgaGF2ZSBub3QgeWV0IGJlZW4gd29ya2luZyB3aXRoIHRo aXMsIGJ1dCBoYXZlIGxvb2tlZCBpbnRvIHRoZSBwcm9ibGVtIGFuZCBhc2tlZCBhcm91bmQuDQoN Cm5ldG1hcCBpcyBkZWZhdWx0IGluIEZyZWVCU0QgYW5kIG9wdGlvbmFsIGluIExpbnV4LiBCdXQg bmVpdGhlciB3b3JrcyBlZmZpY2llbnRseSB3aXRob3V0IGEgaHlwZXJ2aXNvciBwYXRjaCB0aGF0 IGlzIGFsc28gYXZhaWxhYmxlIGZvciBuZXRtYXAuIFdpdGggc3VwcG9ydCBmb3IgbmV0bWFwLCB0 aGUgdXNlciBzcGFjZSBhcHBsaWNhdGlvbiBjYW4gc2VuZCBkaXJlY3RseSB0byB0aGUgbmV0d29y ayBhZGFwdGVyIHdpdGggdmVyeSBsaXR0bGUgb3ZlcmhlYWQuIFRoZXJlIGlzIGFsc28gZHBkayBh bmQgc29tZSBvdGhlciBpbnRlcmZhY2VzIHRoYXQgbWlnaHQgYmUgc2xpZ2h0bHkgZmFzdGVyIGJ1 dCBtb3JlIHZlbmRvciBzcGVjaWZpYy4NCg0KQXNzdW1pbmcgYW4gYXBwbGljYXRpb24gaGFzIGFj Y2VzcyB0byBvcHRpbWl6ZWQgbmV0bWFwLCB0aGUgb25seSBodXJkbGUgaXMgYWRkcmVzcyBsb29r dXAsIGJ1dCBpZiB0aGUgYXBwbGljYXRpb24gYWxzbyBtYW5hZ2VzIHRoYXQsIG9yIGF0IGxlYXN0 IGRvZXMgdGhlIGNhY2hpbmcsIHRoZXJlIHNob3VsZG7igJl0IGJlIG11Y2ggaW4gdGhlIHdheSBv ZiBPUyBpbnRlcmZlcmVuY2UuDQoNCk9mIGNvdXJzZSwgbmV0bWFwIGJsb2NrcyB0aGUgZW50aXJl IG5ldHdvcmsgc3RhY2ssIHNvIG5vIFBJTkcgb3IgU1NILiBDbG91ZEZsYXJlIGFkZGVkIGEgbmV0 bWFwIHBhdGNoIHNvIG9ubHkgc29tZSB0cmFmZmljIHdvdWxkIGJlIHJvdXRlZCBmcmEgdGhlIG5l dHdvcmsgaW50ZXJmYWNlIHRvIG5ldG1hcCwgYW5kIG5ldG1hcCBhbHNvIHN1cHBvcnRzIGVmZmlj aWVudCBwYWNrZXQgZm9yd2FyZGluZyB0byB0aGUgT1Mgb3Igb3RoZXIgYXBwbGljYXRpb25zLg0K DQpOb25lIG9mIHRoaXMgd29ya3Mgd2VsbCBpbiBnZW5lcmFsLCBidXQgZm9yIGEgY2xvdWQgaG9z dCB0aGF0IGNhbiBiZSBib290ZXQgYXV0b21hdGljYWxseSBhbmQgZGVzdHJveWVkIHJhdGhlciB0 aGFuIHNlcnZpY2VkLCB0aGVyZSBpcyBzb21lIG9wcG9ydHVuaXR5Lg0KDQpidXQgb25seSBpZiBj bG91ZCBzZXJ2aWNlIHByb3ZpZGVycyBzdGFydHMgYWRkaW5nIHN1cHBvcnQgdGhlaXIgc3VwcG9y dGVkIGltYWdlcyBhbmQgaHlwZXJ2aXNvcnMuIE5vdCBzdXJlIGlmIGFueSBhcmUgd29ya2luZyBv biB0aGlzIG5vdy4NCg0KDQpNaWtrZWwNCg0KDQoNCk9uIDQgQXByaWwgMjAxOCBhdCAxNS4xMS4x NywgSWFuIFN3ZXR0IChpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi4ub3JnPG1haWx0 bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+KSB3cm90ZToNCkkgaG9wZSBz b21lIG9mIHRoZXNlIHBhdGNoZXMgd2lsbCBiZSBhdmFpbGFibGUgc29vbiwgYnV0IEknbSBub3Qg c3VyZSBpZiBzb29uIGlzIGEgbW9udGggb3IgNi4NCg0KT24gVHVlLCBBcHIgMywgMjAxOCBhdCAx MDo1MCBQTSBTdWJvZGggSXllbmdhciA8c3Vib2RoQGZiLmNvbTxtYWlsdG86c3Vib2RoQGZiLmNv bT4+IHdyb3RlOg0KDQpUaGFua3MgZm9yIHNoYXJpbmcgdGhpcyBJYW4uDQoNCg0KDQpUaGlzIGRl ZmluaXRlbHkgbWF0Y2hlcyBzb21lIG9mIHRoZSBvYnNlcnZhdGlvbnMgd2UndmUgc2VlbiBhcyB3 ZWxsIGluIHRoZSBVRFAgd3JpdGUgcGF0aC4gU29tZSBvZiB0aGUgb3RoZXIgcGF0aHMgdGhhdCB3 ZSBzYXcgdGhhdCBhZGRlZCBvdmVyaGVhZCB3YXMgdGhlIHJvdXRlIHRhYmxlIGxvb2t1cCBpbiBs aW51eCB1ZHAgc3RhY2suIENvbm5lY3RlZCBVRFAgc29ja2V0cyBkaWQgYW1vcnRpemUgdGhhdC4N Cg0KDQoNCkknbSBsb29raW5nIGZvcndhcmQgdG8gYSBzbWFydGVyIHNlbmRtbXNnIHdpdGggR1NP IGFuZCB6ZXJvIGNvcHkuIElzIHRoZXJlIGFueSBpbmRpY2F0aW9uIG9mIHRoZSB0aW1lbGluZSBm b3IgdGhlc2UgcGF0Y2hlcyB0byBtYWtlIGl0IHRvIGxpbnV4PyBXb3VsZCBiZSBoYXBweSB0byB0 cnkgYW55IG9mIHRoZXNlIG91dCB0byBoZWxwIGlyb24gb3V0IHRoZSBBUEkuDQoNCg0KDQpTdWJv ZGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFFVSUMgPHF1aWMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxm IG9mIElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYuLm9yZzxtYWls dG86aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYuLm9yZz4+DQpTZW50OiBUdWVzZGF5 LCBBcHJpbCAzLCAyMDE4IDU6MjA6MDggUE0NClRvOiBJRVRGIFFVSUMgV0cNClN1YmplY3Q6IFVE UCBzZW5kIGNvc3RzIGluIExpbnV4DQoNCk9uZSBjaGFsbGVuZ2Ugd2l0aCBRVUlDIGF0IHRoZSBt b21lbnQgaXMgdGhlIGluY3JlYXNlZCBDUFUgY29zdCBvZiBzZW5kaW5nIFVEUCBwYWNrZXRzIHZz IFRDUCBwYXlsb2Fkcy4gIEkndmUgc2VlbiB0aGlzIGFjcm9zcyBldmVyeSBwbGF0Zm9ybSBHb29n bGUgaGFzIGRlcGxveWVkIFFVSUMgb24sIHNvIGl0J3MgYSB3aWRlc3ByZWFkIGlzc3VlLg0KDQpI ZXJlJ3MgYW4gZXhjZWxsZW50IHByZXNlbnRhdGlvbiBvbiB3aGF0J3MgY2F1c2luZyB0aGUgaW5j cmVhc2VkIENQVSBjb25zdW1wdGlvbiBvbiBMaW51eCBmcm9tIFdpbGxlbSBkZSBCcnVpam4oVURQ IHN0YXJ0cyBvbiBzbGlkZSA5KS4NCmh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbmV0Y29uZjIwMTdf ZmlsZXMvcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBkZjxodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay4uY29tLz91cmw9aHR0cCUzQSUyRiUyRnZnZXIua2VybmVsLm9y ZyUyRm5ldGNvbmYyMDE3X2ZpbGVzJTJGcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBkZiZkYXRh PTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0MxMDNhNmU4MWYzNjg0YzY3MzgyNjA4 ZDU5YTQ5MmMyZSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzElN0M2 MzY1ODQ1NjE0NDk4NzI5MzUmc2RhdGE9RlBlMG1TNWFHJTJCODglMkZTWHZJVlNPM3lXblhoOXRP aFFmS2tINlhuUUR4dkUlM0QmcmVzZXJ2ZWQ9MD4NCg0KQW5kIHdoaWxlIHlvdSdyZSB0aGlua2lu ZyBvZiBDUFUgdXNhZ2UsIGl0J3Mgd29ydGggbG9va2luZyBhdCB0aGUgcHJlc2VudGF0aW9uIG9u IHRpbWluZyB3aGVlbCBiYXNlZCBwYWNrZXQgcGFjaW5nKHdoaWNoIGlzIG1pbmltdW0gcmVsZWFz ZSB0aW1lIGJhc2VkKSBhbmQgaXMgaWRlYWwgZm9yIFFVSUMoYW5kIFRDUCBmb3IgdGhhdCBtYXR0 ZXIpOiBodHRwczovL2NvbmZlcmVuY2VzLnNpZ2NvbW0ub3JnL3NpZ2NvbW0vMjAxNy9maWxlcy9w cm9ncmFtL3RzLTktNC1jYXJvdXNlbC4ucGRmPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX19jb25mZXJlbmNlcy5zaWdjb21tLm9yZ19z aWdjb21tXzIwMTdfZmlsZXNfcHJvZ3JhbV90cy0yRDktMkQ0LTJEY2Fyb3VzZWwucGRmJTI2ZCUz RER3TUZhUSUyNmMlM0Q1VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JTI2ciUzRGgzSnU5RUJTN21IdHdn LXdBeU43ZlElMjZtJTNEdGdnaGd2RmtwczdqWWFGTmROeVpCTkZmMGVwVnhGWmJPR2hoeWJGd1Bp RSUyNnMlM0Q4N2dPR2Z6M1MwbExidzhqeS1sejNNOXZQR0Noa21ndGlKVnpVeGJNZnZZJTI2ZSUz RCZkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0MxMDNhNmU4MWYzNjg0YzY3 MzgyNjA4ZDU5YTQ5MmMyZSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3 QzAlN0M2MzY1ODQ1NjE0NDk4NzI5MzUmc2RhdGE9aFNYWHZUT0R2bGpJNm5pQkxtTXhHVUZTOWcl MkZxT2lIc2tVY05jZ0h0RTZrJTNEJnJlc2VydmVkPTA+DQoNCi1JYW4NCg0KDQo= --_000_CY4PR21MB0630F5F8DD480E168A8F97CDB6A40CY4PR21MB0630namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1z dHlsZS1uYW1lOmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLm0xNDUyNzA4MjE2ODg2MzIzMzQxbTE2NTE3NDI4Nzk1MDU1NTU0OTFhaXJtYWlsb24s IGxpLm0xNDUyNzA4MjE2ODg2MzIzMzQxbTE2NTE3NDI4Nzk1MDU1NTU0OTFhaXJtYWlsb24sIGRp di5tMTQ1MjcwODIxNjg4NjMyMzM0MW0xNjUxNzQyODc5NTA1NTU1NDkxYWlybWFpbG9uDQoJe21z by1zdHlsZS1uYW1lOm1fMTQ1MjcwODIxNjg4NjMyMzM0MW0xNjUxNzQyODc5NTA1NTU1NDkxYWly bWFpbG9uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFy ZHdhcmUgc3VwcG9ydCBpcyBub3Qgb3J0aG9nb25hbCB0byBEUERLIGFuZCBrZXJuZWwgYnlwYXNz IGV2ZW4gdXNlciBtb2RlIGNhbiB0YWtlIGFkdmFudGFnZSBvZiBpdC4gRFBESyBoYXMgYSBsb3Qg b2Ygb3RoZXIgaXNzdWVzIGluY2x1ZGluZyBubyBiYXR0bGUgaGFyZGVuZWQgVENQSVAgc3RhY2tz LiBJTU8gd2UgbmVlZCB0byBtYWtlIHByb2dyZXNzIG9uIGJldHRlciBwZXJmb3JtYW5jZSByZWdh cmRsZXNzDQogb2YgdXNlciBvciBrZXJuZWwgaW1wbGVtZW50YXRpb25zLiBFc3BlY2lhbGx5IGZv ciBjbGllbnQgZGV2aWNlcyB1c2VyIHNwYWNlIGltcGxlbWVudGF0aW9ucyBjYW5ub3QgYmUgZ2l2 ZW4gZGlyZWN0IGhhcmR3YXJlIGFjY2VzcyBmb3Igc2VjdXJpdHkgcmVhc29ucy4gRm9yIGNsb3Vk IFZNcyB0aGVyZSBpcyBTUi1JT1YgZm9yIGRpcmVjdCBoYXJkd2FyZSBhY2Nlc3Mgd2hpY2ggaXMg bm93IHN1cHBvcnRlZCBieSBtb3JlIGFuZCBtb3JlIGNsb3VkDQogcHJvdmlkZXJzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBP Zg0KPC9iPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVz ZGF5LCBBcHJpbCA0LCAyMDE4IDExOjMyIEFNPGJyPg0KPGI+VG86PC9iPiBGcmVkZXJpY2sgS2F1 dHogJmx0O2ZrYXV0ekBhbHVtbmkuY211LmVkdSZndDs7IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFu ICZsdDtwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBTdWJvZGggSXllbmdhciAmbHQ7c3Vib2RoQGZiLmNvbSZndDs7IElhbiBTd2V0dCAmbHQ7 aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs7IFBoaWxsaXAgSGFsbGFtLUJha2VyICZsdDtwaGlsbEBo YWxsYW1iYWtlci5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBVRFAgc2VuZCBjb3N0cyBpbiBMaW51eDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+R290IGl0IGJlZm9yZSwgYnV0IHRoZSByZWFzb24gd2h5IG5l dG1hcCBhbmQgRFBESyBpcyBpbXBvcnRhbnQgaW4gY29udHJhc3QgdG8ga2VybmVsIHN1cHBvcnQg aXMgdGhlIHZlcnkgcmljaCBhcHBsaWNhdGlvbiBpbnRlcmZhY2VzIHRoYXQgYSBjdXN0b20gdXNl ciBzcGFjZSBRVUlDIGltcGxlbWVudGF0aW9uDQogcHJvdmlkZXMuIFNwZW5kaW5nIHRoZSBuZXh0 IDEwIHllYXJzIGRpc2N1c3NpbmcgZXBvbGwgdnMgcG9sbCBmb3IgUVVJQyBpcyBub3QgZ29pbmcg dG8gY3V0IGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3Bf Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21m b250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PUyBzdXBwb3J0 IHRoYXQgbWFrZXMgaXQgZWFzaWVyIHRvIHVzZSBuZXRtYXAgYW5kIGZyaWVuZHMgY29uY3VycmVu dGx5IHdpdGggb3RoZXIgbmV0d29yayB0cmFmZmljIHdvdWxkIGJlIHdlbGNvbWUgdGhvdWdoLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+UXVlc3Rpb24gaXMgd2hh dCBoYXJkd2FyZSBvZmZsb2FkIHN1cHBvcnQgY2FuIGJlIGdpdmVuIHRvIGEgY3VzdG9tIFFVSUMg aW1wbGVtZW50YXRpb24sIGJ1dCBvbmUgdGhpbmcgdGhhdCBjb21lcyB0byBtaW5kIGlzIHByZS1k ZWNyeXB0aW9uIG9uIG5ldG1hcCB3aGVyZSB0aGUgT1MgZmlyc3QgaW50ZXJjZXB0cw0KIHRoZSBw YWNrZXQgYW5kIGZvcndhcmRzIHRoZSBkZWNyeXB0ZWQgYW5kIERvUyBmaWx0ZXJlZCBwYWNrZXQg dG8gdGhlIGFwcCB3aGljaCB0aGVuIGhhbmRsZXMgYWxsIHRoZSBkZXRhaWxlZCBmcmFtaW5nLCBB Q0ssIHBhY2luZyBldGMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBpZD0iYmxvb3Bfc2lnbl8xNTIyODY2MzMyODA4MDA3OTM2Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+S2luZCBSZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk1pa2tlbCBGYWhuw7hl IErDuHJnZW5zZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJhaXJtYWlsb24iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiA0IEFwcmls IDIwMTggYXQgMjAuMjUuMDcsIEZyZWRlcmljayBLYXV0eiAoPGEgaHJlZj0ibWFpbHRvOmZrYXV0 ekBhbHVtbmkuY211LmVkdSI+ZmthdXR6QGFsdW1uaS5jbXUuZWR1PC9hPikgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBhcG9sb2dpemUgdG8gYW55b25lIGhlcmUgd2hvIGdl dHMgYSByZXBlYXQgb2YgdGhpcyBtZXNzYWdlLCB0aGUgbWFpbGluZyBsaXN0IGF0ZSBteSBlYXJs aWVyIHJlcGx5IGJlY2F1c2UgbXkgbWFpbCBwcm92aWRlciBjaGFuZ2VkIG15IGRlZmF1bHQgZW1h aWwgYWRkcmVzcyBkdXJpbmcgYSB0cmFuc2l0aW9uLg0KIEhlcmUgaXMgdGhlIG9yaWdpbmFsIG1l c3NhZ2U6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+SSBhZ3JlZSB3aXRoIHRoaXMgc2VudGlt ZW50LiBJZiB3ZSBzZWUgdHJhY3Rpb24sIHRoZW4gd2Ugc2hvdWxkIHNlZSBiZXR0ZXIga2VybmVs IHN1cHBvcnQgYW5kIG9mZmxvYWRpbmcuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMjIyMjIyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPkl0IHNob3VsZCBiZSB0cml2aWFsIHRvIGdldCB0 aGlzIHdvcmtpbmcgaW4gc29tZXRoaW5nIGxpa2UgVlBQIHdoaWNoIGNhbiB1c2UgRFBESyB0byBo dyBvZmZsb2FkLCBlbnRpcmVseSBza2lwcGluZyB0aGUga2VybmVsIGluIHRoZSBkYXRhDQogcGF0 aC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMy MjIyMjIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzIyMjIyMiI+VGhlcmUgYXJlIGFsc28gdGVjaG5pcXVlcyB0byBieXBhc3MgdGhlIGluaXRp YWwgbWVtb3J5IGFsbG9jYXRpb24gaW4gdGhlIGtlcm5lbCBzdWNoIGFzIGVicGYgdXNlZCBieSBj aWxpdW0gYW5kIG1lbWlmIHVzZWQgYnkgdnBwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj5NeSBtYWluIGNvbmNlcm4gYXQgdGhpcyBw b2ludCB3b3VsZCBiZSB3aXRoIGNsb3VkIG5hdGl2ZSBlbnZpcm9ubWVudHMgd2l0aCBsaW1pdGVk IGh3IG9mZmxvYWRpbmcgc3VwcG9ydC4gRS5nLiBpZiB3ZSBydW4gaW4gQVdTIG9yIEdDRSwNCiBi ZXR0ZXIga2VybmVsIHN1cHBvcnQgd2lsbCBwcm9iYWJseSBiZSBuZWNlc3NhcnkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6MS41 cHQ7b3V0bGluZTpub25lO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0 aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPGRp diBzdHlsZT0iYm9yZGVyOnNvbGlkICNEREREREQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiAw aW47b3V0bGluZTpub25lIiBpZD0iZ21haWwtOjJnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjQuNXB0O2JhY2tncm91bmQ6I0YxRjFGMSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyMjIyMjIiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI1IiBz cmM9Imh0dHBzOi8vc3NsLmdzdGF0aWMuY29tL3VpL3YxL2ljb25zL21haWwvaW1hZ2VzL2NsZWFy ZG90LmdpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIFdlZCwgQXByIDQsIDIwMTggYXQgMTA6 NTcgQU0sIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmI9 NDBtaWNyb3NvZnQuLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiPTQw bWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7DQogd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIG5lZWQgdG8gd29ycnkgaXMgbm90IG9uIHRoZSBj bGllbnQgc2lkZSDigJMgYXQgbGVhc3Qgbm90IGltbWVkaWF0ZWx5LiA4MDIuMTFhZCwgODAyLjEx YXgsIGFuZCA1RyBMVEUgd2lsbCBicmluZw0KIEdpZ2FiaXQgcmF0ZXMgdG8gY2xpZW50IHNpZGUg c28gaXQgaXMgY2VydGFpbmx5IGdvaW5nIHRvIGJlY29tZSBhIHByb2JsZW0gbG9uZ2VyIHRlcm0u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGN1cnJlbnQgd29ycnkgaXMgb24gdGhlIHNlcnZl ciBzaWRlLiBBIGxhcmdlIHBhcnQgb2YgdGhlIHdvcmsgd2UgZG8gaXMgcGVyZm9ybWFuY2Ugb3B0 aW1pemF0aW9uIG9mIHRoZSBuZXR3b3JrDQogc3RhY2suIEdvb2dsZeKAmXMgU2lnY29tbSBRVUlD IHBhcGVyIHNob3dzIGEgMnggQ1BVIGluY3JlYXNlIGdvaW5nIGZyb20gVENQIHRvIFFVSUMuIE1v c3Qgd2ViIHNlcnZpY2VzIHdpbGwgTk9UIGJlIGFibGUgdG8gbWFrZSB0aGF0IHRyYWRlIG9mZiB0 byBnZXQgbGF0ZW5jeSBpbXByb3ZlbWVudHMgZm9yIDkwPHN1cD50aDwvc3VwPiBwZXJjZW50aWxl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklNTw0KPGk+aW1wcm92aW5nIFVEUCBwZXJmb3JtYW5j ZSBhbmQgaGFyZHdhcmUgb2ZmbG9hZHMgYXJlIGFic29sdXRlbHkgYSBuZWNlc3NpdHkgZm9yIFFV SUMgdG8gYmVjb21lIHdpZGVseSBhZG9wdGVkPC9pPiAobm90IGp1c3QgYnkgdGhlIGJpZ2dlc3Qm bmJzcDtjb3Jwb3JhdGlvbnMgd2l0aCBhIGxhcmdlIGJ1ZGdldCkuIFdlIGhhdmUgd29yayB1bmRl ciB3YXkgb24gYm90aCB0aGVzZSBmcm9udHMgYW5kIEkgYW0gdmVyeSBoYXBweSB0byBzZWUgTGlu dXggYWxzbw0KIGludmVzdGluZyBoZXJlIGluIHByZXBhcmF0aW9uIGZvciB3aGF04oCZcyBjb21p bmcuIFdlIG5lZWQgdG8gZG8gb3VyIGJlc3QgZGVtb2NyYXRpemUgdGhpcyB0ZWNobm9sb2d5IC0g bXVsdGlwbGUgaW1wbGVtZW50YXRpb25zIGFuZCBwZXJmb3JtYW5jZSB3aWxsIGJvdGggcGxheSBh IGJpZyByb2xlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+IFFVSUMgW21haWx0bzo8YSBocmVmPSJtYWls dG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZjwvYj4gUGhpbGxpcCBIYWxsYW0tQmFrZXI8YnI+ DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDE4IDk6MjkgQU08YnI+DQo8Yj5U bzo8L2I+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtr ZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5taWtrZWxmakBnbWFpbC5jb208L2E+Jmd0 Ozxicj4NCjxiPkNjOjwvYj4gU3Vib2RoIEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpzdWJv ZGhAZmIuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3Vib2RoQGZiLmNvbTwvYT4mZ3Q7OyBJRVRGIFFV SUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7OyBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0PTxhIGhyZWY9Im1h aWx0bzo0MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGdvb2ds ZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVURQ IHNlbmQgY29zdHMgaW4gTGludXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+SSB3b3VsZCBub3Qgd29ycnkgdG9vIG11Y2ggYXQgdGhpcyBwb2ludC48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHJlYXNv biB3ZSB3YW50IHRvIGJlIGFibGUgdG8gd29yayBhdCB0aGUgYXBwbGljYXRpb24gbGV2ZWwgaXMg YmFja3dhcmRzIGNvbXBhdGliaWxpdHkuIEl0IGhhcyB0byBiZSBwb3NzaWJsZQ0KIHRvIGRlcGxv eSBRVUlDIG9uIGFueSBtYWNoaW5lIGV2ZW4gd2l0aG91dCBPUyBzdXBwb3J0IG9yIGl0IHdvbid0 IGJlIGRlcGxveWFibGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPkl0IGRvZXMgbm90IGhhdmUgdG8gYmUgcGVyZm9ybWFudCBvbiBldmVyeSBwbGF0Zm9y bS4gSWYgcGVvcGxlIGFyZSB1c2luZyBRVUlDLCB3aGF0ZXZlciBuZWVkcyB0byBiZSBtb3ZlZCBp bnRvDQogdGhlIGtlcm5lbCBmb3IgcGVyZm9ybWFuY2UgcmVhc29ucyB3aWxsIG1vdmUgdGhlcmUu PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5PbiBXZWQsIEFwciA0LCAyMDE4IGF0IDExOjMyIEFNLCBNaWtr ZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9hPiZndDsNCiB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IGlkPSJtXzE0NTI3MDgyMTY4ODYzMjMzNDFtXzE2 NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaGF2ZSBubyBkYXRhIHRvIGFkZCBvbiB0aGUgTGludXgg VURQIHN0YWNrLCBidXQgYW5vdGhlciBpc3N1ZSBpcyB0aGUgbGFjayBvZiBuZXRtYXAgc3VwcG9y dCBpbiBjbG91ZCBob3N0aW5nDQogZW52aXJvbm1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0ibV8xNDUyNzA4MjE2ODg2MzIzMzQxbV8xNjUxNzQyODc5NTA1NTU1 NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5JIGhhdmUgbm90IHlldCBiZWVuIHdvcmtpbmcgd2l0aCB0aGlzLCBidXQgaGF2ZSBs b29rZWQgaW50byB0aGUgcHJvYmxlbSBhbmQgYXNrZWQgYXJvdW5kLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xNDUyNzA4MjE2ODg2MzIzMzQxbV8xNjUxNzQyODc5 NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9Im1fMTQ1MjcwODIxNjg4NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3Rv bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bmV0bWFw IGlzIGRlZmF1bHQgaW4gRnJlZUJTRCBhbmQgb3B0aW9uYWwgaW4gTGludXguIEJ1dCBuZWl0aGVy IHdvcmtzIGVmZmljaWVudGx5IHdpdGhvdXQgYSBoeXBlcnZpc29yIHBhdGNoIHRoYXQNCiBpcyBh bHNvIGF2YWlsYWJsZSBmb3IgbmV0bWFwLiBXaXRoIHN1cHBvcnQgZm9yIG5ldG1hcCwgdGhlIHVz ZXIgc3BhY2UgYXBwbGljYXRpb24gY2FuIHNlbmQgZGlyZWN0bHkgdG8gdGhlIG5ldHdvcmsgYWRh cHRlciB3aXRoIHZlcnkgbGl0dGxlIG92ZXJoZWFkLiBUaGVyZSBpcyBhbHNvIGRwZGsgYW5kIHNv bWUgb3RoZXIgaW50ZXJmYWNlcyB0aGF0IG1pZ2h0IGJlIHNsaWdodGx5IGZhc3RlciBidXQgbW9y ZSB2ZW5kb3Igc3BlY2lmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJtXzE0NTI3MDgyMTY4ODYzMjMzNDFtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21m b250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xNDUyNzA4MjE2ODg2MzIz MzQxbV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Bc3N1bWluZyBhbiBhcHBsaWNhdGlvbiBoYXMg YWNjZXNzIHRvIG9wdGltaXplZCBuZXRtYXAsIHRoZSBvbmx5IGh1cmRsZSBpcyBhZGRyZXNzIGxv b2t1cCwgYnV0IGlmIHRoZSBhcHBsaWNhdGlvbg0KIGFsc28gbWFuYWdlcyB0aGF0LCBvciBhdCBs ZWFzdCBkb2VzIHRoZSBjYWNoaW5nLCB0aGVyZSBzaG91bGRu4oCZdCBiZSBtdWNoIGluIHRoZSB3 YXkgb2YgT1MgaW50ZXJmZXJlbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0ibV8xNDUyNzA4MjE2ODg2MzIzMzQxbV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3BfY3Vz dG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTQ1MjcwODIxNjg4 NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T2YgY291cnNlLCBuZXRtYXAgYmxvY2tz IHRoZSBlbnRpcmUgbmV0d29yayBzdGFjaywgc28gbm8gUElORyBvciBTU0guIENsb3VkRmxhcmUg YWRkZWQgYSBuZXRtYXAgcGF0Y2ggc28gb25seSBzb21lDQogdHJhZmZpYyB3b3VsZCBiZSByb3V0 ZWQgZnJhIHRoZSBuZXR3b3JrIGludGVyZmFjZSB0byBuZXRtYXAsIGFuZCBuZXRtYXAgYWxzbyBz dXBwb3J0cyBlZmZpY2llbnQgcGFja2V0IGZvcndhcmRpbmcgdG8gdGhlIE9TIG9yIG90aGVyIGFw cGxpY2F0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTQ1 MjcwODIxNjg4NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE0NTI3MDgyMTY4ODYzMjMzNDFtXzE2 NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk5vbmUgb2YgdGhpcyB3b3JrcyB3ZWxsIGluIGdlbmVyYWws IGJ1dCBmb3IgYSBjbG91ZCBob3N0IHRoYXQgY2FuIGJlIGJvb3RldCBhdXRvbWF0aWNhbGx5IGFu ZCBkZXN0cm95ZWQgcmF0aGVyDQogdGhhbiBzZXJ2aWNlZCwgdGhlcmUgaXMgc29tZSBvcHBvcnR1 bml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTQ1MjcwODIx Njg4NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE0NTI3MDgyMTY4ODYzMjMzNDFtXzE2NTE3NDI4 Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPmJ1dCBvbmx5IGlmIGNsb3VkIHNlcnZpY2UgcHJvdmlkZXJzIHN0YXJ0 cyBhZGRpbmcgc3VwcG9ydCB0aGVpciBzdXBwb3J0ZWQgaW1hZ2VzIGFuZCBoeXBlcnZpc29ycy4g Tm90IHN1cmUgaWYgYW55DQogYXJlIHdvcmtpbmcgb24gdGhpcyBub3cuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE0NTI3MDgyMTY4ODYzMjMzNDFtXzE2NTE3NDI4 Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izg4ODg4OCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTQ1MjcwODIx Njg4NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0ibV8xNDUyNzA4MjE2ODg2MzIzMzQxbV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3Bf Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM4ODg4ODgiPk1pa2tlbDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Im1fMTQ1MjcwODIxNjg4 NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX3NpZ25fMTUyMjg1NTQxODAwMDU0ODg2 NCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJtMTQ1MjcwODIxNjg4NjMyMzM0MW0xNjUxNzQyODc5NTA1NTU1NDkxYWlybWFp bG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gNCBBcHJpbCAyMDE4IGF0IDE1LjExLjE3LCBJYW4g U3dldHQgKDxhIGhyZWY9Im1haWx0bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5pYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi4ub3Jn PC9hPikNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaG9wZSBzb21l IG9mIHRoZXNlIHBhdGNoZXMgd2lsbCBiZSBhdmFpbGFibGUgc29vbiwgYnV0IEknbSBub3Qgc3Vy ZSBpZiBzb29uIGlzIGEgbW9udGggb3IgNi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+T24gVHVlLCBBcHIgMywgMjAxOCBhdCAxMDo1MCBQTSBTdWJvZGggSXll bmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1Ym9kaEBmYi5jb20iIHRhcmdldD0iX2JsYW5rIj5z dWJvZGhAZmIuY29tPC9hPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXYgaWQ9Im1fMTQ1MjcwODIxNjg4NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MW1f LTI1NDc3NDA2NzU1MjY2MzUyMGRpdnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPlRoYW5rcyBmb3Igc2hhcmluZyB0aGlzIElhbi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+VGhpcyBkZWZpbml0ZWx5IG1hdGNoZXMgc29tZSBvZiB0aGUgb2JzZXJ2YXRpb25zIHdlJ3Zl IHNlZW4gYXMgd2VsbCBpbiB0aGUgVURQIHdyaXRlIHBhdGguIFNvbWUgb2YgdGhlIG90aGVyIHBh dGhzIHRoYXQgd2Ugc2F3IHRoYXQgYWRkZWQNCiBvdmVyaGVhZCB3YXMgdGhlIHJvdXRlIHRhYmxl IGxvb2t1cCBpbiBsaW51eCB1ZHAgc3RhY2suIENvbm5lY3RlZCBVRFAgc29ja2V0cyBkaWQgYW1v cnRpemUgdGhhdC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSdtIGxvb2tpbmcgZm9yd2Fy ZCB0byBhIHNtYXJ0ZXIgc2VuZG1tc2cgd2l0aCBHU08gYW5kIHplcm8gY29weS4gSXMgdGhlcmUg YW55IGluZGljYXRpb24gb2YgdGhlIHRpbWVsaW5lIGZvciB0aGVzZSBwYXRjaGVzIHRvIG1ha2Ug aXQNCiB0byBsaW51eD8gV291bGQgYmUgaGFwcHkgdG8gdHJ5IGFueSBvZiB0aGVzZSBvdXQgdG8g aGVscCBpcm9uIG91dCB0aGUgQVBJLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TdWJvZGg8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj ZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4NCjxociBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGln bj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9Im1fMTQ1MjcwODIxNjg4NjMyMzM0 MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MW1fLTI1NDc3NDA2NzU1MjY2MzUyMGRpdlJwbHlGd2RNc2ci Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+UVVJQyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7IG9uIGJlaGFsZiBvZiBJYW4gU3dldHQgJmx0Ozwvc3Bhbj48 YSBocmVmPSJtYWlsdG86aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYuLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLi5vcmc8L2E+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFw cmlsIDMsIDIwMTggNToyMDowOCBQTTxicj4NCjxiPlRvOjwvYj4gSUVURiBRVUlDIFdHPGJyPg0K PGI+U3ViamVjdDo8L2I+IFVEUCBzZW5kIGNvc3RzIGluIExpbnV4PC9zcGFuPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbmUgY2hh bGxlbmdlIHdpdGggUVVJQyBhdCB0aGUgbW9tZW50IGlzIHRoZSBpbmNyZWFzZWQgQ1BVIGNvc3Qg b2Ygc2VuZGluZyBVRFAgcGFja2V0cyB2cyBUQ1AgcGF5bG9hZHMuJm5ic3A7IEkndmUgc2Vlbg0K IHRoaXMgYWNyb3NzIGV2ZXJ5IHBsYXRmb3JtIEdvb2dsZSBoYXMgZGVwbG95ZWQgUVVJQyBvbiwg c28gaXQncyBhIHdpZGVzcHJlYWQgaXNzdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPkhlcmUncyBhbiBleGNlbGxlbnQgcHJlc2VudGF0aW9uIG9uIHdoYXQn cyBjYXVzaW5nIHRoZSBpbmNyZWFzZWQgQ1BVIGNvbnN1bXB0aW9uIG9uIExpbnV4IGZyb20mbmJz cDtXaWxsZW0gZGUgQnJ1aWpuKFVEUA0KIHN0YXJ0cyBvbiBzbGlkZSA5KS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay4uY29tLz91cmw9aHR0cCUzQSUyRiUyRnZnZXIua2VybmVsLm9yZyUyRm5ldGNvbmYyMDE3 X2ZpbGVzJTJGcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBkZiZhbXA7ZGF0YT0wMiU3QzAxJTdD cHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDMTAzYTZlODFmMzY4NGM2NzM4MjYwOGQ1OWE0OTJjMmUl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM2NTg0NTYxNDQ5 ODcyOTM1JmFtcDtzZGF0YT1GUGUwbVM1YUclMkI4OCUyRlNYdklWU08zeVduWGg5dE9oUWZLa0g2 WG5RRHh2RSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly92Z2VyLmtl cm5lbC5vcmcvbmV0Y29uZjIwMTdfZmlsZXMvcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBkZjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5B bmQgd2hpbGUgeW91J3JlIHRoaW5raW5nIG9mIENQVSB1c2FnZSwgaXQncyB3b3J0aCBsb29raW5n IGF0IHRoZSBwcmVzZW50YXRpb24gb24gdGltaW5nIHdoZWVsIGJhc2VkIHBhY2tldCBwYWNpbmco d2hpY2gNCiBpcyBtaW5pbXVtIHJlbGVhc2UgdGltZSBiYXNlZCkgYW5kIGlzIGlkZWFsIGZvciBR VUlDKGFuZCBUQ1AgZm9yIHRoYXQgbWF0dGVyKTombmJzcDs8YSBocmVmPSJodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnVybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20lMkZ2MiUyRnVybCUzRnUlM0RodHRwcy0zQV9fY29uZmVyZW5j ZXMuc2lnY29tbS5vcmdfc2lnY29tbV8yMDE3X2ZpbGVzX3Byb2dyYW1fdHMtMkQ5LTJENC0yRGNh cm91c2VsLnBkZiUyNmQlM0REd01GYVElMjZjJTNENVZEMFJUdE5sVGgzeWNkNDFiM01VdyUyNnIl M0RoM0p1OUVCUzdtSHR3Zy13QXlON2ZRJTI2bSUzRHRnZ2hndkZrcHM3allhRk5kTnlaQk5GZjBl cFZ4RlpiT0doaHliRndQaUUlMjZzJTNEODdnT0dmejNTMGxMYnc4anktbHozTTl2UEdDaGttZ3Rp SlZ6VXhiTWZ2WSUyNmUlM0QmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNv bSU3QzEwM2E2ZTgxZjM2ODRjNjczODI2MDhkNTlhNDkyYzJlJTdDNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjU4NDU2MTQ0OTg3MjkzNSZhbXA7c2RhdGE9aFNY WHZUT0R2bGpJNm5pQkxtTXhHVUZTOWclMkZxT2lIc2tVY05jZ0h0RTZrJTNEJmFtcDtyZXNlcnZl ZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jb25mZXJlbmNlcy5zaWdjb21tLm9yZy9zaWdj b21tLzIwMTcvZmlsZXMvcHJvZ3JhbS90cy05LTQtY2Fyb3VzZWwuLnBkZjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4tSWFuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB0630F5F8DD480E168A8F97CDB6A40CY4PR21MB0630namp_-- From nobody Wed Apr 4 11:39:52 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0172D12D7E2 for ; Wed, 4 Apr 2018 11:39:46 -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=unavailable 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 bvHuVa4AOqU8 for ; Wed, 4 Apr 2018 11:39:42 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0105.outbound.protection.outlook.com [104.47.33.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B5F12D7E5 for ; Wed, 4 Apr 2018 11:39:38 -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=khgfVSEJRM8pIHAfbETpjTGTb1J8T7lJ2j2MquPDM9I=; b=mUurlC1eRs3SonTLzAgIlcyQQttKyGueW82VLrObLyoOnu5J8bdEsmfZ2NolX2/n5jysqpz4Wf9qkez25EeUdnzHku/0oDsXtTKjOoTIu7X4JZpU4bGNe3xrYVupESx1xfBYzymCYQ0oi6mpAdXB8G73UBmTLI70sEhK6/lXja4= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0775.namprd21.prod.outlook.com (10.173.192.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.2; Wed, 4 Apr 2018 18:39:36 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 18:39:36 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Frederick Kautz , Praveen Balasubramanian CC: Subodh Iyengar , Ian Swett , Phillip Hallam-Baker , IETF QUIC WG Subject: RE: UDP send costs in Linux Thread-Topic: UDP send costs in Linux Thread-Index: AQHTy6q+3JsicRIxhkabCq/gojpid6Pv6A6AgACtVICAACezAIAAD5iAgAAXAKCAAAmAAIAAAeWAgAABOKA= Date: Wed, 4 Apr 2018 18:39:36 +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:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0775; 7:b9N1+wxcssvoo8jvI9hE/ziY1xsQE5XfT6oQoXJC3XwA7ndrndn+pgdqmyVDSP34wfSByAnWwRUu587QxDb/pMYdPsRPDiBrB0kd33NJeD8pVv5pyfWswXYBCtKi2Ks9oG3/HGV4fdD3u56GnnBPhMeq7/tQ16Reo7s80hyiWX76yziBNuh0zX7qnI+3dxAUeN8DXkSESBQacqzXQfl2QsEoS9Sn2T0uZTArAqbcSFL+9wD8EpuRoqXMgzxDACdG; 20:OWYZPB2t9v6REO+cPojVv36KUlA4WD8986qdtFmsmYhCA5EInIglg6kQ16hgFv2PcOT5c1usfp1dcNr8zbu3qHULOmX9Q412aFofRgoMQUqbxP6LpgpIQruvBFXu1w91CB55ney1hVx4vi7Y1ItA/1M7AV6v4xvw/YiVKtyf11Y= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ad50b01f-7c4d-4896-bb5b-08d59a5b6a9d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0775; x-ms-traffictypediagnostic: CY4PR21MB0775: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(9452136761055)(189930954265078)(85827821059158)(67672495146484)(211936372134217)(153496737603132)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0775; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0775; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(346002)(376002)(396003)(366004)(45534002)(199004)(189003)(6246003)(33656002)(46003)(478600001)(53546011)(229853002)(59450400001)(476003)(6506007)(7736002)(102836004)(10090500001)(5250100002)(68736007)(8990500004)(97736004)(446003)(4326008)(11346002)(74316002)(25786009)(105586002)(5660300001)(7696005)(76176011)(81166006)(3660700001)(14454004)(19609705001)(2900100001)(316002)(2906002)(86612001)(54906003)(93886005)(86362001)(10290500003)(81156014)(22452003)(8676002)(110136005)(606006)(3280700002)(9686003)(99286004)(106356001)(186003)(55016002)(8936002)(6116002)(53936002)(6306002)(236005)(54896002)(2171002)(6436002)(790700001)(486006)(39060400002)(966005)(733005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0775; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: J2w1aE/VN1B7y+HmihCEF/TkkQichqJTfZoyos+HGQ8/6PliLltMI+Ei/OmuIiap1ozNym1k261REV3emS50gGcoBnvsoGawoixPV5uzgg9y3CbbC2LuNjb/cLCpov+BkGg3cPwTQBeMxqjruCIBQaMQ5kWhn7dOr8YTK7WO+rR+tk8t054V4WJNU+JjCHWrSPaqxCUWHOhYxCniMr7i/Qz8tmXoLB51GwzhU+kE7j/y5SFfdXo2rWWm0h4QEBfZZjZn4aCHZ4SZXebISCUriNx/9nvetfCHWZRrzmjKydA2KUbpAxnWddV5yKqwrbPbdWnovur3yIMib9upphAWX1XTUuAuv9rxJ/YjpLTEEZeMnwQ9yhpdqePt2ylDZGXWm3d/BEkQEWZyWbTvb00Pw8shJKtl/rCUxGc/COJRqqY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630F5F8DD480E168A8F97CDB6A40CY4PR21MB0630namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ad50b01f-7c4d-4896-bb5b-08d59a5b6a9d X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 18:39:36.2835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0775 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 18:39:46 -0000 --_000_CY4PR21MB0630F5F8DD480E168A8F97CDB6A40CY4PR21MB0630namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGFyZHdhcmUgc3VwcG9ydCBpcyBub3Qgb3J0aG9nb25hbCB0byBEUERLIGFuZCBrZXJuZWwgYnlw YXNzIGV2ZW4gdXNlciBtb2RlIGNhbiB0YWtlIGFkdmFudGFnZSBvZiBpdC4gRFBESyBoYXMgYSBs b3Qgb2Ygb3RoZXIgaXNzdWVzIGluY2x1ZGluZyBubyBiYXR0bGUgaGFyZGVuZWQgVENQSVAgc3Rh Y2tzLiBJTU8gd2UgbmVlZCB0byBtYWtlIHByb2dyZXNzIG9uIGJldHRlciBwZXJmb3JtYW5jZSBy ZWdhcmRsZXNzIG9mIHVzZXIgb3Iga2VybmVsIGltcGxlbWVudGF0aW9ucy4gRXNwZWNpYWxseSBm b3IgY2xpZW50IGRldmljZXMgdXNlciBzcGFjZSBpbXBsZW1lbnRhdGlvbnMgY2Fubm90IGJlIGdp dmVuIGRpcmVjdCBoYXJkd2FyZSBhY2Nlc3MgZm9yIHNlY3VyaXR5IHJlYXNvbnMuIEZvciBjbG91 ZCBWTXMgdGhlcmUgaXMgU1ItSU9WIGZvciBkaXJlY3QgaGFyZHdhcmUgYWNjZXNzIHdoaWNoIGlz IG5vdyBzdXBwb3J0ZWQgYnkgbW9yZSBhbmQgbW9yZSBjbG91ZCBwcm92aWRlcnMuDQoNCkZyb206 IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtrZWwg RmFobsO4ZSBKw7hyZ2Vuc2VuDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTggMTE6MzIg QU0NClRvOiBGcmVkZXJpY2sgS2F1dHogPGZrYXV0ekBhbHVtbmkuY211LmVkdT47IFByYXZlZW4g QmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+DQpD YzogU3Vib2RoIEl5ZW5nYXIgPHN1Ym9kaEBmYi5jb20+OyBJYW4gU3dldHQgPGlhbnN3ZXR0QGdv b2dsZS5jb20+OyBQaGlsbGlwIEhhbGxhbS1CYWtlciA8cGhpbGxAaGFsbGFtYmFrZXIuY29tPjsg SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFVEUCBzZW5kIGNvc3Rz IGluIExpbnV4DQoNCkdvdCBpdCBiZWZvcmUsIGJ1dCB0aGUgcmVhc29uIHdoeSBuZXRtYXAgYW5k IERQREsgaXMgaW1wb3J0YW50IGluIGNvbnRyYXN0IHRvIGtlcm5lbCBzdXBwb3J0IGlzIHRoZSB2 ZXJ5IHJpY2ggYXBwbGljYXRpb24gaW50ZXJmYWNlcyB0aGF0IGEgY3VzdG9tIHVzZXIgc3BhY2Ug UVVJQyBpbXBsZW1lbnRhdGlvbiBwcm92aWRlcy4gU3BlbmRpbmcgdGhlIG5leHQgMTAgeWVhcnMg ZGlzY3Vzc2luZyBlcG9sbCB2cyBwb2xsIGZvciBRVUlDIGlzIG5vdCBnb2luZyB0byBjdXQgaXQu DQoNCk9TIHN1cHBvcnQgdGhhdCBtYWtlcyBpdCBlYXNpZXIgdG8gdXNlIG5ldG1hcCBhbmQgZnJp ZW5kcyBjb25jdXJyZW50bHkgd2l0aCBvdGhlciBuZXR3b3JrIHRyYWZmaWMgd291bGQgYmUgd2Vs Y29tZSB0aG91Z2guDQpRdWVzdGlvbiBpcyB3aGF0IGhhcmR3YXJlIG9mZmxvYWQgc3VwcG9ydCBj YW4gYmUgZ2l2ZW4gdG8gYSBjdXN0b20gUVVJQyBpbXBsZW1lbnRhdGlvbiwgYnV0IG9uZSB0aGlu ZyB0aGF0IGNvbWVzIHRvIG1pbmQgaXMgcHJlLWRlY3J5cHRpb24gb24gbmV0bWFwIHdoZXJlIHRo ZSBPUyBmaXJzdCBpbnRlcmNlcHRzIHRoZSBwYWNrZXQgYW5kIGZvcndhcmRzIHRoZSBkZWNyeXB0 ZWQgYW5kIERvUyBmaWx0ZXJlZCBwYWNrZXQgdG8gdGhlIGFwcCB3aGljaCB0aGVuIGhhbmRsZXMg YWxsIHRoZSBkZXRhaWxlZCBmcmFtaW5nLCBBQ0ssIHBhY2luZyBldGMuDQoNCktpbmQgUmVnYXJk cywNCk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCg0KDQpPbiA0IEFwcmlsIDIwMTggYXQgMjAu MjUuMDcsIEZyZWRlcmljayBLYXV0eiAoZmthdXR6QGFsdW1uaS5jbXUuZWR1PG1haWx0bzpma2F1 dHpAYWx1bW5pLmNtdS5lZHU+KSB3cm90ZToNCkkgYXBvbG9naXplIHRvIGFueW9uZSBoZXJlIHdo byBnZXRzIGEgcmVwZWF0IG9mIHRoaXMgbWVzc2FnZSwgdGhlIG1haWxpbmcgbGlzdCBhdGUgbXkg ZWFybGllciByZXBseSBiZWNhdXNlIG15IG1haWwgcHJvdmlkZXIgY2hhbmdlZCBteSBkZWZhdWx0 IGVtYWlsIGFkZHJlc3MgZHVyaW5nIGEgdHJhbnNpdGlvbi4gSGVyZSBpcyB0aGUgb3JpZ2luYWwg bWVzc2FnZToNCg0KSSBhZ3JlZSB3aXRoIHRoaXMgc2VudGltZW50LiBJZiB3ZSBzZWUgdHJhY3Rp b24sIHRoZW4gd2Ugc2hvdWxkIHNlZSBiZXR0ZXIga2VybmVsIHN1cHBvcnQgYW5kIG9mZmxvYWRp bmcuDQoNCkl0IHNob3VsZCBiZSB0cml2aWFsIHRvIGdldCB0aGlzIHdvcmtpbmcgaW4gc29tZXRo aW5nIGxpa2UgVlBQIHdoaWNoIGNhbiB1c2UgRFBESyB0byBodyBvZmZsb2FkLCBlbnRpcmVseSBz a2lwcGluZyB0aGUga2VybmVsIGluIHRoZSBkYXRhIHBhdGguDQoNClRoZXJlIGFyZSBhbHNvIHRl Y2huaXF1ZXMgdG8gYnlwYXNzIHRoZSBpbml0aWFsIG1lbW9yeSBhbGxvY2F0aW9uIGluIHRoZSBr ZXJuZWwgc3VjaCBhcyBlYnBmIHVzZWQgYnkgY2lsaXVtIGFuZCBtZW1pZiB1c2VkIGJ5IHZwcC4N Cg0KTXkgbWFpbiBjb25jZXJuIGF0IHRoaXMgcG9pbnQgd291bGQgYmUgd2l0aCBjbG91ZCBuYXRp dmUgZW52aXJvbm1lbnRzIHdpdGggbGltaXRlZCBodyBvZmZsb2FkaW5nIHN1cHBvcnQuIEUuZy4g aWYgd2UgcnVuIGluIEFXUyBvciBHQ0UsIGJldHRlciBrZXJuZWwgc3VwcG9ydCB3aWxsIHByb2Jh Ymx5IGJlIG5lY2Vzc2FyeS4NCltodHRwczovL3NzbC5nc3RhdGljLmNvbS91aS92MS9pY29ucy9t YWlsL2ltYWdlcy9jbGVhcmRvdC5naWZdDQoNCg0KT24gV2VkLCBBcHIgNCwgMjAxOCBhdCAxMDo1 NyBBTSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFy Yy5pZXRmLm9yZzxtYWlsdG86cHJhdmI9NDBtaWNyb3NvZnQuLmNvbUBkbWFyYy5pZXRmLm9yZz4+ IHdyb3RlOg0KVGhlIG5lZWQgdG8gd29ycnkgaXMgbm90IG9uIHRoZSBjbGllbnQgc2lkZSDigJMg YXQgbGVhc3Qgbm90IGltbWVkaWF0ZWx5LiA4MDIuMTFhZCwgODAyLjExYXgsIGFuZCA1RyBMVEUg d2lsbCBicmluZyBHaWdhYml0IHJhdGVzIHRvIGNsaWVudCBzaWRlIHNvIGl0IGlzIGNlcnRhaW5s eSBnb2luZyB0byBiZWNvbWUgYSBwcm9ibGVtIGxvbmdlciB0ZXJtLg0KDQpUaGUgY3VycmVudCB3 b3JyeSBpcyBvbiB0aGUgc2VydmVyIHNpZGUuIEEgbGFyZ2UgcGFydCBvZiB0aGUgd29yayB3ZSBk byBpcyBwZXJmb3JtYW5jZSBvcHRpbWl6YXRpb24gb2YgdGhlIG5ldHdvcmsgc3RhY2suIEdvb2ds ZeKAmXMgU2lnY29tbSBRVUlDIHBhcGVyIHNob3dzIGEgMnggQ1BVIGluY3JlYXNlIGdvaW5nIGZy b20gVENQIHRvIFFVSUMuIE1vc3Qgd2ViIHNlcnZpY2VzIHdpbGwgTk9UIGJlIGFibGUgdG8gbWFr ZSB0aGF0IHRyYWRlIG9mZiB0byBnZXQgbGF0ZW5jeSBpbXByb3ZlbWVudHMgZm9yIDkwdGggcGVy Y2VudGlsZS4NCg0KSU1PIGltcHJvdmluZyBVRFAgcGVyZm9ybWFuY2UgYW5kIGhhcmR3YXJlIG9m ZmxvYWRzIGFyZSBhYnNvbHV0ZWx5IGEgbmVjZXNzaXR5IGZvciBRVUlDIHRvIGJlY29tZSB3aWRl bHkgYWRvcHRlZCAobm90IGp1c3QgYnkgdGhlIGJpZ2dlc3QgY29ycG9yYXRpb25zIHdpdGggYSBs YXJnZSBidWRnZXQpLiBXZSBoYXZlIHdvcmsgdW5kZXIgd2F5IG9uIGJvdGggdGhlc2UgZnJvbnRz IGFuZCBJIGFtIHZlcnkgaGFwcHkgdG8gc2VlIExpbnV4IGFsc28gaW52ZXN0aW5nIGhlcmUgaW4g cHJlcGFyYXRpb24gZm9yIHdoYXTigJlzIGNvbWluZy4gV2UgbmVlZCB0byBkbyBvdXIgYmVzdCBk ZW1vY3JhdGl6ZSB0aGlzIHRlY2hub2xvZ3kgLSBtdWx0aXBsZSBpbXBsZW1lbnRhdGlvbnMgYW5k IHBlcmZvcm1hbmNlIHdpbGwgYm90aCBwbGF5IGEgYmlnIHJvbGUuDQoNCg0KRnJvbTogUVVJQyBb bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn Pl0gT24gQmVoYWxmIE9mIFBoaWxsaXAgSGFsbGFtLUJha2VyDQpTZW50OiBXZWRuZXNkYXksIEFw cmlsIDQsIDIwMTggOToyOSBBTQ0KVG86IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tl bGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPj4NCkNjOiBTdWJvZGggSXll bmdhciA8c3Vib2RoQGZiLmNvbTxtYWlsdG86c3Vib2RoQGZiLmNvbT4+OyBJRVRGIFFVSUMgV0cg PHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PjsgSWFuIFN3ZXR0IDxpYW5zd2V0 dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5p ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogVURQIHNlbmQgY29zdHMgaW4gTGludXgNCg0KSSB3b3Vs ZCBub3Qgd29ycnkgdG9vIG11Y2ggYXQgdGhpcyBwb2ludC4NCg0KVGhlIHJlYXNvbiB3ZSB3YW50 IHRvIGJlIGFibGUgdG8gd29yayBhdCB0aGUgYXBwbGljYXRpb24gbGV2ZWwgaXMgYmFja3dhcmRz IGNvbXBhdGliaWxpdHkuIEl0IGhhcyB0byBiZSBwb3NzaWJsZSB0byBkZXBsb3kgUVVJQyBvbiBh bnkgbWFjaGluZSBldmVuIHdpdGhvdXQgT1Mgc3VwcG9ydCBvciBpdCB3b24ndCBiZSBkZXBsb3lh YmxlLg0KDQpJdCBkb2VzIG5vdCBoYXZlIHRvIGJlIHBlcmZvcm1hbnQgb24gZXZlcnkgcGxhdGZv cm0uIElmIHBlb3BsZSBhcmUgdXNpbmcgUVVJQywgd2hhdGV2ZXIgbmVlZHMgdG8gYmUgbW92ZWQg aW50byB0aGUga2VybmVsIGZvciBwZXJmb3JtYW5jZSByZWFzb25zIHdpbGwgbW92ZSB0aGVyZS4N Cg0KDQoNCg0KT24gV2VkLCBBcHIgNCwgMjAxOCBhdCAxMTozMiBBTSwgTWlra2VsIEZhaG7DuGUg SsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+ PiB3cm90ZToNCkkgaGF2ZSBubyBkYXRhIHRvIGFkZCBvbiB0aGUgTGludXggVURQIHN0YWNrLCBi dXQgYW5vdGhlciBpc3N1ZSBpcyB0aGUgbGFjayBvZiBuZXRtYXAgc3VwcG9ydCBpbiBjbG91ZCBo b3N0aW5nIGVudmlyb25tZW50cy4NCkkgaGF2ZSBub3QgeWV0IGJlZW4gd29ya2luZyB3aXRoIHRo aXMsIGJ1dCBoYXZlIGxvb2tlZCBpbnRvIHRoZSBwcm9ibGVtIGFuZCBhc2tlZCBhcm91bmQuDQoN Cm5ldG1hcCBpcyBkZWZhdWx0IGluIEZyZWVCU0QgYW5kIG9wdGlvbmFsIGluIExpbnV4LiBCdXQg bmVpdGhlciB3b3JrcyBlZmZpY2llbnRseSB3aXRob3V0IGEgaHlwZXJ2aXNvciBwYXRjaCB0aGF0 IGlzIGFsc28gYXZhaWxhYmxlIGZvciBuZXRtYXAuIFdpdGggc3VwcG9ydCBmb3IgbmV0bWFwLCB0 aGUgdXNlciBzcGFjZSBhcHBsaWNhdGlvbiBjYW4gc2VuZCBkaXJlY3RseSB0byB0aGUgbmV0d29y ayBhZGFwdGVyIHdpdGggdmVyeSBsaXR0bGUgb3ZlcmhlYWQuIFRoZXJlIGlzIGFsc28gZHBkayBh bmQgc29tZSBvdGhlciBpbnRlcmZhY2VzIHRoYXQgbWlnaHQgYmUgc2xpZ2h0bHkgZmFzdGVyIGJ1 dCBtb3JlIHZlbmRvciBzcGVjaWZpYy4NCg0KQXNzdW1pbmcgYW4gYXBwbGljYXRpb24gaGFzIGFj Y2VzcyB0byBvcHRpbWl6ZWQgbmV0bWFwLCB0aGUgb25seSBodXJkbGUgaXMgYWRkcmVzcyBsb29r dXAsIGJ1dCBpZiB0aGUgYXBwbGljYXRpb24gYWxzbyBtYW5hZ2VzIHRoYXQsIG9yIGF0IGxlYXN0 IGRvZXMgdGhlIGNhY2hpbmcsIHRoZXJlIHNob3VsZG7igJl0IGJlIG11Y2ggaW4gdGhlIHdheSBv ZiBPUyBpbnRlcmZlcmVuY2UuDQoNCk9mIGNvdXJzZSwgbmV0bWFwIGJsb2NrcyB0aGUgZW50aXJl IG5ldHdvcmsgc3RhY2ssIHNvIG5vIFBJTkcgb3IgU1NILiBDbG91ZEZsYXJlIGFkZGVkIGEgbmV0 bWFwIHBhdGNoIHNvIG9ubHkgc29tZSB0cmFmZmljIHdvdWxkIGJlIHJvdXRlZCBmcmEgdGhlIG5l dHdvcmsgaW50ZXJmYWNlIHRvIG5ldG1hcCwgYW5kIG5ldG1hcCBhbHNvIHN1cHBvcnRzIGVmZmlj aWVudCBwYWNrZXQgZm9yd2FyZGluZyB0byB0aGUgT1Mgb3Igb3RoZXIgYXBwbGljYXRpb25zLg0K DQpOb25lIG9mIHRoaXMgd29ya3Mgd2VsbCBpbiBnZW5lcmFsLCBidXQgZm9yIGEgY2xvdWQgaG9z dCB0aGF0IGNhbiBiZSBib290ZXQgYXV0b21hdGljYWxseSBhbmQgZGVzdHJveWVkIHJhdGhlciB0 aGFuIHNlcnZpY2VkLCB0aGVyZSBpcyBzb21lIG9wcG9ydHVuaXR5Lg0KDQpidXQgb25seSBpZiBj bG91ZCBzZXJ2aWNlIHByb3ZpZGVycyBzdGFydHMgYWRkaW5nIHN1cHBvcnQgdGhlaXIgc3VwcG9y dGVkIGltYWdlcyBhbmQgaHlwZXJ2aXNvcnMuIE5vdCBzdXJlIGlmIGFueSBhcmUgd29ya2luZyBv biB0aGlzIG5vdy4NCg0KDQpNaWtrZWwNCg0KDQoNCk9uIDQgQXByaWwgMjAxOCBhdCAxNS4xMS4x NywgSWFuIFN3ZXR0IChpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi4ub3JnPG1haWx0 bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+KSB3cm90ZToNCkkgaG9wZSBz b21lIG9mIHRoZXNlIHBhdGNoZXMgd2lsbCBiZSBhdmFpbGFibGUgc29vbiwgYnV0IEknbSBub3Qg c3VyZSBpZiBzb29uIGlzIGEgbW9udGggb3IgNi4NCg0KT24gVHVlLCBBcHIgMywgMjAxOCBhdCAx MDo1MCBQTSBTdWJvZGggSXllbmdhciA8c3Vib2RoQGZiLmNvbTxtYWlsdG86c3Vib2RoQGZiLmNv bT4+IHdyb3RlOg0KDQpUaGFua3MgZm9yIHNoYXJpbmcgdGhpcyBJYW4uDQoNCg0KDQpUaGlzIGRl ZmluaXRlbHkgbWF0Y2hlcyBzb21lIG9mIHRoZSBvYnNlcnZhdGlvbnMgd2UndmUgc2VlbiBhcyB3 ZWxsIGluIHRoZSBVRFAgd3JpdGUgcGF0aC4gU29tZSBvZiB0aGUgb3RoZXIgcGF0aHMgdGhhdCB3 ZSBzYXcgdGhhdCBhZGRlZCBvdmVyaGVhZCB3YXMgdGhlIHJvdXRlIHRhYmxlIGxvb2t1cCBpbiBs aW51eCB1ZHAgc3RhY2suIENvbm5lY3RlZCBVRFAgc29ja2V0cyBkaWQgYW1vcnRpemUgdGhhdC4N Cg0KDQoNCkknbSBsb29raW5nIGZvcndhcmQgdG8gYSBzbWFydGVyIHNlbmRtbXNnIHdpdGggR1NP IGFuZCB6ZXJvIGNvcHkuIElzIHRoZXJlIGFueSBpbmRpY2F0aW9uIG9mIHRoZSB0aW1lbGluZSBm b3IgdGhlc2UgcGF0Y2hlcyB0byBtYWtlIGl0IHRvIGxpbnV4PyBXb3VsZCBiZSBoYXBweSB0byB0 cnkgYW55IG9mIHRoZXNlIG91dCB0byBoZWxwIGlyb24gb3V0IHRoZSBBUEkuDQoNCg0KDQpTdWJv ZGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFFVSUMgPHF1aWMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxm IG9mIElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYuLm9yZzxtYWls dG86aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYuLm9yZz4+DQpTZW50OiBUdWVzZGF5 LCBBcHJpbCAzLCAyMDE4IDU6MjA6MDggUE0NClRvOiBJRVRGIFFVSUMgV0cNClN1YmplY3Q6IFVE UCBzZW5kIGNvc3RzIGluIExpbnV4DQoNCk9uZSBjaGFsbGVuZ2Ugd2l0aCBRVUlDIGF0IHRoZSBt b21lbnQgaXMgdGhlIGluY3JlYXNlZCBDUFUgY29zdCBvZiBzZW5kaW5nIFVEUCBwYWNrZXRzIHZz IFRDUCBwYXlsb2Fkcy4gIEkndmUgc2VlbiB0aGlzIGFjcm9zcyBldmVyeSBwbGF0Zm9ybSBHb29n bGUgaGFzIGRlcGxveWVkIFFVSUMgb24sIHNvIGl0J3MgYSB3aWRlc3ByZWFkIGlzc3VlLg0KDQpI ZXJlJ3MgYW4gZXhjZWxsZW50IHByZXNlbnRhdGlvbiBvbiB3aGF0J3MgY2F1c2luZyB0aGUgaW5j cmVhc2VkIENQVSBjb25zdW1wdGlvbiBvbiBMaW51eCBmcm9tIFdpbGxlbSBkZSBCcnVpam4oVURQ IHN0YXJ0cyBvbiBzbGlkZSA5KS4NCmh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbmV0Y29uZjIwMTdf ZmlsZXMvcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBkZjxodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay4uY29tLz91cmw9aHR0cCUzQSUyRiUyRnZnZXIua2VybmVsLm9y ZyUyRm5ldGNvbmYyMDE3X2ZpbGVzJTJGcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBkZiZkYXRh PTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0MxMDNhNmU4MWYzNjg0YzY3MzgyNjA4 ZDU5YTQ5MmMyZSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzElN0M2 MzY1ODQ1NjE0NDk4NzI5MzUmc2RhdGE9RlBlMG1TNWFHJTJCODglMkZTWHZJVlNPM3lXblhoOXRP aFFmS2tINlhuUUR4dkUlM0QmcmVzZXJ2ZWQ9MD4NCg0KQW5kIHdoaWxlIHlvdSdyZSB0aGlua2lu ZyBvZiBDUFUgdXNhZ2UsIGl0J3Mgd29ydGggbG9va2luZyBhdCB0aGUgcHJlc2VudGF0aW9uIG9u IHRpbWluZyB3aGVlbCBiYXNlZCBwYWNrZXQgcGFjaW5nKHdoaWNoIGlzIG1pbmltdW0gcmVsZWFz ZSB0aW1lIGJhc2VkKSBhbmQgaXMgaWRlYWwgZm9yIFFVSUMoYW5kIFRDUCBmb3IgdGhhdCBtYXR0 ZXIpOiBodHRwczovL2NvbmZlcmVuY2VzLnNpZ2NvbW0ub3JnL3NpZ2NvbW0vMjAxNy9maWxlcy9w cm9ncmFtL3RzLTktNC1jYXJvdXNlbC4ucGRmPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX19jb25mZXJlbmNlcy5zaWdjb21tLm9yZ19z aWdjb21tXzIwMTdfZmlsZXNfcHJvZ3JhbV90cy0yRDktMkQ0LTJEY2Fyb3VzZWwucGRmJTI2ZCUz RER3TUZhUSUyNmMlM0Q1VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JTI2ciUzRGgzSnU5RUJTN21IdHdn LXdBeU43ZlElMjZtJTNEdGdnaGd2RmtwczdqWWFGTmROeVpCTkZmMGVwVnhGWmJPR2hoeWJGd1Bp RSUyNnMlM0Q4N2dPR2Z6M1MwbExidzhqeS1sejNNOXZQR0Noa21ndGlKVnpVeGJNZnZZJTI2ZSUz RCZkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0MxMDNhNmU4MWYzNjg0YzY3 MzgyNjA4ZDU5YTQ5MmMyZSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3 QzAlN0M2MzY1ODQ1NjE0NDk4NzI5MzUmc2RhdGE9aFNYWHZUT0R2bGpJNm5pQkxtTXhHVUZTOWcl MkZxT2lIc2tVY05jZ0h0RTZrJTNEJnJlc2VydmVkPTA+DQoNCi1JYW4NCg0KDQo= --_000_CY4PR21MB0630F5F8DD480E168A8F97CDB6A40CY4PR21MB0630namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1z dHlsZS1uYW1lOmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLm0xNDUyNzA4MjE2ODg2MzIzMzQxbTE2NTE3NDI4Nzk1MDU1NTU0OTFhaXJtYWlsb24s IGxpLm0xNDUyNzA4MjE2ODg2MzIzMzQxbTE2NTE3NDI4Nzk1MDU1NTU0OTFhaXJtYWlsb24sIGRp di5tMTQ1MjcwODIxNjg4NjMyMzM0MW0xNjUxNzQyODc5NTA1NTU1NDkxYWlybWFpbG9uDQoJe21z by1zdHlsZS1uYW1lOm1fMTQ1MjcwODIxNjg4NjMyMzM0MW0xNjUxNzQyODc5NTA1NTU1NDkxYWly bWFpbG9uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFy ZHdhcmUgc3VwcG9ydCBpcyBub3Qgb3J0aG9nb25hbCB0byBEUERLIGFuZCBrZXJuZWwgYnlwYXNz IGV2ZW4gdXNlciBtb2RlIGNhbiB0YWtlIGFkdmFudGFnZSBvZiBpdC4gRFBESyBoYXMgYSBsb3Qg b2Ygb3RoZXIgaXNzdWVzIGluY2x1ZGluZyBubyBiYXR0bGUgaGFyZGVuZWQgVENQSVAgc3RhY2tz LiBJTU8gd2UgbmVlZCB0byBtYWtlIHByb2dyZXNzIG9uIGJldHRlciBwZXJmb3JtYW5jZSByZWdh cmRsZXNzDQogb2YgdXNlciBvciBrZXJuZWwgaW1wbGVtZW50YXRpb25zLiBFc3BlY2lhbGx5IGZv ciBjbGllbnQgZGV2aWNlcyB1c2VyIHNwYWNlIGltcGxlbWVudGF0aW9ucyBjYW5ub3QgYmUgZ2l2 ZW4gZGlyZWN0IGhhcmR3YXJlIGFjY2VzcyBmb3Igc2VjdXJpdHkgcmVhc29ucy4gRm9yIGNsb3Vk IFZNcyB0aGVyZSBpcyBTUi1JT1YgZm9yIGRpcmVjdCBoYXJkd2FyZSBhY2Nlc3Mgd2hpY2ggaXMg bm93IHN1cHBvcnRlZCBieSBtb3JlIGFuZCBtb3JlIGNsb3VkDQogcHJvdmlkZXJzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBP Zg0KPC9iPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVz ZGF5LCBBcHJpbCA0LCAyMDE4IDExOjMyIEFNPGJyPg0KPGI+VG86PC9iPiBGcmVkZXJpY2sgS2F1 dHogJmx0O2ZrYXV0ekBhbHVtbmkuY211LmVkdSZndDs7IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFu ICZsdDtwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBTdWJvZGggSXllbmdhciAmbHQ7c3Vib2RoQGZiLmNvbSZndDs7IElhbiBTd2V0dCAmbHQ7 aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs7IFBoaWxsaXAgSGFsbGFtLUJha2VyICZsdDtwaGlsbEBo YWxsYW1iYWtlci5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBVRFAgc2VuZCBjb3N0cyBpbiBMaW51eDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+R290IGl0IGJlZm9yZSwgYnV0IHRoZSByZWFzb24gd2h5IG5l dG1hcCBhbmQgRFBESyBpcyBpbXBvcnRhbnQgaW4gY29udHJhc3QgdG8ga2VybmVsIHN1cHBvcnQg aXMgdGhlIHZlcnkgcmljaCBhcHBsaWNhdGlvbiBpbnRlcmZhY2VzIHRoYXQgYSBjdXN0b20gdXNl ciBzcGFjZSBRVUlDIGltcGxlbWVudGF0aW9uDQogcHJvdmlkZXMuIFNwZW5kaW5nIHRoZSBuZXh0 IDEwIHllYXJzIGRpc2N1c3NpbmcgZXBvbGwgdnMgcG9sbCBmb3IgUVVJQyBpcyBub3QgZ29pbmcg dG8gY3V0IGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3Bf Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21m b250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PUyBzdXBwb3J0 IHRoYXQgbWFrZXMgaXQgZWFzaWVyIHRvIHVzZSBuZXRtYXAgYW5kIGZyaWVuZHMgY29uY3VycmVu dGx5IHdpdGggb3RoZXIgbmV0d29yayB0cmFmZmljIHdvdWxkIGJlIHdlbGNvbWUgdGhvdWdoLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+UXVlc3Rpb24gaXMgd2hh dCBoYXJkd2FyZSBvZmZsb2FkIHN1cHBvcnQgY2FuIGJlIGdpdmVuIHRvIGEgY3VzdG9tIFFVSUMg aW1wbGVtZW50YXRpb24sIGJ1dCBvbmUgdGhpbmcgdGhhdCBjb21lcyB0byBtaW5kIGlzIHByZS1k ZWNyeXB0aW9uIG9uIG5ldG1hcCB3aGVyZSB0aGUgT1MgZmlyc3QgaW50ZXJjZXB0cw0KIHRoZSBw YWNrZXQgYW5kIGZvcndhcmRzIHRoZSBkZWNyeXB0ZWQgYW5kIERvUyBmaWx0ZXJlZCBwYWNrZXQg dG8gdGhlIGFwcCB3aGljaCB0aGVuIGhhbmRsZXMgYWxsIHRoZSBkZXRhaWxlZCBmcmFtaW5nLCBB Q0ssIHBhY2luZyBldGMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBpZD0iYmxvb3Bfc2lnbl8xNTIyODY2MzMyODA4MDA3OTM2Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+S2luZCBSZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk1pa2tlbCBGYWhuw7hl IErDuHJnZW5zZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJhaXJtYWlsb24iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiA0IEFwcmls IDIwMTggYXQgMjAuMjUuMDcsIEZyZWRlcmljayBLYXV0eiAoPGEgaHJlZj0ibWFpbHRvOmZrYXV0 ekBhbHVtbmkuY211LmVkdSI+ZmthdXR6QGFsdW1uaS5jbXUuZWR1PC9hPikgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBhcG9sb2dpemUgdG8gYW55b25lIGhlcmUgd2hvIGdl dHMgYSByZXBlYXQgb2YgdGhpcyBtZXNzYWdlLCB0aGUgbWFpbGluZyBsaXN0IGF0ZSBteSBlYXJs aWVyIHJlcGx5IGJlY2F1c2UgbXkgbWFpbCBwcm92aWRlciBjaGFuZ2VkIG15IGRlZmF1bHQgZW1h aWwgYWRkcmVzcyBkdXJpbmcgYSB0cmFuc2l0aW9uLg0KIEhlcmUgaXMgdGhlIG9yaWdpbmFsIG1l c3NhZ2U6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+SSBhZ3JlZSB3aXRoIHRoaXMgc2VudGlt ZW50LiBJZiB3ZSBzZWUgdHJhY3Rpb24sIHRoZW4gd2Ugc2hvdWxkIHNlZSBiZXR0ZXIga2VybmVs IHN1cHBvcnQgYW5kIG9mZmxvYWRpbmcuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMjIyMjIyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPkl0IHNob3VsZCBiZSB0cml2aWFsIHRvIGdldCB0 aGlzIHdvcmtpbmcgaW4gc29tZXRoaW5nIGxpa2UgVlBQIHdoaWNoIGNhbiB1c2UgRFBESyB0byBo dyBvZmZsb2FkLCBlbnRpcmVseSBza2lwcGluZyB0aGUga2VybmVsIGluIHRoZSBkYXRhDQogcGF0 aC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMy MjIyMjIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzIyMjIyMiI+VGhlcmUgYXJlIGFsc28gdGVjaG5pcXVlcyB0byBieXBhc3MgdGhlIGluaXRp YWwgbWVtb3J5IGFsbG9jYXRpb24gaW4gdGhlIGtlcm5lbCBzdWNoIGFzIGVicGYgdXNlZCBieSBj aWxpdW0gYW5kIG1lbWlmIHVzZWQgYnkgdnBwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj5NeSBtYWluIGNvbmNlcm4gYXQgdGhpcyBw b2ludCB3b3VsZCBiZSB3aXRoIGNsb3VkIG5hdGl2ZSBlbnZpcm9ubWVudHMgd2l0aCBsaW1pdGVk IGh3IG9mZmxvYWRpbmcgc3VwcG9ydC4gRS5nLiBpZiB3ZSBydW4gaW4gQVdTIG9yIEdDRSwNCiBi ZXR0ZXIga2VybmVsIHN1cHBvcnQgd2lsbCBwcm9iYWJseSBiZSBuZWNlc3NhcnkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6MS41 cHQ7b3V0bGluZTpub25lO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0 aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPGRp diBzdHlsZT0iYm9yZGVyOnNvbGlkICNEREREREQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiAw aW47b3V0bGluZTpub25lIiBpZD0iZ21haWwtOjJnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjQuNXB0O2JhY2tncm91bmQ6I0YxRjFGMSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyMjIyMjIiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI1IiBz cmM9Imh0dHBzOi8vc3NsLmdzdGF0aWMuY29tL3VpL3YxL2ljb25zL21haWwvaW1hZ2VzL2NsZWFy ZG90LmdpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIFdlZCwgQXByIDQsIDIwMTggYXQgMTA6 NTcgQU0sIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmI9 NDBtaWNyb3NvZnQuLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiPTQw bWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7DQogd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIG5lZWQgdG8gd29ycnkgaXMgbm90IG9uIHRoZSBj bGllbnQgc2lkZSDigJMgYXQgbGVhc3Qgbm90IGltbWVkaWF0ZWx5LiA4MDIuMTFhZCwgODAyLjEx YXgsIGFuZCA1RyBMVEUgd2lsbCBicmluZw0KIEdpZ2FiaXQgcmF0ZXMgdG8gY2xpZW50IHNpZGUg c28gaXQgaXMgY2VydGFpbmx5IGdvaW5nIHRvIGJlY29tZSBhIHByb2JsZW0gbG9uZ2VyIHRlcm0u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGN1cnJlbnQgd29ycnkgaXMgb24gdGhlIHNlcnZl ciBzaWRlLiBBIGxhcmdlIHBhcnQgb2YgdGhlIHdvcmsgd2UgZG8gaXMgcGVyZm9ybWFuY2Ugb3B0 aW1pemF0aW9uIG9mIHRoZSBuZXR3b3JrDQogc3RhY2suIEdvb2dsZeKAmXMgU2lnY29tbSBRVUlD IHBhcGVyIHNob3dzIGEgMnggQ1BVIGluY3JlYXNlIGdvaW5nIGZyb20gVENQIHRvIFFVSUMuIE1v c3Qgd2ViIHNlcnZpY2VzIHdpbGwgTk9UIGJlIGFibGUgdG8gbWFrZSB0aGF0IHRyYWRlIG9mZiB0 byBnZXQgbGF0ZW5jeSBpbXByb3ZlbWVudHMgZm9yIDkwPHN1cD50aDwvc3VwPiBwZXJjZW50aWxl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklNTw0KPGk+aW1wcm92aW5nIFVEUCBwZXJmb3JtYW5j ZSBhbmQgaGFyZHdhcmUgb2ZmbG9hZHMgYXJlIGFic29sdXRlbHkgYSBuZWNlc3NpdHkgZm9yIFFV SUMgdG8gYmVjb21lIHdpZGVseSBhZG9wdGVkPC9pPiAobm90IGp1c3QgYnkgdGhlIGJpZ2dlc3Qm bmJzcDtjb3Jwb3JhdGlvbnMgd2l0aCBhIGxhcmdlIGJ1ZGdldCkuIFdlIGhhdmUgd29yayB1bmRl ciB3YXkgb24gYm90aCB0aGVzZSBmcm9udHMgYW5kIEkgYW0gdmVyeSBoYXBweSB0byBzZWUgTGlu dXggYWxzbw0KIGludmVzdGluZyBoZXJlIGluIHByZXBhcmF0aW9uIGZvciB3aGF04oCZcyBjb21p bmcuIFdlIG5lZWQgdG8gZG8gb3VyIGJlc3QgZGVtb2NyYXRpemUgdGhpcyB0ZWNobm9sb2d5IC0g bXVsdGlwbGUgaW1wbGVtZW50YXRpb25zIGFuZCBwZXJmb3JtYW5jZSB3aWxsIGJvdGggcGxheSBh IGJpZyByb2xlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+IFFVSUMgW21haWx0bzo8YSBocmVmPSJtYWls dG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZjwvYj4gUGhpbGxpcCBIYWxsYW0tQmFrZXI8YnI+ DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDE4IDk6MjkgQU08YnI+DQo8Yj5U bzo8L2I+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtr ZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5taWtrZWxmakBnbWFpbC5jb208L2E+Jmd0 Ozxicj4NCjxiPkNjOjwvYj4gU3Vib2RoIEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpzdWJv ZGhAZmIuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3Vib2RoQGZiLmNvbTwvYT4mZ3Q7OyBJRVRGIFFV SUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7OyBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0PTxhIGhyZWY9Im1h aWx0bzo0MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGdvb2ds ZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVURQ IHNlbmQgY29zdHMgaW4gTGludXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+SSB3b3VsZCBub3Qgd29ycnkgdG9vIG11Y2ggYXQgdGhpcyBwb2ludC48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHJlYXNv biB3ZSB3YW50IHRvIGJlIGFibGUgdG8gd29yayBhdCB0aGUgYXBwbGljYXRpb24gbGV2ZWwgaXMg YmFja3dhcmRzIGNvbXBhdGliaWxpdHkuIEl0IGhhcyB0byBiZSBwb3NzaWJsZQ0KIHRvIGRlcGxv eSBRVUlDIG9uIGFueSBtYWNoaW5lIGV2ZW4gd2l0aG91dCBPUyBzdXBwb3J0IG9yIGl0IHdvbid0 IGJlIGRlcGxveWFibGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPkl0IGRvZXMgbm90IGhhdmUgdG8gYmUgcGVyZm9ybWFudCBvbiBldmVyeSBwbGF0Zm9y bS4gSWYgcGVvcGxlIGFyZSB1c2luZyBRVUlDLCB3aGF0ZXZlciBuZWVkcyB0byBiZSBtb3ZlZCBp bnRvDQogdGhlIGtlcm5lbCBmb3IgcGVyZm9ybWFuY2UgcmVhc29ucyB3aWxsIG1vdmUgdGhlcmUu PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5PbiBXZWQsIEFwciA0LCAyMDE4IGF0IDExOjMyIEFNLCBNaWtr ZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9hPiZndDsNCiB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IGlkPSJtXzE0NTI3MDgyMTY4ODYzMjMzNDFtXzE2 NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaGF2ZSBubyBkYXRhIHRvIGFkZCBvbiB0aGUgTGludXgg VURQIHN0YWNrLCBidXQgYW5vdGhlciBpc3N1ZSBpcyB0aGUgbGFjayBvZiBuZXRtYXAgc3VwcG9y dCBpbiBjbG91ZCBob3N0aW5nDQogZW52aXJvbm1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0ibV8xNDUyNzA4MjE2ODg2MzIzMzQxbV8xNjUxNzQyODc5NTA1NTU1 NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5JIGhhdmUgbm90IHlldCBiZWVuIHdvcmtpbmcgd2l0aCB0aGlzLCBidXQgaGF2ZSBs b29rZWQgaW50byB0aGUgcHJvYmxlbSBhbmQgYXNrZWQgYXJvdW5kLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xNDUyNzA4MjE2ODg2MzIzMzQxbV8xNjUxNzQyODc5 NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9Im1fMTQ1MjcwODIxNjg4NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3Rv bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bmV0bWFw IGlzIGRlZmF1bHQgaW4gRnJlZUJTRCBhbmQgb3B0aW9uYWwgaW4gTGludXguIEJ1dCBuZWl0aGVy IHdvcmtzIGVmZmljaWVudGx5IHdpdGhvdXQgYSBoeXBlcnZpc29yIHBhdGNoIHRoYXQNCiBpcyBh bHNvIGF2YWlsYWJsZSBmb3IgbmV0bWFwLiBXaXRoIHN1cHBvcnQgZm9yIG5ldG1hcCwgdGhlIHVz ZXIgc3BhY2UgYXBwbGljYXRpb24gY2FuIHNlbmQgZGlyZWN0bHkgdG8gdGhlIG5ldHdvcmsgYWRh cHRlciB3aXRoIHZlcnkgbGl0dGxlIG92ZXJoZWFkLiBUaGVyZSBpcyBhbHNvIGRwZGsgYW5kIHNv bWUgb3RoZXIgaW50ZXJmYWNlcyB0aGF0IG1pZ2h0IGJlIHNsaWdodGx5IGZhc3RlciBidXQgbW9y ZSB2ZW5kb3Igc3BlY2lmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJtXzE0NTI3MDgyMTY4ODYzMjMzNDFtXzE2NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21m b250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xNDUyNzA4MjE2ODg2MzIz MzQxbV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Bc3N1bWluZyBhbiBhcHBsaWNhdGlvbiBoYXMg YWNjZXNzIHRvIG9wdGltaXplZCBuZXRtYXAsIHRoZSBvbmx5IGh1cmRsZSBpcyBhZGRyZXNzIGxv b2t1cCwgYnV0IGlmIHRoZSBhcHBsaWNhdGlvbg0KIGFsc28gbWFuYWdlcyB0aGF0LCBvciBhdCBs ZWFzdCBkb2VzIHRoZSBjYWNoaW5nLCB0aGVyZSBzaG91bGRu4oCZdCBiZSBtdWNoIGluIHRoZSB3 YXkgb2YgT1MgaW50ZXJmZXJlbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0ibV8xNDUyNzA4MjE2ODg2MzIzMzQxbV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3BfY3Vz dG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTQ1MjcwODIxNjg4 NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T2YgY291cnNlLCBuZXRtYXAgYmxvY2tz IHRoZSBlbnRpcmUgbmV0d29yayBzdGFjaywgc28gbm8gUElORyBvciBTU0guIENsb3VkRmxhcmUg YWRkZWQgYSBuZXRtYXAgcGF0Y2ggc28gb25seSBzb21lDQogdHJhZmZpYyB3b3VsZCBiZSByb3V0 ZWQgZnJhIHRoZSBuZXR3b3JrIGludGVyZmFjZSB0byBuZXRtYXAsIGFuZCBuZXRtYXAgYWxzbyBz dXBwb3J0cyBlZmZpY2llbnQgcGFja2V0IGZvcndhcmRpbmcgdG8gdGhlIE9TIG9yIG90aGVyIGFw cGxpY2F0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTQ1 MjcwODIxNjg4NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE0NTI3MDgyMTY4ODYzMjMzNDFtXzE2 NTE3NDI4Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk5vbmUgb2YgdGhpcyB3b3JrcyB3ZWxsIGluIGdlbmVyYWws IGJ1dCBmb3IgYSBjbG91ZCBob3N0IHRoYXQgY2FuIGJlIGJvb3RldCBhdXRvbWF0aWNhbGx5IGFu ZCBkZXN0cm95ZWQgcmF0aGVyDQogdGhhbiBzZXJ2aWNlZCwgdGhlcmUgaXMgc29tZSBvcHBvcnR1 bml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTQ1MjcwODIx Njg4NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE0NTI3MDgyMTY4ODYzMjMzNDFtXzE2NTE3NDI4 Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPmJ1dCBvbmx5IGlmIGNsb3VkIHNlcnZpY2UgcHJvdmlkZXJzIHN0YXJ0 cyBhZGRpbmcgc3VwcG9ydCB0aGVpciBzdXBwb3J0ZWQgaW1hZ2VzIGFuZCBoeXBlcnZpc29ycy4g Tm90IHN1cmUgaWYgYW55DQogYXJlIHdvcmtpbmcgb24gdGhpcyBub3cuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE0NTI3MDgyMTY4ODYzMjMzNDFtXzE2NTE3NDI4 Nzk1MDU1NTU0OTFibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izg4ODg4OCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTQ1MjcwODIx Njg4NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0ibV8xNDUyNzA4MjE2ODg2MzIzMzQxbV8xNjUxNzQyODc5NTA1NTU1NDkxYmxvb3Bf Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM4ODg4ODgiPk1pa2tlbDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Im1fMTQ1MjcwODIxNjg4 NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MWJsb29wX3NpZ25fMTUyMjg1NTQxODAwMDU0ODg2 NCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJtMTQ1MjcwODIxNjg4NjMyMzM0MW0xNjUxNzQyODc5NTA1NTU1NDkxYWlybWFp bG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gNCBBcHJpbCAyMDE4IGF0IDE1LjExLjE3LCBJYW4g U3dldHQgKDxhIGhyZWY9Im1haWx0bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5pYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi4ub3Jn PC9hPikNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaG9wZSBzb21l IG9mIHRoZXNlIHBhdGNoZXMgd2lsbCBiZSBhdmFpbGFibGUgc29vbiwgYnV0IEknbSBub3Qgc3Vy ZSBpZiBzb29uIGlzIGEgbW9udGggb3IgNi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+T24gVHVlLCBBcHIgMywgMjAxOCBhdCAxMDo1MCBQTSBTdWJvZGggSXll bmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1Ym9kaEBmYi5jb20iIHRhcmdldD0iX2JsYW5rIj5z dWJvZGhAZmIuY29tPC9hPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXYgaWQ9Im1fMTQ1MjcwODIxNjg4NjMyMzM0MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MW1f LTI1NDc3NDA2NzU1MjY2MzUyMGRpdnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPlRoYW5rcyBmb3Igc2hhcmluZyB0aGlzIElhbi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+VGhpcyBkZWZpbml0ZWx5IG1hdGNoZXMgc29tZSBvZiB0aGUgb2JzZXJ2YXRpb25zIHdlJ3Zl IHNlZW4gYXMgd2VsbCBpbiB0aGUgVURQIHdyaXRlIHBhdGguIFNvbWUgb2YgdGhlIG90aGVyIHBh dGhzIHRoYXQgd2Ugc2F3IHRoYXQgYWRkZWQNCiBvdmVyaGVhZCB3YXMgdGhlIHJvdXRlIHRhYmxl IGxvb2t1cCBpbiBsaW51eCB1ZHAgc3RhY2suIENvbm5lY3RlZCBVRFAgc29ja2V0cyBkaWQgYW1v cnRpemUgdGhhdC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSdtIGxvb2tpbmcgZm9yd2Fy ZCB0byBhIHNtYXJ0ZXIgc2VuZG1tc2cgd2l0aCBHU08gYW5kIHplcm8gY29weS4gSXMgdGhlcmUg YW55IGluZGljYXRpb24gb2YgdGhlIHRpbWVsaW5lIGZvciB0aGVzZSBwYXRjaGVzIHRvIG1ha2Ug aXQNCiB0byBsaW51eD8gV291bGQgYmUgaGFwcHkgdG8gdHJ5IGFueSBvZiB0aGVzZSBvdXQgdG8g aGVscCBpcm9uIG91dCB0aGUgQVBJLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TdWJvZGg8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj ZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4NCjxociBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGln bj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9Im1fMTQ1MjcwODIxNjg4NjMyMzM0 MW1fMTY1MTc0Mjg3OTUwNTU1NTQ5MW1fLTI1NDc3NDA2NzU1MjY2MzUyMGRpdlJwbHlGd2RNc2ci Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+UVVJQyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7IG9uIGJlaGFsZiBvZiBJYW4gU3dldHQgJmx0Ozwvc3Bhbj48 YSBocmVmPSJtYWlsdG86aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYuLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLi5vcmc8L2E+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFw cmlsIDMsIDIwMTggNToyMDowOCBQTTxicj4NCjxiPlRvOjwvYj4gSUVURiBRVUlDIFdHPGJyPg0K PGI+U3ViamVjdDo8L2I+IFVEUCBzZW5kIGNvc3RzIGluIExpbnV4PC9zcGFuPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbmUgY2hh bGxlbmdlIHdpdGggUVVJQyBhdCB0aGUgbW9tZW50IGlzIHRoZSBpbmNyZWFzZWQgQ1BVIGNvc3Qg b2Ygc2VuZGluZyBVRFAgcGFja2V0cyB2cyBUQ1AgcGF5bG9hZHMuJm5ic3A7IEkndmUgc2Vlbg0K IHRoaXMgYWNyb3NzIGV2ZXJ5IHBsYXRmb3JtIEdvb2dsZSBoYXMgZGVwbG95ZWQgUVVJQyBvbiwg c28gaXQncyBhIHdpZGVzcHJlYWQgaXNzdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPkhlcmUncyBhbiBleGNlbGxlbnQgcHJlc2VudGF0aW9uIG9uIHdoYXQn cyBjYXVzaW5nIHRoZSBpbmNyZWFzZWQgQ1BVIGNvbnN1bXB0aW9uIG9uIExpbnV4IGZyb20mbmJz cDtXaWxsZW0gZGUgQnJ1aWpuKFVEUA0KIHN0YXJ0cyBvbiBzbGlkZSA5KS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay4uY29tLz91cmw9aHR0cCUzQSUyRiUyRnZnZXIua2VybmVsLm9yZyUyRm5ldGNvbmYyMDE3 X2ZpbGVzJTJGcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBkZiZhbXA7ZGF0YT0wMiU3QzAxJTdD cHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDMTAzYTZlODFmMzY4NGM2NzM4MjYwOGQ1OWE0OTJjMmUl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM2NTg0NTYxNDQ5 ODcyOTM1JmFtcDtzZGF0YT1GUGUwbVM1YUclMkI4OCUyRlNYdklWU08zeVduWGg5dE9oUWZLa0g2 WG5RRHh2RSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly92Z2VyLmtl cm5lbC5vcmcvbmV0Y29uZjIwMTdfZmlsZXMvcnhfaGFyZGVuaW5nX2FuZF91ZHBfZ3NvLnBkZjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5B bmQgd2hpbGUgeW91J3JlIHRoaW5raW5nIG9mIENQVSB1c2FnZSwgaXQncyB3b3J0aCBsb29raW5n IGF0IHRoZSBwcmVzZW50YXRpb24gb24gdGltaW5nIHdoZWVsIGJhc2VkIHBhY2tldCBwYWNpbmco d2hpY2gNCiBpcyBtaW5pbXVtIHJlbGVhc2UgdGltZSBiYXNlZCkgYW5kIGlzIGlkZWFsIGZvciBR VUlDKGFuZCBUQ1AgZm9yIHRoYXQgbWF0dGVyKTombmJzcDs8YSBocmVmPSJodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnVybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20lMkZ2MiUyRnVybCUzRnUlM0RodHRwcy0zQV9fY29uZmVyZW5j ZXMuc2lnY29tbS5vcmdfc2lnY29tbV8yMDE3X2ZpbGVzX3Byb2dyYW1fdHMtMkQ5LTJENC0yRGNh cm91c2VsLnBkZiUyNmQlM0REd01GYVElMjZjJTNENVZEMFJUdE5sVGgzeWNkNDFiM01VdyUyNnIl M0RoM0p1OUVCUzdtSHR3Zy13QXlON2ZRJTI2bSUzRHRnZ2hndkZrcHM3allhRk5kTnlaQk5GZjBl cFZ4RlpiT0doaHliRndQaUUlMjZzJTNEODdnT0dmejNTMGxMYnc4anktbHozTTl2UEdDaGttZ3Rp SlZ6VXhiTWZ2WSUyNmUlM0QmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNv bSU3QzEwM2E2ZTgxZjM2ODRjNjczODI2MDhkNTlhNDkyYzJlJTdDNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjU4NDU2MTQ0OTg3MjkzNSZhbXA7c2RhdGE9aFNY WHZUT0R2bGpJNm5pQkxtTXhHVUZTOWclMkZxT2lIc2tVY05jZ0h0RTZrJTNEJmFtcDtyZXNlcnZl ZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jb25mZXJlbmNlcy5zaWdjb21tLm9yZy9zaWdj b21tLzIwMTcvZmlsZXMvcHJvZ3JhbS90cy05LTQtY2Fyb3VzZWwuLnBkZjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4tSWFuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB0630F5F8DD480E168A8F97CDB6A40CY4PR21MB0630namp_-- From nobody Wed Apr 4 11:48:33 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070E212D7E5 for ; Wed, 4 Apr 2018 11:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQHyTAXwY44J for ; Wed, 4 Apr 2018 11:48:30 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1840C12D775 for ; Wed, 4 Apr 2018 11:48:30 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id 132so23608164qkd.5 for ; Wed, 04 Apr 2018 11:48:30 -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:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=A/rmTh3NIyQpN55/OO4wnPI06HvPcEryBWWa9iB9BxI=; b=GyU4Y+oQiau/d/+8LtrEgxojDEgbxmMyCDkTXeK9salJpcozHMt1ct5vGPoER6Wuiu d9OdcAyJSLFbcDf9pmpPl0XFBfm95z5KP2ZyhTW+5eVQTbVV3EOGHf3lZd05p/qWs6hC DlRG1UjFn16kCNIzfvbrUxhQ3nIDpJvzYEJci8N6uSNBywMDbuuOQNBPnQho63Wcpj7J GFvzWv4ZJrlbwBR9xMIjITV7+yqsGNpkpu8wVO5koc110fktSaXXvF3Yg4CE1zI9eJtj 7v5qeLRzXy9ftz1ZfMkTu9wGvVj6Id5rUe0biuIqlZfFU74QIR0p+RsQTJeiebZ2Dvnk 7kqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=A/rmTh3NIyQpN55/OO4wnPI06HvPcEryBWWa9iB9BxI=; b=pDa1sbSquJ2oziVUiL+OzkYnbRuzJNqPs6aZnDJkE4YOMXsHBQzIrUOU8HyJ47UL1N wo3gb39GGrE58hx4mp9eUKXr29h5JeSoNvDCkKLHQQgreIRIe803RVLxZtlt/FPHzBz0 aYtM7li3Z2vZvwB6oVA6lkVi7Eo+N4ZfVqQ9XvhLNIpm54eUHdesG+idc7qrpoTPBtY6 wWAuIHT2ApUfWmnKqFrkKfgb6kUlUNJkqi95eBOW6iZtbk0/AF3W2CbGUcZoOQwGI0b8 7QnIAllFVzxmZkOh1dKDdLyEusFePxzoyTB2fwhgwTVYVtzswf9DnM4N1ZJzCqOv8Xlz PLxg== X-Gm-Message-State: ALQs6tBf3DSb5mMLeFXeKGnaYlnR9BV9fwd0+eDt1XIxPIsjPoMKQU/s s+krYE8d4tXr+Zw9vfqEsSf0FA== X-Google-Smtp-Source: AIpwx49Mt/wyahhIFomOVnJC54hbplGkUd/bJlDpG//wFznKnVBwzffNWLuWh6Ks5ooe0wWewfV57Q== X-Received: by 10.55.13.82 with SMTP id 79mr25391004qkn.280.1522867709205; Wed, 04 Apr 2018 11:48:29 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id n58sm4971695qta.34.2018.04.04.11.48.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 11:48:28 -0700 (PDT) Date: Wed, 4 Apr 2018 14:48:26 -0400 From: Dmitri Tikhonov To: Mike Bishop Cc: Mark Nottingham , IETF QUIC WG , Lars Eggert Subject: Re: Getting to consensus on packet number encryption Message-ID: <20180404184825.GB12306@ubuntu-dmitri> Mail-Followup-To: Mike Bishop , Mark Nottingham , IETF QUIC WG , Lars Eggert References: <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 18:48:32 -0000 On Wed, Apr 04, 2018 at 06:38:18PM +0000, Mike Bishop wrote: > When you get right down to it, I'm sympathetic to the cost argument, > but it doesn't outweigh the other two. A given server can (I > presume) sustain dramatically more Telnet connections than it can > SSH connections, but people who advocate continuing to use Telnet > for that reason are roundly ridiculed.. SSH has a different, better > security profile and those differences justify the cost. TCP versus > QUIC seems similar. We are comparing HTTPS with QUIC -- thus the telnet/SSH analogy is not applicable. - Dmitri. From nobody Wed Apr 4 11:51:41 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDA712D7E5 for ; Wed, 4 Apr 2018 11:51:30 -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 (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 dr_UT4Vs17yh for ; Wed, 4 Apr 2018 11:51:27 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0121.outbound.protection.outlook.com [104.47.42.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7C912D7EC for ; Wed, 4 Apr 2018 11:51: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=wXSAfRlOwjZdPg+kq46ZgXrmtQ6gEcR3aNQwBKohF0Q=; b=e8mP0QMLLCBOucwHFUXzDQTJoXHG2KC/1D41Z1SlNqK1oDUkBi+LVHPiYcv9zaxCKsSmLUXWjEcLxr+AiKl+d9pzSu6LJAkj2EpsOmdUgmIJba+idpLpYtcgi6QtgLxHA1gqP7YrQa5LT68vR5x54d4CUCEpY0/YDESu/KarQ8I= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0854.namprd21.prod.outlook.com (10.173.192.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 18:51:25 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 18:51:25 +0000 From: Praveen Balasubramanian To: Dmitri Tikhonov , Mike Bishop CC: Lars Eggert , Mark Nottingham , IETF QUIC WG Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPw8I8AgAAC1QCAAAAuoA== Date: Wed, 4 Apr 2018 18:51:25 +0000 Message-ID: References: <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <20180404184825.GB12306@ubuntu-dmitri> In-Reply-To: <20180404184825.GB12306@ubuntu-dmitri> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0854; 7:rLf8/DXb5tFITMUfXvcVwvOogpIY7rwmAKjj/VmKywipksRqXKznkg/WOhBTWWIPpS4k5qVcbYtcO7b33UoQqg0Ad7lH/qb1EHzqCpqM/MWyVY7wllEJxVrmgnekhoqBTPO7MNoukRoYCvx63k52j7sQa4JwWQQqnI5xH07wNjEUl98cN+zXBXv9Rgs5lIdSG9dKpyRCUee+CKFdxroPMhbjt7DYaw8TbfWgAPn3EarAauIBUC1iaJiqBoPtXo0N; 20:MmKc76WRA+F9NwbDOzkXdVoJYr9aGphC9UiPlWJwu7aFUh6XGdRzV+oyzdy23GvKNMK7A+Wxk1MY1okH9TqxmETuAuCbjzeFaRYP7Qrtnwp+ERod8ylHdBBLfAZBmUNQe61luvntoOfBxK0xPmp8xTZqF40FuQpQXtY6xAQBhK4= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 3b4f2b3d-b523-4adf-faed-08d59a5d113b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0854; x-ms-traffictypediagnostic: CY4PR21MB0854: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(209352067349851)(192374486261705)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0854; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0854; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39380400002)(39860400002)(366004)(396003)(346002)(13464003)(199004)(189003)(6436002)(106356001)(46003)(5250100002)(54906003)(97736004)(11346002)(3280700002)(446003)(22452003)(93886005)(110136005)(10090500001)(486006)(476003)(53546011)(5660300001)(102836004)(86362001)(59450400001)(55016002)(3660700001)(9686003)(2906002)(6506007)(81166006)(81156014)(2900100001)(8936002)(53936002)(33656002)(74316002)(105586002)(99286004)(68736007)(10290500003)(4326008)(305945005)(14454004)(76176011)(478600001)(229853002)(7736002)(186003)(8676002)(6246003)(316002)(6116002)(86612001)(7696005)(8990500004)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0854; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: X5z3QBaVFW692ncD3ThbWPKJmhG5fd1VgoAMFbpbP1EQoe/G4XdsnvETa45vWkmAWwPWwNAoxfz07Ic864k83XNHU0YPGhgmWAJbBKiOSSR9GUnRT86CwvBoJD8GBOSG7bh3RctCvgJmExlS3RjcQkQUXn1fD7jWtJ3FsbWyPXAAV4m/x7oi/jthYlx9u+4k/GdOTe65r4bLOfyf/oZTFQYO1ZDUvbqdcrIemlfVz7ZAF0+M2ldny7YhkvuP8FC7QoHG/TVSsWjyT3OFiwTVDmL7sU2L1VzIF0ka4bdt0dT3FfDTJSNu1pXh9vmkhZuyF/oJTgzV32jEciuPYOFk7Is5qdKDSV93emgHGCFtv73MxKTP9M8n2H5+w/a09dM80MsRJQU6ZhrZsXS9KouWJ8L6CtQA9TEFX9ttgEd1Z68= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3b4f2b3d-b523-4adf-faed-08d59a5d113b X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 18:51:25.3371 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0854 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 18:51:31 -0000 You are also ignoring all bulk transfer applications over WAN and in DC whe= re the CPU costs will magnify much more compared to online streaming web vi= deo and web search. I suspect the cost will be more like 3-4x. From service= deployment point of view its still HTTP with TLS, just changing a transpor= t underneath shouldn't require throwing 3x more servers. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Dmitri Tikhonov Sent: Wednesday, April 4, 2018 11:48 AM To: Mike Bishop Cc: Lars Eggert ; Mark Nottingham ; IETF QU= IC WG Subject: Re: Getting to consensus on packet number encryption On Wed, Apr 04, 2018 at 06:38:18PM +0000, Mike Bishop wrote: > When you get right down to it, I'm sympathetic to the cost argument,=20 > but it doesn't outweigh the other two. A given server can (I > presume) sustain dramatically more Telnet connections than it can SSH=20 > connections, but people who advocate continuing to use Telnet for that=20 > reason are roundly ridiculed.. SSH has a different, better security=20 > profile and those differences justify the cost. TCP versus QUIC seems=20 > similar. We are comparing HTTPS with QUIC -- thus the telnet/SSH analogy is not appl= icable. - Dmitri. From nobody Wed Apr 4 12:01:19 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E5512D80E for ; Wed, 4 Apr 2018 12:01:18 -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 qyXVe9KJKthr for ; Wed, 4 Apr 2018 12:01:16 -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 7167312E8C3 for ; Wed, 4 Apr 2018 12:00:46 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id r19-v6so29569753itc.0 for ; Wed, 04 Apr 2018 12:00: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=b44Ojr8N8IcSkyoVW3YgZGiEkVyhV4Q6BFRFBM3VT5c=; b=fMV0SEWGmMiyWDfpBhIDjdDAEYctthJDRIcFYZDwVjCeTioN5eJDhmWWAT4GYzbaRu LvAAMGIka47zeJbOTgtn+tgsafmVgJ9eTEvrsD66Uvd7rDFv7sA07QDxoFHOIelexqVJ in+LVpgjwp/LmOJc0HuIYrShSM0e5blUAjKdmb8IOLOtIiCLeED2uc+PITpnx1fUY1mM nDM6Qds8SJN7E+Il6wzn831AlARe+/y7QJl0mH/yzGpC0IY4/FRnU4MmQoPsbU9IAYTE nvpup7RJ+RHlZSSe6E++qt1ld01BWMlQk8PMjsWUd7JR7H1EHRejFJU2fJL8rklFh82z 8UIQ== 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=b44Ojr8N8IcSkyoVW3YgZGiEkVyhV4Q6BFRFBM3VT5c=; b=nYI8z9AAe2altVVLgRnKbjVauQj+N5wYyHhYBVSrnHeOQq8dwb9zsyH+PUAitTVJvm PPRPzXOBf7tVyBJGtr00BMEr1n4o4XNO3t7+e84B9ay2rwJWIzN23o5weJrcwkFlpvCY utCqwSsVek5wYzUehhqZVx9KbEzOqEW22PBcdj5hctKyFauSCsdP5+EHwy2YcTd4peft 9ePdzZU5ArpIPuY44w0NeTbIXr26wANFo6n9Q5PY7jf4xp9uyZZPEmzGxxqkRJKzGDJY /TsDXqsHNG3mdzklcYasfNAt0irunfwO4hcx8yVwFz60F3S+LxRQkhGjAnFY98aXI3ce FaVw== X-Gm-Message-State: ALQs6tD3IQVaLLFz+ig3u/G+UHXh1LWw/xiCNEuby+TVR9sL8Y+i4yF6 kr4/1uHuFZ2/OAtvktVRctCvv6hEBJ/V4Po2UMU= X-Google-Smtp-Source: AIpwx4+TJxDjdEXo3W0UVLdgsd4MimBemUD5StDLP6dG7phUuhwvm9RrobDUd/JExCrUlHDw21vEUmhakBpKhMWn9Wg= X-Received: by 2002:a24:7088:: with SMTP id f130-v6mr10601232itc.39.1522868444984; Wed, 04 Apr 2018 12:00:44 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Apr 2018 21:00:44 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <20180404184825.GB12306@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 4 Apr 2018 21:00:44 +0200 Message-ID: Subject: RE: Getting to consensus on packet number encryption To: Praveen Balasubramanian , Mike Bishop , Dmitri Tikhonov Cc: Lars Eggert , IETF QUIC WG , Mark Nottingham Content-Type: multipart/alternative; boundary="000000000000b3fe7605690a702f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 19:01:18 -0000 --000000000000b3fe7605690a702f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mike, on your 3 options list you are missing 4) multiple PN spaces (what I call segmented packet numbers), ie. a serial PN per CID and a unique CID per path. We keep assuming this is very difficult and only a v2 thing. But I think it is not very difficult to do and it would solve nearly all the issues except ossification on a single path. And if that is a problem (which I don=E2=80=99t think), it would be good to know before v2 where it = really becomes important. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 4 April 2018 at 20.51.41, Praveen Balasubramanian ( pravb=3D40microsoft.com@dmarc.ietf.org) wrote: You are also ignoring all bulk transfer applications over WAN and in DC where the CPU costs will magnify much more compared to online streaming web video and web search. I suspect the cost will be more like 3-4x. From service deployment point of view its still HTTP with TLS, just changing a transport underneath shouldn't require throwing 3x more servers. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Dmitri Tikhonov Sent: Wednesday, April 4, 2018 11:48 AM To: Mike Bishop Cc: Lars Eggert ; Mark Nottingham ; IETF QUIC WG Subject: Re: Getting to consensus on packet number encryption On Wed, Apr 04, 2018 at 06:38:18PM +0000, Mike Bishop wrote: > When you get right down to it, I'm sympathetic to the cost argument, > but it doesn't outweigh the other two. A given server can (I > presume) sustain dramatically more Telnet connections than it can SSH > connections, but people who advocate continuing to use Telnet for that > reason are roundly ridiculed.. SSH has a different, better security > profile and those differences justify the cost. TCP versus QUIC seems > similar. We are comparing HTTPS with QUIC -- thus the telnet/SSH analogy is not applicable. - Dmitri. --000000000000b3fe7605690a702f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Mike,

on your 3 options list you are mi= ssing 4) multiple PN spaces (what I call segmented packet numbers), ie. a s= erial PN per CID and a unique CID per path. We keep assuming this is very d= ifficult and only a v2 thing.
But I think it is not very difficult to do and it would so= lve nearly all the issues except ossification on a single path. And if that= is a problem (which I don=E2=80=99t think), it would be good to know befor= e v2 where it really becomes important.


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


=

On 4 April 2018 at 20.51.41, Praveen Balasubramania= n (pravb=3D40micr= osoft.com@dmarc.ietf.org) wrote:

You are also ignoring all bulk transf= er applications over WAN and in DC where the CPU costs will magnify much mo= re compared to online streaming web video and web search. I suspect the cos= t will be more like 3-4x. From service deployment point of view its still H= TTP with TLS, just changing a transport underneath shouldn't require th= rowing 3x more servers.

-----Original Message-----
From: QUIC [mailto:quic-bounce= s@ietf.org] On Behalf Of Dmitri Tikhonov
Sent: Wednesday, April 4, 2018 11:48 AM
To: Mike Bishop <mbishop@eve= quefou.be>
Cc: Lars Eggert <lars@eggert.org<= /a>>; Mark Nottingham <mnot@mnot.net= >; IETF QUIC WG <quic@ietf.org>
Subject: Re: Getting to consensus on packet number encryption

On Wed, Apr 04, 2018 at 06:38:18PM +0000, Mike Bishop wrote:
> When you get right down to it, I'm sympathetic to the cost arg= ument, =20
> but it doesn't outweigh the other two. A given server can (I
> presume) sustain dramatically more Telnet connections than it can = SSH =20
> connections, but people who advocate continuing to use Telnet for = that =20
> reason are roundly ridiculed.. SSH has a different, better securi= ty =20
> profile and those differences justify the cost. TCP versus QUIC s= eems =20
> similar.

We are comparing HTTPS with QUIC -- thus the telnet/SSH analogy is not = applicable.

- Dmitri.

--000000000000b3fe7605690a702f-- From nobody Wed Apr 4 12:01:33 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBBC12DA73 for ; Wed, 4 Apr 2018 12:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522868479; bh=WfHoEkDM+ZWZMNCle2Ue3ft3qWZOusIkQLquRotC27A=; h=From:In-Reply-To:References:Date:Subject:Cc:To:To:To; b=p0oxg2xacYKMS6DREdBBKha1J61vOpjCQ0k2epZT3VXeRP2akYolQsxocRcQTlbee ie9sZl2f6Gnx21n51QQXkZJQZYYd3lMgWnuoYej3iCUgzECwn8PR6gX2xXhT3ByiZi RdVMmzFJ8PYVAauU1FL1Zot7Jw2XZjshosE/9Pms= X-Mailbox-Line: From mikkelfj@gmail.com Wed Apr 4 12:01:19 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA4412DA6B; Wed, 4 Apr 2018 12:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522868479; bh=WfHoEkDM+ZWZMNCle2Ue3ft3qWZOusIkQLquRotC27A=; h=From:In-Reply-To:References:Date:Subject:Cc:To:To:To; b=p0oxg2xacYKMS6DREdBBKha1J61vOpjCQ0k2epZT3VXeRP2akYolQsxocRcQTlbee ie9sZl2f6Gnx21n51QQXkZJQZYYd3lMgWnuoYej3iCUgzECwn8PR6gX2xXhT3ByiZi RdVMmzFJ8PYVAauU1FL1Zot7Jw2XZjshosE/9Pms= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B9012D80E for ; Wed, 4 Apr 2018 12:01:18 -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=unavailable 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 GEFlzDOhFqhR for ; Wed, 4 Apr 2018 12:01:17 -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 9736312EAA3 for ; Wed, 4 Apr 2018 12:00:46 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id 142-v6so29518913itl.5 for ; Wed, 04 Apr 2018 12:00: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=b44Ojr8N8IcSkyoVW3YgZGiEkVyhV4Q6BFRFBM3VT5c=; b=fMV0SEWGmMiyWDfpBhIDjdDAEYctthJDRIcFYZDwVjCeTioN5eJDhmWWAT4GYzbaRu LvAAMGIka47zeJbOTgtn+tgsafmVgJ9eTEvrsD66Uvd7rDFv7sA07QDxoFHOIelexqVJ in+LVpgjwp/LmOJc0HuIYrShSM0e5blUAjKdmb8IOLOtIiCLeED2uc+PITpnx1fUY1mM nDM6Qds8SJN7E+Il6wzn831AlARe+/y7QJl0mH/yzGpC0IY4/FRnU4MmQoPsbU9IAYTE nvpup7RJ+RHlZSSe6E++qt1ld01BWMlQk8PMjsWUd7JR7H1EHRejFJU2fJL8rklFh82z 8UIQ== 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=b44Ojr8N8IcSkyoVW3YgZGiEkVyhV4Q6BFRFBM3VT5c=; b=t5Le8fkcTnDYeymkR+9uDcXsU8R5eMR0MgMdlkhqpAKKkdw5AF3zZGiHh7sIYZgCTI TwLfvjgfaB9d+rhWqwdDmDXq74JDG7RsuvgN2CzXC0IGv1e0zo1bmnnA1gwNL3OX4va2 jLqvyA5GWKJfBpN55/G2+smBHPWltp1WZ6gQrZUtUzZW4oHT/n/KwvTOOZVONOoz+0Xh OsGi9icyg0z1GiMOg/N5MZFgwG/cQFeC6OyjsxOmw9SMNdEdFZIZEP58CBLw43oMpjKQ pGh8KJbdvXWJoRm80b+np9v1aenetpifPCD3Ks+YrQlWr8EXOzA63YdEDvzHQvcTXzXS VpRg== X-Gm-Message-State: ALQs6tBxuKVzOq8v9lkBgPr5sq5TRIxPMJS3f5R/gj2Pt4PFdg39oPjR 5oHtwSBqbMOlEh+FoTCRvBeRrsCRfK0HnXtMoGKINBmZ X-Google-Smtp-Source: AIpwx4+TJxDjdEXo3W0UVLdgsd4MimBemUD5StDLP6dG7phUuhwvm9RrobDUd/JExCrUlHDw21vEUmhakBpKhMWn9Wg= X-Received: by 2002:a24:7088:: with SMTP id f130-v6mr10601232itc.39.1522868444984; Wed, 04 Apr 2018 12:00:44 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Apr 2018 21:00:44 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <20180404184825.GB12306@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 4 Apr 2018 21:00:44 +0200 Message-ID: Subject: RE: Getting to consensus on packet number encryption Cc: Lars Eggert , IETF QUIC WG , Mark Nottingham Content-Type: multipart/alternative; boundary="000000000000b3fe7605690a702f" To: Praveen Balasubramanian To: Mike Bishop To: Dmitri Tikhonov Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 19:01:19 -0000 --000000000000b3fe7605690a702f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mike, on your 3 options list you are missing 4) multiple PN spaces (what I call segmented packet numbers), ie. a serial PN per CID and a unique CID per path. We keep assuming this is very difficult and only a v2 thing. But I think it is not very difficult to do and it would solve nearly all the issues except ossification on a single path. And if that is a problem (which I don=E2=80=99t think), it would be good to know before v2 where it = really becomes important. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 4 April 2018 at 20.51.41, Praveen Balasubramanian ( pravb=3D40microsoft.com@dmarc.ietf.org) wrote: You are also ignoring all bulk transfer applications over WAN and in DC where the CPU costs will magnify much more compared to online streaming web video and web search. I suspect the cost will be more like 3-4x. From service deployment point of view its still HTTP with TLS, just changing a transport underneath shouldn't require throwing 3x more servers. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Dmitri Tikhonov Sent: Wednesday, April 4, 2018 11:48 AM To: Mike Bishop Cc: Lars Eggert ; Mark Nottingham ; IETF QUIC WG Subject: Re: Getting to consensus on packet number encryption On Wed, Apr 04, 2018 at 06:38:18PM +0000, Mike Bishop wrote: > When you get right down to it, I'm sympathetic to the cost argument, > but it doesn't outweigh the other two. A given server can (I > presume) sustain dramatically more Telnet connections than it can SSH > connections, but people who advocate continuing to use Telnet for that > reason are roundly ridiculed.. SSH has a different, better security > profile and those differences justify the cost. TCP versus QUIC seems > similar. We are comparing HTTPS with QUIC -- thus the telnet/SSH analogy is not applicable. - Dmitri. --000000000000b3fe7605690a702f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Mike,



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


=

On 4 April 2018 at 20.51.41, Praveen Balasubramania= n (pravb=3D40micr= osoft.com@dmarc.ietf.org) wrote:

You are also ignoring all bulk transf= er applications over WAN and in DC where the CPU costs will magnify much mo= re compared to online streaming web video and web search. I suspect the cos= t will be more like 3-4x. From service deployment point of view its still H= TTP with TLS, just changing a transport underneath shouldn't require th= rowing 3x more servers.

-----Original Message-----
From: QUIC [mailto:quic-bounce= s@ietf.org] On Behalf Of Dmitri Tikhonov
Sent: Wednesday, April 4, 2018 11:48 AM
To: Mike Bishop <mbishop@eve= quefou.be>
Cc: Lars Eggert <lars@eggert.org<= /a>>; Mark Nottingham <mnot@mnot.net= >; IETF QUIC WG <quic@ietf.org>
Subject: Re: Getting to consensus on packet number encryption

On Wed, Apr 04, 2018 at 06:38:18PM +0000, Mike Bishop wrote:
> When you get right down to it, I'm sympathetic to the cost arg= ument, =20
> but it doesn't outweigh the other two. A given server can (I
> presume) sustain dramatically more Telnet connections than it can = SSH =20
> connections, but people who advocate continuing to use Telnet for = that =20
> reason are roundly ridiculed.. SSH has a different, better securi= ty =20
> profile and those differences justify the cost. TCP versus QUIC s= eems =20
> similar.

We are comparing HTTPS with QUIC -- thus the telnet/SSH analogy is not = applicable.

- Dmitri.

--000000000000b3fe7605690a702f-- From nobody Wed Apr 4 12:15:03 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8F412DA6C for ; Wed, 4 Apr 2018 12:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 MDROnSvTNvHy for ; Wed, 4 Apr 2018 12:14:58 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0098.outbound.protection.outlook.com [104.47.36.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F5F12DA6B for ; Wed, 4 Apr 2018 12:14:58 -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=oEiINeF3GBDH3M3moxEGv/irIqVW49KWS6YNxL7qIds=; b=gaLY/Ur4geMhkgTPfVlMYRGayDMIzs+rbIwWlHRRkKw04VKbg5zEKUpe+MrsWI4571wJIovTGI2z05/UutpI27T12IyY/ClPWLnJy77naTlFJ2yRH/j2+tscN8lbTRUGuwngq50K6hclOEgp8Y1wHqv4aYFbQDtUjI/c9TT8UfA= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0280.namprd21.prod.outlook.com (10.173.193.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 19:14:55 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 19:14:55 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Praveen Balasubramanian , Mike Bishop , Dmitri Tikhonov CC: Lars Eggert , Mark Nottingham , IETF QUIC WG Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPw8I8AgAAC1QCAAAAuoIAAA0IAgAAD8YA= Date: Wed, 4 Apr 2018 19:14:55 +0000 Message-ID: References: <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <20180404184825.GB12306@ubuntu-dmitri> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0280; 7:gES9pWHHoEs5N1jIJZzrtZ+qFr/FB4ne38boXFKROqoj0PYLzweXYj1nu16TRnJnvn1ciTURnICbFRoFH+plVb0TzFZoIy7W2yLuksD8Q/qPCVUMy4PBIQrQjn2pa75o9CEU1Nkj23d44VDUWU8+63jLRycTnQZmujCXTU51BL1kFufMIAJxdYziMy9M9eXOTmCpck0XRD47CrumpEc6MoGHo1FDVmcp9iXahQleFrrYLONszThv3ybB+ibytYgD; 20:xNvh0qBg+KDq/Ekhv2algSZIxG4ju3zb+yq5+HFgYl8Foc/qsPQpePy+xFetJYNDRTivzrknx1w3YOMowj8Pxi2N4b6tefRztqGA0EpvwSiNirN+iARKaDcNJ5dWhk9jwtz6Fvg7/+KWzb+erGXbQeC+DoXdQlMlsYtCtzWRAU8= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 21cc0191-da64-4f62-0b7e-08d59a6059f9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0280; x-ms-traffictypediagnostic: CY4PR21MB0280: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(278428928389397)(209352067349851)(192374486261705)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(10201501046)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0280; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0280; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(346002)(376002)(366004)(39860400002)(13464003)(189003)(199004)(55016002)(9686003)(6306002)(14454004)(54896002)(6436002)(5250100002)(81166006)(81156014)(8936002)(8676002)(68736007)(106356001)(105586002)(74316002)(790700001)(110136005)(5660300001)(316002)(33656002)(22452003)(7736002)(236005)(93886005)(76176011)(6506007)(102836004)(53546011)(59450400001)(486006)(6116002)(7696005)(229853002)(54906003)(97736004)(186003)(46003)(99286004)(446003)(11346002)(476003)(39060400002)(2900100001)(53936002)(6246003)(478600001)(10290500003)(3280700002)(3660700001)(10090500001)(8990500004)(4326008)(2906002)(86612001)(86362001)(19609705001)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0280; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: FIPz0IT+OGJd8tpRR5CO8SRxAsCv+K60Ojy1GV+rhLtNAeagjtZceJzW1j1fvZNZlRvCxlEk6CxWw+ka38u+KNSedIZzPuOTAf9lpJ5iUuVsk0O4PTu3x0ZkusDBcgFo4qTPGm86iaLNpb131vujbYaTTICkLxyXBhFJC/vhoYOlJipkOo2ohXUQTYcLWfjSpLX/NrwNmZ48ejFFwl6geYKO1dxohNnVf+R5wbwUZ9LUU+3DdUxXa0kuklw5erJzrVVf9K2IzhcUCl8P+D8SKW2Hvfmull1JqDbMYODOjnLmOjBTXVAX2XuDU8loB5aujyO0qmmbu5m6anMgL/+ll1AO5/Znk5iCNtUyi/GPFX896oRptRqtS6CtnEWGElT4jlfuQDG+Iu7GsxtGQlyJwh1hsufCe4izggz/ewwHeYo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB06308060E05E23CD91AB521AB6A40CY4PR21MB0630namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21cc0191-da64-4f62-0b7e-08d59a6059f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 19:14:55.8523 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0280 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 19:15:01 -0000 --_000_CY4PR21MB06308060E05E23CD91AB521AB6A40CY4PR21MB0630namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgNCwg MjAxOCAxMjowMSBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jv c29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+OyBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3Uu YmU+OyBEbWl0cmkgVGlraG9ub3YgPGR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbT4NCkNjOiBM YXJzIEVnZ2VydCA8bGFyc0BlZ2dlcnQub3JnPjsgTWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3Qu bmV0PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUkU6IEdldHRpbmcg dG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpNaWtlLA0KDQpvbiB5 b3VyIDMgb3B0aW9ucyBsaXN0IHlvdSBhcmUgbWlzc2luZyA0KSBtdWx0aXBsZSBQTiBzcGFjZXMg KHdoYXQgSSBjYWxsIHNlZ21lbnRlZCBwYWNrZXQgbnVtYmVycyksIGllLiBhIHNlcmlhbCBQTiBw ZXIgQ0lEIGFuZCBhIHVuaXF1ZSBDSUQgcGVyIHBhdGguIFdlIGtlZXAgYXNzdW1pbmcgdGhpcyBp cyB2ZXJ5IGRpZmZpY3VsdCBhbmQgb25seSBhIHYyIHRoaW5nLg0KQnV0IEkgdGhpbmsgaXQgaXMg bm90IHZlcnkgZGlmZmljdWx0IHRvIGRvIGFuZCBpdCB3b3VsZCBzb2x2ZSBuZWFybHkgYWxsIHRo ZSBpc3N1ZXMgZXhjZXB0IG9zc2lmaWNhdGlvbiBvbiBhIHNpbmdsZSBwYXRoLiBBbmQgaWYgdGhh dCBpcyBhIHByb2JsZW0gKHdoaWNoIEkgZG9u4oCZdCB0aGluayksIGl0IHdvdWxkIGJlIGdvb2Qg dG8ga25vdyBiZWZvcmUgdjIgd2hlcmUgaXQgcmVhbGx5IGJlY29tZXMgaW1wb3J0YW50Lg0KDQoN CktpbmQgUmVnYXJkcywNCk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCg0KDQpPbiA0IEFwcmls IDIwMTggYXQgMjAuNTEuNDEsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIChwcmF2Yj00MG1pY3Jv c29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFy Yy5pZXRmLm9yZz4pIHdyb3RlOg0KWW91IGFyZSBhbHNvIGlnbm9yaW5nIGFsbCBidWxrIHRyYW5z ZmVyIGFwcGxpY2F0aW9ucyBvdmVyIFdBTiBhbmQgaW4gREMgd2hlcmUgdGhlIENQVSBjb3N0cyB3 aWxsIG1hZ25pZnkgbXVjaCBtb3JlIGNvbXBhcmVkIHRvIG9ubGluZSBzdHJlYW1pbmcgd2ViIHZp ZGVvIGFuZCB3ZWIgc2VhcmNoLiBJIHN1c3BlY3QgdGhlIGNvc3Qgd2lsbCBiZSBtb3JlIGxpa2Ug My00eC4gRnJvbSBzZXJ2aWNlIGRlcGxveW1lbnQgcG9pbnQgb2YgdmlldyBpdHMgc3RpbGwgSFRU UCB3aXRoIFRMUywganVzdCBjaGFuZ2luZyBhIHRyYW5zcG9ydCB1bmRlcm5lYXRoIHNob3VsZG4n dCByZXF1aXJlIHRocm93aW5nIDN4IG1vcmUgc2VydmVycy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBEbWl0cmkgVGlraG9ub3YNClNl bnQ6IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxOCAxMTo0OCBBTQ0KVG86IE1pa2UgQmlzaG9wIDxt YmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+Pg0KQ2M6IExh cnMgRWdnZXJ0IDxsYXJzQGVnZ2VydC5vcmc8bWFpbHRvOmxhcnNAZWdnZXJ0Lm9yZz4+OyBNYXJr IE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ8bWFpbHRvOm1ub3RAbW5vdC5uZXQ+PjsgSUVURiBR VUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJl OiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KT24g V2VkLCBBcHIgMDQsIDIwMTggYXQgMDY6Mzg6MThQTSArMDAwMCwgTWlrZSBCaXNob3Agd3JvdGU6 DQo+IFdoZW4geW91IGdldCByaWdodCBkb3duIHRvIGl0LCBJJ20gc3ltcGF0aGV0aWMgdG8gdGhl IGNvc3QgYXJndW1lbnQsDQo+IGJ1dCBpdCBkb2Vzbid0IG91dHdlaWdoIHRoZSBvdGhlciB0d28u IEEgZ2l2ZW4gc2VydmVyIGNhbiAoSQ0KPiBwcmVzdW1lKSBzdXN0YWluIGRyYW1hdGljYWxseSBt b3JlIFRlbG5ldCBjb25uZWN0aW9ucyB0aGFuIGl0IGNhbiBTU0gNCj4gY29ubmVjdGlvbnMsIGJ1 dCBwZW9wbGUgd2hvIGFkdm9jYXRlIGNvbnRpbnVpbmcgdG8gdXNlIFRlbG5ldCBmb3IgdGhhdA0K PiByZWFzb24gYXJlIHJvdW5kbHkgcmlkaWN1bGVkLi4gU1NIIGhhcyBhIGRpZmZlcmVudCwgYmV0 dGVyIHNlY3VyaXR5DQo+IHByb2ZpbGUgYW5kIHRob3NlIGRpZmZlcmVuY2VzIGp1c3RpZnkgdGhl IGNvc3QuIFRDUCB2ZXJzdXMgUVVJQyBzZWVtcw0KPiBzaW1pbGFyLg0KDQpXZSBhcmUgY29tcGFy aW5nIEhUVFBTIHdpdGggUVVJQyAtLSB0aHVzIHRoZSB0ZWxuZXQvU1NIIGFuYWxvZ3kgaXMgbm90 IGFwcGxpY2FibGUuDQoNCi0gRG1pdHJpLg0K --_000_CY4PR21MB06308060E05E23CD91AB521AB6A40CY4PR21MB0630namp_ 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 Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7 MTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9u IEJlaGFsZiBPZg0KPC9iPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDE4IDEyOjAxIFBNPGJyPg0KPGI+VG86PC9iPiBQcmF2 ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu b3JnJmd0OzsgTWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJlJmd0OzsgRG1pdHJp IFRpa2hvbm92ICZsdDtkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBMYXJzIEVnZ2VydCAmbHQ7bGFyc0BlZ2dlcnQub3JnJmd0OzsgTWFyayBOb3R0aW5naGFt ICZsdDttbm90QG1ub3QubmV0Jmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogR2V0dGluZyB0byBjb25zZW5zdXMgb24gcGFja2V0 IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJibG9vcF9jdXN0 b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtlLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5vbiB5b3VyIDMgb3B0aW9ucyBsaXN0 IHlvdSBhcmUgbWlzc2luZyA0KSBtdWx0aXBsZSBQTiBzcGFjZXMgKHdoYXQgSSBjYWxsIHNlZ21l bnRlZCBwYWNrZXQgbnVtYmVycyksIGllLiBhIHNlcmlhbCBQTiBwZXIgQ0lEIGFuZCBhIHVuaXF1 ZSBDSUQgcGVyIHBhdGguIFdlIGtlZXAgYXNzdW1pbmcgdGhpcw0KIGlzIHZlcnkgZGlmZmljdWx0 IGFuZCBvbmx5IGEgdjIgdGhpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5CdXQgSSB0aGluayBpdCBpcyBub3QgdmVyeSBkaWZmaWN1bHQgdG8gZG8gYW5kIGl0 IHdvdWxkIHNvbHZlIG5lYXJseSBhbGwgdGhlIGlzc3VlcyBleGNlcHQgb3NzaWZpY2F0aW9uIG9u IGEgc2luZ2xlIHBhdGguIEFuZCBpZiB0aGF0IGlzIGEgcHJvYmxlbSAod2hpY2ggSSBkb27igJl0 IHRoaW5rKSwNCiBpdCB3b3VsZCBiZSBnb29kIHRvIGtub3cgYmVmb3JlIHYyIHdoZXJlIGl0IHJl YWxseSBiZWNvbWVzIGltcG9ydGFudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgaWQ9ImJsb29wX3NpZ25fMTUyMjg2ODI1OTI4OTM0NzA3MiI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWwgRmFobsO4 ZSBKw7hyZ2Vuc2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gNCBBcHJp bCAyMDE4IGF0IDIwLjUxLjQxLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAoPGEgaHJlZj0ibWFp bHRvOnByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyI+cHJhdmI9NDBtaWNyb3Nv ZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPikgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPllvdSBhcmUgYWxzbyBpZ25vcmluZyBhbGwgYnVs ayB0cmFuc2ZlciBhcHBsaWNhdGlvbnMgb3ZlciBXQU4gYW5kIGluIERDIHdoZXJlIHRoZSBDUFUg Y29zdHMgd2lsbCBtYWduaWZ5IG11Y2ggbW9yZSBjb21wYXJlZCB0byBvbmxpbmUgc3RyZWFtaW5n DQogd2ViIHZpZGVvIGFuZCB3ZWIgc2VhcmNoLiBJIHN1c3BlY3QgdGhlIGNvc3Qgd2lsbCBiZSBt b3JlIGxpa2UgMy00eC4gRnJvbSBzZXJ2aWNlIGRlcGxveW1lbnQgcG9pbnQgb2YgdmlldyBpdHMg c3RpbGwgSFRUUCB3aXRoIFRMUywganVzdCBjaGFuZ2luZyBhIHRyYW5zcG9ydCB1bmRlcm5lYXRo IHNob3VsZG4ndCByZXF1aXJlIHRocm93aW5nIDN4IG1vcmUgc2VydmVycy4NCjxicj4NCjxicj4N Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIDxicj4NCkZyb206IFFVSUMgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSBPbiBCZWhhbGYgT2YgRG1pdHJpIFRpa2hvbm92DQo8YnI+DQpTZW50OiBXZWRuZXNkYXks IEFwcmlsIDQsIDIwMTggMTE6NDggQU0gPGJyPg0KVG86IE1pa2UgQmlzaG9wICZsdDs8YSBocmVm PSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPiZn dDsgPGJyPg0KQ2M6IExhcnMgRWdnZXJ0ICZsdDs8YSBocmVmPSJtYWlsdG86bGFyc0BlZ2dlcnQu b3JnIj5sYXJzQGVnZ2VydC5vcmc8L2E+Jmd0OzsgTWFyayBOb3R0aW5naGFtICZsdDs8YSBocmVm PSJtYWlsdG86bW5vdEBtbm90Lm5ldCI+bW5vdEBtbm90Lm5ldDwvYT4mZ3Q7OyBJRVRGIFFVSUMg V0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZn dDsNCjxicj4NClN1YmplY3Q6IFJlOiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVt YmVyIGVuY3J5cHRpb24gPGJyPg0KPGJyPg0KT24gV2VkLCBBcHIgMDQsIDIwMTggYXQgMDY6Mzg6 MThQTSAmIzQzOzAwMDAsIE1pa2UgQmlzaG9wIHdyb3RlOiA8YnI+DQomZ3Q7IFdoZW4geW91IGdl dCByaWdodCBkb3duIHRvIGl0LCBJJ20gc3ltcGF0aGV0aWMgdG8gdGhlIGNvc3QgYXJndW1lbnQs IDxicj4NCiZndDsgYnV0IGl0IGRvZXNuJ3Qgb3V0d2VpZ2ggdGhlIG90aGVyIHR3by4gQSBnaXZl biBzZXJ2ZXIgY2FuIChJIDxicj4NCiZndDsgcHJlc3VtZSkgc3VzdGFpbiBkcmFtYXRpY2FsbHkg bW9yZSBUZWxuZXQgY29ubmVjdGlvbnMgdGhhbiBpdCBjYW4gU1NIIDxicj4NCiZndDsgY29ubmVj dGlvbnMsIGJ1dCBwZW9wbGUgd2hvIGFkdm9jYXRlIGNvbnRpbnVpbmcgdG8gdXNlIFRlbG5ldCBm b3IgdGhhdCA8YnI+DQomZ3Q7IHJlYXNvbiBhcmUgcm91bmRseSByaWRpY3VsZWQuLiBTU0ggaGFz IGEgZGlmZmVyZW50LCBiZXR0ZXIgc2VjdXJpdHkgPGJyPg0KJmd0OyBwcm9maWxlIGFuZCB0aG9z ZSBkaWZmZXJlbmNlcyBqdXN0aWZ5IHRoZSBjb3N0LiBUQ1AgdmVyc3VzIFFVSUMgc2VlbXMgPGJy Pg0KJmd0OyBzaW1pbGFyLiA8YnI+DQo8YnI+DQpXZSBhcmUgY29tcGFyaW5nIEhUVFBTIHdpdGgg UVVJQyAtLSB0aHVzIHRoZSB0ZWxuZXQvU1NIIGFuYWxvZ3kgaXMgbm90IGFwcGxpY2FibGUuDQo8 YnI+DQo8YnI+DQotIERtaXRyaS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB06308060E05E23CD91AB521AB6A40CY4PR21MB0630namp_-- From nobody Wed Apr 4 12:15:07 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2BF126D45 for ; Wed, 4 Apr 2018 12:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522869301; bh=oEiINeF3GBDH3M3moxEGv/irIqVW49KWS6YNxL7qIds=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To:To; b=aCHWTuIGp7/l+AfBxPnABzY7/eziXnFUwACCqAhgN7RHK1g2HrHkzOf50+hNKoKGp 9ft7JZjecBHYoVo6wakWddiwH1f9sDJkI2gvqNXs/OkawecsbRie58ujFYLo7Bv3aM weWoewb5mn6YSQYO3AUxSCKlEpdFVvoNXExJfnVI= X-Mailbox-Line: From pravb@microsoft.com Wed Apr 4 12:15:01 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8429112DA6E; Wed, 4 Apr 2018 12:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522869301; bh=oEiINeF3GBDH3M3moxEGv/irIqVW49KWS6YNxL7qIds=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To:To; b=aCHWTuIGp7/l+AfBxPnABzY7/eziXnFUwACCqAhgN7RHK1g2HrHkzOf50+hNKoKGp 9ft7JZjecBHYoVo6wakWddiwH1f9sDJkI2gvqNXs/OkawecsbRie58ujFYLo7Bv3aM weWoewb5mn6YSQYO3AUxSCKlEpdFVvoNXExJfnVI= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661A5126D45 for ; Wed, 4 Apr 2018 12:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 YvxsZVg7VHEY for ; Wed, 4 Apr 2018 12:14:58 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe44::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E06B12DA6C for ; Wed, 4 Apr 2018 12:14:58 -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=oEiINeF3GBDH3M3moxEGv/irIqVW49KWS6YNxL7qIds=; b=gaLY/Ur4geMhkgTPfVlMYRGayDMIzs+rbIwWlHRRkKw04VKbg5zEKUpe+MrsWI4571wJIovTGI2z05/UutpI27T12IyY/ClPWLnJy77naTlFJ2yRH/j2+tscN8lbTRUGuwngq50K6hclOEgp8Y1wHqv4aYFbQDtUjI/c9TT8UfA= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0280.namprd21.prod.outlook.com (10.173.193.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 19:14:55 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 19:14:55 +0000 From: Praveen Balasubramanian CC: Lars Eggert , Mark Nottingham , IETF QUIC WG Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPw8I8AgAAC1QCAAAAuoIAAA0IAgAAD8YA= Date: Wed, 4 Apr 2018 19:14:55 +0000 Message-ID: References: <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <20180404184825.GB12306@ubuntu-dmitri> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0280; 7:gES9pWHHoEs5N1jIJZzrtZ+qFr/FB4ne38boXFKROqoj0PYLzweXYj1nu16TRnJnvn1ciTURnICbFRoFH+plVb0TzFZoIy7W2yLuksD8Q/qPCVUMy4PBIQrQjn2pa75o9CEU1Nkj23d44VDUWU8+63jLRycTnQZmujCXTU51BL1kFufMIAJxdYziMy9M9eXOTmCpck0XRD47CrumpEc6MoGHo1FDVmcp9iXahQleFrrYLONszThv3ybB+ibytYgD; 20:xNvh0qBg+KDq/Ekhv2algSZIxG4ju3zb+yq5+HFgYl8Foc/qsPQpePy+xFetJYNDRTivzrknx1w3YOMowj8Pxi2N4b6tefRztqGA0EpvwSiNirN+iARKaDcNJ5dWhk9jwtz6Fvg7/+KWzb+erGXbQeC+DoXdQlMlsYtCtzWRAU8= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 21cc0191-da64-4f62-0b7e-08d59a6059f9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0280; x-ms-traffictypediagnostic: CY4PR21MB0280: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(278428928389397)(209352067349851)(192374486261705)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(10201501046)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0280; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0280; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(346002)(376002)(366004)(39860400002)(13464003)(189003)(199004)(55016002)(9686003)(6306002)(14454004)(54896002)(6436002)(5250100002)(81166006)(81156014)(8936002)(8676002)(68736007)(106356001)(105586002)(74316002)(790700001)(110136005)(5660300001)(316002)(33656002)(22452003)(7736002)(236005)(93886005)(76176011)(6506007)(102836004)(53546011)(59450400001)(486006)(6116002)(7696005)(229853002)(54906003)(97736004)(186003)(46003)(99286004)(446003)(11346002)(476003)(39060400002)(2900100001)(53936002)(6246003)(478600001)(10290500003)(3280700002)(3660700001)(10090500001)(8990500004)(4326008)(2906002)(86612001)(86362001)(19609705001)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0280; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: FIPz0IT+OGJd8tpRR5CO8SRxAsCv+K60Ojy1GV+rhLtNAeagjtZceJzW1j1fvZNZlRvCxlEk6CxWw+ka38u+KNSedIZzPuOTAf9lpJ5iUuVsk0O4PTu3x0ZkusDBcgFo4qTPGm86iaLNpb131vujbYaTTICkLxyXBhFJC/vhoYOlJipkOo2ohXUQTYcLWfjSpLX/NrwNmZ48ejFFwl6geYKO1dxohNnVf+R5wbwUZ9LUU+3DdUxXa0kuklw5erJzrVVf9K2IzhcUCl8P+D8SKW2Hvfmull1JqDbMYODOjnLmOjBTXVAX2XuDU8loB5aujyO0qmmbu5m6anMgL/+ll1AO5/Znk5iCNtUyi/GPFX896oRptRqtS6CtnEWGElT4jlfuQDG+Iu7GsxtGQlyJwh1hsufCe4izggz/ewwHeYo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB06308060E05E23CD91AB521AB6A40CY4PR21MB0630namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21cc0191-da64-4f62-0b7e-08d59a6059f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 19:14:55.8523 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0280 To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= To: Praveen Balasubramanian To: Mike Bishop To: Dmitri Tikhonov Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 19:15:02 -0000 --_000_CY4PR21MB06308060E05E23CD91AB521AB6A40CY4PR21MB0630namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgNCwg MjAxOCAxMjowMSBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jv c29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+OyBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3Uu YmU+OyBEbWl0cmkgVGlraG9ub3YgPGR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbT4NCkNjOiBM YXJzIEVnZ2VydCA8bGFyc0BlZ2dlcnQub3JnPjsgTWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3Qu bmV0PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUkU6IEdldHRpbmcg dG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpNaWtlLA0KDQpvbiB5 b3VyIDMgb3B0aW9ucyBsaXN0IHlvdSBhcmUgbWlzc2luZyA0KSBtdWx0aXBsZSBQTiBzcGFjZXMg KHdoYXQgSSBjYWxsIHNlZ21lbnRlZCBwYWNrZXQgbnVtYmVycyksIGllLiBhIHNlcmlhbCBQTiBw ZXIgQ0lEIGFuZCBhIHVuaXF1ZSBDSUQgcGVyIHBhdGguIFdlIGtlZXAgYXNzdW1pbmcgdGhpcyBp cyB2ZXJ5IGRpZmZpY3VsdCBhbmQgb25seSBhIHYyIHRoaW5nLg0KQnV0IEkgdGhpbmsgaXQgaXMg bm90IHZlcnkgZGlmZmljdWx0IHRvIGRvIGFuZCBpdCB3b3VsZCBzb2x2ZSBuZWFybHkgYWxsIHRo ZSBpc3N1ZXMgZXhjZXB0IG9zc2lmaWNhdGlvbiBvbiBhIHNpbmdsZSBwYXRoLiBBbmQgaWYgdGhh dCBpcyBhIHByb2JsZW0gKHdoaWNoIEkgZG9u4oCZdCB0aGluayksIGl0IHdvdWxkIGJlIGdvb2Qg dG8ga25vdyBiZWZvcmUgdjIgd2hlcmUgaXQgcmVhbGx5IGJlY29tZXMgaW1wb3J0YW50Lg0KDQoN CktpbmQgUmVnYXJkcywNCk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCg0KDQpPbiA0IEFwcmls IDIwMTggYXQgMjAuNTEuNDEsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIChwcmF2Yj00MG1pY3Jv c29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFy Yy5pZXRmLm9yZz4pIHdyb3RlOg0KWW91IGFyZSBhbHNvIGlnbm9yaW5nIGFsbCBidWxrIHRyYW5z ZmVyIGFwcGxpY2F0aW9ucyBvdmVyIFdBTiBhbmQgaW4gREMgd2hlcmUgdGhlIENQVSBjb3N0cyB3 aWxsIG1hZ25pZnkgbXVjaCBtb3JlIGNvbXBhcmVkIHRvIG9ubGluZSBzdHJlYW1pbmcgd2ViIHZp ZGVvIGFuZCB3ZWIgc2VhcmNoLiBJIHN1c3BlY3QgdGhlIGNvc3Qgd2lsbCBiZSBtb3JlIGxpa2Ug My00eC4gRnJvbSBzZXJ2aWNlIGRlcGxveW1lbnQgcG9pbnQgb2YgdmlldyBpdHMgc3RpbGwgSFRU UCB3aXRoIFRMUywganVzdCBjaGFuZ2luZyBhIHRyYW5zcG9ydCB1bmRlcm5lYXRoIHNob3VsZG4n dCByZXF1aXJlIHRocm93aW5nIDN4IG1vcmUgc2VydmVycy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBEbWl0cmkgVGlraG9ub3YNClNl bnQ6IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxOCAxMTo0OCBBTQ0KVG86IE1pa2UgQmlzaG9wIDxt YmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+Pg0KQ2M6IExh cnMgRWdnZXJ0IDxsYXJzQGVnZ2VydC5vcmc8bWFpbHRvOmxhcnNAZWdnZXJ0Lm9yZz4+OyBNYXJr IE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ8bWFpbHRvOm1ub3RAbW5vdC5uZXQ+PjsgSUVURiBR VUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJl OiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KT24g V2VkLCBBcHIgMDQsIDIwMTggYXQgMDY6Mzg6MThQTSArMDAwMCwgTWlrZSBCaXNob3Agd3JvdGU6 DQo+IFdoZW4geW91IGdldCByaWdodCBkb3duIHRvIGl0LCBJJ20gc3ltcGF0aGV0aWMgdG8gdGhl IGNvc3QgYXJndW1lbnQsDQo+IGJ1dCBpdCBkb2Vzbid0IG91dHdlaWdoIHRoZSBvdGhlciB0d28u IEEgZ2l2ZW4gc2VydmVyIGNhbiAoSQ0KPiBwcmVzdW1lKSBzdXN0YWluIGRyYW1hdGljYWxseSBt b3JlIFRlbG5ldCBjb25uZWN0aW9ucyB0aGFuIGl0IGNhbiBTU0gNCj4gY29ubmVjdGlvbnMsIGJ1 dCBwZW9wbGUgd2hvIGFkdm9jYXRlIGNvbnRpbnVpbmcgdG8gdXNlIFRlbG5ldCBmb3IgdGhhdA0K PiByZWFzb24gYXJlIHJvdW5kbHkgcmlkaWN1bGVkLi4gU1NIIGhhcyBhIGRpZmZlcmVudCwgYmV0 dGVyIHNlY3VyaXR5DQo+IHByb2ZpbGUgYW5kIHRob3NlIGRpZmZlcmVuY2VzIGp1c3RpZnkgdGhl IGNvc3QuIFRDUCB2ZXJzdXMgUVVJQyBzZWVtcw0KPiBzaW1pbGFyLg0KDQpXZSBhcmUgY29tcGFy aW5nIEhUVFBTIHdpdGggUVVJQyAtLSB0aHVzIHRoZSB0ZWxuZXQvU1NIIGFuYWxvZ3kgaXMgbm90 IGFwcGxpY2FibGUuDQoNCi0gRG1pdHJpLg0K --_000_CY4PR21MB06308060E05E23CD91AB521AB6A40CY4PR21MB0630namp_ 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 Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7 MTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9u IEJlaGFsZiBPZg0KPC9iPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDE4IDEyOjAxIFBNPGJyPg0KPGI+VG86PC9iPiBQcmF2 ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu b3JnJmd0OzsgTWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJlJmd0OzsgRG1pdHJp IFRpa2hvbm92ICZsdDtkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBMYXJzIEVnZ2VydCAmbHQ7bGFyc0BlZ2dlcnQub3JnJmd0OzsgTWFyayBOb3R0aW5naGFt ICZsdDttbm90QG1ub3QubmV0Jmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogR2V0dGluZyB0byBjb25zZW5zdXMgb24gcGFja2V0 IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJibG9vcF9jdXN0 b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtlLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5vbiB5b3VyIDMgb3B0aW9ucyBsaXN0 IHlvdSBhcmUgbWlzc2luZyA0KSBtdWx0aXBsZSBQTiBzcGFjZXMgKHdoYXQgSSBjYWxsIHNlZ21l bnRlZCBwYWNrZXQgbnVtYmVycyksIGllLiBhIHNlcmlhbCBQTiBwZXIgQ0lEIGFuZCBhIHVuaXF1 ZSBDSUQgcGVyIHBhdGguIFdlIGtlZXAgYXNzdW1pbmcgdGhpcw0KIGlzIHZlcnkgZGlmZmljdWx0 IGFuZCBvbmx5IGEgdjIgdGhpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5CdXQgSSB0aGluayBpdCBpcyBub3QgdmVyeSBkaWZmaWN1bHQgdG8gZG8gYW5kIGl0 IHdvdWxkIHNvbHZlIG5lYXJseSBhbGwgdGhlIGlzc3VlcyBleGNlcHQgb3NzaWZpY2F0aW9uIG9u IGEgc2luZ2xlIHBhdGguIEFuZCBpZiB0aGF0IGlzIGEgcHJvYmxlbSAod2hpY2ggSSBkb27igJl0 IHRoaW5rKSwNCiBpdCB3b3VsZCBiZSBnb29kIHRvIGtub3cgYmVmb3JlIHYyIHdoZXJlIGl0IHJl YWxseSBiZWNvbWVzIGltcG9ydGFudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgaWQ9ImJsb29wX3NpZ25fMTUyMjg2ODI1OTI4OTM0NzA3MiI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWwgRmFobsO4 ZSBKw7hyZ2Vuc2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gNCBBcHJp bCAyMDE4IGF0IDIwLjUxLjQxLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAoPGEgaHJlZj0ibWFp bHRvOnByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyI+cHJhdmI9NDBtaWNyb3Nv ZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPikgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPllvdSBhcmUgYWxzbyBpZ25vcmluZyBhbGwgYnVs ayB0cmFuc2ZlciBhcHBsaWNhdGlvbnMgb3ZlciBXQU4gYW5kIGluIERDIHdoZXJlIHRoZSBDUFUg Y29zdHMgd2lsbCBtYWduaWZ5IG11Y2ggbW9yZSBjb21wYXJlZCB0byBvbmxpbmUgc3RyZWFtaW5n DQogd2ViIHZpZGVvIGFuZCB3ZWIgc2VhcmNoLiBJIHN1c3BlY3QgdGhlIGNvc3Qgd2lsbCBiZSBt b3JlIGxpa2UgMy00eC4gRnJvbSBzZXJ2aWNlIGRlcGxveW1lbnQgcG9pbnQgb2YgdmlldyBpdHMg c3RpbGwgSFRUUCB3aXRoIFRMUywganVzdCBjaGFuZ2luZyBhIHRyYW5zcG9ydCB1bmRlcm5lYXRo IHNob3VsZG4ndCByZXF1aXJlIHRocm93aW5nIDN4IG1vcmUgc2VydmVycy4NCjxicj4NCjxicj4N Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIDxicj4NCkZyb206IFFVSUMgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSBPbiBCZWhhbGYgT2YgRG1pdHJpIFRpa2hvbm92DQo8YnI+DQpTZW50OiBXZWRuZXNkYXks IEFwcmlsIDQsIDIwMTggMTE6NDggQU0gPGJyPg0KVG86IE1pa2UgQmlzaG9wICZsdDs8YSBocmVm PSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPiZn dDsgPGJyPg0KQ2M6IExhcnMgRWdnZXJ0ICZsdDs8YSBocmVmPSJtYWlsdG86bGFyc0BlZ2dlcnQu b3JnIj5sYXJzQGVnZ2VydC5vcmc8L2E+Jmd0OzsgTWFyayBOb3R0aW5naGFtICZsdDs8YSBocmVm PSJtYWlsdG86bW5vdEBtbm90Lm5ldCI+bW5vdEBtbm90Lm5ldDwvYT4mZ3Q7OyBJRVRGIFFVSUMg V0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZn dDsNCjxicj4NClN1YmplY3Q6IFJlOiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVt YmVyIGVuY3J5cHRpb24gPGJyPg0KPGJyPg0KT24gV2VkLCBBcHIgMDQsIDIwMTggYXQgMDY6Mzg6 MThQTSAmIzQzOzAwMDAsIE1pa2UgQmlzaG9wIHdyb3RlOiA8YnI+DQomZ3Q7IFdoZW4geW91IGdl dCByaWdodCBkb3duIHRvIGl0LCBJJ20gc3ltcGF0aGV0aWMgdG8gdGhlIGNvc3QgYXJndW1lbnQs IDxicj4NCiZndDsgYnV0IGl0IGRvZXNuJ3Qgb3V0d2VpZ2ggdGhlIG90aGVyIHR3by4gQSBnaXZl biBzZXJ2ZXIgY2FuIChJIDxicj4NCiZndDsgcHJlc3VtZSkgc3VzdGFpbiBkcmFtYXRpY2FsbHkg bW9yZSBUZWxuZXQgY29ubmVjdGlvbnMgdGhhbiBpdCBjYW4gU1NIIDxicj4NCiZndDsgY29ubmVj dGlvbnMsIGJ1dCBwZW9wbGUgd2hvIGFkdm9jYXRlIGNvbnRpbnVpbmcgdG8gdXNlIFRlbG5ldCBm b3IgdGhhdCA8YnI+DQomZ3Q7IHJlYXNvbiBhcmUgcm91bmRseSByaWRpY3VsZWQuLiBTU0ggaGFz IGEgZGlmZmVyZW50LCBiZXR0ZXIgc2VjdXJpdHkgPGJyPg0KJmd0OyBwcm9maWxlIGFuZCB0aG9z ZSBkaWZmZXJlbmNlcyBqdXN0aWZ5IHRoZSBjb3N0LiBUQ1AgdmVyc3VzIFFVSUMgc2VlbXMgPGJy Pg0KJmd0OyBzaW1pbGFyLiA8YnI+DQo8YnI+DQpXZSBhcmUgY29tcGFyaW5nIEhUVFBTIHdpdGgg UVVJQyAtLSB0aHVzIHRoZSB0ZWxuZXQvU1NIIGFuYWxvZ3kgaXMgbm90IGFwcGxpY2FibGUuDQo8 YnI+DQo8YnI+DQotIERtaXRyaS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB06308060E05E23CD91AB521AB6A40CY4PR21MB0630namp_-- From nobody Wed Apr 4 12:15:32 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF9312E051 for ; Wed, 4 Apr 2018 12:15:23 -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 (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 IGN31CDcGOm0 for ; Wed, 4 Apr 2018 12:15:20 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on070b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::70b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E77812E8A9 for ; Wed, 4 Apr 2018 12:15:19 -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=HxVShu+2oUbxzKFfRpWhkkq8UYcJy8J2UXR/ERIWY2A=; b=Ddj0p7Fg/R0YwDg7FLbUcWhjq39qXEi7LS5HwCIgijk4yKlN07dmiSbhRFRG9WvwfWkTqyVOT02NjACE3PBbW320f7jVo2dECmrfahsVWhG4lH1kPdWGkA7PBJRBB0IOfCYPWaxh8r1JIrqI50DKH9DKmzOE8bybBL6VF7qDAU4= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0742.namprd21.prod.outlook.com (10.173.189.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 19:15:17 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 19:15:17 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Mark Nottingham CC: Lars Eggert , IETF QUIC WG Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwZ0sAgAB4hlA= Date: Wed, 4 Apr 2018 19:15:17 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> In-Reply-To: <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0742; 7:tUsHCTR3Un8wsafrKfaIVLABmf8+lXJk76PaRjfhF9d07bV+LwwCPL4+8Jsu0pGWrVSIEYiBBCG82n4VyeWgR/19r/MC8FdiSSydCDGvpx/ZWPqu2c4VqjzAUfW/CrcgicB2WZ5U9jWQGF6jXcfeErjCIcM49C2PByphu4zgaZ8pZE05O0maX702cPUZWy3IdTxYQyoLuuafVF7OGk31+yMPcjJPg5OxEFSetJEknh3YW9Jc1lsxZkIzTjFlqwW2; 20:IXKXT8hhsk+7y867fSj3/FFYqZ3eJm7AkCsfaYi+qRekh+8CjPqAMz/J0uTJ83SC/DbTLHMC9zNHSd5W/VdcxaQ+FhFx0njorotBPdvDVbBBNZHjzGWC/m7WSBa4bVcBJ7HKiyn3GI8BAxqi5w5JGEChGJLDz8YpPAkCwnP+8Fk= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 56d3003b-a167-4d76-1e69-08d59a60670c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0742; x-ms-traffictypediagnostic: CY4PR21MB0742: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(85827821059158)(100405760836317)(219752817060721)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231221)(944501327)(52105095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0742; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0742; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(39860400002)(376002)(346002)(396003)(199004)(189003)(13464003)(53754006)(51914003)(22452003)(8676002)(5660300001)(561944003)(11346002)(81166006)(8936002)(446003)(46003)(10090500001)(33656002)(76176011)(6506007)(2906002)(7736002)(476003)(6116002)(93886005)(81156014)(59450400001)(7696005)(86362001)(486006)(53546011)(305945005)(575784001)(97736004)(54906003)(478600001)(110136005)(68736007)(316002)(3280700002)(74316002)(99286004)(8990500004)(106356001)(86612001)(3660700001)(102836004)(25786009)(186003)(4326008)(10290500003)(14454004)(966005)(5250100002)(105586002)(6436002)(6306002)(229853002)(55016002)(2900100001)(9686003)(6246003)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0742; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: bokwcsRjotSNAOQOQGk8BxjPKVQDg/JdO0elg4pskyainwHcbL9vNlX6bHETWPSA6gbPrsj2sECP+xnZ7yjVJ3cHVG9EgFY4pmRwl4LVCrUEdZ+sB4S0xY7ElZkGXOzP+PRdiTmU3Nl2nPYJIuVHhES5/yTRi9xBT8Xfa26ppRrNJjwnZDeCgcJq7bLPR4DnVDkV2DcYkOGApuzYyr8Dg8/tq77O8cb2Xqy9ubCg8im2spXZJR7LFj7u8jtlSHHEaFn4z9dz6vg3ZGn5CAd0eA7gpzwu1gsRcTVo9KsoZwNSr79QA+LXjhTvOVqApJdJ1yOG2Y2toB614HQi7XqQ0BBpInao+7GKppYGiluYaEh903E3g65/BS1M9qCS6kU5c80JZxwRlWjew5LNyjdtSpT2aVookLezaAw1f3fk6XQ= 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-Network-Message-Id: 56d3003b-a167-4d76-1e69-08d59a60670c X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 19:15:17.7627 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0742 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 19:15:23 -0000 SSB0b28gZGlzYWdyZWUgd2l0aCB0aGUgYXNzZXNzbWVudCBvZiB0aGUgc2l0dWF0aW9uLiArMSB0 byBldmVyeXRoaW5nIE1pcmphIHNhaWQuDQoNCj4+IHRoZXJlIGlzIG5vICpyZXF1aXJlbWVudCog dGhhdCB3ZSBwcm9kdWNlIGEgcHJvdG9jb2wgdGhhdCBpcyBhYmxlIHRvIGJlIGFjY2VsZXJhdGVk IGJ5IGhhcmR3YXJlLg0KSXQgaXMgaG93ZXZlciBhIHJlcXVpcmVtZW50IGZvciBkZXBsb3ltZW50 IHRoYXQgd2UgYmUgYWJsZSB0byBvZmZsb2FkIFFVSUMuIEEgbGFyZ2UgcGFydCBvZiB3b3JrIHdl IGRvIGluIFRDUCBpcyBhY2NlbGVyYXRpb24gaW4gc29mdHdhcmUgYW5kIGhhcmR3YXJlLiBJZiBR VUlDIGhhcyB0byBldm9sdmUgZnJvbSBleHBlcmltZW50IHRvIGJyb2FkIGRlcGxveW1lbnQgcGVy Zm9ybWFuY2UgaXMgYSBrZXkgZ29hbC4gVGhpcyBpcyBicm91Z2h0IHVwIHNldmVyYWwgdGltZXMg aW4gVENQIHdvcmtpbmcgZ3JvdXAgd2hlcmUgd2Ugc2VlIHByb3Bvc2FscyB0aGF0IHdvdWxkbuKA mXQgd29yayB3aXRoIHdpZGVseSBkZXBsb3llZCBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUgYWNjZWxl cmF0aW9ucy4gDQoNCldoZXRoZXIgd2UgbGlrZSBpdCBvciBub3QgcGVyZm9ybWFuY2UgaXMgYSBr ZXkgcmVxdWlyZW1lbnQgZm9yIFFVSUMgb24gc2VydmVycyBhbmQgZm9yIGRhdGFjZW50ZXIgc2Nl bmFyaW9zLiBFdmVuIElhbiBtZW50aW9uZWQgYmVmb3JlIHRoYXQgaGUnZCBub3Qgd2FudCB0byBk byBQTkUgd2l0aGluIERDIGFuZCBJIGFncmVlLiBNb3N0IGNvbm5lY3Rpb25zIHdpbGwgYWxzbyBu b3QgYmUgZG9pbmcgbWlncmF0aW9uIG9yIHVzaW5nIG11bHRpIHBhdGggc28gd2h5IHBheSB0aGUg ZXh0cmEgb3ZlcmhlYWQgaW4gdGhlIGNvbW1vbiBjYXNlIGZvciBubyBiZW5lZml0Pw0KDQpTaW5j ZSBQTkUgZG9lc27igJl0IGFmZmVjdCB0aGUgaW52YXJpYW50cyAoaXRzIHNpbXBseSBhbiBleHRy YSBzdGVwIHBvc3QgcGFja2V0aXphdGlvbiBhbmQgcHJlIHBhcnNpbmcpLCBwbGVhc2UgZXhwbGFp biB3aHkgaXQgd291bGQgYmxvY2sgcHJvZ3Jlc3Mgb24gb3RoZXIgZnJvbnRzPyBXaGF0IGlzIHRo ZSBsaXN0IG9mIHRoaW5ncyB0aGF0IGdldCBibG9ja2VkPw0KDQpQbGVhc2UgbGV0IHVzIG5vdCBy dXNoIGludG8gYSBkZXNpZ24gdGhhdCBpbXBhY3RzIHBlciBwYWNrZXQgcHJvY2Vzc2luZyBjb3N0 cyB3aXRoIG5vIGNsZWFyIGFydGljdWxhdGlvbiBvZiB0aGUgcHJvYmxlbSBhbmQgdGhlIGJlbmVm aXRzLiANCg0KRnJvbSB3aGF0IEkgY2FuIHRlbGwgdGhlcmUgaXMgd2lkZSBkaXNhZ3JlZW1lbnQg aW4gdGhlIGdyb3VwIGFuZCBub3RoaW5nIHJlc2VtYmxpbmcgY29uc2Vuc3VzLiBUaGUgZmFjdCB0 aGF0IHdlIGhhdmUgcG9vciByZXByZXNlbnRhdGlvbiBmcm9tIGhhcmR3YXJlIGRldmVsb3BlcnMg YW5kIHB1YmxpYyBjbG91ZCBwcm92aWRlcnMgaXMgZnVydGhlciBza2V3aW5nIHRoZSBwZXJjZXB0 aW9uLiANCg0KTXkgcmVjb21tZW5kYXRpb25zOg0KMS4gTGVhdmUgdGhlIGN1cnJlbnQgZHJhZnQg YXMgaXMuIE1ha2Ugc3VyZSB3ZSBoYXZlIHNvbWUgcHJvdmlzaW9uIGZvciBncmVhc2luZyB0aGUg UE4gdG8gcHJldmVudCBvc3NpZmljYXRpb24uDQoyLiBFeHBsb3JlIG11bHRpcGxlIFBOIHNwYWNl cyBmb3IgY29ubmVjdGlvbiBtaWdyYXRpb24gKGFuZCBldmVudHVhbGx5IG11bHRpcGF0aCkuDQoz LiBNYWtlIFBORSBhbiBvcHRpb25hbCBuZWdvdGlhdGVkIGV4dGVuc2lvbiBmb3IgaW1wbGVtZW50 YXRpb25zIHRoYXQgd2FudCB0byBkbyBjb25uZWN0aW9uIG1pZ3JhdGlvbiBpbiBWMSB3aXRoIHRo ZSBjYXZlYXQgdGhhdCB3ZSB3aWxsIHJldmlzaXQgdGhpcyBmb3IgVjIgd2hlbiB3ZSBkbyBtdWx0 aXBhdGguDQo0LiBTb2xpY2l0IG1vcmUgZmVlZGJhY2sgb24gdGhlIHByb3RvY29sIGZyb20gaGFy ZHdhcmUgdmVuZG9ycyBhbmQgcHVibGljIGFuZCBwcml2YXRlIGNsb3VkIHByb3ZpZGVycy4gSSBj YW4gdHJ5IHRvIGxvb3AgaW4gbW9yZSBmb2xrcyBidXQgb3RoZXJzIHNob3VsZCB0b28uDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlyamEgS8O8aGxld2luZA0KU2VudDogV2VkbmVzZGF5 LCBBcHJpbCA0LCAyMDE4IDM6MjcgQU0NClRvOiBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5u ZXQ+DQpDYzogTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz47IElFVEYgUVVJQyBXRyA8cXVp Y0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQg bnVtYmVyIGVuY3J5cHRpb24NCg0KSGkgTWFyaywNCg0Kd2l0aG91dCBpbnRlbmRpbmcgdG8gc3Rh dGUgYSB0ZWNobmljYWwgb3BpbmlvbiwgSSB0aGluayBJIG5lZWQgdG8gZGlzYWdyZWUgd2l0aCB5 b3VyIGFzc2Vzc21lbnQgb2YgdGhlIHNpdHVhdGlvbi4gUGxlYXNlIHNlZSBiZWxvdy4NCg0KPiBB bSAwNC4wNC4yMDE4IHVtIDA2OjU4IHNjaHJpZWIgTWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3Qu bmV0PjoNCj4gDQo+IEhpIGV2ZXJ5b25lLA0KPiANCj4gVGhlIGVkaXRvcnMgaGF2ZSB0b2xkIHlv dXIgY2hhaXJzIHRoYXQgdGhpcyBpc3N1ZSBpcyBzdGFydGluZyB0byBibG9jayBwcm9ncmVzcyBv biBvdGhlciBhc3BlY3RzIG9mIFFVSUMuIENvbWluZyB0byBjb25zZW5zdXMgb24gaXQgc29vbiAo aS5lLiwgYmVmb3JlIFN0b2NraG9sbSwgaWYgcG9zc2libGUpIHdvdWxkIGJlIGdvb2QuDQo+IA0K PiBJdCBsb29rcyBsaWtlIHRoaXMgdGhyZWFkIGhhcyBjb21lIHRvIGEgbmF0dXJhbCBwYXVzZS4g UmVhZGluZyB0aHJvdWdoIGl0LCBJIHRoaW5rIHdlIGFncmVlIHRoZXJlIGFyZSBzb21lIHVucGxl YXNhbnQgdHJhZGVvZmZzIGhlcmUsIGJ1dCBzbyBmYXIgd2UgaGF2ZSBvbmx5IG9uZSBjb25jcmV0 ZSBwcm9wb3NhbCAtLSBQUiMxMDc5Lg0KDQpUaGUgb3RoZXIgcHJvcG9zYWwgaXMgdG8gdXNlIGEg cmFuZG9tIG9mZnNldCB0aGF0IGNhbi9zaG91bGQgYmUgY2hhbmdlZCB3aGVuIHRoZSBjb25uZWN0 aW9uIElEIGlzIGNoYW5nZWQuIFdoaWNoIGlzIG1vc3RseSBpbmxpbmUgd2l0aCB3aGF0IHRoZSBk cmFmdCBjdXJyZW50bHkgc2F5cy4NCj4gDQo+IE15IEFVJC4wNSAtIFdoaWxlIHdlJ3JlIGNoYXJ0 ZXJlZCB0byBwcm9kdWNlIGEgcHJvdG9jb2wgdGhhdCdzIGVuY3J5cHRlZCBhcyBtdWNoIGFzIG9w ZXJhdGlvbmFsIGNvbmNlcm5zIGFsbG93LA0KDQpJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyB3aGF0 IHRoZSBjaGFydGVyIHNheS4gVGhlIGNoYXJ0ZXIgc2F5cyAiUHJvdmlkaW5nIGFsd2F5cy1zZWN1 cmUgdHJhbnNwb3J0LCB1c2luZyBUTFMgMS4zIGJ5IGRlZmF1bHQu4oCcIHBsdXMgYW5vdGhlciBw YXJhZ3JhcGggdGhhdCB0YWxrcyBhYm91dCBUTFMxLjMuIEl0IGRvZXMgbm90IHNwZWxsIG91dCB0 aGUgZGVzaXJlIG9mIHNvbWUgaW5kaXZpZHVhbCB0byDigJ5lbmNyeXB0IGFzIG11Y2ggYXMgcG9z c2libGXigJwuIA0KDQo+IGFuZCB0aGF0IHByaXZhY3kgaXMgYSBuYXR1cmFsIGV4dGVuc2lvbiBv ZiB0aGF0IChlc3BlY2lhbGx5IGluIGxpZ2h0IG9mIFJGQzcyNTggYW5kIFJGQzY5NzMpLCB0aGVy ZSBpcyBubyAqcmVxdWlyZW1lbnQqIHRoYXQgd2UgcHJvZHVjZSBhIHByb3RvY29sIHRoYXQgaXMg YWJsZSB0byBiZSBhY2NlbGVyYXRlZCBieSBoYXJkd2FyZS4NCg0KTm90IHRoZXJlIGlzIG5vIHJl cXVpcmVtZW50IHRoYXQgdGhlIHByb3RvY29sIG5lZWQgdG8gYmUgYWNjZWxlcmF0ZWQgYnkgaGFy ZHdhcmUuIEhvd2V2ZXIsIG5vdCBhbGwgcmVxdWlyZW1lbnQgYXJlIGxpc3RlZCBpbiB0aGUgY2hh cnRlci4gV2UgYXMgYSBncm91cCBoYXZlIHRvIGRlZmluZSB0aGUgcmVxdWlyZW1lbnQuIEhvd2V2 ZXIsIHRoZXJlIGlzIG9mIGNvdXJzZSBhbiBpbXBsaWNpdCByZXF1aXJlbWVudCBmb3IgYWxsIHdv cmsgaW4gdGhlIElFRlQgdGhhdCBpcyBtdXN0IGJlIGRlcGxveWFibGUgYW5kIHNlcnZlIHRoZSBu ZWVkcyBvZiB0aG9zZSBwZW9wbGUgd2hvIHdhbnQgdG8gZGVwbG95IGl0Lg0KDQo+IA0KPiBUaGF0 IGJlaW5nIHRoZSBjYXNlLCBJIHRoaW5rIHdlIG5lZWQgdG8gYXNrIG91cnNlbHZlcyBpZiB3ZSBi ZWxpZXZlIHRoYXQgaW5jbHVzaW9uIG9mIFBSIzEwNzkgd2lsbCBzaWduaWZpY2FudGx5IGluaGli aXQgZGVwbG95bWVudCBvZiB0aGUgcHJvdG9jb2wuIEJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIHNv IGZhciwgdGhhdCBkb2Vzbid0IHNlZW0gdG8gYmUgdGhlIGNhc2UsIGJ1dCBJJ2QgYmUgaW50ZXJl c3RlZCB0byBoZWFyIHdoYXQgb3RoZXJzIHRoaW5rLg0KDQpIZXJlIG15IGFzc2Vzc21lbnQgaXMg YWxzbyBkaWZmZXJlbnQuIFRoZXJlIGFyZSBtdWx0aXBsZSBwZW9wbGUgdGhhdCBoYXZlIHJhaXNl ZCBjb25jZXJucyB0aGF0IHRoaXMgY291bGQgaGluZGVyIGRlcGxveW1lbnQuDQo+IA0KPiBJZiB3 ZSBjYW4gZ2V0IHRvIGNvbnNlbnN1cyB0byBpbmNvcnBvcmF0ZSB0aGUgUFIsIGFuZCBmb2xrcyBj b21lIGJhY2sgbGF0ZXIgd2l0aCBhIG1vcmUgaGFyZHdhcmUtZnJpZW5kbHkgcmVwbGFjZW1lbnQg dGhhdCBkb2Vzbid0IGNoYW5nZSB0aGUgSW52YXJpYW50cyBvciBpbmNyZWFzZSBsaW5rYWJpbGl0 eSwgSSBzdXNwZWN0IHRoZSBXRyB3aWxsIGJlIGFtZW5hYmxlIHRvIHRoYXQuDQoNCkkgZG9u4oCZ dCB0aGluayB0byBqdXN0IGdvIHdpdGggd2hhdCB3ZSBoYXZlIGV2ZW4gdGhvdWdoIHRoZXJlIGFy ZSBjb25jZXJucywgaXMgdGhlIHJpZ2h0IGFwcHJvYWNoIGFuZCBkZWZpbml0ZWx5IG5vdCB0aGUg YXBwcm9hY2ggdGhhdCB3YXMgY2hvc2VuIGZvciBvdGhlciBwcm9wb3NhbHMuIEluIHRoZSBzYWtl IG9mIGdldHRpbmcgdmVyc2lvbiB2MSBvdXQgcXVpY2tseSwgSSB3b3VsZCB0aGluayB0aGF0IG5v dCBpbmNvcnBvcmF0aW5nIGFub3RoZXIgY2hhbmdlIHRoYXQgZG9lcyBub3QgaGF2ZSBjb25zZW5z dXMgaXMgdGhlIHByb3Bvc2VyIGFwcHJvYWNoLg0KDQpNaXJqYQ0KDQoNCg0KPiANCj4gV2hhdCBk byBmb2xrcyB0aGluaz8NCj4gDQo+IENoZWVycywNCj4gDQo+IA0KPj4gT24gMjkgTWFyIDIwMTgs IGF0IDExOjM5IGFtLCBJYW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRm Lm9yZz4gd3JvdGU6DQo+PiANCj4+IFRoYW5rcyBmb3IgdGhlIG5pY2Ugc3VtbWFyeSBKYW5hLg0K Pj4gDQo+PiBBcyBtdWNoIGFzIEknZCBsb3ZlIHRvIGhhdmUgZWFzaWVyIGNyeXB0byBIVyBhY2Nl bGVyYXRpb24sIEkndmUgZW5kZWQgdXAgYXJyaXZpbmcgYXQgdGhlIHNhbWUgY29uY2x1c2lvbi4g IEkgZG9uJ3Qgd2FudCB0byBiaXRlIG9mZiB0aGUgd29yayB0byBkbyBwcm9wZXIgbXVsdGlwYXRo IGluIFFVSUMgdjEsIHdoaWNoIEkgdGhpbmsgaXMgdGhlIG9ubHkgb3RoZXIgcmVhc29uYWJsZSBv cHRpb24gb2YgdGhvc2UgQ2hyaXN0aWFuIG91dGxpbmVkLg0KPj4gDQo+PiBJZiBzb21lb25lIGNv bWVzIHVwIHdpdGggYSB3YXkgdG8gdHJhbnNmb3JtIHBhY2tldCBudW1iZXIgdG8gbWFrZSBpdCBu b24tbGlua2FibGUsIGJ1dCBkb2Vzbid0IGhhdmUgdGhlIGRvd25zaWRlIG9mIG1ha2luZyBoYXJk d2FyZSBvZmZsb2FkIGRpZmZpY3VsdCwgdGhlbiBJJ20gb3BlbiB0byBpdC4gIEJ1dCB3ZSd2ZSBi ZWVuIHRhbGtpbmcgYWJvdXQgdGhpcyBmb3IgMiBtb250aHMgd2l0aG91dCBhbnkgbm90YWJsZSBp bXByb3ZlbWVudHMgb3ZlciBNYXJ0aW4ncyBQUi4NCj4+IA0KPj4gR2l2ZW4gd2UgbmV2ZXIgdGFs ayBhYm91dCBhbnkgaXNzdWUgb25seSBvbmNlIGluIFFVSUMsIEknbSBzdXJlIHRoaXMgd2lsbCBj b21lIHVwIGFnYWluLCBidXQgZm9yIHRoZSB0aW1lIGJlaW5nIEkgdGhpbmsgIzEwNzkgaXMgdGhl IGJlc3Qgb3B0aW9uIHdlIGhhdmUuDQo+PiANCj4+IA0KPj4gDQo+PiBPbiBXZWQsIE1hciAyOCwg MjAxOCBhdCA4OjAzIFBNIEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPiB3cm90ZToN Cj4+IEEgZmV3IHF1aWNrIHRob3VnaHRzIGFzIEkgY2F0Y2ggdXAgb24gdGhpcyB0aHJlYWQuDQo+ PiANCj4+IEkgc3BlbnQgc29tZSB0aW1lIGxhc3Qgd2VlayB3b3JraW5nIHRocm91Z2ggYSBkZXNp Z24gdXNpbmcgbXVsdGlwbGUgUE4gc3BhY2VzLCBhbmQgaXQgaXMgcXVpdGUgZG9hYmxlLiBJIHN1 c3BlY3Qgd2UnbGwgaGVhZCB0b3dhcmRzIG11bHRpcGxlIFBOIHNwYWNlcyBhcyB3ZSBjb25zaWRl ciBtdWx0aXBhdGggaW4gdGhlIGZ1dHVyZS4gVGhhdCBzYWlkLCB0aGVyZSBpcyBjb21wbGV4aXR5 IChhcyBDaHJpc3RpYW4gbm90ZXMpLiBUaGlzIGNvbXBsZXhpdHkgbWF5IGJlIHdhcnJhbnRlZCB3 aGVuIGRvaW5nIG11bHRpcGF0aCBpbiB2MiBvciBsYXRlciwgYnV0IEknbSBub3QgY29udmluY2Vk IHRoYXQgdGhpcyBpcyBuZWNlc3NhcnkgYXMgYSBkZXNpZ24gcHJpbWl0aXZlIGZvciBRVUlDdjEu IA0KPj4gDQo+PiBXZSBtYXkgd2FudCB0byBjcmVhdGl2ZWx5IHVzZSB0aGUgUE4gYml0cyBpbiB2 Miwgc2F5IHRvIGVuY29kZSBhIHBhdGggSUQgYW5kIGEgUE4sIGZvciBtdWx0aXBhdGguIFdlIHdh bnQgdG8gcmV0YWluIGZsZXhpYmlsaXR5IGluIHRoZXNlIGJpdHMgZ29pbmcgaW50byB2Mi4gV2Un dmUgdXNlZCBlbmNyeXB0aW9uIHRvIGVuc3VyZSB0aGF0IHdlIGRvbid0IGxvc2UgZmxleGliaWxp dHkgZWxzZXdoZXJlIGluIHRoZSBoZWFkZXIsIGFuZCBpdCBmb2xsb3dzIHRoYXQgd2Ugc2hvdWxk IHVzZSBQTkUgdG8gcmV0YWluIGZsZXhpYmlsaXR5IGluIHRoZXNlIGJpdHMgYXMgd2VsbC4gKFNp bXBsaWNpdHkgb2YgZGVzaWduIGlzIHRoZSBvdGhlciB2YWx1ZSBpbiB1c2luZyBQTkUsIHNpbmNl IGhhbmRsaW5nIG1pZ3JhdGlvbiBsaW5rYWJpbGl0eSBpcyBub24tdHJpdmlhbCB3aXRob3V0IGl0 LikNCj4+IA0KPj4gVGhpcyBsZWF2ZXMgdGhlIHF1ZXN0aW9uIG9mIEhXIGFjY2VsZXJhdGlvbiBi ZWluZyBhdCBsb2dnZXJoZWFkcyB3aXRoIHRoZSBkZXNpZ24gaW4gUFIgIzEwNzkuIEZpcnN0LCBJ IGV4cGVjdCB0aGF0IHRoZSBwcmltYXJ5IGJlbmVmaXQgb2YgYWNjZWxlcmF0aW9uIHdpbGwgYmUg aW4gREMgZW52aXJvbm1lbnRzLiBZZXMsIHRoZXJlIGFyZSBzb21lIGdhaW5zIHRvIGJlIGhhZCBp biBzZXJ2aW5nIHRoZSBwdWJsaWMgSW50ZXJuZXQgYXMgd2VsbCwgYnV0IEknbSB1bmNvbnZpbmNl ZCB0aGF0IHRoaXMgaXMgdGhlIGRyaXZpbmcgdXNlIGNhc2UgZm9yIGhhcmR3YXJlIGFjY2VsZXJh dGlvbi4gSSB1bmRlcnN0YW5kIHRoYXQgb3RoZXJzIG1heSBkaXNhZ3JlZSB3aXRoIG1lIGhlcmUu DQo+PiANCj4+IEFGQUlLLCBRVUlDIGhhcyBub3QgYmVlbiB1c2VkIGluIERDIGVudmlyb25tZW50 cyB5ZXQuIEkgZXhwZWN0IHRoZXJlIGFyZSBvdGhlciB0aGluZ3MgaW4gdGhlIHByb3RvY29sIHRo YXQgd2UnZCB3YW50IHRvIGNoYW5nZSBhcyB3ZSBnYWluIGV4cGVyaWVuY2UgZGVwbG95aW5nIFFV SUMgaW4gRENzLiBTcGlubmluZyB1cCBhIG5ldyB2ZXJzaW9uIHRvIHRyeSBRVUlDIHdpdGhpbiBE Q3MgaXMgbm90IG9ubHkgYXBwcm9wcmlhdGUsIEkgd291bGQgcmVjb21tZW5kIGl0LiBUaGlzIGFs bG93cyBmb3IgcmFwaWQgaXRlcmF0aW9ucyBpbnRlcm5hbGx5LCBhbmQgdGhlIGV4cGVyaWVuY2Ug Y2FuIGRyaXZlIHN1YnNlcXVlbnQgY2hhbmdlcyB0byBRVUlDLiBJdCdzIHdoYXQgKkkqIHdvdWxk IGRvIGlmIEkgd2FzIHRvIGRlcGxveSBRVUlDIGluc2lkZSBhIERDLg0KPj4gDQo+PiBTbywgaW4g c2hvcnQsIEkgdGhpbmsgd2Ugc2hvdWxkIGdvIGFoZWFkIHdpdGggUFIjIDEwNzkuIFRoaXMgZW5z dXJlcyB0aGF0IGZ1dHVyZSB2ZXJzaW9ucyBhcmUgZ3VhcmFudGVlZCB0aGUgZmxleGliaWxpdHkg dG8gY2hhbmdlIHRoZSBQTiBiaXRzIGZvciBiZXR0ZXIgc3VwcG9ydCBvZiBIVyBhY2NlbGVyYXRp b24gb3IgbXVsdGlwYXRoIG9yIHdoYXQtaGF2ZS15b3UuDQo+PiANCj4+IC0gamFuYQ0KPj4gDQo+ PiBPbiBNYXIgMjYsIDIwMTggOTo0MSBBTSwgIkNocmlzdGlhbiBIdWl0ZW1hIiA8aHVpdGVtYUBo dWl0ZW1hLm5ldD4gd3JvdGU6DQo+PiANCj4+IE9uIDMvMjYvMjAxOCA4OjIwIEFNLCBTd2luZGVs bHMsIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UpIHdyb3RlOg0KPj4+IExvb2tpbmcgYXQg aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZlbi53aWtpcGVkaWEub3JnJTJGd2lraSUyRkFFU19pbnN0cnVjdGlvbl9zZXQlMjNJ bnRlbF9hbmRfQU1EX3g4Nl9hcmNoaXRlY3R1cmUmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNy b3NvZnQuY29tJTdDMTRmMjc4YWIzNzY5NDY5YTQ0ZjkwOGQ1OWExNmEyZDYlN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTg0MzQ0MzgzOTU5NzY1JnNkYXRh PWFPSGM3RlpvSUJDRTFPbHFtTnB2ZE1NMG50TGVyWjNGcHFFU1ZqODV6ZkUlM0QmcmVzZXJ2ZWQ9 MCBpdCBzZWVtcyB0byBpbXBseSBhIGxhcmdlIHJhbmdlIG9mIHNlcnZlciwgZGVza3RvcCBhbmQg bW9iaWxlIGNoaXBzIGFsbCBoYXZlIGEgQ1BVIGluc3RydWN0aW9uIHNldCBhdmFpbGFibGUgdG8g ZG8gQUVTIGFjY2VsZXJhdGlvbiBhbmQgb3RoZXIgc2ltaWxhciBvcGVyYXRpb25zIChvdGhlciBp bnN0cnVjdGlvbiBzZXRzIGFyZSBhbHNvIGF2YWlsYWJsZSkuDQo+Pj4gDQo+Pj4gSWYgd2UgYXJl IGNvbnNpZGVyaW5nIHRoZSBBRVMgaW5zdHJ1Y3Rpb25zIHRoZW4gaXQgbG9va3MgbGlrZSBpdCBp cyAob3IgYXQgbGVhc3Qgd2lsbCBiZSBpbiB0aGUgbmVhciBmdXR1cmUpIGEgc2l6ZWFibGUgcHJv cG9ydGlvbiBvZiB0aGUgcHVibGljIGludGVybmV0IGhhdmUgaXQgdG8gYmUgdXNlZC4NCj4+PiAN Cj4+IA0KPj4gQ2VydGFpbmx5LCBidXQgdGhhdCdzIG5vdCB0aGUgY3VycmVudCBkZWJhdGUuIFBS ICMxMDc5IGlzIGZ1bGx5IGNvbXBhdGlibGUgd2l0aCB1c2Ugb2YgdGhlIEFFUyBpbnN0cnVjdGlv bnMuIFRoZSBpc3N1ZSBvZiB0aGUgZGViYXRlIGlzIHRoYXQgdGhlIG1lY2hhbmlzbSBpbiBQUiAj MTA3OSByZXF1aXJlZCBkb3VibGUgYnVmZmVyaW5nLCBmaXJzdCBlbmNyeXB0IHRoZSBwYXlsb2Fk LCB0aGVuIHVzZSB0aGUgcmVzdWx0IG9mIHRoZSBlbmNyeXB0aW9uIHRvIGVuY3J5cHQgdGhlIFBO LiBUaGlzIGlzIG5vdCBhbiBpc3N1ZSBpbiBhIHNvZnR3YXJlIGltcGxlbWVudGF0aW9uIHRoYXQg Y2FuIHJlYWRpbHkgYWNjZXNzIGFsbCBieXRlcyBvZiB0aGUgcGFja2V0IGZyb20gbWVtb3J5LCBi dXQgaXQgbWF5IGJlIGFuIGlzc3VlIGluIHNvbWUgaGFyZHdhcmUgaW1wbGVtZW50YXRpb25zIHRo YXQgYXJlIGRlc2lnbmVkIHRvIGRvIGp1c3Qgb25lIHBhc3Mgb3ZlciB0aGUgZGF0YS4NCj4+IA0K Pj4gDQo+PiAtLSBDaHJpc3RpYW4gSHVpdGVtYQ0KPj4gDQo+PiANCj4+IA0KPiANCj4gLS0NCj4g TWFyayBOb3R0aW5naGFtICAgaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cubW5vdC5uZXQlMkYmZGF0YT0wMiU3QzAxJTdD cHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDMTRmMjc4YWIzNzY5NDY5YTQ0ZjkwOGQ1OWExNmEyZDYl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTg0MzQ0Mzgz OTU5NzY1JnNkYXRhPVJYYmEyVHl2WXo2b3RlY0VIb0xDVDR0WjJJN0VvZHhEaXlQeFdybiUyRm5B dyUzRCZyZXNlcnZlZD0wDQo+IA0KDQo= From ffk@alumni.cmu.edu Wed Apr 4 09:46:00 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C73712DA3E for ; Wed, 4 Apr 2018 09:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=alumni-cmu-edu.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 BptDrdwymD0t for ; Wed, 4 Apr 2018 09:45:53 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F3E120724 for ; Wed, 4 Apr 2018 09:45:53 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id f6-v6so17818584ita.2 for ; Wed, 04 Apr 2018 09:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cmu-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O7IE8sFb0z829C0MLDVuuJFo+O62yY/b3fofrkCZXJA=; b=nGpLOUneBMlz7NQc+WFWVq4WFAs/NpUmslvcLK3ixrBkEKXQ8y8hjMxqzGrVCoK0sY DUB6R6lHmcFA9LC2WGZ3axohYDa8LQzvQHDIz+TBZTWvOMED9U44bcnzfyMsgUXbbrnT qi1gTkoASFRxJ7iluase21NdiEVjk0yvI0CjUmq/1SyNhZaoJRGq/ocaU1QgqlcSMMDw biWm4//kHeMp/yM5MKsKw7gXbJhZJvqwE3gLJiXvDPa3h1nbxHGWqFcT8/5bxjWB8H1r S8UZjLhau0/GOirOagJ99dnG2KwNv/Z47Nj/mx//XDoqDhyvwWV2VDIJGyn/qMR5REy9 f8Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O7IE8sFb0z829C0MLDVuuJFo+O62yY/b3fofrkCZXJA=; b=fD55UuEfxSPMb6Db+0D6D6gNTgd7XDg6DPSLRZLNcxZWkyL13FVQz+MiA5b15sQ+Km MwDq1oeXGCVuyCH4Zdp0mmPdy4rDaNARNSR559ti1qHGP5jPprJ4QsXlV750Xaa0nt5t uk7rwO13PxELTjkUqHk8OY5H6U/rjLx0knwwcER53DUQhW/e1myMdgo5rZgyK/Wp0I6u p/8OuTJgGlp9Tr8KdIu9bqpwW8ZbLtZy/e1GlmtM35VMIFEtxN0Jv2fre4aexMSAOCML omorcWRMoQUE1v5aLVwMv8YGFn1oMI4tGRkP9n4Cr73rlLWZphYCxOcxTry2vK/A0dEb pWGQ== X-Gm-Message-State: ALQs6tCExoW3GN1L7rzDg15GDYXX/JNtXtnxi8HVY4nt+99ciW5E+fI6 Ulo3WGIM4ISbqCzk2TEYmmt0eQ9TY6e9XxVmAXjqWg== X-Google-Smtp-Source: AIpwx4/e6A5TulfK/ddIocj1vBTPGmy5wTZzlzDz5q/PSMethTvzmJZ9bRa+pTS5WdJukrcr29t1l6S78o0DcnrpERI= X-Received: by 2002:a24:ec8:: with SMTP id 191-v6mr10999601ite.42.1522860352816; Wed, 04 Apr 2018 09:45:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Frederick Kautz Date: Wed, 04 Apr 2018 16:45:41 +0000 Message-ID: Subject: Re: UDP send costs in Linux To: Phillip Hallam-Baker Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Subodh Iyengar , IETF QUIC WG , Ian Swett Content-Type: multipart/alternative; boundary="0000000000005f97c10569088e99" Archived-At: X-Mailman-Approved-At: Wed, 04 Apr 2018 12:39:47 -0700 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 16:52:34 -0000 --0000000000005f97c10569088e99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with this sentiment. If we see traction, then we should see better kernel support and offloading. It should be trivial to get this working in something like VPP which can use DPDK to hw offload, entirely skipping the kernel in the data path. There are also techniques to bypass the initial memory allocation in the kernel such as ebpf used by cilium and memif used by vpp. My main concern at this point would be with cloud native environments with limited hw offloading support. E.g. if we run in AWS or GCE, better kernel support will probably be necessary. On Wed, Apr 4, 2018, 9:28 AM Phillip Hallam-Baker wrote: > I would not worry too much at this point. > > The reason we want to be able to work at the application level is > backwards compatibility. It has to be possible to deploy QUIC on any > machine even without OS support or it won't be deployable. > > It does not have to be performant on every platform. If people are using > QUIC, whatever needs to be moved into the kernel for performance reasons > will move there. > > > > > On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > >> I have no data to add on the Linux UDP stack, but another issue is the >> lack of netmap support in cloud hosting environments. >> I have not yet been working with this, but have looked into the problem >> and asked around. >> >> netmap is default in FreeBSD and optional in Linux. But neither works >> efficiently without a hypervisor patch that is also available for netmap= . >> With support for netmap, the user space application can send directly to >> the network adapter with very little overhead. There is also dpdk and so= me >> other interfaces that might be slightly faster but more vendor specific. >> >> Assuming an application has access to optimized netmap, the only hurdle >> is address lookup, but if the application also manages that, or at least >> does the caching, there shouldn=E2=80=99t be much in the way of OS inter= ference. >> >> Of course, netmap blocks the entire network stack, so no PING or SSH. >> CloudFlare added a netmap patch so only some traffic would be routed fra >> the network interface to netmap, and netmap also supports efficient pack= et >> forwarding to the OS or other applications. >> >> None of this works well in general, but for a cloud host that can be >> bootet automatically and destroyed rather than serviced, there is some >> opportunity. >> >> but only if cloud service providers starts adding support their supporte= d >> images and hypervisors. Not sure if any are working on this now. >> >> >> Mikkel >> >> >> On 4 April 2018 at 15.11.17, Ian Swett ( >> ianswett=3D40google.com@dmarc.ietf.org) wrote: >> >> I hope some of these patches will be available soon, but I'm not sure if >> soon is a month or 6. >> >> On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar wrote: >> >>> Thanks for sharing this Ian. >>> >>> >>> This definitely matches some of the observations we've seen as well in >>> the UDP write path. Some of the other paths that we saw that added over= head >>> was the route table lookup in linux udp stack. Connected UDP sockets di= d >>> amortize that. >>> >>> >>> I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is >>> there any indication of the timeline for these patches to make it to li= nux? >>> Would be happy to try any of these out to help iron out the API. >>> >>> >>> Subodh >>> ------------------------------ >>> *From:* QUIC on behalf of Ian Swett >>> >>> *Sent:* Tuesday, April 3, 2018 5:20:08 PM >>> *To:* IETF QUIC WG >>> *Subject:* UDP send costs in Linux >>> >>> One challenge with QUIC at the moment is the increased CPU cost of >>> sending UDP packets vs TCP payloads. I've seen this across every platf= orm >>> Google has deployed QUIC on, so it's a widespread issue. >>> >>> Here's an excellent presentation on what's causing the increased CPU >>> consumption on Linux from Willem de Bruijn(UDP starts on slide 9). >>> http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf >>> >>> And while you're thinking of CPU usage, it's worth looking at the >>> presentation on timing wheel based packet pacing(which is minimum relea= se >>> time based) and is ideal for QUIC(and TCP for that matter): >>> https://conferences.sigcomm.org/sigcomm/2017/files/program/ts-9-4-carou= sel..pdf >>> >>> >>> -Ian >>> >> > --0000000000005f97c10569088e99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with this sentiment. If we see traction, then we = should see better kernel support and offloading.=C2=A0
It should be trivial to get this working in someth= ing like VPP which can use DPDK to hw offload, entirely skipping the kernel= in the data path.=C2=A0

There are also techniques to bypass the initial memory allocation in the k= ernel such as ebpf used by cilium and memif used by vpp.

My main concern at this point would be wit= h cloud native environments with limited hw offloading support. E.g. if we = run in AWS or GCE, better kernel support will probably be necessary.
<= /div>
=
I w= ould not worry too much at this point.

The reason we want to be able to work at the application leve= l is backwards compatibility. It has to be possible to deploy QUIC on any m= achine even without OS support or it won't be deployable.

It does not have to be performant on e= very platform. If people are using QUIC, whatever needs to be moved into th= e kernel for performance reasons will move there.




On Wed, Apr 4, 2018 at 11:32 AM, Mikkel Fahn=C3=B8e J=C3=B8rg= ensen <mikkelfj@gmail.com> wrote:
I have no data to add on the Lin= ux UDP stack, but another issue is the lack of netmap support in cloud host= ing environments.
I have not yet been working= with this, but have looked into the problem and asked around.

netmap is default in F= reeBSD and optional in Linux. But neither works efficiently without a hyper= visor patch that is also available for netmap. With support for netmap, the= user space application can send directly to the network adapter with very = little overhead. There is also dpdk and some other interfaces that might be= slightly faster but more vendor specific.
Assuming an application has access to opti= mized netmap, the only hurdle is address lookup, but if the application als= o manages that, or at least does the caching, there shouldn=E2=80=99t be mu= ch in the way of OS interference.

<= div id=3D"m_-5905200581022919942m_1651742879505555491bloop_customfont" styl= e=3D"font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margi= n:0px;line-height:auto">Of course, netmap blocks the entire network stack, = so no PING or SSH. CloudFlare added a netmap patch so only some traffic wou= ld be routed fra the network interface to netmap, and netmap also supports = efficient packet forwarding to the OS or other applications.

None of this works wel= l in general, but for a cloud host that can be bootet automatically and des= troyed rather than serviced, there is some opportunity.

but only if cloud service providers starts adding support= their supported images and hypervisors. Not sure if any are working on thi= s now.


Mikkel


On 4 April 2018 at 15.11.17, Ian Swett (ianswett=3D40google.com@dmarc.ietf.org) wrote:

I hope some of these patches will be available soon, but I'm not sure if soon is a month or 6.

On Tue, Apr 3, 2018 at 10:50 PM Subodh Iyengar <s= ubodh@fb.com> wrote:

Thanks for sharing this Ian.


This definitely matches some of the observations we've seen as well in the UDP write path. Some of the other paths that we saw that added overhead was the route table lookup in linux udp stack. Connected UDP sockets did amortize that.


I'm looking forward to a smarter sendmmsg with GSO and zero copy. Is there any indication of the timeline for these patches to make it to linux? Would be happy to try any of these out to help iron out the API.


Subodh

From: QUIC <quic-bounces@ietf.or= g> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf..org>
Sent: Tuesday, April 3, 2018 5:20:08 PM
To: IETF QUIC WG
Subject: UDP send costs in Linux
=C2=A0
One challenge with QUIC at the moment is the increased CPU cost of sending UDP packets vs TCP payloads.=C2=A0 I've seen this across every platform Google has deployed QUIC on, so it's a widespread issue.

Here's an excellent presentation on what's causing the increased CPU consumption on Linux from=C2=A0Willem de Bruijn(UDP starts on slide 9).

And while you're thinking of CPU usage, it's worth looking at the presentation on timing wheel based packet pacing(which is minimum release time based) and is ideal for QUIC(and TCP for that matter):=C2=A0https://conferences.sigcomm.org/sigcomm/2017/files/program/ts-9-4= -carousel..pdf

-Ian

--0000000000005f97c10569088e99-- From nobody Wed Apr 4 12:55:57 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBBD12D869 for ; Wed, 4 Apr 2018 12:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522871755; bh=50buSiHQIbqKmR9hvCbidLfKGXN3+TbbnPLY1hqQyYo=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To; b=YkuRWaooQcoGfikgp98Csk/9JzKZx5JclHKeSGLxP1+lCOWlq4yK8MO0L5gNKHo5w Iy453mGEVc7Opq36vBSw8GU6PN9DMDA7SxlxXt12o+ese3CO+eKp0JIuraXOXn1iDe GLG4W9JH6HgcmfwPx2T8B9jDNu5GkwqTu1XifMo8= X-Mailbox-Line: From ilubashe@akamai.com Wed Apr 4 12:55:55 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCE512D82F; Wed, 4 Apr 2018 12:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522871755; bh=50buSiHQIbqKmR9hvCbidLfKGXN3+TbbnPLY1hqQyYo=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To; b=YkuRWaooQcoGfikgp98Csk/9JzKZx5JclHKeSGLxP1+lCOWlq4yK8MO0L5gNKHo5w Iy453mGEVc7Opq36vBSw8GU6PN9DMDA7SxlxXt12o+ese3CO+eKp0JIuraXOXn1iDe GLG4W9JH6HgcmfwPx2T8B9jDNu5GkwqTu1XifMo8= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19770126DCA for ; Wed, 4 Apr 2018 12:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1u7wBoHkcWBw for ; Wed, 4 Apr 2018 12:55:51 -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 ADC8D12D82F for ; Wed, 4 Apr 2018 12:55:51 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w34JqdNo018997; Wed, 4 Apr 2018 20:55:50 +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=50buSiHQIbqKmR9hvCbidLfKGXN3+TbbnPLY1hqQyYo=; b=F/IyIagijv5vSYZUmoE6oBsPdVyKkmsilUern8+Vd2N7GNw9qvZYhlDXycGtWNDVUkJF V6IAwSmZKxrG/CGtnbj07xTTFqThoDTn1p09HoIrF3f2bK8KlcnkN4/TlK9+7CFOKIuq KQq1/0WS4i0yThyBc+izOP4bY0ScnU1TB5Ib/OwK2Q7+F3tVenb7OdKr4jMkzCIeaq5V k7In3vK3r0kJ64WnZh2jLCJXnhz7r/y8zKVJ7iF9efLHMDgebbSB6gEzS7HAkB6bNgH4 11GubVuiHHHBSqfbVxyLNMILK1BMqVCEUvXKn7KW6ic2pD22W9iMgeVvbFXkr3KFI06C ow== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2h4vfv19yg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Apr 2018 20:55:50 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w34Jpa11026943; Wed, 4 Apr 2018 15:55:49 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2h25nv80k2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 Apr 2018 15:55:49 -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.1365.1; Wed, 4 Apr 2018 15:55:48 -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.1365.000; Wed, 4 Apr 2018 15:55:48 -0400 From: "Lubashev, Igor" CC: Lars Eggert , IETF QUIC WG Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GWvgm/QKk890OIh9EYaPY3H6PwqlkAgACTmoD//8ZYwA== Date: Wed, 4 Apr 2018 19:55:47 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804040196 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804040196 To: Praveen Balasubramanian To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= To: Mark Nottingham Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 19:55:55 -0000 VG8gcmVzdGF0ZSB0aGUgb3B0aW9uczoNCigxKSAtIFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbi4N CigyKSAtIFBlci1DSUQgb2Zmc2V0Lg0KKDMpIC0gUGxhaW4gdGV4dCBQTnMgYWNyb3NzIGNvbm5l Y3Rpb24gbWlncmF0aW9ucy4NCig0KSAtIFBlci1DSUQgUE4gc3BhY2VzLg0KDQpOb25lIG9mIHRo ZSBhbHRlcm5hdGl2ZXMgbWFzayB0aGUg4oCcY29ubmVjdGlvbiBtaWdyYXRpb27igJ0gZXZlbnQg ZnJvbSBhbiBvbi1wYXRoIG9ic2VydmVyLiAgVGhlIOKAnG9yaWdpbmFs4oCdIGNvbm5lY3Rpb24g ZXN0YWJsaXNobWVudCBpcyBkb25lIHZpYSBjbGVhcmx5IGlkZW50aWZpYWJsZSBoYW5kc2hha2Ug cGFja2V0cyBvbiBhIDUtdHVwbGUgYmVmb3JlIHNob3J0LWhlYWRlciBwYWNrZXRzIHNob3cgdXAs IHdoaWxlIOKAnGNvbm5lY3Rpb24gbWlncmF0aW9u4oCdIGV2ZW50cyBhcmUgaWRlbnRpZmlhYmxl IGJ5IHRoZSB1c2Ugb2YgYSBuZXcgQ0lEIHdpdGggc2hvcnQtaGVhZGVyIHBhY2tldHMgb24gYSBu ZXcgNS10dXBsZSB3L28gcHJlY2VkaW5nIGhhbmRzaGFrZSBwYWNrZXRzLg0KDQpBcyBpdCB3YXMg cG9pbnRlZCBvdXQgbWFueSB0aW1lcyAoZXNwZWNpYWxseSBieSBCcmlhbiksIGl0IGlzIG5vdCB0 aGF0IGhhcmQgdG8gY29ycmVsYXRlIGNlc3NhdGlvbiBvZiBwYWNrZXRzIGZyb20gb25lIDUtdHVw bGUgYW5kIGFwcGVhcmFuY2Ugb2YgYSBuZXcgcG9zdC3igJxjb25uZWN0aW9uIG1pZ3JhdGlvbuKA nSA1LXR1cGxlLCBlc3BlY2lhbGx5IGlmIGRlc3RpbmF0aW9uIElQcyBmb3IgYm90aCBhcmUgaWRl bnRpY2FsLiAgTW9yZW92ZXIsIHNpbmNlIGRldmljZXMgdGhhdCB3aXNoIHRvIG1haW50YWluIGNv bm5lY3Rpb25zIGR1cmluZyBtaWdyYXRpb24gd2lsbCBsaWtlbHkgbWlncmF0ZSBtdWx0aXBsZSBj b25uZWN0aW9ucywgdGhlIG9uLXBhdGggb2JzZXJ2ZXIgd2lsbCBzZWUgYSBncm91cCBvZiA1LXR1 cGxlcyBmcm9tIHRoZSBzYW1lIElQIGNlYXNlIGFjdGl2aXR5LCB3aGlsZSBhIHNpbWlsYXIgZ3Jv dXAgb2YgcG9zdC3igJxjb25uZWN0aW9uIG1pZ3JhdGlvbuKAnSA1LXR1cGxlcyBhcHBlYXJzIGZy b20gYSBkaWZmZXJlbnQgSVAsIGFsbCB3aXRoIG1hdGNoZWQgZGVzdGluYXRpb24gSVBzLg0KDQpH aXZlbiB0aGUgYWJvdmUsIEkgYW0gbGVmdCB3b25kZXJpbmcgaWYgaW5jcmVhc2luZyB0aGUgY29z dHMgZm9yIGNvbnRlbnQgaG9zdGluZywgaW5jcmVhc2luZyBwZXItcGFja2V0IHBvd2VyIHJlcXVp cmVtZW50cyBmb3IgbW9iaWxlIGFuZCBtaWNybyBkZXZpY2VzLCBhbmQgbWFraW5nIHRoZSBJbnRl cm5ldCBoYXJkZXIgdG8gdHJvdWJsZXNob290IGFuZCBvcGVyYXRlIGlzIHdvcnRoIHRoZSBtb3N0 bHkgaWxsdXNvcnkgcHJpdmFjeSBnYWlucyBvZiAoMSkuICBQYXRyaWNr4oCZcyDigJx0aGUgcHJp dmFjeSBpcyBhIG11c3QgaGF2ZeKAnSBpcyBhIGRlc2lyZSBJIHNoYXJlLCBidXQgZG9lcyAoMSkg cHJvdmlkZSBwcml2YWN5IGFnYWluc3QgYSBzb3BoaXN0aWNhdGVkIG9uLXBhdGggb2JzZXJ2ZXI/ DQoNCllldCwgKDIpIHNlZW1zIHNpbXBsZSBlbm91Z2ggYW5kIGEgZ29vZCBjb21wcm9taXNlLiAg QXMgTWlrZSBwb2ludHMgb3V0LCBpdCBhbGxvd3MgYW4gb24tcGF0aCBvYnNlcnZlciB3aG8gY2Fu IGxpbmsgQ0lEcyBhY3Jvc3Mg4oCcY29ubmVjdGlvbiBtaWdyYXRpb25z4oCdIHRvIGluZmVyIFBO cy4gIEJ1dCBpZiBDSURzIGFyZSBhbHJlYWR5IGxpbmtlZCwgdGhlcmUgaXMgbm8gbW9yZSBwcml2 YWN5IGFyZ3VtZW50IHRvIGJlIG1hZGUgYW55d2F5LiAgT25lIHRoaW5nICgyKSBkb2VzIG5vdCBh bGxvdyBhbiBvbi1wYXRoIG9ic2VydmVyIHRvIGRvIGlzIHRvIGxpbmsgQ0lEcyB2aWEgUE4gYW5h bHlzaXMuICAoVGhvdWdoIGl0IHN0aWxsIHNlZW1zIGxpa2UgdGhlIHByaXZhY3kgZ2FpbnMgZnJv bSBhbnkgb2YgdGhlIGFib3ZlIGFyZSBtb3N0bHkgYW4gaWxsdXNpb24uKSAgU28gbXkgdm90ZSBp cyBmb3IgKDIpLg0KDQotIElnb3INCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gW21haWx0bzpwcmF2Yj00MG1pY3Jvc29mdC5jb21A ZG1hcmMuaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwNCwgMjAxOCAzOjE1IFBN DQpUbzogTWlyamEgS8O8aGxld2luZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD47 IE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldD4NCkNjOiBMYXJzIEVnZ2VydCA8bGFyc0Bl Z2dlcnQub3JnPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUkU6IEdl dHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpJIHRvbyBk aXNhZ3JlZSB3aXRoIHRoZSBhc3Nlc3NtZW50IG9mIHRoZSBzaXR1YXRpb24uICsxIHRvIGV2ZXJ5 dGhpbmcgTWlyamEgc2FpZC4NCg0KPj4gdGhlcmUgaXMgbm8gKnJlcXVpcmVtZW50KiB0aGF0IHdl IHByb2R1Y2UgYSBwcm90b2NvbCB0aGF0IGlzIGFibGUgdG8gYmUgYWNjZWxlcmF0ZWQgYnkgaGFy ZHdhcmUuDQpJdCBpcyBob3dldmVyIGEgcmVxdWlyZW1lbnQgZm9yIGRlcGxveW1lbnQgdGhhdCB3 ZSBiZSBhYmxlIHRvIG9mZmxvYWQgUVVJQy4gQSBsYXJnZSBwYXJ0IG9mIHdvcmsgd2UgZG8gaW4g VENQIGlzIGFjY2VsZXJhdGlvbiBpbiBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUuIElmIFFVSUMgaGFz IHRvIGV2b2x2ZSBmcm9tIGV4cGVyaW1lbnQgdG8gYnJvYWQgZGVwbG95bWVudCBwZXJmb3JtYW5j ZSBpcyBhIGtleSBnb2FsLiBUaGlzIGlzIGJyb3VnaHQgdXAgc2V2ZXJhbCB0aW1lcyBpbiBUQ1Ag d29ya2luZyBncm91cCB3aGVyZSB3ZSBzZWUgcHJvcG9zYWxzIHRoYXQgd291bGRu4oCZdCB3b3Jr IHdpdGggd2lkZWx5IGRlcGxveWVkIHNvZnR3YXJlIGFuZCBoYXJkd2FyZSBhY2NlbGVyYXRpb25z LiANCg0KV2hldGhlciB3ZSBsaWtlIGl0IG9yIG5vdCBwZXJmb3JtYW5jZSBpcyBhIGtleSByZXF1 aXJlbWVudCBmb3IgUVVJQyBvbiBzZXJ2ZXJzIGFuZCBmb3IgZGF0YWNlbnRlciBzY2VuYXJpb3Mu IEV2ZW4gSWFuIG1lbnRpb25lZCBiZWZvcmUgdGhhdCBoZSdkIG5vdCB3YW50IHRvIGRvIFBORSB3 aXRoaW4gREMgYW5kIEkgYWdyZWUuIE1vc3QgY29ubmVjdGlvbnMgd2lsbCBhbHNvIG5vdCBiZSBk b2luZyBtaWdyYXRpb24gb3IgdXNpbmcgbXVsdGkgcGF0aCBzbyB3aHkgcGF5IHRoZSBleHRyYSBv dmVyaGVhZCBpbiB0aGUgY29tbW9uIGNhc2UgZm9yIG5vIGJlbmVmaXQ/DQoNClNpbmNlIFBORSBk b2VzbuKAmXQgYWZmZWN0IHRoZSBpbnZhcmlhbnRzIChpdHMgc2ltcGx5IGFuIGV4dHJhIHN0ZXAg cG9zdCBwYWNrZXRpemF0aW9uIGFuZCBwcmUgcGFyc2luZyksIHBsZWFzZSBleHBsYWluIHdoeSBp dCB3b3VsZCBibG9jayBwcm9ncmVzcyBvbiBvdGhlciBmcm9udHM/IFdoYXQgaXMgdGhlIGxpc3Qg b2YgdGhpbmdzIHRoYXQgZ2V0IGJsb2NrZWQ/DQoNClBsZWFzZSBsZXQgdXMgbm90IHJ1c2ggaW50 byBhIGRlc2lnbiB0aGF0IGltcGFjdHMgcGVyIHBhY2tldCBwcm9jZXNzaW5nIGNvc3RzIHdpdGgg bm8gY2xlYXIgYXJ0aWN1bGF0aW9uIG9mIHRoZSBwcm9ibGVtIGFuZCB0aGUgYmVuZWZpdHMuIA0K DQpGcm9tIHdoYXQgSSBjYW4gdGVsbCB0aGVyZSBpcyB3aWRlIGRpc2FncmVlbWVudCBpbiB0aGUg Z3JvdXAgYW5kIG5vdGhpbmcgcmVzZW1ibGluZyBjb25zZW5zdXMuIFRoZSBmYWN0IHRoYXQgd2Ug aGF2ZSBwb29yIHJlcHJlc2VudGF0aW9uIGZyb20gaGFyZHdhcmUgZGV2ZWxvcGVycyBhbmQgcHVi bGljIGNsb3VkIHByb3ZpZGVycyBpcyBmdXJ0aGVyIHNrZXdpbmcgdGhlIHBlcmNlcHRpb24uIA0K DQpNeSByZWNvbW1lbmRhdGlvbnM6DQoxLiBMZWF2ZSB0aGUgY3VycmVudCBkcmFmdCBhcyBpcy4g TWFrZSBzdXJlIHdlIGhhdmUgc29tZSBwcm92aXNpb24gZm9yIGdyZWFzaW5nIHRoZSBQTiB0byBw cmV2ZW50IG9zc2lmaWNhdGlvbi4NCjIuIEV4cGxvcmUgbXVsdGlwbGUgUE4gc3BhY2VzIGZvciBj b25uZWN0aW9uIG1pZ3JhdGlvbiAoYW5kIGV2ZW50dWFsbHkgbXVsdGlwYXRoKS4NCjMuIE1ha2Ug UE5FIGFuIG9wdGlvbmFsIG5lZ290aWF0ZWQgZXh0ZW5zaW9uIGZvciBpbXBsZW1lbnRhdGlvbnMg dGhhdCB3YW50IHRvIGRvIGNvbm5lY3Rpb24gbWlncmF0aW9uIGluIFYxIHdpdGggdGhlIGNhdmVh dCB0aGF0IHdlIHdpbGwgcmV2aXNpdCB0aGlzIGZvciBWMiB3aGVuIHdlIGRvIG11bHRpcGF0aC4N CjQuIFNvbGljaXQgbW9yZSBmZWVkYmFjayBvbiB0aGUgcHJvdG9jb2wgZnJvbSBoYXJkd2FyZSB2 ZW5kb3JzIGFuZCBwdWJsaWMgYW5kIHByaXZhdGUgY2xvdWQgcHJvdmlkZXJzLiBJIGNhbiB0cnkg dG8gbG9vcCBpbiBtb3JlIGZvbGtzIGJ1dCBvdGhlcnMgc2hvdWxkIHRvby4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBNaXJqYSBLw7xobGV3aW5kDQpTZW50OiBXZWRuZXNkYXksIEFwcmls IDQsIDIwMTggMzoyNyBBTQ0KVG86IE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldD4NCkNj OiBMYXJzIEVnZ2VydCA8bGFyc0BlZ2dlcnQub3JnPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIg ZW5jcnlwdGlvbg0KDQpIaSBNYXJrLA0KDQp3aXRob3V0IGludGVuZGluZyB0byBzdGF0ZSBhIHRl Y2huaWNhbCBvcGluaW9uLCBJIHRoaW5rIEkgbmVlZCB0byBkaXNhZ3JlZSB3aXRoIHlvdXIgYXNz ZXNzbWVudCBvZiB0aGUgc2l0dWF0aW9uLiBQbGVhc2Ugc2VlIGJlbG93Lg0KDQo+IEFtIDA0LjA0 LjIwMTggdW0gMDY6NTggc2NocmllYiBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ+Og0K PiANCj4gSGkgZXZlcnlvbmUsDQo+IA0KPiBUaGUgZWRpdG9ycyBoYXZlIHRvbGQgeW91ciBjaGFp cnMgdGhhdCB0aGlzIGlzc3VlIGlzIHN0YXJ0aW5nIHRvIGJsb2NrIHByb2dyZXNzIG9uIG90aGVy IGFzcGVjdHMgb2YgUVVJQy4gQ29taW5nIHRvIGNvbnNlbnN1cyBvbiBpdCBzb29uIChpLmUuLCBi ZWZvcmUgU3RvY2tob2xtLCBpZiBwb3NzaWJsZSkgd291bGQgYmUgZ29vZC4NCj4gDQo+IEl0IGxv b2tzIGxpa2UgdGhpcyB0aHJlYWQgaGFzIGNvbWUgdG8gYSBuYXR1cmFsIHBhdXNlLiBSZWFkaW5n IHRocm91Z2ggaXQsIEkgdGhpbmsgd2UgYWdyZWUgdGhlcmUgYXJlIHNvbWUgdW5wbGVhc2FudCB0 cmFkZW9mZnMgaGVyZSwgYnV0IHNvIGZhciB3ZSBoYXZlIG9ubHkgb25lIGNvbmNyZXRlIHByb3Bv c2FsIC0tIFBSIzEwNzkuDQoNClRoZSBvdGhlciBwcm9wb3NhbCBpcyB0byB1c2UgYSByYW5kb20g b2Zmc2V0IHRoYXQgY2FuL3Nob3VsZCBiZSBjaGFuZ2VkIHdoZW4gdGhlIGNvbm5lY3Rpb24gSUQg aXMgY2hhbmdlZC4gV2hpY2ggaXMgbW9zdGx5IGlubGluZSB3aXRoIHdoYXQgdGhlIGRyYWZ0IGN1 cnJlbnRseSBzYXlzLg0KPiANCj4gTXkgQVUkLjA1IC0gV2hpbGUgd2UncmUgY2hhcnRlcmVkIHRv IHByb2R1Y2UgYSBwcm90b2NvbCB0aGF0J3MgZW5jcnlwdGVkIGFzIG11Y2ggYXMgb3BlcmF0aW9u YWwgY29uY2VybnMgYWxsb3csDQoNCkkgZG9u4oCZdCB0aGluayB0aGlzIGlzIHdoYXQgdGhlIGNo YXJ0ZXIgc2F5LiBUaGUgY2hhcnRlciBzYXlzICJQcm92aWRpbmcgYWx3YXlzLXNlY3VyZSB0cmFu c3BvcnQsIHVzaW5nIFRMUyAxLjMgYnkgZGVmYXVsdC7igJwgcGx1cyBhbm90aGVyIHBhcmFncmFw aCB0aGF0IHRhbGtzIGFib3V0IFRMUzEuMy4gSXQgZG9lcyBub3Qgc3BlbGwgb3V0IHRoZSBkZXNp cmUgb2Ygc29tZSBpbmRpdmlkdWFsIHRvIOKAnmVuY3J5cHQgYXMgbXVjaCBhcyBwb3NzaWJsZeKA nC4gDQoNCj4gYW5kIHRoYXQgcHJpdmFjeSBpcyBhIG5hdHVyYWwgZXh0ZW5zaW9uIG9mIHRoYXQg KGVzcGVjaWFsbHkgaW4gbGlnaHQgb2YgUkZDNzI1OCBhbmQgUkZDNjk3MyksIHRoZXJlIGlzIG5v ICpyZXF1aXJlbWVudCogdGhhdCB3ZSBwcm9kdWNlIGEgcHJvdG9jb2wgdGhhdCBpcyBhYmxlIHRv IGJlIGFjY2VsZXJhdGVkIGJ5IGhhcmR3YXJlLg0KDQpOb3QgdGhlcmUgaXMgbm8gcmVxdWlyZW1l bnQgdGhhdCB0aGUgcHJvdG9jb2wgbmVlZCB0byBiZSBhY2NlbGVyYXRlZCBieSBoYXJkd2FyZS4g SG93ZXZlciwgbm90IGFsbCByZXF1aXJlbWVudCBhcmUgbGlzdGVkIGluIHRoZSBjaGFydGVyLiBX ZSBhcyBhIGdyb3VwIGhhdmUgdG8gZGVmaW5lIHRoZSByZXF1aXJlbWVudC4gSG93ZXZlciwgdGhl cmUgaXMgb2YgY291cnNlIGFuIGltcGxpY2l0IHJlcXVpcmVtZW50IGZvciBhbGwgd29yayBpbiB0 aGUgSUVGVCB0aGF0IGlzIG11c3QgYmUgZGVwbG95YWJsZSBhbmQgc2VydmUgdGhlIG5lZWRzIG9m IHRob3NlIHBlb3BsZSB3aG8gd2FudCB0byBkZXBsb3kgaXQuDQoNCj4gDQo+IFRoYXQgYmVpbmcg dGhlIGNhc2UsIEkgdGhpbmsgd2UgbmVlZCB0byBhc2sgb3Vyc2VsdmVzIGlmIHdlIGJlbGlldmUg dGhhdCBpbmNsdXNpb24gb2YgUFIjMTA3OSB3aWxsIHNpZ25pZmljYW50bHkgaW5oaWJpdCBkZXBs b3ltZW50IG9mIHRoZSBwcm90b2NvbC4gQmFzZWQgb24gdGhlIGRpc2N1c3Npb24gc28gZmFyLCB0 aGF0IGRvZXNuJ3Qgc2VlbSB0byBiZSB0aGUgY2FzZSwgYnV0IEknZCBiZSBpbnRlcmVzdGVkIHRv IGhlYXIgd2hhdCBvdGhlcnMgdGhpbmsuDQoNCkhlcmUgbXkgYXNzZXNzbWVudCBpcyBhbHNvIGRp ZmZlcmVudC4gVGhlcmUgYXJlIG11bHRpcGxlIHBlb3BsZSB0aGF0IGhhdmUgcmFpc2VkIGNvbmNl cm5zIHRoYXQgdGhpcyBjb3VsZCBoaW5kZXIgZGVwbG95bWVudC4NCj4gDQo+IElmIHdlIGNhbiBn ZXQgdG8gY29uc2Vuc3VzIHRvIGluY29ycG9yYXRlIHRoZSBQUiwgYW5kIGZvbGtzIGNvbWUgYmFj ayBsYXRlciB3aXRoIGEgbW9yZSBoYXJkd2FyZS1mcmllbmRseSByZXBsYWNlbWVudCB0aGF0IGRv ZXNuJ3QgY2hhbmdlIHRoZSBJbnZhcmlhbnRzIG9yIGluY3JlYXNlIGxpbmthYmlsaXR5LCBJIHN1 c3BlY3QgdGhlIFdHIHdpbGwgYmUgYW1lbmFibGUgdG8gdGhhdC4NCg0KSSBkb27igJl0IHRoaW5r IHRvIGp1c3QgZ28gd2l0aCB3aGF0IHdlIGhhdmUgZXZlbiB0aG91Z2ggdGhlcmUgYXJlIGNvbmNl cm5zLCBpcyB0aGUgcmlnaHQgYXBwcm9hY2ggYW5kIGRlZmluaXRlbHkgbm90IHRoZSBhcHByb2Fj aCB0aGF0IHdhcyBjaG9zZW4gZm9yIG90aGVyIHByb3Bvc2Fscy4gSW4gdGhlIHNha2Ugb2YgZ2V0 dGluZyB2ZXJzaW9uIHYxIG91dCBxdWlja2x5LCBJIHdvdWxkIHRoaW5rIHRoYXQgbm90IGluY29y cG9yYXRpbmcgYW5vdGhlciBjaGFuZ2UgdGhhdCBkb2VzIG5vdCBoYXZlIGNvbnNlbnN1cyBpcyB0 aGUgcHJvcG9zZXIgYXBwcm9hY2guDQoNCk1pcmphDQoNCg0KDQo+IA0KPiBXaGF0IGRvIGZvbGtz IHRoaW5rPw0KPiANCj4gQ2hlZXJzLA0KPiANCj4gDQo+PiBPbiAyOSBNYXIgMjAxOCwgYXQgMTE6 MzkgYW0sIElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPiB3 cm90ZToNCj4+IA0KPj4gVGhhbmtzIGZvciB0aGUgbmljZSBzdW1tYXJ5IEphbmEuDQo+PiANCj4+ IEFzIG11Y2ggYXMgSSdkIGxvdmUgdG8gaGF2ZSBlYXNpZXIgY3J5cHRvIEhXIGFjY2VsZXJhdGlv biwgSSd2ZSBlbmRlZCB1cCBhcnJpdmluZyBhdCB0aGUgc2FtZSBjb25jbHVzaW9uLiAgSSBkb24n dCB3YW50IHRvIGJpdGUgb2ZmIHRoZSB3b3JrIHRvIGRvIHByb3BlciBtdWx0aXBhdGggaW4gUVVJ QyB2MSwgd2hpY2ggSSB0aGluayBpcyB0aGUgb25seSBvdGhlciByZWFzb25hYmxlIG9wdGlvbiBv ZiB0aG9zZSBDaHJpc3RpYW4gb3V0bGluZWQuDQo+PiANCj4+IElmIHNvbWVvbmUgY29tZXMgdXAg d2l0aCBhIHdheSB0byB0cmFuc2Zvcm0gcGFja2V0IG51bWJlciB0byBtYWtlIGl0IG5vbi1saW5r YWJsZSwgYnV0IGRvZXNuJ3QgaGF2ZSB0aGUgZG93bnNpZGUgb2YgbWFraW5nIGhhcmR3YXJlIG9m ZmxvYWQgZGlmZmljdWx0LCB0aGVuIEknbSBvcGVuIHRvIGl0LiAgQnV0IHdlJ3ZlIGJlZW4gdGFs a2luZyBhYm91dCB0aGlzIGZvciAyIG1vbnRocyB3aXRob3V0IGFueSBub3RhYmxlIGltcHJvdmVt ZW50cyBvdmVyIE1hcnRpbidzIFBSLg0KPj4gDQo+PiBHaXZlbiB3ZSBuZXZlciB0YWxrIGFib3V0 IGFueSBpc3N1ZSBvbmx5IG9uY2UgaW4gUVVJQywgSSdtIHN1cmUgdGhpcyB3aWxsIGNvbWUgdXAg YWdhaW4sIGJ1dCBmb3IgdGhlIHRpbWUgYmVpbmcgSSB0aGluayAjMTA3OSBpcyB0aGUgYmVzdCBv cHRpb24gd2UgaGF2ZS4NCj4+IA0KPj4gDQo+PiANCj4+IE9uIFdlZCwgTWFyIDI4LCAyMDE4IGF0 IDg6MDMgUE0gSmFuYSBJeWVuZ2FyIDxqcmkuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPj4gQSBm ZXcgcXVpY2sgdGhvdWdodHMgYXMgSSBjYXRjaCB1cCBvbiB0aGlzIHRocmVhZC4NCj4+IA0KPj4g SSBzcGVudCBzb21lIHRpbWUgbGFzdCB3ZWVrIHdvcmtpbmcgdGhyb3VnaCBhIGRlc2lnbiB1c2lu ZyBtdWx0aXBsZSBQTiBzcGFjZXMsIGFuZCBpdCBpcyBxdWl0ZSBkb2FibGUuIEkgc3VzcGVjdCB3 ZSdsbCBoZWFkIHRvd2FyZHMgbXVsdGlwbGUgUE4gc3BhY2VzIGFzIHdlIGNvbnNpZGVyIG11bHRp cGF0aCBpbiB0aGUgZnV0dXJlLiBUaGF0IHNhaWQsIHRoZXJlIGlzIGNvbXBsZXhpdHkgKGFzIENo cmlzdGlhbiBub3RlcykuIFRoaXMgY29tcGxleGl0eSBtYXkgYmUgd2FycmFudGVkIHdoZW4gZG9p bmcgbXVsdGlwYXRoIGluIHYyIG9yIGxhdGVyLCBidXQgSSdtIG5vdCBjb252aW5jZWQgdGhhdCB0 aGlzIGlzIG5lY2Vzc2FyeSBhcyBhIGRlc2lnbiBwcmltaXRpdmUgZm9yIFFVSUN2MS4gDQo+PiAN Cj4+IFdlIG1heSB3YW50IHRvIGNyZWF0aXZlbHkgdXNlIHRoZSBQTiBiaXRzIGluIHYyLCBzYXkg dG8gZW5jb2RlIGEgcGF0aCBJRCBhbmQgYSBQTiwgZm9yIG11bHRpcGF0aC4gV2Ugd2FudCB0byBy ZXRhaW4gZmxleGliaWxpdHkgaW4gdGhlc2UgYml0cyBnb2luZyBpbnRvIHYyLiBXZSd2ZSB1c2Vk IGVuY3J5cHRpb24gdG8gZW5zdXJlIHRoYXQgd2UgZG9uJ3QgbG9zZSBmbGV4aWJpbGl0eSBlbHNl d2hlcmUgaW4gdGhlIGhlYWRlciwgYW5kIGl0IGZvbGxvd3MgdGhhdCB3ZSBzaG91bGQgdXNlIFBO RSB0byByZXRhaW4gZmxleGliaWxpdHkgaW4gdGhlc2UgYml0cyBhcyB3ZWxsLiAoU2ltcGxpY2l0 eSBvZiBkZXNpZ24gaXMgdGhlIG90aGVyIHZhbHVlIGluIHVzaW5nIFBORSwgc2luY2UgaGFuZGxp bmcgbWlncmF0aW9uIGxpbmthYmlsaXR5IGlzIG5vbi10cml2aWFsIHdpdGhvdXQgaXQuKQ0KPj4g DQo+PiBUaGlzIGxlYXZlcyB0aGUgcXVlc3Rpb24gb2YgSFcgYWNjZWxlcmF0aW9uIGJlaW5nIGF0 IGxvZ2dlcmhlYWRzIHdpdGggdGhlIGRlc2lnbiBpbiBQUiAjMTA3OS4gRmlyc3QsIEkgZXhwZWN0 IHRoYXQgdGhlIHByaW1hcnkgYmVuZWZpdCBvZiBhY2NlbGVyYXRpb24gd2lsbCBiZSBpbiBEQyBl bnZpcm9ubWVudHMuIFllcywgdGhlcmUgYXJlIHNvbWUgZ2FpbnMgdG8gYmUgaGFkIGluIHNlcnZp bmcgdGhlIHB1YmxpYyBJbnRlcm5ldCBhcyB3ZWxsLCBidXQgSSdtIHVuY29udmluY2VkIHRoYXQg dGhpcyBpcyB0aGUgZHJpdmluZyB1c2UgY2FzZSBmb3IgaGFyZHdhcmUgYWNjZWxlcmF0aW9uLiBJ IHVuZGVyc3RhbmQgdGhhdCBvdGhlcnMgbWF5IGRpc2FncmVlIHdpdGggbWUgaGVyZS4NCj4+IA0K Pj4gQUZBSUssIFFVSUMgaGFzIG5vdCBiZWVuIHVzZWQgaW4gREMgZW52aXJvbm1lbnRzIHlldC4g SSBleHBlY3QgdGhlcmUgYXJlIG90aGVyIHRoaW5ncyBpbiB0aGUgcHJvdG9jb2wgdGhhdCB3ZSdk IHdhbnQgdG8gY2hhbmdlIGFzIHdlIGdhaW4gZXhwZXJpZW5jZSBkZXBsb3lpbmcgUVVJQyBpbiBE Q3MuIFNwaW5uaW5nIHVwIGEgbmV3IHZlcnNpb24gdG8gdHJ5IFFVSUMgd2l0aGluIERDcyBpcyBu b3Qgb25seSBhcHByb3ByaWF0ZSwgSSB3b3VsZCByZWNvbW1lbmQgaXQuIFRoaXMgYWxsb3dzIGZv ciByYXBpZCBpdGVyYXRpb25zIGludGVybmFsbHksIGFuZCB0aGUgZXhwZXJpZW5jZSBjYW4gZHJp dmUgc3Vic2VxdWVudCBjaGFuZ2VzIHRvIFFVSUMuIEl0J3Mgd2hhdCAqSSogd291bGQgZG8gaWYg SSB3YXMgdG8gZGVwbG95IFFVSUMgaW5zaWRlIGEgREMuDQo+PiANCj4+IFNvLCBpbiBzaG9ydCwg SSB0aGluayB3ZSBzaG91bGQgZ28gYWhlYWQgd2l0aCBQUiMgMTA3OS4gVGhpcyBlbnN1cmVzIHRo YXQgZnV0dXJlIHZlcnNpb25zIGFyZSBndWFyYW50ZWVkIHRoZSBmbGV4aWJpbGl0eSB0byBjaGFu Z2UgdGhlIFBOIGJpdHMgZm9yIGJldHRlciBzdXBwb3J0IG9mIEhXIGFjY2VsZXJhdGlvbiBvciBt dWx0aXBhdGggb3Igd2hhdC1oYXZlLXlvdS4NCj4+IA0KPj4gLSBqYW5hDQo+PiANCj4+IE9uIE1h ciAyNiwgMjAxOCA5OjQxIEFNLCAiQ2hyaXN0aWFuIEh1aXRlbWEiIDxodWl0ZW1hQGh1aXRlbWEu bmV0PiB3cm90ZToNCj4+IA0KPj4gT24gMy8yNi8yMDE4IDg6MjAgQU0sIFN3aW5kZWxscywgVGhv bWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSkgd3JvdGU6DQo+Pj4gTG9va2luZyBhdCBodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy RmVuLndpa2lwZWRpYS5vcmclMkZ3aWtpJTJGQUVTX2luc3RydWN0aW9uX3NldCUyM0ludGVsX2Fu ZF9BTURfeDg2X2FyY2hpdGVjdHVyZSZkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5j b20lN0MxNGYyNzhhYjM3Njk0NjlhNDRmOTA4ZDU5YTE2YTJkNiU3QzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY1ODQzNDQzODM5NTk3NjUmc2RhdGE9YU9IYzdG Wm9JQkNFMU9scW1OcHZkTU0wbnRMZXJaM0ZwcUVTVmo4NXpmRSUzRCZyZXNlcnZlZD0wIGl0IHNl ZW1zIHRvIGltcGx5IGEgbGFyZ2UgcmFuZ2Ugb2Ygc2VydmVyLCBkZXNrdG9wIGFuZCBtb2JpbGUg Y2hpcHMgYWxsIGhhdmUgYSBDUFUgaW5zdHJ1Y3Rpb24gc2V0IGF2YWlsYWJsZSB0byBkbyBBRVMg YWNjZWxlcmF0aW9uIGFuZCBvdGhlciBzaW1pbGFyIG9wZXJhdGlvbnMgKG90aGVyIGluc3RydWN0 aW9uIHNldHMgYXJlIGFsc28gYXZhaWxhYmxlKS4NCj4+PiANCj4+PiBJZiB3ZSBhcmUgY29uc2lk ZXJpbmcgdGhlIEFFUyBpbnN0cnVjdGlvbnMgdGhlbiBpdCBsb29rcyBsaWtlIGl0IGlzIChvciBh dCBsZWFzdCB3aWxsIGJlIGluIHRoZSBuZWFyIGZ1dHVyZSkgYSBzaXplYWJsZSBwcm9wb3J0aW9u IG9mIHRoZSBwdWJsaWMgaW50ZXJuZXQgaGF2ZSBpdCB0byBiZSB1c2VkLg0KPj4+IA0KPj4gDQo+ PiBDZXJ0YWlubHksIGJ1dCB0aGF0J3Mgbm90IHRoZSBjdXJyZW50IGRlYmF0ZS4gUFIgIzEwNzkg aXMgZnVsbHkgY29tcGF0aWJsZSB3aXRoIHVzZSBvZiB0aGUgQUVTIGluc3RydWN0aW9ucy4gVGhl IGlzc3VlIG9mIHRoZSBkZWJhdGUgaXMgdGhhdCB0aGUgbWVjaGFuaXNtIGluIFBSICMxMDc5IHJl cXVpcmVkIGRvdWJsZSBidWZmZXJpbmcsIGZpcnN0IGVuY3J5cHQgdGhlIHBheWxvYWQsIHRoZW4g dXNlIHRoZSByZXN1bHQgb2YgdGhlIGVuY3J5cHRpb24gdG8gZW5jcnlwdCB0aGUgUE4uIFRoaXMg aXMgbm90IGFuIGlzc3VlIGluIGEgc29mdHdhcmUgaW1wbGVtZW50YXRpb24gdGhhdCBjYW4gcmVh ZGlseSBhY2Nlc3MgYWxsIGJ5dGVzIG9mIHRoZSBwYWNrZXQgZnJvbSBtZW1vcnksIGJ1dCBpdCBt YXkgYmUgYW4gaXNzdWUgaW4gc29tZSBoYXJkd2FyZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhcmUg ZGVzaWduZWQgdG8gZG8ganVzdCBvbmUgcGFzcyBvdmVyIHRoZSBkYXRhLg0KPj4gDQo+PiANCj4+ IC0tIENocmlzdGlhbiBIdWl0ZW1hDQo+PiANCj4+IA0KPj4gDQo+IA0KPiAtLQ0KPiBNYXJrIE5v dHRpbmdoYW0gICBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnd3dy5tbm90Lm5ldCUyRiZkYXRhPTAyJTdDMDElN0NwcmF2YiU0 MG1pY3Jvc29mdC5jb20lN0MxNGYyNzhhYjM3Njk0NjlhNDRmOTA4ZDU5YTE2YTJkNiU3QzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY1ODQzNDQzODM5NTk3NjUm c2RhdGE9UlhiYTJUeXZZejZvdGVjRUhvTENUNHRaMkk3RW9keERpeVB4V3JuJTJGbkF3JTNEJnJl c2VydmVkPTANCj4gDQoNCg== From nobody Wed Apr 4 12:56:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C41512E892 for ; Wed, 4 Apr 2018 12:55:59 -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=unavailable 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 x7xAj7O8MZvz for ; Wed, 4 Apr 2018 12:55:56 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2335A12D82F for ; Wed, 4 Apr 2018 12:55:56 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w34JqdNo018997; Wed, 4 Apr 2018 20:55:50 +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=50buSiHQIbqKmR9hvCbidLfKGXN3+TbbnPLY1hqQyYo=; b=F/IyIagijv5vSYZUmoE6oBsPdVyKkmsilUern8+Vd2N7GNw9qvZYhlDXycGtWNDVUkJF V6IAwSmZKxrG/CGtnbj07xTTFqThoDTn1p09HoIrF3f2bK8KlcnkN4/TlK9+7CFOKIuq KQq1/0WS4i0yThyBc+izOP4bY0ScnU1TB5Ib/OwK2Q7+F3tVenb7OdKr4jMkzCIeaq5V k7In3vK3r0kJ64WnZh2jLCJXnhz7r/y8zKVJ7iF9efLHMDgebbSB6gEzS7HAkB6bNgH4 11GubVuiHHHBSqfbVxyLNMILK1BMqVCEUvXKn7KW6ic2pD22W9iMgeVvbFXkr3KFI06C ow== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2h4vfv19yg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Apr 2018 20:55:50 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w34Jpa11026943; Wed, 4 Apr 2018 15:55:49 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2h25nv80k2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 Apr 2018 15:55:49 -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.1365.1; Wed, 4 Apr 2018 15:55:48 -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.1365.000; Wed, 4 Apr 2018 15:55:48 -0400 From: "Lubashev, Igor" To: Praveen Balasubramanian , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "Mark Nottingham" CC: Lars Eggert , IETF QUIC WG Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GWvgm/QKk890OIh9EYaPY3H6PwqlkAgACTmoD//8ZYwA== Date: Wed, 4 Apr 2018 19:55:47 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804040196 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804040196 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 19:56:02 -0000 VG8gcmVzdGF0ZSB0aGUgb3B0aW9uczoNCigxKSAtIFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbi4N CigyKSAtIFBlci1DSUQgb2Zmc2V0Lg0KKDMpIC0gUGxhaW4gdGV4dCBQTnMgYWNyb3NzIGNvbm5l Y3Rpb24gbWlncmF0aW9ucy4NCig0KSAtIFBlci1DSUQgUE4gc3BhY2VzLg0KDQpOb25lIG9mIHRo ZSBhbHRlcm5hdGl2ZXMgbWFzayB0aGUg4oCcY29ubmVjdGlvbiBtaWdyYXRpb27igJ0gZXZlbnQg ZnJvbSBhbiBvbi1wYXRoIG9ic2VydmVyLiAgVGhlIOKAnG9yaWdpbmFs4oCdIGNvbm5lY3Rpb24g ZXN0YWJsaXNobWVudCBpcyBkb25lIHZpYSBjbGVhcmx5IGlkZW50aWZpYWJsZSBoYW5kc2hha2Ug cGFja2V0cyBvbiBhIDUtdHVwbGUgYmVmb3JlIHNob3J0LWhlYWRlciBwYWNrZXRzIHNob3cgdXAs IHdoaWxlIOKAnGNvbm5lY3Rpb24gbWlncmF0aW9u4oCdIGV2ZW50cyBhcmUgaWRlbnRpZmlhYmxl IGJ5IHRoZSB1c2Ugb2YgYSBuZXcgQ0lEIHdpdGggc2hvcnQtaGVhZGVyIHBhY2tldHMgb24gYSBu ZXcgNS10dXBsZSB3L28gcHJlY2VkaW5nIGhhbmRzaGFrZSBwYWNrZXRzLg0KDQpBcyBpdCB3YXMg cG9pbnRlZCBvdXQgbWFueSB0aW1lcyAoZXNwZWNpYWxseSBieSBCcmlhbiksIGl0IGlzIG5vdCB0 aGF0IGhhcmQgdG8gY29ycmVsYXRlIGNlc3NhdGlvbiBvZiBwYWNrZXRzIGZyb20gb25lIDUtdHVw bGUgYW5kIGFwcGVhcmFuY2Ugb2YgYSBuZXcgcG9zdC3igJxjb25uZWN0aW9uIG1pZ3JhdGlvbuKA nSA1LXR1cGxlLCBlc3BlY2lhbGx5IGlmIGRlc3RpbmF0aW9uIElQcyBmb3IgYm90aCBhcmUgaWRl bnRpY2FsLiAgTW9yZW92ZXIsIHNpbmNlIGRldmljZXMgdGhhdCB3aXNoIHRvIG1haW50YWluIGNv bm5lY3Rpb25zIGR1cmluZyBtaWdyYXRpb24gd2lsbCBsaWtlbHkgbWlncmF0ZSBtdWx0aXBsZSBj b25uZWN0aW9ucywgdGhlIG9uLXBhdGggb2JzZXJ2ZXIgd2lsbCBzZWUgYSBncm91cCBvZiA1LXR1 cGxlcyBmcm9tIHRoZSBzYW1lIElQIGNlYXNlIGFjdGl2aXR5LCB3aGlsZSBhIHNpbWlsYXIgZ3Jv dXAgb2YgcG9zdC3igJxjb25uZWN0aW9uIG1pZ3JhdGlvbuKAnSA1LXR1cGxlcyBhcHBlYXJzIGZy b20gYSBkaWZmZXJlbnQgSVAsIGFsbCB3aXRoIG1hdGNoZWQgZGVzdGluYXRpb24gSVBzLg0KDQpH aXZlbiB0aGUgYWJvdmUsIEkgYW0gbGVmdCB3b25kZXJpbmcgaWYgaW5jcmVhc2luZyB0aGUgY29z dHMgZm9yIGNvbnRlbnQgaG9zdGluZywgaW5jcmVhc2luZyBwZXItcGFja2V0IHBvd2VyIHJlcXVp cmVtZW50cyBmb3IgbW9iaWxlIGFuZCBtaWNybyBkZXZpY2VzLCBhbmQgbWFraW5nIHRoZSBJbnRl cm5ldCBoYXJkZXIgdG8gdHJvdWJsZXNob290IGFuZCBvcGVyYXRlIGlzIHdvcnRoIHRoZSBtb3N0 bHkgaWxsdXNvcnkgcHJpdmFjeSBnYWlucyBvZiAoMSkuICBQYXRyaWNr4oCZcyDigJx0aGUgcHJp dmFjeSBpcyBhIG11c3QgaGF2ZeKAnSBpcyBhIGRlc2lyZSBJIHNoYXJlLCBidXQgZG9lcyAoMSkg cHJvdmlkZSBwcml2YWN5IGFnYWluc3QgYSBzb3BoaXN0aWNhdGVkIG9uLXBhdGggb2JzZXJ2ZXI/ DQoNCllldCwgKDIpIHNlZW1zIHNpbXBsZSBlbm91Z2ggYW5kIGEgZ29vZCBjb21wcm9taXNlLiAg QXMgTWlrZSBwb2ludHMgb3V0LCBpdCBhbGxvd3MgYW4gb24tcGF0aCBvYnNlcnZlciB3aG8gY2Fu IGxpbmsgQ0lEcyBhY3Jvc3Mg4oCcY29ubmVjdGlvbiBtaWdyYXRpb25z4oCdIHRvIGluZmVyIFBO cy4gIEJ1dCBpZiBDSURzIGFyZSBhbHJlYWR5IGxpbmtlZCwgdGhlcmUgaXMgbm8gbW9yZSBwcml2 YWN5IGFyZ3VtZW50IHRvIGJlIG1hZGUgYW55d2F5LiAgT25lIHRoaW5nICgyKSBkb2VzIG5vdCBh bGxvdyBhbiBvbi1wYXRoIG9ic2VydmVyIHRvIGRvIGlzIHRvIGxpbmsgQ0lEcyB2aWEgUE4gYW5h bHlzaXMuICAoVGhvdWdoIGl0IHN0aWxsIHNlZW1zIGxpa2UgdGhlIHByaXZhY3kgZ2FpbnMgZnJv bSBhbnkgb2YgdGhlIGFib3ZlIGFyZSBtb3N0bHkgYW4gaWxsdXNpb24uKSAgU28gbXkgdm90ZSBp cyBmb3IgKDIpLg0KDQotIElnb3INCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gW21haWx0bzpwcmF2Yj00MG1pY3Jvc29mdC5jb21A ZG1hcmMuaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwNCwgMjAxOCAzOjE1IFBN DQpUbzogTWlyamEgS8O8aGxld2luZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD47 IE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldD4NCkNjOiBMYXJzIEVnZ2VydCA8bGFyc0Bl Z2dlcnQub3JnPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUkU6IEdl dHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpJIHRvbyBk aXNhZ3JlZSB3aXRoIHRoZSBhc3Nlc3NtZW50IG9mIHRoZSBzaXR1YXRpb24uICsxIHRvIGV2ZXJ5 dGhpbmcgTWlyamEgc2FpZC4NCg0KPj4gdGhlcmUgaXMgbm8gKnJlcXVpcmVtZW50KiB0aGF0IHdl IHByb2R1Y2UgYSBwcm90b2NvbCB0aGF0IGlzIGFibGUgdG8gYmUgYWNjZWxlcmF0ZWQgYnkgaGFy ZHdhcmUuDQpJdCBpcyBob3dldmVyIGEgcmVxdWlyZW1lbnQgZm9yIGRlcGxveW1lbnQgdGhhdCB3 ZSBiZSBhYmxlIHRvIG9mZmxvYWQgUVVJQy4gQSBsYXJnZSBwYXJ0IG9mIHdvcmsgd2UgZG8gaW4g VENQIGlzIGFjY2VsZXJhdGlvbiBpbiBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUuIElmIFFVSUMgaGFz IHRvIGV2b2x2ZSBmcm9tIGV4cGVyaW1lbnQgdG8gYnJvYWQgZGVwbG95bWVudCBwZXJmb3JtYW5j ZSBpcyBhIGtleSBnb2FsLiBUaGlzIGlzIGJyb3VnaHQgdXAgc2V2ZXJhbCB0aW1lcyBpbiBUQ1Ag d29ya2luZyBncm91cCB3aGVyZSB3ZSBzZWUgcHJvcG9zYWxzIHRoYXQgd291bGRu4oCZdCB3b3Jr IHdpdGggd2lkZWx5IGRlcGxveWVkIHNvZnR3YXJlIGFuZCBoYXJkd2FyZSBhY2NlbGVyYXRpb25z LiANCg0KV2hldGhlciB3ZSBsaWtlIGl0IG9yIG5vdCBwZXJmb3JtYW5jZSBpcyBhIGtleSByZXF1 aXJlbWVudCBmb3IgUVVJQyBvbiBzZXJ2ZXJzIGFuZCBmb3IgZGF0YWNlbnRlciBzY2VuYXJpb3Mu IEV2ZW4gSWFuIG1lbnRpb25lZCBiZWZvcmUgdGhhdCBoZSdkIG5vdCB3YW50IHRvIGRvIFBORSB3 aXRoaW4gREMgYW5kIEkgYWdyZWUuIE1vc3QgY29ubmVjdGlvbnMgd2lsbCBhbHNvIG5vdCBiZSBk b2luZyBtaWdyYXRpb24gb3IgdXNpbmcgbXVsdGkgcGF0aCBzbyB3aHkgcGF5IHRoZSBleHRyYSBv dmVyaGVhZCBpbiB0aGUgY29tbW9uIGNhc2UgZm9yIG5vIGJlbmVmaXQ/DQoNClNpbmNlIFBORSBk b2VzbuKAmXQgYWZmZWN0IHRoZSBpbnZhcmlhbnRzIChpdHMgc2ltcGx5IGFuIGV4dHJhIHN0ZXAg cG9zdCBwYWNrZXRpemF0aW9uIGFuZCBwcmUgcGFyc2luZyksIHBsZWFzZSBleHBsYWluIHdoeSBp dCB3b3VsZCBibG9jayBwcm9ncmVzcyBvbiBvdGhlciBmcm9udHM/IFdoYXQgaXMgdGhlIGxpc3Qg b2YgdGhpbmdzIHRoYXQgZ2V0IGJsb2NrZWQ/DQoNClBsZWFzZSBsZXQgdXMgbm90IHJ1c2ggaW50 byBhIGRlc2lnbiB0aGF0IGltcGFjdHMgcGVyIHBhY2tldCBwcm9jZXNzaW5nIGNvc3RzIHdpdGgg bm8gY2xlYXIgYXJ0aWN1bGF0aW9uIG9mIHRoZSBwcm9ibGVtIGFuZCB0aGUgYmVuZWZpdHMuIA0K DQpGcm9tIHdoYXQgSSBjYW4gdGVsbCB0aGVyZSBpcyB3aWRlIGRpc2FncmVlbWVudCBpbiB0aGUg Z3JvdXAgYW5kIG5vdGhpbmcgcmVzZW1ibGluZyBjb25zZW5zdXMuIFRoZSBmYWN0IHRoYXQgd2Ug aGF2ZSBwb29yIHJlcHJlc2VudGF0aW9uIGZyb20gaGFyZHdhcmUgZGV2ZWxvcGVycyBhbmQgcHVi bGljIGNsb3VkIHByb3ZpZGVycyBpcyBmdXJ0aGVyIHNrZXdpbmcgdGhlIHBlcmNlcHRpb24uIA0K DQpNeSByZWNvbW1lbmRhdGlvbnM6DQoxLiBMZWF2ZSB0aGUgY3VycmVudCBkcmFmdCBhcyBpcy4g TWFrZSBzdXJlIHdlIGhhdmUgc29tZSBwcm92aXNpb24gZm9yIGdyZWFzaW5nIHRoZSBQTiB0byBw cmV2ZW50IG9zc2lmaWNhdGlvbi4NCjIuIEV4cGxvcmUgbXVsdGlwbGUgUE4gc3BhY2VzIGZvciBj b25uZWN0aW9uIG1pZ3JhdGlvbiAoYW5kIGV2ZW50dWFsbHkgbXVsdGlwYXRoKS4NCjMuIE1ha2Ug UE5FIGFuIG9wdGlvbmFsIG5lZ290aWF0ZWQgZXh0ZW5zaW9uIGZvciBpbXBsZW1lbnRhdGlvbnMg dGhhdCB3YW50IHRvIGRvIGNvbm5lY3Rpb24gbWlncmF0aW9uIGluIFYxIHdpdGggdGhlIGNhdmVh dCB0aGF0IHdlIHdpbGwgcmV2aXNpdCB0aGlzIGZvciBWMiB3aGVuIHdlIGRvIG11bHRpcGF0aC4N CjQuIFNvbGljaXQgbW9yZSBmZWVkYmFjayBvbiB0aGUgcHJvdG9jb2wgZnJvbSBoYXJkd2FyZSB2 ZW5kb3JzIGFuZCBwdWJsaWMgYW5kIHByaXZhdGUgY2xvdWQgcHJvdmlkZXJzLiBJIGNhbiB0cnkg dG8gbG9vcCBpbiBtb3JlIGZvbGtzIGJ1dCBvdGhlcnMgc2hvdWxkIHRvby4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBNaXJqYSBLw7xobGV3aW5kDQpTZW50OiBXZWRuZXNkYXksIEFwcmls IDQsIDIwMTggMzoyNyBBTQ0KVG86IE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldD4NCkNj OiBMYXJzIEVnZ2VydCA8bGFyc0BlZ2dlcnQub3JnPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIg ZW5jcnlwdGlvbg0KDQpIaSBNYXJrLA0KDQp3aXRob3V0IGludGVuZGluZyB0byBzdGF0ZSBhIHRl Y2huaWNhbCBvcGluaW9uLCBJIHRoaW5rIEkgbmVlZCB0byBkaXNhZ3JlZSB3aXRoIHlvdXIgYXNz ZXNzbWVudCBvZiB0aGUgc2l0dWF0aW9uLiBQbGVhc2Ugc2VlIGJlbG93Lg0KDQo+IEFtIDA0LjA0 LjIwMTggdW0gMDY6NTggc2NocmllYiBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ+Og0K PiANCj4gSGkgZXZlcnlvbmUsDQo+IA0KPiBUaGUgZWRpdG9ycyBoYXZlIHRvbGQgeW91ciBjaGFp cnMgdGhhdCB0aGlzIGlzc3VlIGlzIHN0YXJ0aW5nIHRvIGJsb2NrIHByb2dyZXNzIG9uIG90aGVy IGFzcGVjdHMgb2YgUVVJQy4gQ29taW5nIHRvIGNvbnNlbnN1cyBvbiBpdCBzb29uIChpLmUuLCBi ZWZvcmUgU3RvY2tob2xtLCBpZiBwb3NzaWJsZSkgd291bGQgYmUgZ29vZC4NCj4gDQo+IEl0IGxv b2tzIGxpa2UgdGhpcyB0aHJlYWQgaGFzIGNvbWUgdG8gYSBuYXR1cmFsIHBhdXNlLiBSZWFkaW5n IHRocm91Z2ggaXQsIEkgdGhpbmsgd2UgYWdyZWUgdGhlcmUgYXJlIHNvbWUgdW5wbGVhc2FudCB0 cmFkZW9mZnMgaGVyZSwgYnV0IHNvIGZhciB3ZSBoYXZlIG9ubHkgb25lIGNvbmNyZXRlIHByb3Bv c2FsIC0tIFBSIzEwNzkuDQoNClRoZSBvdGhlciBwcm9wb3NhbCBpcyB0byB1c2UgYSByYW5kb20g b2Zmc2V0IHRoYXQgY2FuL3Nob3VsZCBiZSBjaGFuZ2VkIHdoZW4gdGhlIGNvbm5lY3Rpb24gSUQg aXMgY2hhbmdlZC4gV2hpY2ggaXMgbW9zdGx5IGlubGluZSB3aXRoIHdoYXQgdGhlIGRyYWZ0IGN1 cnJlbnRseSBzYXlzLg0KPiANCj4gTXkgQVUkLjA1IC0gV2hpbGUgd2UncmUgY2hhcnRlcmVkIHRv IHByb2R1Y2UgYSBwcm90b2NvbCB0aGF0J3MgZW5jcnlwdGVkIGFzIG11Y2ggYXMgb3BlcmF0aW9u YWwgY29uY2VybnMgYWxsb3csDQoNCkkgZG9u4oCZdCB0aGluayB0aGlzIGlzIHdoYXQgdGhlIGNo YXJ0ZXIgc2F5LiBUaGUgY2hhcnRlciBzYXlzICJQcm92aWRpbmcgYWx3YXlzLXNlY3VyZSB0cmFu c3BvcnQsIHVzaW5nIFRMUyAxLjMgYnkgZGVmYXVsdC7igJwgcGx1cyBhbm90aGVyIHBhcmFncmFw aCB0aGF0IHRhbGtzIGFib3V0IFRMUzEuMy4gSXQgZG9lcyBub3Qgc3BlbGwgb3V0IHRoZSBkZXNp cmUgb2Ygc29tZSBpbmRpdmlkdWFsIHRvIOKAnmVuY3J5cHQgYXMgbXVjaCBhcyBwb3NzaWJsZeKA nC4gDQoNCj4gYW5kIHRoYXQgcHJpdmFjeSBpcyBhIG5hdHVyYWwgZXh0ZW5zaW9uIG9mIHRoYXQg KGVzcGVjaWFsbHkgaW4gbGlnaHQgb2YgUkZDNzI1OCBhbmQgUkZDNjk3MyksIHRoZXJlIGlzIG5v ICpyZXF1aXJlbWVudCogdGhhdCB3ZSBwcm9kdWNlIGEgcHJvdG9jb2wgdGhhdCBpcyBhYmxlIHRv IGJlIGFjY2VsZXJhdGVkIGJ5IGhhcmR3YXJlLg0KDQpOb3QgdGhlcmUgaXMgbm8gcmVxdWlyZW1l bnQgdGhhdCB0aGUgcHJvdG9jb2wgbmVlZCB0byBiZSBhY2NlbGVyYXRlZCBieSBoYXJkd2FyZS4g SG93ZXZlciwgbm90IGFsbCByZXF1aXJlbWVudCBhcmUgbGlzdGVkIGluIHRoZSBjaGFydGVyLiBX ZSBhcyBhIGdyb3VwIGhhdmUgdG8gZGVmaW5lIHRoZSByZXF1aXJlbWVudC4gSG93ZXZlciwgdGhl cmUgaXMgb2YgY291cnNlIGFuIGltcGxpY2l0IHJlcXVpcmVtZW50IGZvciBhbGwgd29yayBpbiB0 aGUgSUVGVCB0aGF0IGlzIG11c3QgYmUgZGVwbG95YWJsZSBhbmQgc2VydmUgdGhlIG5lZWRzIG9m IHRob3NlIHBlb3BsZSB3aG8gd2FudCB0byBkZXBsb3kgaXQuDQoNCj4gDQo+IFRoYXQgYmVpbmcg dGhlIGNhc2UsIEkgdGhpbmsgd2UgbmVlZCB0byBhc2sgb3Vyc2VsdmVzIGlmIHdlIGJlbGlldmUg dGhhdCBpbmNsdXNpb24gb2YgUFIjMTA3OSB3aWxsIHNpZ25pZmljYW50bHkgaW5oaWJpdCBkZXBs b3ltZW50IG9mIHRoZSBwcm90b2NvbC4gQmFzZWQgb24gdGhlIGRpc2N1c3Npb24gc28gZmFyLCB0 aGF0IGRvZXNuJ3Qgc2VlbSB0byBiZSB0aGUgY2FzZSwgYnV0IEknZCBiZSBpbnRlcmVzdGVkIHRv IGhlYXIgd2hhdCBvdGhlcnMgdGhpbmsuDQoNCkhlcmUgbXkgYXNzZXNzbWVudCBpcyBhbHNvIGRp ZmZlcmVudC4gVGhlcmUgYXJlIG11bHRpcGxlIHBlb3BsZSB0aGF0IGhhdmUgcmFpc2VkIGNvbmNl cm5zIHRoYXQgdGhpcyBjb3VsZCBoaW5kZXIgZGVwbG95bWVudC4NCj4gDQo+IElmIHdlIGNhbiBn ZXQgdG8gY29uc2Vuc3VzIHRvIGluY29ycG9yYXRlIHRoZSBQUiwgYW5kIGZvbGtzIGNvbWUgYmFj ayBsYXRlciB3aXRoIGEgbW9yZSBoYXJkd2FyZS1mcmllbmRseSByZXBsYWNlbWVudCB0aGF0IGRv ZXNuJ3QgY2hhbmdlIHRoZSBJbnZhcmlhbnRzIG9yIGluY3JlYXNlIGxpbmthYmlsaXR5LCBJIHN1 c3BlY3QgdGhlIFdHIHdpbGwgYmUgYW1lbmFibGUgdG8gdGhhdC4NCg0KSSBkb27igJl0IHRoaW5r IHRvIGp1c3QgZ28gd2l0aCB3aGF0IHdlIGhhdmUgZXZlbiB0aG91Z2ggdGhlcmUgYXJlIGNvbmNl cm5zLCBpcyB0aGUgcmlnaHQgYXBwcm9hY2ggYW5kIGRlZmluaXRlbHkgbm90IHRoZSBhcHByb2Fj aCB0aGF0IHdhcyBjaG9zZW4gZm9yIG90aGVyIHByb3Bvc2Fscy4gSW4gdGhlIHNha2Ugb2YgZ2V0 dGluZyB2ZXJzaW9uIHYxIG91dCBxdWlja2x5LCBJIHdvdWxkIHRoaW5rIHRoYXQgbm90IGluY29y cG9yYXRpbmcgYW5vdGhlciBjaGFuZ2UgdGhhdCBkb2VzIG5vdCBoYXZlIGNvbnNlbnN1cyBpcyB0 aGUgcHJvcG9zZXIgYXBwcm9hY2guDQoNCk1pcmphDQoNCg0KDQo+IA0KPiBXaGF0IGRvIGZvbGtz IHRoaW5rPw0KPiANCj4gQ2hlZXJzLA0KPiANCj4gDQo+PiBPbiAyOSBNYXIgMjAxOCwgYXQgMTE6 MzkgYW0sIElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPiB3 cm90ZToNCj4+IA0KPj4gVGhhbmtzIGZvciB0aGUgbmljZSBzdW1tYXJ5IEphbmEuDQo+PiANCj4+ IEFzIG11Y2ggYXMgSSdkIGxvdmUgdG8gaGF2ZSBlYXNpZXIgY3J5cHRvIEhXIGFjY2VsZXJhdGlv biwgSSd2ZSBlbmRlZCB1cCBhcnJpdmluZyBhdCB0aGUgc2FtZSBjb25jbHVzaW9uLiAgSSBkb24n dCB3YW50IHRvIGJpdGUgb2ZmIHRoZSB3b3JrIHRvIGRvIHByb3BlciBtdWx0aXBhdGggaW4gUVVJ QyB2MSwgd2hpY2ggSSB0aGluayBpcyB0aGUgb25seSBvdGhlciByZWFzb25hYmxlIG9wdGlvbiBv ZiB0aG9zZSBDaHJpc3RpYW4gb3V0bGluZWQuDQo+PiANCj4+IElmIHNvbWVvbmUgY29tZXMgdXAg d2l0aCBhIHdheSB0byB0cmFuc2Zvcm0gcGFja2V0IG51bWJlciB0byBtYWtlIGl0IG5vbi1saW5r YWJsZSwgYnV0IGRvZXNuJ3QgaGF2ZSB0aGUgZG93bnNpZGUgb2YgbWFraW5nIGhhcmR3YXJlIG9m ZmxvYWQgZGlmZmljdWx0LCB0aGVuIEknbSBvcGVuIHRvIGl0LiAgQnV0IHdlJ3ZlIGJlZW4gdGFs a2luZyBhYm91dCB0aGlzIGZvciAyIG1vbnRocyB3aXRob3V0IGFueSBub3RhYmxlIGltcHJvdmVt ZW50cyBvdmVyIE1hcnRpbidzIFBSLg0KPj4gDQo+PiBHaXZlbiB3ZSBuZXZlciB0YWxrIGFib3V0 IGFueSBpc3N1ZSBvbmx5IG9uY2UgaW4gUVVJQywgSSdtIHN1cmUgdGhpcyB3aWxsIGNvbWUgdXAg YWdhaW4sIGJ1dCBmb3IgdGhlIHRpbWUgYmVpbmcgSSB0aGluayAjMTA3OSBpcyB0aGUgYmVzdCBv cHRpb24gd2UgaGF2ZS4NCj4+IA0KPj4gDQo+PiANCj4+IE9uIFdlZCwgTWFyIDI4LCAyMDE4IGF0 IDg6MDMgUE0gSmFuYSBJeWVuZ2FyIDxqcmkuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPj4gQSBm ZXcgcXVpY2sgdGhvdWdodHMgYXMgSSBjYXRjaCB1cCBvbiB0aGlzIHRocmVhZC4NCj4+IA0KPj4g SSBzcGVudCBzb21lIHRpbWUgbGFzdCB3ZWVrIHdvcmtpbmcgdGhyb3VnaCBhIGRlc2lnbiB1c2lu ZyBtdWx0aXBsZSBQTiBzcGFjZXMsIGFuZCBpdCBpcyBxdWl0ZSBkb2FibGUuIEkgc3VzcGVjdCB3 ZSdsbCBoZWFkIHRvd2FyZHMgbXVsdGlwbGUgUE4gc3BhY2VzIGFzIHdlIGNvbnNpZGVyIG11bHRp cGF0aCBpbiB0aGUgZnV0dXJlLiBUaGF0IHNhaWQsIHRoZXJlIGlzIGNvbXBsZXhpdHkgKGFzIENo cmlzdGlhbiBub3RlcykuIFRoaXMgY29tcGxleGl0eSBtYXkgYmUgd2FycmFudGVkIHdoZW4gZG9p bmcgbXVsdGlwYXRoIGluIHYyIG9yIGxhdGVyLCBidXQgSSdtIG5vdCBjb252aW5jZWQgdGhhdCB0 aGlzIGlzIG5lY2Vzc2FyeSBhcyBhIGRlc2lnbiBwcmltaXRpdmUgZm9yIFFVSUN2MS4gDQo+PiAN Cj4+IFdlIG1heSB3YW50IHRvIGNyZWF0aXZlbHkgdXNlIHRoZSBQTiBiaXRzIGluIHYyLCBzYXkg dG8gZW5jb2RlIGEgcGF0aCBJRCBhbmQgYSBQTiwgZm9yIG11bHRpcGF0aC4gV2Ugd2FudCB0byBy ZXRhaW4gZmxleGliaWxpdHkgaW4gdGhlc2UgYml0cyBnb2luZyBpbnRvIHYyLiBXZSd2ZSB1c2Vk IGVuY3J5cHRpb24gdG8gZW5zdXJlIHRoYXQgd2UgZG9uJ3QgbG9zZSBmbGV4aWJpbGl0eSBlbHNl d2hlcmUgaW4gdGhlIGhlYWRlciwgYW5kIGl0IGZvbGxvd3MgdGhhdCB3ZSBzaG91bGQgdXNlIFBO RSB0byByZXRhaW4gZmxleGliaWxpdHkgaW4gdGhlc2UgYml0cyBhcyB3ZWxsLiAoU2ltcGxpY2l0 eSBvZiBkZXNpZ24gaXMgdGhlIG90aGVyIHZhbHVlIGluIHVzaW5nIFBORSwgc2luY2UgaGFuZGxp bmcgbWlncmF0aW9uIGxpbmthYmlsaXR5IGlzIG5vbi10cml2aWFsIHdpdGhvdXQgaXQuKQ0KPj4g DQo+PiBUaGlzIGxlYXZlcyB0aGUgcXVlc3Rpb24gb2YgSFcgYWNjZWxlcmF0aW9uIGJlaW5nIGF0 IGxvZ2dlcmhlYWRzIHdpdGggdGhlIGRlc2lnbiBpbiBQUiAjMTA3OS4gRmlyc3QsIEkgZXhwZWN0 IHRoYXQgdGhlIHByaW1hcnkgYmVuZWZpdCBvZiBhY2NlbGVyYXRpb24gd2lsbCBiZSBpbiBEQyBl bnZpcm9ubWVudHMuIFllcywgdGhlcmUgYXJlIHNvbWUgZ2FpbnMgdG8gYmUgaGFkIGluIHNlcnZp bmcgdGhlIHB1YmxpYyBJbnRlcm5ldCBhcyB3ZWxsLCBidXQgSSdtIHVuY29udmluY2VkIHRoYXQg dGhpcyBpcyB0aGUgZHJpdmluZyB1c2UgY2FzZSBmb3IgaGFyZHdhcmUgYWNjZWxlcmF0aW9uLiBJ IHVuZGVyc3RhbmQgdGhhdCBvdGhlcnMgbWF5IGRpc2FncmVlIHdpdGggbWUgaGVyZS4NCj4+IA0K Pj4gQUZBSUssIFFVSUMgaGFzIG5vdCBiZWVuIHVzZWQgaW4gREMgZW52aXJvbm1lbnRzIHlldC4g SSBleHBlY3QgdGhlcmUgYXJlIG90aGVyIHRoaW5ncyBpbiB0aGUgcHJvdG9jb2wgdGhhdCB3ZSdk IHdhbnQgdG8gY2hhbmdlIGFzIHdlIGdhaW4gZXhwZXJpZW5jZSBkZXBsb3lpbmcgUVVJQyBpbiBE Q3MuIFNwaW5uaW5nIHVwIGEgbmV3IHZlcnNpb24gdG8gdHJ5IFFVSUMgd2l0aGluIERDcyBpcyBu b3Qgb25seSBhcHByb3ByaWF0ZSwgSSB3b3VsZCByZWNvbW1lbmQgaXQuIFRoaXMgYWxsb3dzIGZv ciByYXBpZCBpdGVyYXRpb25zIGludGVybmFsbHksIGFuZCB0aGUgZXhwZXJpZW5jZSBjYW4gZHJp dmUgc3Vic2VxdWVudCBjaGFuZ2VzIHRvIFFVSUMuIEl0J3Mgd2hhdCAqSSogd291bGQgZG8gaWYg SSB3YXMgdG8gZGVwbG95IFFVSUMgaW5zaWRlIGEgREMuDQo+PiANCj4+IFNvLCBpbiBzaG9ydCwg SSB0aGluayB3ZSBzaG91bGQgZ28gYWhlYWQgd2l0aCBQUiMgMTA3OS4gVGhpcyBlbnN1cmVzIHRo YXQgZnV0dXJlIHZlcnNpb25zIGFyZSBndWFyYW50ZWVkIHRoZSBmbGV4aWJpbGl0eSB0byBjaGFu Z2UgdGhlIFBOIGJpdHMgZm9yIGJldHRlciBzdXBwb3J0IG9mIEhXIGFjY2VsZXJhdGlvbiBvciBt dWx0aXBhdGggb3Igd2hhdC1oYXZlLXlvdS4NCj4+IA0KPj4gLSBqYW5hDQo+PiANCj4+IE9uIE1h ciAyNiwgMjAxOCA5OjQxIEFNLCAiQ2hyaXN0aWFuIEh1aXRlbWEiIDxodWl0ZW1hQGh1aXRlbWEu bmV0PiB3cm90ZToNCj4+IA0KPj4gT24gMy8yNi8yMDE4IDg6MjAgQU0sIFN3aW5kZWxscywgVGhv bWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSkgd3JvdGU6DQo+Pj4gTG9va2luZyBhdCBodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy RmVuLndpa2lwZWRpYS5vcmclMkZ3aWtpJTJGQUVTX2luc3RydWN0aW9uX3NldCUyM0ludGVsX2Fu ZF9BTURfeDg2X2FyY2hpdGVjdHVyZSZkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5j b20lN0MxNGYyNzhhYjM3Njk0NjlhNDRmOTA4ZDU5YTE2YTJkNiU3QzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY1ODQzNDQzODM5NTk3NjUmc2RhdGE9YU9IYzdG Wm9JQkNFMU9scW1OcHZkTU0wbnRMZXJaM0ZwcUVTVmo4NXpmRSUzRCZyZXNlcnZlZD0wIGl0IHNl ZW1zIHRvIGltcGx5IGEgbGFyZ2UgcmFuZ2Ugb2Ygc2VydmVyLCBkZXNrdG9wIGFuZCBtb2JpbGUg Y2hpcHMgYWxsIGhhdmUgYSBDUFUgaW5zdHJ1Y3Rpb24gc2V0IGF2YWlsYWJsZSB0byBkbyBBRVMg YWNjZWxlcmF0aW9uIGFuZCBvdGhlciBzaW1pbGFyIG9wZXJhdGlvbnMgKG90aGVyIGluc3RydWN0 aW9uIHNldHMgYXJlIGFsc28gYXZhaWxhYmxlKS4NCj4+PiANCj4+PiBJZiB3ZSBhcmUgY29uc2lk ZXJpbmcgdGhlIEFFUyBpbnN0cnVjdGlvbnMgdGhlbiBpdCBsb29rcyBsaWtlIGl0IGlzIChvciBh dCBsZWFzdCB3aWxsIGJlIGluIHRoZSBuZWFyIGZ1dHVyZSkgYSBzaXplYWJsZSBwcm9wb3J0aW9u IG9mIHRoZSBwdWJsaWMgaW50ZXJuZXQgaGF2ZSBpdCB0byBiZSB1c2VkLg0KPj4+IA0KPj4gDQo+ PiBDZXJ0YWlubHksIGJ1dCB0aGF0J3Mgbm90IHRoZSBjdXJyZW50IGRlYmF0ZS4gUFIgIzEwNzkg aXMgZnVsbHkgY29tcGF0aWJsZSB3aXRoIHVzZSBvZiB0aGUgQUVTIGluc3RydWN0aW9ucy4gVGhl IGlzc3VlIG9mIHRoZSBkZWJhdGUgaXMgdGhhdCB0aGUgbWVjaGFuaXNtIGluIFBSICMxMDc5IHJl cXVpcmVkIGRvdWJsZSBidWZmZXJpbmcsIGZpcnN0IGVuY3J5cHQgdGhlIHBheWxvYWQsIHRoZW4g dXNlIHRoZSByZXN1bHQgb2YgdGhlIGVuY3J5cHRpb24gdG8gZW5jcnlwdCB0aGUgUE4uIFRoaXMg aXMgbm90IGFuIGlzc3VlIGluIGEgc29mdHdhcmUgaW1wbGVtZW50YXRpb24gdGhhdCBjYW4gcmVh ZGlseSBhY2Nlc3MgYWxsIGJ5dGVzIG9mIHRoZSBwYWNrZXQgZnJvbSBtZW1vcnksIGJ1dCBpdCBt YXkgYmUgYW4gaXNzdWUgaW4gc29tZSBoYXJkd2FyZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhcmUg ZGVzaWduZWQgdG8gZG8ganVzdCBvbmUgcGFzcyBvdmVyIHRoZSBkYXRhLg0KPj4gDQo+PiANCj4+ IC0tIENocmlzdGlhbiBIdWl0ZW1hDQo+PiANCj4+IA0KPj4gDQo+IA0KPiAtLQ0KPiBNYXJrIE5v dHRpbmdoYW0gICBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnd3dy5tbm90Lm5ldCUyRiZkYXRhPTAyJTdDMDElN0NwcmF2YiU0 MG1pY3Jvc29mdC5jb20lN0MxNGYyNzhhYjM3Njk0NjlhNDRmOTA4ZDU5YTE2YTJkNiU3QzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY1ODQzNDQzODM5NTk3NjUm c2RhdGE9UlhiYTJUeXZZejZvdGVjRUhvTENUNHRaMkk3RW9keERpeVB4V3JuJTJGbkF3JTNEJnJl c2VydmVkPTANCj4gDQoNCg== From nobody Wed Apr 4 13:15:44 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4045F12D869 for ; Wed, 4 Apr 2018 13:15: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 (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 a5ALzAukvkH8 for ; Wed, 4 Apr 2018 13:15:41 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0132.outbound.protection.outlook.com [104.47.42.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88207126DCA for ; Wed, 4 Apr 2018 13:15:41 -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=xpmmWNbwYcMpDgSM+JnuiesMZRBsRoKUn9YeRgPp6gc=; b=KwUnd8vMN4NXqvHk7aZDoxn17p9hbDSBWsDqaK1O5mBIwRjLfq9IrHffrxQuLYXLFGz6VfHaKoI0UoHSGDDf0pFKe+GNDBF7CzUCoHBkV3Bc8OpEAZNZ0PUUoa20O5o4iD63yTJ8zjOQkudD4maz+70CjAkWgCa8GoFiLHbI6UU= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0184.namprd21.prod.outlook.com (10.173.193.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 20:15:40 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 20:15:40 +0000 From: Praveen Balasubramanian To: IETF QUIC WG Subject: Impact of hardware offloads on network stack performance Thread-Topic: Impact of hardware offloads on network stack performance Thread-Index: AdPMUbL7T8nZAW2ySiO289IPTC0ttg== Date: Wed, 4 Apr 2018 20:15:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0184; 7:7NJWJVrqBGr3Lx3lwO3eiOwU1ZNR/KFZZJb7AbZZzUCYGnU5mQmvk4TlVLimA8zhPeMvhH3+KocsnbcOsk2/G088z1YuIF2nQ0Wps3j3N2Wn7Co9YNL0Ug5Pin1MW2zEZhWbuiuBtEpHG3Vl2gGWkyx9D90QpDjSysLRWqvFd8w5dxEInusQeMXWtODe2t7U1m3EEfLDuH8UabVHibZL0IenJrB0eulUBaopbITrLHwG2np0AexqgJ945+kJbvYz; 20:VT0BlZdgWGqe3OJaI8FoaRwavbbIEmFYALr77Y6+4FqahkYvs8hKgRptNBp+3njnfIl5qgP14HoOjtH4e5Uhc+YGfySvL7fuAyLZwFx2qXNi61RdgD36aLygTcHdfKbl++vXm2n9XfN0qpiwGlNYevWTCXmMh7IHdmNn2tFoiBQ= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 940e2884-9fc8-4afe-6c2b-08d59a68d648 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0184; x-ms-traffictypediagnostic: CY4PR21MB0184: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0184; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0184; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(376002)(396003)(39380400002)(199004)(189003)(99286004)(6916009)(7696005)(476003)(55016002)(54896002)(33656002)(81156014)(8676002)(53936002)(486006)(86612001)(7736002)(5250100002)(81166006)(2906002)(3660700001)(106356001)(68736007)(6116002)(790700001)(46003)(3280700002)(74316002)(6506007)(186003)(105586002)(102836004)(316002)(10090500001)(22452003)(97736004)(8990500004)(6306002)(6436002)(25786009)(8936002)(5660300001)(14454004)(478600001)(10290500003)(2900100001)(9686003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0184; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: lRkjMXDx4WzxxvSUUAwJVN96gOQVpz62oB0zZdWCTMw7u0v6Pidw9a6OdZNgQkxLR8aQtQ4xru+BYCnjTCxvZ04gRPHKcBrHRhjAwkXlx2/sNYg12ZgoAVZL0SodDxL/ri3+2U1cgiBA5XVd8Fvg86eI/000+A9FoMedQs3uG+a7FICnzsA8ww2gTE8hm2IsKOT8IF1S10anthsv2jTmM2SWSf4n33GsOxcbhLyCAti0E5OOGHHAXl2YTQtgj/I0iR8v/+nEVJ+u+BoFNLTyxN47TinlG7dOuYgJ81EAo2mYKQAIAhyXDN73D8/spvfh76d7zc3586ONfoiEZlFt+fApaXc/f+jzrad5k2WLXhk3YXl5hb/sCesIlLq9s+Q3Pt7Cvt9Jxk9JoMJBBqUsS48BJlpI5Zim7VDbvKIWYz4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630CE4DE6BA4EDF54A1FEB1B6A40CY4PR21MB0630namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 940e2884-9fc8-4afe-6c2b-08d59a68d648 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 20:15:40.3898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0184 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 20:15:43 -0000 --_000_CY4PR21MB0630CE4DE6BA4EDF54A1FEB1B6A40CY4PR21MB0630namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some comparative numbers from an out of box default settings Windows Server= 2016 (released version) for a single connection with a microbenchmark tool= : Offloads enabled TCP gbps UDP gbps LSO + LRO + checksum 24 3.6 Checksum only 7.6 3.6 None 5.6 2.3 This is for a fully bottlenecked CPU core -- if you run lower data rates th= ere is still a significant difference in Cycles/byte cost. Same increased C= PU cost applies for client systems going over high data rate Wifi and cellu= lar. This is without any crypto. Once you add crypto the numbers become much wor= se with crypto cost becoming dominant. Adding another crypto step further e= xacerbates the problem. Hence crypto offload gains in importance followed b= y these batch offloads. If folks need any more numbers I'd be happy to provide them. Thanks --_000_CY4PR21MB0630CE4DE6BA4EDF54A1FEB1B6A40CY4PR21MB0630namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some comparative numbers from an out of box default = settings Windows Server 2016 (released version) for a single connection wit= h a microbenchmark tool:

 

Offloads enabled

TCP gbps

UDP gbps

LSO + LRO + checksum

24

3.6

Checksum only

7.6

3.6

None

5.6

2.3

 

This is for a fully bottlenecked CPU core -- if y= ou run lower data rates there is still a significant difference in Cycles/b= yte cost. Same increased CPU cost applies for client systems going over= high data rate Wifi and cellular.

 

This is without any crypto. Once you add crypto the = numbers become much worse with crypto cost becoming dominant. Adding another crypto step furth= er exacerbates the problem. Hence crypto offload gains in importance follow= ed by these batch offloads.

 

If folks need any more numbers I’d be happy to= provide them.

 

Thanks

 

--_000_CY4PR21MB0630CE4DE6BA4EDF54A1FEB1B6A40CY4PR21MB0630namp_-- From nobody Wed Apr 4 13:28:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD1812DB71 for ; Wed, 4 Apr 2018 13:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522873727; bh=j5/ko/pJLyYRgEJwzDNjm7iUqj8Q+lX2sHAlqZuA0Ao=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To:To; b=Cl65PPND4ZTToBVJ7hLNlockpvGPFJxLQt45jgqN4jNw2wtII/qkv4ZCwHZ6GqDZw ssEX4E2YIdEKsOH6uHSwqF99sP4r4j+ikV/7JguUhE41BTaYFTF5ELU6iV/qrSYJBV zkd2XY6YZ7bjG7WBGjbnfttGOStX9qqcE1Yqg3+s= X-Mailbox-Line: From fenix@fb.com Wed Apr 4 13:28:47 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB60312DA68; Wed, 4 Apr 2018 13:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522873726; bh=R7abBt3ak4FvFtSTcE0OV0KFAQtG68OkI1+Dw8HO43I=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To:To; b=BoHUexWaaR8sjXsyK1Zm81clQbcJHEPONqlWsE0WExGiPCBDgX8FRx38OWCS1BcHF WS666GGYKngH+i2pFb00XZm3My0Qz4a/9wTCBiOvcqaHJaYObgIND4nwQo82H8qvby 20cG+j4ITar3wmPkT7r1VsjtHVss5zJSc9FNybWg= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B695712DB70 for ; Wed, 4 Apr 2018 13:28: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, 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 (1024-bit key) header.d=fb.com header.b=KyXN5pSV; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=fbH3mXOz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Rb-lVybCj4M for ; Wed, 4 Apr 2018 13:28:42 -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 872F412DA68 for ; Wed, 4 Apr 2018 13:28:42 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w34KLvPX029444; Wed, 4 Apr 2018 13:28:41 -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=Msm9IffCnjchCUuYdyGDtX1sJsHbHNxtK8ul6IGROTc=; b=KyXN5pSVwWjSs9RyXuowveWbk2/i7kcLo9GjQDPBsjuzjU4TFEUWtICDBlHSiKYJgwUJ nFLhtWb0WYO+Bxgz1CA0i0a1o7dzIkBrw69CPGJJ1KpcvfutrIN3bLPzgFGVm4tNbcvj qf1qT60AG+jPvXtsNst0iVkQpLK83XFd2Nk= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 2h51y80swb-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 04 Apr 2018 13:28:41 -0700 Received: from PRN-CHUB02.TheFacebook.com (2620:10d:c081:35::11) by PRN-CHUB01.TheFacebook.com (2620:10d:c081:35::10) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 4 Apr 2018 13:28:40 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.12) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 4 Apr 2018 13:28:38 -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=Msm9IffCnjchCUuYdyGDtX1sJsHbHNxtK8ul6IGROTc=; b=fbH3mXOztGvqwlBsD7JscQb4yYE+8JDs+KXIADzsYlcZGhANnViixijD2nUx2JyhJsHRVD/U5gYetJ0ENrGLrhxGfJv8SW6iWBDoLDyUUmeSV2uWVMUfnwBkUAs/0Sev+xVfbd5g//MbFHrQIlzbDWejpQIqv78avg4BLWh9UqM= Received: from DM3PR15MB0783.namprd15.prod.outlook.com (10.164.201.11) by DM3PR15MB1002.namprd15.prod.outlook.com (10.166.160.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.631.10; Wed, 4 Apr 2018 20:28:37 +0000 Received: from DM3PR15MB0783.namprd15.prod.outlook.com ([fe80::e8a0:580f:a9c5:5185]) by DM3PR15MB0783.namprd15.prod.outlook.com ([fe80::e8a0:580f:a9c5:5185%13]) with mapi id 15.20.0653.012; Wed, 4 Apr 2018 20:28:37 +0000 From: Roberto Peon CC: Lars Eggert , IETF QUIC WG Subject: Re: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GjyGQaKf4GI0anNhXTngANsKPwZ0sAgACTmYCAAAtRgIAABxcr Date: Wed, 4 Apr 2018 20:28:36 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> , 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:d981] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM3PR15MB1002; 7:it0UVEiodmsx8z67HvQLwBMWWHDBXnfqesd2UdWVI2fl999m+6b7Om3p57Xz05ckuHTOwZmij0GdmQasSCkoRFJX34xSNyqV6GNGJgMyGY7mppou2ffUMxEaOjmc+lYKpy7VtuL2a32ZHneeY6sS2pDiuCDht48JHqq/Vk2kdwUZF7QC3WLekfrNTGIMRxKgs8twx6/6nMzkjMtB4q2zhURd8tb6Gp21CfovRrpKUllYGVQ4fmjw478NEy2Wzs1Q; 20:nhdZWpV2byrNLR41CrsxkNGkUEUp3nt2tfg535d4/qZDCpqaGz7zbi2yefkt6EKuVutOaPlDC6chBqlpPkzth7Oq5JwRfjwUDmUGIEXUQR2vhn7T3ryMItotmqGPAv0WlQ4Awfn67aVD7soZ2h1veqthjHjKgV+OosEVeSHhKes= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 2042066b-12ea-4069-f78a-08d59a6aa51b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM3PR15MB1002; x-ms-traffictypediagnostic: DM3PR15MB1002: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(189930954265078)(85827821059158)(100405760836317)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(11241501184)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DM3PR15MB1002; BCL:0; PCL:0; RULEID:; SRVR:DM3PR15MB1002; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(39860400002)(346002)(376002)(396003)(199004)(13464003)(53754006)(189003)(51914003)(105586002)(25786009)(106356001)(102836004)(186003)(5250100002)(476003)(6116002)(97736004)(486006)(7736002)(14454004)(46003)(1511001)(575784001)(11346002)(8936002)(478600001)(45080400002)(86362001)(966005)(4326008)(446003)(54906003)(55016002)(316002)(229853002)(2906002)(59450400001)(74316002)(6606003)(3660700001)(33656002)(93886005)(110136005)(8666007)(68736007)(6506007)(53546011)(6306002)(54896002)(2900100001)(8676002)(6436002)(236005)(19627405001)(9686003)(5660300001)(53936002)(606006)(7696005)(81156014)(561944003)(6246003)(76176011)(99286004)(81166006)(3280700002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM3PR15MB1002; H:DM3PR15MB0783.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: xBpvGPA0/sOfF9ypxejoChp+l0k2g2JOfjsZ64xxVEmoLQc3rakrRTEslD0p6gR4fNTffCigobFlxnLsHbiZfGyB09jhLrzw1PX4bMqfymCpL035STia91jqjZUab802K2soNhMpSjQoJURYzP63biGOh02jc7ELFpyvmKViPteCPfjYDvKZWjXiMCs+GLoGVurr/kPoCWE8wXWhluThh9cVlZdEoIjJ/BmVTVOhv8uf2enUzG3vaiXduIDHKn56P08Z8es9Q7K29Q7UzCjs7O8eaH18F/8f4fa9ZF2Db705RBw7ka6c4AuP4dTMfIpVG/RIGU+NFh+WFC0RwM3C5GvsOjzKtI6nDEGvBgahJe6PH/xItBdIpSYV5d++5Hm3tVfVciUyo53EhKvRB52CuL1g9GQpSYJv/f77mSubDng= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM3PR15MB0783129C7E584AF193B43485CDA40DM3PR15MB0783namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2042066b-12ea-4069-f78a-08d59a6aa51b X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 20:28:36.9608 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR15MB1002 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-04_06:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe To: "Lubashev, Igor" To: Praveen Balasubramanian To: =?Windows-1252?Q?Mirja_K=FChlewind?= To: Mark Nottingham Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 20:28:47 -0000 --_000_DM3PR15MB0783129C7E584AF193B43485CDA40DM3PR15MB0783namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable PN encryption plus multiple (rotating) GUIDs specified on a per-path basis,= as discussed in Melbourne do seem able to provide substantively better pri= vacy. With such a scheme nothing appears to be shared from one 5-tuple+GUID= to another 5-tuple+GUID. An implementation that cared deeply about privacy would send packets along = both paths for some time. This doesn't seem like something we can reasonabl= e require with the protocol, but it can be allowed by the protocol. I am not particularly interested in seeing QUIC v1 become the most CPU effi= cient thing. I'd rather we release it, and continue iterating. Concentratin= g on features that prevent ossification furthers this goal and allows for a= n eventual (and possibly better) HW acceleration path later. -=3DR ________________________________ From: QUIC on behalf of Lubashev, Igor Sent: Wednesday, April 4, 2018 12:55:47 PM To: Praveen Balasubramanian; Mirja K=FChlewind; Mark Nottingham Cc: Lars Eggert; IETF QUIC WG Subject: RE: Getting to consensus on packet number encryption To restate the options: (1) - Packet number encryption. (2) - Per-CID offset. (3) - Plain text PNs across connection migrations. (4) - Per-CID PN spaces. None of the alternatives mask the =93connection migration=94 event from an = on-path observer. The =93original=94 connection establishment is done via = clearly identifiable handshake packets on a 5-tuple before short-header pac= kets show up, while =93connection migration=94 events are identifiable by t= he use of a new CID with short-header packets on a new 5-tuple w/o precedin= g handshake packets. As it was pointed out many times (especially by Brian), it is not that hard= to correlate cessation of packets from one 5-tuple and appearance of a new= post-=93connection migration=94 5-tuple, especially if destination IPs for= both are identical. Moreover, since devices that wish to maintain connect= ions during migration will likely migrate multiple connections, the on-path= observer will see a group of 5-tuples from the same IP cease activity, whi= le a similar group of post-=93connection migration=94 5-tuples appears from= a different IP, all with matched destination IPs. Given the above, I am left wondering if increasing the costs for content ho= sting, increasing per-packet power requirements for mobile and micro device= s, and making the Internet harder to troubleshoot and operate is worth the = mostly illusory privacy gains of (1). Patrick=92s =93the privacy is a must= have=94 is a desire I share, but does (1) provide privacy against a sophis= ticated on-path observer? Yet, (2) seems simple enough and a good compromise. As Mike points out, it= allows an on-path observer who can link CIDs across =93connection migratio= ns=94 to infer PNs. But if CIDs are already linked, there is no more priva= cy argument to be made anyway. One thing (2) does not allow an on-path obs= erver to do is to link CIDs via PN analysis. (Though it still seems like t= he privacy gains from any of the above are mostly an illusion.) So my vote= is for (2). - Igor -----Original Message----- From: Praveen Balasubramanian [mailto:pravb=3D40microsoft.com@dmarc.ietf.or= g] Sent: Wednesday, April 04, 2018 3:15 PM To: Mirja K=FChlewind ; Mark Nottingham Cc: Lars Eggert ; IETF QUIC WG Subject: RE: Getting to consensus on packet number encryption I too disagree with the assessment of the situation. +1 to everything Mirja= said. >> there is no *requirement* that we produce a protocol that is able to be = accelerated by hardware. It is however a requirement for deployment that we be able to offload QUIC.= A large part of work we do in TCP is acceleration in software and hardware= .. If QUIC has to evolve from experiment to broad deployment performance is = a key goal. This is brought up several times in TCP working group where we = see proposals that wouldn=92t work with widely deployed software and hardwa= re accelerations. Whether we like it or not performance is a key requirement for QUIC on serv= ers and for datacenter scenarios. Even Ian mentioned before that he'd not w= ant to do PNE within DC and I agree. Most connections will also not be doin= g migration or using multi path so why pay the extra overhead in the common= case for no benefit? Since PNE doesn=92t affect the invariants (its simply an extra step post pa= cketization and pre parsing), please explain why it would block progress on= other fronts? What is the list of things that get blocked? Please let us not rush into a design that impacts per packet processing cos= ts with no clear articulation of the problem and the benefits. >From what I can tell there is wide disagreement in the group and nothing re= sembling consensus. The fact that we have poor representation from hardware= developers and public cloud providers is further skewing the perception. My recommendations: 1. Leave the current draft as is. Make sure we have some provision for grea= sing the PN to prevent ossification. 2. Explore multiple PN spaces for connection migration (and eventually mult= ipath). 3. Make PNE an optional negotiated extension for implementations that want = to do connection migration in V1 with the caveat that we will revisit this = for V2 when we do multipath. 4. Solicit more feedback on the protocol from hardware vendors and public a= nd private cloud providers. I can try to loop in more folks but others shou= ld too. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mirja K=FChlewind Sent: Wednesday, April 4, 2018 3:27 AM To: Mark Nottingham Cc: Lars Eggert ; IETF QUIC WG Subject: Re: Getting to consensus on packet number encryption Hi Mark, without intending to state a technical opinion, I think I need to disagree = with your assessment of the situation. Please see below. > Am 04.04.2018 um 06:58 schrieb Mark Nottingham : > > Hi everyone, > > The editors have told your chairs that this issue is starting to block pr= ogress on other aspects of QUIC. Coming to consensus on it soon (i.e., befo= re Stockholm, if possible) would be good. > > It looks like this thread has come to a natural pause. Reading through it= , I think we agree there are some unpleasant tradeoffs here, but so far we = have only one concrete proposal -- PR#1079. The other proposal is to use a random offset that can/should be changed whe= n the connection ID is changed. Which is mostly inline with what the draft = currently says. > > My AU$.05 - While we're chartered to produce a protocol that's encrypted = as much as operational concerns allow, I don=92t think this is what the charter say. The charter says "Providing a= lways-secure transport, using TLS 1.3 by default.=93 plus another paragraph= that talks about TLS1.3. It does not spell out the desire of some individu= al to =84encrypt as much as possible=93. > and that privacy is a natural extension of that (especially in light of R= FC7258 and RFC6973), there is no *requirement* that we produce a protocol t= hat is able to be accelerated by hardware. Not there is no requirement that the protocol need to be accelerated by har= dware. However, not all requirement are listed in the charter. We as a grou= p have to define the requirement. However, there is of course an implicit r= equirement for all work in the IEFT that is must be deployable and serve th= e needs of those people who want to deploy it. > > That being the case, I think we need to ask ourselves if we believe that = inclusion of PR#1079 will significantly inhibit deployment of the protocol.= Based on the discussion so far, that doesn't seem to be the case, but I'd = be interested to hear what others think. Here my assessment is also different. There are multiple people that have r= aised concerns that this could hinder deployment. > > If we can get to consensus to incorporate the PR, and folks come back lat= er with a more hardware-friendly replacement that doesn't change the Invari= ants or increase linkability, I suspect the WG will be amenable to that. I don=92t think to just go with what we have even though there are concerns= , is the right approach and definitely not the approach that was chosen for= other proposals. In the sake of getting version v1 out quickly, I would th= ink that not incorporating another change that does not have consensus is t= he proposer approach. Mirja > > What do folks think? > > Cheers, > > >> On 29 Mar 2018, at 11:39 am, Ian Swett wrote: >> >> Thanks for the nice summary Jana. >> >> As much as I'd love to have easier crypto HW acceleration, I've ended up= arriving at the same conclusion. I don't want to bite off the work to do = proper multipath in QUIC v1, which I think is the only other reasonable opt= ion of those Christian outlined. >> >> If someone comes up with a way to transform packet number to make it non= -linkable, but doesn't have the downside of making hardware offload difficu= lt, then I'm open to it. But we've been talking about this for 2 months wi= thout any notable improvements over Martin's PR. >> >> Given we never talk about any issue only once in QUIC, I'm sure this wil= l come up again, but for the time being I think #1079 is the best option we= have. >> >> >> >> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar wrote: >> A few quick thoughts as I catch up on this thread. >> >> I spent some time last week working through a design using multiple PN s= paces, and it is quite doable. I suspect we'll head towards multiple PN spa= ces as we consider multipath in the future. That said, there is complexity = (as Christian notes). This complexity may be warranted when doing multipath= in v2 or later, but I'm not convinced that this is necessary as a design p= rimitive for QUICv1. >> >> We may want to creatively use the PN bits in v2, say to encode a path ID= and a PN, for multipath. We want to retain flexibility in these bits going= into v2. We've used encryption to ensure that we don't lose flexibility el= sewhere in the header, and it follows that we should use PNE to retain flex= ibility in these bits as well. (Simplicity of design is the other value in = using PNE, since handling migration linkability is non-trivial without it.) >> >> This leaves the question of HW acceleration being at loggerheads with th= e design in PR #1079. First, I expect that the primary benefit of accelerat= ion will be in DC environments. Yes, there are some gains to be had in serv= ing the public Internet as well, but I'm unconvinced that this is the drivi= ng use case for hardware acceleration. I understand that others may disagre= e with me here. >> >> AFAIK, QUIC has not been used in DC environments yet. I expect there are= other things in the protocol that we'd want to change as we gain experienc= e deploying QUIC in DCs. Spinning up a new version to try QUIC within DCs i= s not only appropriate, I would recommend it. This allows for rapid iterati= ons internally, and the experience can drive subsequent changes to QUIC. It= 's what *I* would do if I was to deploy QUIC inside a DC. >> >> So, in short, I think we should go ahead with PR# 1079. This ensures tha= t future versions are guaranteed the flexibility to change the PN bits for = better support of HW acceleration or multipath or what-have-you. >> >> - jana >> >> On Mar 26, 2018 9:41 AM, "Christian Huitema" wrote= : >> >> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote: >>> Looking at https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__na01.= safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fen.wikipedia.= org-252Fwiki-252FAES-5Finstruction-5Fset-2523Intel-5Fand-5FAMD-5Fx86-5Farch= itecture-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C14f278ab3769469= a44f908d59a16a2d6-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C6365= 84344383959765-26sdata-3DaOHc7FZoIBCE1OlqmNpvdMM0ntLerZ3FpqESVj85zfE-253D-2= 6reserved-3D0&d=3DDwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf= 6TA&m=3Dym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=3DWkBplmuEwMxL-oezaQ4= rK1_9-0SXgkY1NJ_V3SPhYOU&e=3D it seems to imply a large range of server, de= sktop and mobile chips all have a CPU instruction set available to do AES a= cceleration and other similar operations (other instruction sets are also a= vailable). >>> >>> If we are considering the AES instructions then it looks like it is (or= at least will be in the near future) a sizeable proportion of the public i= nternet have it to be used. >>> >> >> Certainly, but that's not the current debate. PR #1079 is fully compatib= le with use of the AES instructions. The issue of the debate is that the me= chanism in PR #1079 required double buffering, first encrypt the payload, t= hen use the result of the encryption to encrypt the PN. This is not an issu= e in a software implementation that can readily access all bytes of the pac= ket from memory, but it may be an issue in some hardware implementations th= at are designed to do just one pass over the data. >> >> >> -- Christian Huitema >> >> >> > > -- > Mark Nottingham https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.mnot= ..net-252F-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C14f278ab376946= 9a44f908d59a16a2d6-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636= 584344383959765-26sdata-3DRXba2TyvYz6otecEHoLCT4tZ2I7EodxDiyPxWrn-252FnAw-2= 53D-26reserved-3D0&d=3DDwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfy= oaCsf6TA&m=3Dym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=3Db_XyJvAQscNJNC= wHmgj11ep8Xbsf7PvhDvONVZe3PR0&e=3D > --_000_DM3PR15MB0783129C7E584AF193B43485CDA40DM3PR15MB0783namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

PN encryption plus multiple (rota= ting) GUIDs specified on a per-path basis, as discussed in Melbourne do see= m able to provide substantively better privacy. With such a scheme nothing = appears to be shared from one 5-tuple+GUID to another 5-tuple+GUID.

An implementation that cared deep= ly about privacy would send packets along both paths for some time. This do= esn't seem like something we can reasonable require with the protocol, but = it can be allowed by the protocol.


I am not particularly interested = in seeing QUIC v1 become the most CPU efficient thing. I'd rather we releas= e it, and continue iterating. Concentrating on features that prevent ossifi= cation furthers this goal and allows for an eventual (and possibly better) HW acceleration path later.
-=3DR

From: QUIC <quic-bounces= @ietf.org> on behalf of Lubashev, Igor <ilubashe=3D40akamai.com@dmarc= ..ietf.org>
Sent: Wednesday, April 4, 2018 12:55:47 PM
To: Praveen Balasubramanian; Mirja K=FChlewind; Mark Nottingham
Cc: Lars Eggert; IETF QUIC WG
Subject: RE: Getting to consensus on packet number encryption
 
To restate the options:

(1) - Packet number encryption.

(2) - Per-CID offset.

(3) - Plain text PNs across connection migrations.

(4) - Per-CID PN spaces.



None of the alternatives mask the =93connection migration=94 event from an = on-path observer.  The =93original=94 connection establishment is done= via clearly identifiable handshake packets on a 5-tuple before short-heade= r packets show up, while =93connection migration=94 events are identifiable by the use of a new CID with short-header packets = on a new 5-tuple w/o preceding handshake packets.



As it was pointed out many times (especially by Brian), it is not that hard= to correlate cessation of packets from one 5-tuple and appearance of a new= post-=93connection migration=94 5-tuple, especially if destination IPs for= both are identical.  Moreover, since devices that wish to maintain connections during migration will likely mig= rate multiple connections, the on-path observer will see a group of 5-tuple= s from the same IP cease activity, while a similar group of post-=93connect= ion migration=94 5-tuples appears from a different IP, all with matched destination IPs.



Given the above, I am left wondering if increasing the costs for content ho= sting, increasing per-packet power requirements for mobile and micro device= s, and making the Internet harder to troubleshoot and operate is worth the = mostly illusory privacy gains of (1).  Patrick=92s =93the privacy is a must have=94 is a desire I shar= e, but does (1) provide privacy against a sophisticated on-path observer?


Yet, (2) seems simple enough and a good compromise.  As Mike points ou= t, it allows an on-path observer who can link CIDs across =93connection mig= rations=94 to infer PNs.  But if CIDs are already linked, there is no = more privacy argument to be made anyway.  One thing (2) does not allow an on-path observer to do is to link CIDs via PN = analysis.  (Though it still seems like the privacy gains from any of t= he above are mostly an illusion.)  So my vote is for (2).



- Igor





-----Original Message-----

From: Praveen Balasubramanian [mailto:pravb=3D40microsoft.com@dmarc.ietf.org]

Sent: Wednesday, April 04, 2018 3:15 PM

To: Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Mark Notting= ham <mnot@mnot.net>

Cc: Lars Eggert <lars@eggert.org>; IETF QUIC WG <quic@ietf.org>=

Subject: RE: Getting to consensus on packet number encryption



I too disagree with the assessment of the situation. +1 to everything M= irja said.



>> there is no *requirement* that we produce a protocol that is able = to be accelerated by hardware.

It is however a requirement for deployment that we be able to offload QUIC.= A large part of work we do in TCP is acceleration in software and hardware= .. If QUIC has to evolve from experiment to broad deployment performance is = a key goal. This is brought up several times in TCP working group where we see proposals that wouldn=92t work wit= h widely deployed software and hardware accelerations.



Whether we like it or not performance is a key requirement for QUIC on serv= ers and for datacenter scenarios. Even Ian mentioned before that he'd not w= ant to do PNE within DC and I agree. Most connections will also not be doin= g migration or using multi path so why pay the extra overhead in the common case for no benefit?



Since PNE doesn=92t affect the invariants (its simply an extra step post pa= cketization and pre parsing), please explain why it would block progress on= other fronts? What is the list of things that get blocked?



Please let us not rush into a design that impacts per packet processing cos= ts with no clear articulation of the problem and the benefits.



>From what I can tell there is wide disagreement in the group and nothing re= sembling consensus. The fact that we have poor representation from hardware= developers and public cloud providers is further skewing the perception.



My recommendations:

1. Leave the current draft as is. Make sure we have some provision for grea= sing the PN to prevent ossification.

2. Explore multiple PN spaces for connection migration (and eventually mult= ipath).

3. Make PNE an optional negotiated extension for implementations that want = to do connection migration in V1 with the caveat that we will revisit this = for V2 when we do multipath.

4. Solicit more feedback on the protocol from hardware vendors and public a= nd private cloud providers. I can try to loop in more folks but others shou= ld too.



-----Original Message-----

From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Mirja K=FChlewind

Sent: Wednesday, April 4, 2018 3:27 AM

To: Mark Nottingham <mnot@mnot.net>

Cc: Lars Eggert <lars@eggert.org>; IETF QUIC WG <quic@ietf.org>=

Subject: Re: Getting to consensus on packet number encryption



Hi Mark,



without intending to state a technical opinion, I think I need to disagree = with your assessment of the situation. Please see below.



> Am 04.04.2018 um 06:58 schrieb Mark Nottingham <mnot@mnot.net>:<= br>
>

> Hi everyone,

>

> The editors have told your chairs that this issue is starting to block= progress on other aspects of QUIC. Coming to consensus on it soon (i.e., b= efore Stockholm, if possible) would be good.

>

> It looks like this thread has come to a natural pause. Reading through= it, I think we agree there are some unpleasant tradeoffs here, but so far = we have only one concrete proposal -- PR#1079.



The other proposal is to use a random offset that can/should be changed whe= n the connection ID is changed. Which is mostly inline with what the draft = currently says.

>

> My AU$.05 - While we're chartered to produce a protocol that's encrypt= ed as much as operational concerns allow,



I don=92t think this is what the charter say. The charter says "Provid= ing always-secure transport, using TLS 1.3 by default.=93 plus another para= graph that talks about TLS1.3. It does not spell out the desire of some ind= ividual to =84encrypt as much as possible=93.



> and that privacy is a natural extension of that (especially in light o= f RFC7258 and RFC6973), there is no *requirement* that we produce a protoco= l that is able to be accelerated by hardware.



Not there is no requirement that the protocol need to be accelerated by har= dware. However, not all requirement are listed in the charter. We as a grou= p have to define the requirement. However, there is of course an implicit r= equirement for all work in the IEFT that is must be deployable and serve the needs of those people who want to= deploy it.



>

> That being the case, I think we need to ask ourselves if we believe th= at inclusion of PR#1079 will significantly inhibit deployment of the protoc= ol. Based on the discussion so far, that doesn't seem to be the case, but I= 'd be interested to hear what others think.



Here my assessment is also different. There are multiple people that have r= aised concerns that this could hinder deployment.

>

> If we can get to consensus to incorporate the PR, and folks come back = later with a more hardware-friendly replacement that doesn't change the Inv= ariants or increase linkability, I suspect the WG will be amenable to that.=



I don=92t think to just go with what we have even though there are concerns= , is the right approach and definitely not the approach that was chosen for= other proposals. In the sake of getting version v1 out quickly, I would th= ink that not incorporating another change that does not have consensus is the proposer approach.



Mirja







>

> What do folks think?

>

> Cheers,

>

>

>> On 29 Mar 2018, at 11:39 am, Ian Swett <ianswett=3D40google.com= @dmarc.ietf.org> wrote:

>>

>> Thanks for the nice summary Jana.

>>

>> As much as I'd love to have easier crypto HW acceleration, I've en= ded up arriving at the same conclusion.  I don't want to bite off the = work to do proper multipath in QUIC v1, which I think is the only other rea= sonable option of those Christian outlined.

>>

>> If someone comes up with a way to transform packet number to make = it non-linkable, but doesn't have the downside of making hardware offload d= ifficult, then I'm open to it.  But we've been talking about this for = 2 months without any notable improvements over Martin's PR.

>>

>> Given we never talk about any issue only once in QUIC, I'm sure th= is will come up again, but for the time being I think #1079 is the best opt= ion we have.

>>

>>

>>

>> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar <jri.ietf@gmail.co= m> wrote:

>> A few quick thoughts as I catch up on this thread.

>>

>> I spent some time last week working through a design using multipl= e PN spaces, and it is quite doable. I suspect we'll head towards multiple = PN spaces as we consider multipath in the future. That said, there is compl= exity (as Christian notes). This complexity may be warranted when doing multipath in v2 or later, but I'm not convince= d that this is necessary as a design primitive for QUICv1.

>>

>> We may want to creatively use the PN bits in v2, say to encode a p= ath ID and a PN, for multipath. We want to retain flexibility in these bits= going into v2. We've used encryption to ensure that we don't lose flexibil= ity elsewhere in the header, and it follows that we should use PNE to retain flexibility in these bits as well. (Simpl= icity of design is the other value in using PNE, since handling migration l= inkability is non-trivial without it.)

>>

>> This leaves the question of HW acceleration being at loggerheads w= ith the design in PR #1079. First, I expect that the primary benefit of acc= eleration will be in DC environments. Yes, there are some gains to be had i= n serving the public Internet as well, but I'm unconvinced that this is the driving use case for hardware acceler= ation. I understand that others may disagree with me here.

>>

>> AFAIK, QUIC has not been used in DC environments yet. I expect the= re are other things in the protocol that we'd want to change as we gain exp= erience deploying QUIC in DCs. Spinning up a new version to try QUIC within= DCs is not only appropriate, I would recommend it. This allows for rapid iterations internally, and the experie= nce can drive subsequent changes to QUIC. It's what *I* would do if I was t= o deploy QUIC inside a DC.

>>

>> So, in short, I think we should go ahead with PR# 1079. This ensur= es that future versions are guaranteed the flexibility to change the PN bit= s for better support of HW acceleration or multipath or what-have-you.

>>

>> - jana

>>

>> On Mar 26, 2018 9:41 AM, "Christian Huitema" <huitema= @huitema.net> wrote:

>>

>> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wro= te:

>>> Looking at https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__na01.safelinks.prote= ction.outlook.com_-3Furl-3Dhttps-253A-252F-252Fen.wikipedia.org-252Fwiki-25= 2FAES-5Finstruction-5Fset-2523Intel-5Fand-5FAMD-5Fx86-5Farchitecture-26data= -3D02-257C01-257Cpravb-2540microsoft.com-257C14f278ab3769469a44f908d59a16a2= d6-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636584344383959765-= 26sdata-3DaOHc7FZoIBCE1OlqmNpvdMM0ntLerZ3FpqESVj85zfE-253D-26reserved-3D0&a= mp;d=3DDwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf6TA= &m=3Dym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=3DWkBplmuEwMxL-o= ezaQ4rK1_9-0SXgkY1NJ_V3SPhYOU&e=3D it seems to imply a large range of server, desktop and mobile chips all ha= ve a CPU instruction set available to do AES acceleration and other similar= operations (other instruction sets are also available).

>>>

>>> If we are considering the AES instructions then it looks like = it is (or at least will be in the near future) a sizeable proportion of the= public internet have it to be used.

>>>

>>

>> Certainly, but that's not the current debate. PR #1079 is fully co= mpatible with use of the AES instructions. The issue of the debate is that = the mechanism in PR #1079 required double buffering, first encrypt the payl= oad, then use the result of the encryption to encrypt the PN. This is not an issue in a software implementation that = can readily access all bytes of the packet from memory, but it may be an is= sue in some hardware implementations that are designed to do just one pass = over the data.

>>

>>

>> -- Christian Huitema

>>

>>

>>

>

> --

> Mark Nottingham   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__na01.safelinks.prote= ction.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.mnot.net-252F-26data-3D0= 2-257C01-257Cpravb-2540microsoft.com-257C14f278ab3769469a44f908d59a16a2d6-2= 57C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636584344383959765-26sd= ata-3DRXba2TyvYz6otecEHoLCT4tZ2I7EodxDiyPxWrn-252FnAw-253D-26reserved-3D0&a= mp;d=3DDwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf6TA= &m=3Dym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=3Db_XyJvAQscNJNC= wHmgj11ep8Xbsf7PvhDvONVZe3PR0&e=3D

>



--_000_DM3PR15MB0783129C7E584AF193B43485CDA40DM3PR15MB0783namp_-- From nobody Wed Apr 4 13:29:10 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25CE12E894 for ; Wed, 4 Apr 2018 13:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=KyXN5pSV; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=fbH3mXOz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coJcsRu8NuzB for ; Wed, 4 Apr 2018 13:28:46 -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 3E9A912D864 for ; Wed, 4 Apr 2018 13:28:46 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w34KLvPX029444; Wed, 4 Apr 2018 13:28:41 -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=Msm9IffCnjchCUuYdyGDtX1sJsHbHNxtK8ul6IGROTc=; b=KyXN5pSVwWjSs9RyXuowveWbk2/i7kcLo9GjQDPBsjuzjU4TFEUWtICDBlHSiKYJgwUJ nFLhtWb0WYO+Bxgz1CA0i0a1o7dzIkBrw69CPGJJ1KpcvfutrIN3bLPzgFGVm4tNbcvj qf1qT60AG+jPvXtsNst0iVkQpLK83XFd2Nk= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 2h51y80swb-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 04 Apr 2018 13:28:41 -0700 Received: from PRN-CHUB02.TheFacebook.com (2620:10d:c081:35::11) by PRN-CHUB01.TheFacebook.com (2620:10d:c081:35::10) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 4 Apr 2018 13:28:40 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.12) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 4 Apr 2018 13:28:38 -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=Msm9IffCnjchCUuYdyGDtX1sJsHbHNxtK8ul6IGROTc=; b=fbH3mXOztGvqwlBsD7JscQb4yYE+8JDs+KXIADzsYlcZGhANnViixijD2nUx2JyhJsHRVD/U5gYetJ0ENrGLrhxGfJv8SW6iWBDoLDyUUmeSV2uWVMUfnwBkUAs/0Sev+xVfbd5g//MbFHrQIlzbDWejpQIqv78avg4BLWh9UqM= Received: from DM3PR15MB0783.namprd15.prod.outlook.com (10.164.201.11) by DM3PR15MB1002.namprd15.prod.outlook.com (10.166.160.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.631.10; Wed, 4 Apr 2018 20:28:37 +0000 Received: from DM3PR15MB0783.namprd15.prod.outlook.com ([fe80::e8a0:580f:a9c5:5185]) by DM3PR15MB0783.namprd15.prod.outlook.com ([fe80::e8a0:580f:a9c5:5185%13]) with mapi id 15.20.0653.012; Wed, 4 Apr 2018 20:28:37 +0000 From: Roberto Peon To: "Lubashev, Igor" , "Praveen Balasubramanian" , =?Windows-1252?Q?Mirja_K=FChlewind?= , Mark Nottingham CC: Lars Eggert , IETF QUIC WG Subject: Re: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GjyGQaKf4GI0anNhXTngANsKPwZ0sAgACTmYCAAAtRgIAABxcr Date: Wed, 4 Apr 2018 20:28:36 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> , 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:d981] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM3PR15MB1002; 7:it0UVEiodmsx8z67HvQLwBMWWHDBXnfqesd2UdWVI2fl999m+6b7Om3p57Xz05ckuHTOwZmij0GdmQasSCkoRFJX34xSNyqV6GNGJgMyGY7mppou2ffUMxEaOjmc+lYKpy7VtuL2a32ZHneeY6sS2pDiuCDht48JHqq/Vk2kdwUZF7QC3WLekfrNTGIMRxKgs8twx6/6nMzkjMtB4q2zhURd8tb6Gp21CfovRrpKUllYGVQ4fmjw478NEy2Wzs1Q; 20:nhdZWpV2byrNLR41CrsxkNGkUEUp3nt2tfg535d4/qZDCpqaGz7zbi2yefkt6EKuVutOaPlDC6chBqlpPkzth7Oq5JwRfjwUDmUGIEXUQR2vhn7T3ryMItotmqGPAv0WlQ4Awfn67aVD7soZ2h1veqthjHjKgV+OosEVeSHhKes= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 2042066b-12ea-4069-f78a-08d59a6aa51b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM3PR15MB1002; x-ms-traffictypediagnostic: DM3PR15MB1002: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(189930954265078)(85827821059158)(100405760836317)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(11241501184)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DM3PR15MB1002; BCL:0; PCL:0; RULEID:; SRVR:DM3PR15MB1002; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(39860400002)(346002)(376002)(396003)(199004)(13464003)(53754006)(189003)(51914003)(105586002)(25786009)(106356001)(102836004)(186003)(5250100002)(476003)(6116002)(97736004)(486006)(7736002)(14454004)(46003)(1511001)(575784001)(11346002)(8936002)(478600001)(45080400002)(86362001)(966005)(4326008)(446003)(54906003)(55016002)(316002)(229853002)(2906002)(59450400001)(74316002)(6606003)(3660700001)(33656002)(93886005)(110136005)(8666007)(68736007)(6506007)(53546011)(6306002)(54896002)(2900100001)(8676002)(6436002)(236005)(19627405001)(9686003)(5660300001)(53936002)(606006)(7696005)(81156014)(561944003)(6246003)(76176011)(99286004)(81166006)(3280700002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM3PR15MB1002; H:DM3PR15MB0783.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: xBpvGPA0/sOfF9ypxejoChp+l0k2g2JOfjsZ64xxVEmoLQc3rakrRTEslD0p6gR4fNTffCigobFlxnLsHbiZfGyB09jhLrzw1PX4bMqfymCpL035STia91jqjZUab802K2soNhMpSjQoJURYzP63biGOh02jc7ELFpyvmKViPteCPfjYDvKZWjXiMCs+GLoGVurr/kPoCWE8wXWhluThh9cVlZdEoIjJ/BmVTVOhv8uf2enUzG3vaiXduIDHKn56P08Z8es9Q7K29Q7UzCjs7O8eaH18F/8f4fa9ZF2Db705RBw7ka6c4AuP4dTMfIpVG/RIGU+NFh+WFC0RwM3C5GvsOjzKtI6nDEGvBgahJe6PH/xItBdIpSYV5d++5Hm3tVfVciUyo53EhKvRB52CuL1g9GQpSYJv/f77mSubDng= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM3PR15MB0783129C7E584AF193B43485CDA40DM3PR15MB0783namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2042066b-12ea-4069-f78a-08d59a6aa51b X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 20:28:36.9608 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR15MB1002 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-04_06:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 20:28:54 -0000 --_000_DM3PR15MB0783129C7E584AF193B43485CDA40DM3PR15MB0783namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable PN encryption plus multiple (rotating) GUIDs specified on a per-path basis,= as discussed in Melbourne do seem able to provide substantively better pri= vacy. With such a scheme nothing appears to be shared from one 5-tuple+GUID= to another 5-tuple+GUID. An implementation that cared deeply about privacy would send packets along = both paths for some time. This doesn't seem like something we can reasonabl= e require with the protocol, but it can be allowed by the protocol. I am not particularly interested in seeing QUIC v1 become the most CPU effi= cient thing. I'd rather we release it, and continue iterating. Concentratin= g on features that prevent ossification furthers this goal and allows for a= n eventual (and possibly better) HW acceleration path later. -=3DR ________________________________ From: QUIC on behalf of Lubashev, Igor Sent: Wednesday, April 4, 2018 12:55:47 PM To: Praveen Balasubramanian; Mirja K=FChlewind; Mark Nottingham Cc: Lars Eggert; IETF QUIC WG Subject: RE: Getting to consensus on packet number encryption To restate the options: (1) - Packet number encryption. (2) - Per-CID offset. (3) - Plain text PNs across connection migrations. (4) - Per-CID PN spaces. None of the alternatives mask the =93connection migration=94 event from an = on-path observer. The =93original=94 connection establishment is done via = clearly identifiable handshake packets on a 5-tuple before short-header pac= kets show up, while =93connection migration=94 events are identifiable by t= he use of a new CID with short-header packets on a new 5-tuple w/o precedin= g handshake packets. As it was pointed out many times (especially by Brian), it is not that hard= to correlate cessation of packets from one 5-tuple and appearance of a new= post-=93connection migration=94 5-tuple, especially if destination IPs for= both are identical. Moreover, since devices that wish to maintain connect= ions during migration will likely migrate multiple connections, the on-path= observer will see a group of 5-tuples from the same IP cease activity, whi= le a similar group of post-=93connection migration=94 5-tuples appears from= a different IP, all with matched destination IPs. Given the above, I am left wondering if increasing the costs for content ho= sting, increasing per-packet power requirements for mobile and micro device= s, and making the Internet harder to troubleshoot and operate is worth the = mostly illusory privacy gains of (1). Patrick=92s =93the privacy is a must= have=94 is a desire I share, but does (1) provide privacy against a sophis= ticated on-path observer? Yet, (2) seems simple enough and a good compromise. As Mike points out, it= allows an on-path observer who can link CIDs across =93connection migratio= ns=94 to infer PNs. But if CIDs are already linked, there is no more priva= cy argument to be made anyway. One thing (2) does not allow an on-path obs= erver to do is to link CIDs via PN analysis. (Though it still seems like t= he privacy gains from any of the above are mostly an illusion.) So my vote= is for (2). - Igor -----Original Message----- From: Praveen Balasubramanian [mailto:pravb=3D40microsoft.com@dmarc.ietf.or= g] Sent: Wednesday, April 04, 2018 3:15 PM To: Mirja K=FChlewind ; Mark Nottingham Cc: Lars Eggert ; IETF QUIC WG Subject: RE: Getting to consensus on packet number encryption I too disagree with the assessment of the situation. +1 to everything Mirja= said. >> there is no *requirement* that we produce a protocol that is able to be = accelerated by hardware. It is however a requirement for deployment that we be able to offload QUIC.= A large part of work we do in TCP is acceleration in software and hardware= . If QUIC has to evolve from experiment to broad deployment performance is = a key goal. This is brought up several times in TCP working group where we = see proposals that wouldn=92t work with widely deployed software and hardwa= re accelerations. Whether we like it or not performance is a key requirement for QUIC on serv= ers and for datacenter scenarios. Even Ian mentioned before that he'd not w= ant to do PNE within DC and I agree. Most connections will also not be doin= g migration or using multi path so why pay the extra overhead in the common= case for no benefit? Since PNE doesn=92t affect the invariants (its simply an extra step post pa= cketization and pre parsing), please explain why it would block progress on= other fronts? What is the list of things that get blocked? Please let us not rush into a design that impacts per packet processing cos= ts with no clear articulation of the problem and the benefits. >From what I can tell there is wide disagreement in the group and nothing re= sembling consensus. The fact that we have poor representation from hardware= developers and public cloud providers is further skewing the perception. My recommendations: 1. Leave the current draft as is. Make sure we have some provision for grea= sing the PN to prevent ossification. 2. Explore multiple PN spaces for connection migration (and eventually mult= ipath). 3. Make PNE an optional negotiated extension for implementations that want = to do connection migration in V1 with the caveat that we will revisit this = for V2 when we do multipath. 4. Solicit more feedback on the protocol from hardware vendors and public a= nd private cloud providers. I can try to loop in more folks but others shou= ld too. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mirja K=FChlewind Sent: Wednesday, April 4, 2018 3:27 AM To: Mark Nottingham Cc: Lars Eggert ; IETF QUIC WG Subject: Re: Getting to consensus on packet number encryption Hi Mark, without intending to state a technical opinion, I think I need to disagree = with your assessment of the situation. Please see below. > Am 04.04.2018 um 06:58 schrieb Mark Nottingham : > > Hi everyone, > > The editors have told your chairs that this issue is starting to block pr= ogress on other aspects of QUIC. Coming to consensus on it soon (i.e., befo= re Stockholm, if possible) would be good. > > It looks like this thread has come to a natural pause. Reading through it= , I think we agree there are some unpleasant tradeoffs here, but so far we = have only one concrete proposal -- PR#1079. The other proposal is to use a random offset that can/should be changed whe= n the connection ID is changed. Which is mostly inline with what the draft = currently says. > > My AU$.05 - While we're chartered to produce a protocol that's encrypted = as much as operational concerns allow, I don=92t think this is what the charter say. The charter says "Providing a= lways-secure transport, using TLS 1.3 by default.=93 plus another paragraph= that talks about TLS1.3. It does not spell out the desire of some individu= al to =84encrypt as much as possible=93. > and that privacy is a natural extension of that (especially in light of R= FC7258 and RFC6973), there is no *requirement* that we produce a protocol t= hat is able to be accelerated by hardware. Not there is no requirement that the protocol need to be accelerated by har= dware. However, not all requirement are listed in the charter. We as a grou= p have to define the requirement. However, there is of course an implicit r= equirement for all work in the IEFT that is must be deployable and serve th= e needs of those people who want to deploy it. > > That being the case, I think we need to ask ourselves if we believe that = inclusion of PR#1079 will significantly inhibit deployment of the protocol.= Based on the discussion so far, that doesn't seem to be the case, but I'd = be interested to hear what others think. Here my assessment is also different. There are multiple people that have r= aised concerns that this could hinder deployment. > > If we can get to consensus to incorporate the PR, and folks come back lat= er with a more hardware-friendly replacement that doesn't change the Invari= ants or increase linkability, I suspect the WG will be amenable to that. I don=92t think to just go with what we have even though there are concerns= , is the right approach and definitely not the approach that was chosen for= other proposals. In the sake of getting version v1 out quickly, I would th= ink that not incorporating another change that does not have consensus is t= he proposer approach. Mirja > > What do folks think? > > Cheers, > > >> On 29 Mar 2018, at 11:39 am, Ian Swett wrote: >> >> Thanks for the nice summary Jana. >> >> As much as I'd love to have easier crypto HW acceleration, I've ended up= arriving at the same conclusion. I don't want to bite off the work to do = proper multipath in QUIC v1, which I think is the only other reasonable opt= ion of those Christian outlined. >> >> If someone comes up with a way to transform packet number to make it non= -linkable, but doesn't have the downside of making hardware offload difficu= lt, then I'm open to it. But we've been talking about this for 2 months wi= thout any notable improvements over Martin's PR. >> >> Given we never talk about any issue only once in QUIC, I'm sure this wil= l come up again, but for the time being I think #1079 is the best option we= have. >> >> >> >> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar wrote: >> A few quick thoughts as I catch up on this thread. >> >> I spent some time last week working through a design using multiple PN s= paces, and it is quite doable. I suspect we'll head towards multiple PN spa= ces as we consider multipath in the future. That said, there is complexity = (as Christian notes). This complexity may be warranted when doing multipath= in v2 or later, but I'm not convinced that this is necessary as a design p= rimitive for QUICv1. >> >> We may want to creatively use the PN bits in v2, say to encode a path ID= and a PN, for multipath. We want to retain flexibility in these bits going= into v2. We've used encryption to ensure that we don't lose flexibility el= sewhere in the header, and it follows that we should use PNE to retain flex= ibility in these bits as well. (Simplicity of design is the other value in = using PNE, since handling migration linkability is non-trivial without it.) >> >> This leaves the question of HW acceleration being at loggerheads with th= e design in PR #1079. First, I expect that the primary benefit of accelerat= ion will be in DC environments. Yes, there are some gains to be had in serv= ing the public Internet as well, but I'm unconvinced that this is the drivi= ng use case for hardware acceleration. I understand that others may disagre= e with me here. >> >> AFAIK, QUIC has not been used in DC environments yet. I expect there are= other things in the protocol that we'd want to change as we gain experienc= e deploying QUIC in DCs. Spinning up a new version to try QUIC within DCs i= s not only appropriate, I would recommend it. This allows for rapid iterati= ons internally, and the experience can drive subsequent changes to QUIC. It= 's what *I* would do if I was to deploy QUIC inside a DC. >> >> So, in short, I think we should go ahead with PR# 1079. This ensures tha= t future versions are guaranteed the flexibility to change the PN bits for = better support of HW acceleration or multipath or what-have-you. >> >> - jana >> >> On Mar 26, 2018 9:41 AM, "Christian Huitema" wrote= : >> >> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote: >>> Looking at https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__na01.= safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fen.wikipedia.= org-252Fwiki-252FAES-5Finstruction-5Fset-2523Intel-5Fand-5FAMD-5Fx86-5Farch= itecture-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C14f278ab3769469= a44f908d59a16a2d6-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C6365= 84344383959765-26sdata-3DaOHc7FZoIBCE1OlqmNpvdMM0ntLerZ3FpqESVj85zfE-253D-2= 6reserved-3D0&d=3DDwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf= 6TA&m=3Dym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=3DWkBplmuEwMxL-oezaQ4= rK1_9-0SXgkY1NJ_V3SPhYOU&e=3D it seems to imply a large range of server, de= sktop and mobile chips all have a CPU instruction set available to do AES a= cceleration and other similar operations (other instruction sets are also a= vailable). >>> >>> If we are considering the AES instructions then it looks like it is (or= at least will be in the near future) a sizeable proportion of the public i= nternet have it to be used. >>> >> >> Certainly, but that's not the current debate. PR #1079 is fully compatib= le with use of the AES instructions. The issue of the debate is that the me= chanism in PR #1079 required double buffering, first encrypt the payload, t= hen use the result of the encryption to encrypt the PN. This is not an issu= e in a software implementation that can readily access all bytes of the pac= ket from memory, but it may be an issue in some hardware implementations th= at are designed to do just one pass over the data. >> >> >> -- Christian Huitema >> >> >> > > -- > Mark Nottingham https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.mnot= .net-252F-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C14f278ab376946= 9a44f908d59a16a2d6-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636= 584344383959765-26sdata-3DRXba2TyvYz6otecEHoLCT4tZ2I7EodxDiyPxWrn-252FnAw-2= 53D-26reserved-3D0&d=3DDwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfy= oaCsf6TA&m=3Dym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=3Db_XyJvAQscNJNC= wHmgj11ep8Xbsf7PvhDvONVZe3PR0&e=3D > --_000_DM3PR15MB0783129C7E584AF193B43485CDA40DM3PR15MB0783namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

PN encryption plus multiple (rota= ting) GUIDs specified on a per-path basis, as discussed in Melbourne do see= m able to provide substantively better privacy. With such a scheme nothing = appears to be shared from one 5-tuple+GUID to another 5-tuple+GUID.

An implementation that cared deep= ly about privacy would send packets along both paths for some time. This do= esn't seem like something we can reasonable require with the protocol, but = it can be allowed by the protocol.


I am not particularly interested = in seeing QUIC v1 become the most CPU efficient thing. I'd rather we releas= e it, and continue iterating. Concentrating on features that prevent ossifi= cation furthers this goal and allows for an eventual (and possibly better) HW acceleration path later.
-=3DR

From: QUIC <quic-bounces= @ietf.org> on behalf of Lubashev, Igor <ilubashe=3D40akamai.com@dmarc= .ietf.org>
Sent: Wednesday, April 4, 2018 12:55:47 PM
To: Praveen Balasubramanian; Mirja K=FChlewind; Mark Nottingham
Cc: Lars Eggert; IETF QUIC WG
Subject: RE: Getting to consensus on packet number encryption
 
To restate the options:

(1) - Packet number encryption.

(2) - Per-CID offset.

(3) - Plain text PNs across connection migrations.

(4) - Per-CID PN spaces.



None of the alternatives mask the =93connection migration=94 event from an = on-path observer.  The =93original=94 connection establishment is done= via clearly identifiable handshake packets on a 5-tuple before short-heade= r packets show up, while =93connection migration=94 events are identifiable by the use of a new CID with short-header packets = on a new 5-tuple w/o preceding handshake packets.



As it was pointed out many times (especially by Brian), it is not that hard= to correlate cessation of packets from one 5-tuple and appearance of a new= post-=93connection migration=94 5-tuple, especially if destination IPs for= both are identical.  Moreover, since devices that wish to maintain connections during migration will likely mig= rate multiple connections, the on-path observer will see a group of 5-tuple= s from the same IP cease activity, while a similar group of post-=93connect= ion migration=94 5-tuples appears from a different IP, all with matched destination IPs.



Given the above, I am left wondering if increasing the costs for content ho= sting, increasing per-packet power requirements for mobile and micro device= s, and making the Internet harder to troubleshoot and operate is worth the = mostly illusory privacy gains of (1).  Patrick=92s =93the privacy is a must have=94 is a desire I shar= e, but does (1) provide privacy against a sophisticated on-path observer?


Yet, (2) seems simple enough and a good compromise.  As Mike points ou= t, it allows an on-path observer who can link CIDs across =93connection mig= rations=94 to infer PNs.  But if CIDs are already linked, there is no = more privacy argument to be made anyway.  One thing (2) does not allow an on-path observer to do is to link CIDs via PN = analysis.  (Though it still seems like the privacy gains from any of t= he above are mostly an illusion.)  So my vote is for (2).



- Igor





-----Original Message-----

From: Praveen Balasubramanian [mailto:pravb=3D40microsoft.com@dmarc.ietf.org]

Sent: Wednesday, April 04, 2018 3:15 PM

To: Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Mark Notting= ham <mnot@mnot.net>

Cc: Lars Eggert <lars@eggert.org>; IETF QUIC WG <quic@ietf.org>=

Subject: RE: Getting to consensus on packet number encryption



I too disagree with the assessment of the situation. +1 to everything M= irja said.



>> there is no *requirement* that we produce a protocol that is able = to be accelerated by hardware.

It is however a requirement for deployment that we be able to offload QUIC.= A large part of work we do in TCP is acceleration in software and hardware= . If QUIC has to evolve from experiment to broad deployment performance is = a key goal. This is brought up several times in TCP working group where we see proposals that wouldn=92t work wit= h widely deployed software and hardware accelerations.



Whether we like it or not performance is a key requirement for QUIC on serv= ers and for datacenter scenarios. Even Ian mentioned before that he'd not w= ant to do PNE within DC and I agree. Most connections will also not be doin= g migration or using multi path so why pay the extra overhead in the common case for no benefit?



Since PNE doesn=92t affect the invariants (its simply an extra step post pa= cketization and pre parsing), please explain why it would block progress on= other fronts? What is the list of things that get blocked?



Please let us not rush into a design that impacts per packet processing cos= ts with no clear articulation of the problem and the benefits.



>From what I can tell there is wide disagreement in the group and nothing re= sembling consensus. The fact that we have poor representation from hardware= developers and public cloud providers is further skewing the perception.



My recommendations:

1. Leave the current draft as is. Make sure we have some provision for grea= sing the PN to prevent ossification.

2. Explore multiple PN spaces for connection migration (and eventually mult= ipath).

3. Make PNE an optional negotiated extension for implementations that want = to do connection migration in V1 with the caveat that we will revisit this = for V2 when we do multipath.

4. Solicit more feedback on the protocol from hardware vendors and public a= nd private cloud providers. I can try to loop in more folks but others shou= ld too.



-----Original Message-----

From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Mirja K=FChlewind

Sent: Wednesday, April 4, 2018 3:27 AM

To: Mark Nottingham <mnot@mnot.net>

Cc: Lars Eggert <lars@eggert.org>; IETF QUIC WG <quic@ietf.org>=

Subject: Re: Getting to consensus on packet number encryption



Hi Mark,



without intending to state a technical opinion, I think I need to disagree = with your assessment of the situation. Please see below.



> Am 04.04.2018 um 06:58 schrieb Mark Nottingham <mnot@mnot.net>:<= br>
>

> Hi everyone,

>

> The editors have told your chairs that this issue is starting to block= progress on other aspects of QUIC. Coming to consensus on it soon (i.e., b= efore Stockholm, if possible) would be good.

>

> It looks like this thread has come to a natural pause. Reading through= it, I think we agree there are some unpleasant tradeoffs here, but so far = we have only one concrete proposal -- PR#1079.



The other proposal is to use a random offset that can/should be changed whe= n the connection ID is changed. Which is mostly inline with what the draft = currently says.

>

> My AU$.05 - While we're chartered to produce a protocol that's encrypt= ed as much as operational concerns allow,



I don=92t think this is what the charter say. The charter says "Provid= ing always-secure transport, using TLS 1.3 by default.=93 plus another para= graph that talks about TLS1.3. It does not spell out the desire of some ind= ividual to =84encrypt as much as possible=93.



> and that privacy is a natural extension of that (especially in light o= f RFC7258 and RFC6973), there is no *requirement* that we produce a protoco= l that is able to be accelerated by hardware.



Not there is no requirement that the protocol need to be accelerated by har= dware. However, not all requirement are listed in the charter. We as a grou= p have to define the requirement. However, there is of course an implicit r= equirement for all work in the IEFT that is must be deployable and serve the needs of those people who want to= deploy it.



>

> That being the case, I think we need to ask ourselves if we believe th= at inclusion of PR#1079 will significantly inhibit deployment of the protoc= ol. Based on the discussion so far, that doesn't seem to be the case, but I= 'd be interested to hear what others think.



Here my assessment is also different. There are multiple people that have r= aised concerns that this could hinder deployment.

>

> If we can get to consensus to incorporate the PR, and folks come back = later with a more hardware-friendly replacement that doesn't change the Inv= ariants or increase linkability, I suspect the WG will be amenable to that.=



I don=92t think to just go with what we have even though there are concerns= , is the right approach and definitely not the approach that was chosen for= other proposals. In the sake of getting version v1 out quickly, I would th= ink that not incorporating another change that does not have consensus is the proposer approach.



Mirja







>

> What do folks think?

>

> Cheers,

>

>

>> On 29 Mar 2018, at 11:39 am, Ian Swett <ianswett=3D40google.com= @dmarc.ietf.org> wrote:

>>

>> Thanks for the nice summary Jana.

>>

>> As much as I'd love to have easier crypto HW acceleration, I've en= ded up arriving at the same conclusion.  I don't want to bite off the = work to do proper multipath in QUIC v1, which I think is the only other rea= sonable option of those Christian outlined.

>>

>> If someone comes up with a way to transform packet number to make = it non-linkable, but doesn't have the downside of making hardware offload d= ifficult, then I'm open to it.  But we've been talking about this for = 2 months without any notable improvements over Martin's PR.

>>

>> Given we never talk about any issue only once in QUIC, I'm sure th= is will come up again, but for the time being I think #1079 is the best opt= ion we have.

>>

>>

>>

>> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar <jri.ietf@gmail.co= m> wrote:

>> A few quick thoughts as I catch up on this thread.

>>

>> I spent some time last week working through a design using multipl= e PN spaces, and it is quite doable. I suspect we'll head towards multiple = PN spaces as we consider multipath in the future. That said, there is compl= exity (as Christian notes). This complexity may be warranted when doing multipath in v2 or later, but I'm not convince= d that this is necessary as a design primitive for QUICv1.

>>

>> We may want to creatively use the PN bits in v2, say to encode a p= ath ID and a PN, for multipath. We want to retain flexibility in these bits= going into v2. We've used encryption to ensure that we don't lose flexibil= ity elsewhere in the header, and it follows that we should use PNE to retain flexibility in these bits as well. (Simpl= icity of design is the other value in using PNE, since handling migration l= inkability is non-trivial without it.)

>>

>> This leaves the question of HW acceleration being at loggerheads w= ith the design in PR #1079. First, I expect that the primary benefit of acc= eleration will be in DC environments. Yes, there are some gains to be had i= n serving the public Internet as well, but I'm unconvinced that this is the driving use case for hardware acceler= ation. I understand that others may disagree with me here.

>>

>> AFAIK, QUIC has not been used in DC environments yet. I expect the= re are other things in the protocol that we'd want to change as we gain exp= erience deploying QUIC in DCs. Spinning up a new version to try QUIC within= DCs is not only appropriate, I would recommend it. This allows for rapid iterations internally, and the experie= nce can drive subsequent changes to QUIC. It's what *I* would do if I was t= o deploy QUIC inside a DC.

>>

>> So, in short, I think we should go ahead with PR# 1079. This ensur= es that future versions are guaranteed the flexibility to change the PN bit= s for better support of HW acceleration or multipath or what-have-you.

>>

>> - jana

>>

>> On Mar 26, 2018 9:41 AM, "Christian Huitema" <huitema= @huitema.net> wrote:

>>

>> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wro= te:

>>> Looking at https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__na01.safelinks.prote= ction.outlook.com_-3Furl-3Dhttps-253A-252F-252Fen.wikipedia.org-252Fwiki-25= 2FAES-5Finstruction-5Fset-2523Intel-5Fand-5FAMD-5Fx86-5Farchitecture-26data= -3D02-257C01-257Cpravb-2540microsoft.com-257C14f278ab3769469a44f908d59a16a2= d6-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636584344383959765-= 26sdata-3DaOHc7FZoIBCE1OlqmNpvdMM0ntLerZ3FpqESVj85zfE-253D-26reserved-3D0&a= mp;d=3DDwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf6TA= &m=3Dym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=3DWkBplmuEwMxL-o= ezaQ4rK1_9-0SXgkY1NJ_V3SPhYOU&e=3D it seems to imply a large range of server, desktop and mobile chips all ha= ve a CPU instruction set available to do AES acceleration and other similar= operations (other instruction sets are also available).

>>>

>>> If we are considering the AES instructions then it looks like = it is (or at least will be in the near future) a sizeable proportion of the= public internet have it to be used.

>>>

>>

>> Certainly, but that's not the current debate. PR #1079 is fully co= mpatible with use of the AES instructions. The issue of the debate is that = the mechanism in PR #1079 required double buffering, first encrypt the payl= oad, then use the result of the encryption to encrypt the PN. This is not an issue in a software implementation that = can readily access all bytes of the packet from memory, but it may be an is= sue in some hardware implementations that are designed to do just one pass = over the data.

>>

>>

>> -- Christian Huitema

>>

>>

>>

>

> --

> Mark Nottingham   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__na01.safelinks.prote= ction.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.mnot.net-252F-26data-3D0= 2-257C01-257Cpravb-2540microsoft.com-257C14f278ab3769469a44f908d59a16a2d6-2= 57C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636584344383959765-26sd= ata-3DRXba2TyvYz6otecEHoLCT4tZ2I7EodxDiyPxWrn-252FnAw-253D-26reserved-3D0&a= mp;d=3DDwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf6TA= &m=3Dym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=3Db_XyJvAQscNJNC= wHmgj11ep8Xbsf7PvhDvONVZe3PR0&e=3D

>



--_000_DM3PR15MB0783129C7E584AF193B43485CDA40DM3PR15MB0783namp_-- From nobody Wed Apr 4 13:34:21 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F61B12DB6E for ; Wed, 4 Apr 2018 13:34: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, 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 eqNs0trZZBhm for ; Wed, 4 Apr 2018 13:34:17 -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 B4BDF12D864 for ; Wed, 4 Apr 2018 13:34:17 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id f6-v6so249598ita.2 for ; Wed, 04 Apr 2018 13:34: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; bh=k1pKaS709lgCzISYRbVgEQ55UUoLeVPFVDFneEgKMvU=; b=ZLOEV0f/RZLU9M/xpPZSovKVoV2GY2wfTuxYTwbHtfqyfe+SZUGTExy//HAdkNpkT4 BNcym33vqX7+xJEaKHf5T5T4WzN22PEEmymjrFmG4KdgRabxesNiOCree7W5iB0DZRM1 Iel7Q394YLZgKK47Hz+tqDecIdKh7b32C4CV7VYVaHwxXmX6iGatbeaJXKp5G4IBt3pG d5dPMiMTmYUUOFnzW1b1JAgFZaURvWBHzPeMXlqjntK1q5TYIxZebwXjlx8xu6C1RmWk GboqL9qTgdSUXQGOzDJk8UvQW7TZYhoTfuczkS6TlgsuBqpE7Sm+hhrNufYayosz7qPO 5X6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=k1pKaS709lgCzISYRbVgEQ55UUoLeVPFVDFneEgKMvU=; b=CKYCHERz5tqfTsN0P4H9k0JymTmHQ2I5v7Z+ChT/XXziK73CRF/wiCDxD4wlCE/EFI RQjtHIlBUpmP+ZDuRKgIx5uUvnZ8uyanL+Bb91Qi/UhtMc3kGggu7mYYWzdS5S0LaBCz qs7e4Ii5B6MFNC1g6d3Zn3GxAEv87ySv0THbbBWrwQrl0rv4vbQ7lrEbwhtAHa7eRi9d 652KVTGWygRUfkX9yyBHcRMy0a2KT/9QgeN0YVefqLDFCrpVytTCV//VvIcadMlHHSBC cmF8DZVeLhtQHrKd4ATs5YXYppvWif7KmWyhEKD/IJmo6jZlW/cm2IhOAVDO9JAUfF4S XOUg== X-Gm-Message-State: ALQs6tAyDzmJeYF+ccLzIKNuy/n+++3+FP2ijyQx8nDuwKVEsQvYcESL z4uPUVTdSM1hlUgHeKRux4KsEirAwmxk6FeqbCKy8P2k X-Google-Smtp-Source: AIpwx4/QCtfS2yKdgmkOt94Oev5fcsR2aLEbKPgkCy6RYfXxZUMmCCaNB6eiGB2Chmo9UfFQUngl3WqMMXxsdDMIDnc= X-Received: by 2002:a24:7088:: with SMTP id f130-v6mr10931990itc.39.1522874057020; Wed, 04 Apr 2018 13:34:17 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Apr 2018 22:34:16 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 4 Apr 2018 22:34:16 +0200 Message-ID: Subject: Re: Impact of hardware offloads on network stack performance To: Praveen Balasubramanian , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000034d9ea05690bbf5d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 20:34:20 -0000 --00000000000034d9ea05690bbf5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for sharing these numbers. My guess is that these offloads deal with kernel scheduling, memory cache issues, and interrupt scheduling. It probably has very little to do with crypto, TCP headers, and any other cpu sensitive processing. This is where netmap enters: you can transparently feed the data as it becomes available with very little sync work and you can also efficiently pipeline so you pass data to decryptor, then to app, with as little bus traffic as possible. No need to copy data or synchronize kernel space. For 1K packets you would use about 1000ns (3 cycles/byte) on crypto and this would happen in L1 cache. It would of course consume a core which a crypto offload would not, but that can be debated because with 18 core systems, your problem is memory and network more than CPU. My concern with PNE is for small packets and low latency where 1) an estimated 24ns for PN encryption and decryption becomes measurable if your network is fast enough. 2) any damage to the packet buffer cause all sorts of memory and cpu bus traffic issues. 1) is annoying. 2) is bad, completely avoidable but not as PR 1079 is formulated currently. 2) is also likely bad for hardware offload units as well. As to SRV-IO - I=E2=80=99m not familiar with it, but obviously there is som= e IO abstraction layer - the question is how you make it accessible to apps as opposed to device drivers that does nor work with you QUIC custom stack, and netmap is one option here. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 4 April 2018 at 22.15.52, Praveen Balasubramanian ( pravb=3D40microsoft.com@dmarc.ietf.org) wrote: Some comparative numbers from an out of box default settings Windows Server 2016 (released version) for a single connection with a microbenchmark tool: *Offloads enabled* *TCP gbps* *UDP gbps* *LSO + LRO + checksum* 24 3.6 *Checksum only* 7.6 3.6 *None* 5.6 2.3 This is for a fully bottlenecked CPU core -- *if you run lower data rates there is still a significant difference in Cycles/byte cost*. Same increased CPU cost applies for client systems going over high data rate Wifi and cellular. This is without any crypto. Once you add crypto the numbers become much worse *with crypto cost becoming dominant*. Adding another crypto step further exacerbates the problem. Hence crypto offload gains in importance followed by these batch offloads. If folks need any more numbers I=E2=80=99d be happy to provide them. Thanks --00000000000034d9ea05690bbf5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Thanks for sharing t= hese numbers.

My gues= s is that these offloads deal with kernel scheduling, memory cache issues, = and interrupt scheduling.

It probably has very little to do with crypto, TCP headers, and any ot= her cpu sensitive processing.

This is where netmap enters: you can transparently feed the data a= s it becomes available with very little sync work and you can also efficien= tly pipeline so you pass data to decryptor, then to app, with as little bus= traffic as possible. No need to copy data or synchronize kernel space.

For 1K packets you would= use about 1000ns (3 cycles/byte) on crypto and this would happen in L1 cac= he. It would of course consume a core which a crypto offload would not, but= that can be debated because with 18 core systems, your problem is memory a= nd network more than CPU.

My concern with PNE is for small packets and low latency where
1) an estimated 24ns= for PN encryption and decryption becomes measurable if your network is fas= t enough.
2) = any damage to the packet buffer cause all sorts of memory and cpu bus traff= ic issues.
1) is anno= ying. 2) is bad, completely avoidable but not as PR 1079 is formulated curr= ently.

2) is also lik= ely bad for hardware offload units as well.

As to SRV-IO - I=E2=80=99m not fa= miliar with it, but obviously there is some IO abstraction layer - the ques= tion is how you make it accessible to apps as opposed to device drivers tha= t does nor work with you QUIC custom stack, and netmap is one option here.<= div>
Kind Regards,
=
Mikkel Fahn=C3=B8= e J=C3=B8rgensen


On 4 April= 2018 at 22.15.52, Praveen Balasubramanian (pravb=3D40microsoft.com@dmarc.ietf.org) wrot= e:

Some comparative numbers from an out of box default = settings Windows Server 2016 (released version) for a single connection wit= h a microbenchmark tool:

=C2=A0

Offloads enabled

TCP gbps

UDP gbps

LSO + LRO + checksum

24

3.6

Checksum only

7.6

3.6

None

5.6

2.3

=C2=A0

This is for a fully bottlenecked CPU core -- if y= ou run lower data rates there is still a significant difference in Cycles/b= yte cost. Same increased CPU cost applies for client systems going over= high data rate Wifi and cellular.

=C2=A0

This is without any crypto. Once you add crypto the = numbers become much worse with crypto cost becoming dominant. Adding another crypto step furth= er exacerbates the problem. Hence crypto offload gains in importance follow= ed by these batch offloads.

=C2=A0

If folks need any more numbers I=E2=80=99d be happy = to provide them.

=C2=A0

Thanks

=C2=A0

--00000000000034d9ea05690bbf5d-- From nobody Wed Apr 4 13:34:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC2512DB6E for ; Wed, 4 Apr 2018 13:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522874061; bh=k1pKaS709lgCzISYRbVgEQ55UUoLeVPFVDFneEgKMvU=; h=From:In-Reply-To:References:Date:Subject:To:To; b=pCou4OdsnI9jYw1GXr453MMPSdrdRM1L4M9lYEq7movpt1fJ82WbXa5QyS9LUJxSr 2zquvTHgSBqB/pkFXRyy4b8i0p/et9bHJg0k9A2Sz3GAP6pIuV2GfmrZH5QAfjaD8e IzO92eESEZjX31jL0bmijtYQ/i9Dvt7o3it8z79M= X-Mailbox-Line: From mikkelfj@gmail.com Wed Apr 4 13:34:21 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F4512DA68; Wed, 4 Apr 2018 13:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522874061; bh=k1pKaS709lgCzISYRbVgEQ55UUoLeVPFVDFneEgKMvU=; h=From:In-Reply-To:References:Date:Subject:To:To; b=pCou4OdsnI9jYw1GXr453MMPSdrdRM1L4M9lYEq7movpt1fJ82WbXa5QyS9LUJxSr 2zquvTHgSBqB/pkFXRyy4b8i0p/et9bHJg0k9A2Sz3GAP6pIuV2GfmrZH5QAfjaD8e IzO92eESEZjX31jL0bmijtYQ/i9Dvt7o3it8z79M= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D1D12D864 for ; Wed, 4 Apr 2018 13:34:21 -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=unavailable 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 iecN9WV8oY1Z for ; Wed, 4 Apr 2018 13:34:18 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F268B12DA68 for ; Wed, 4 Apr 2018 13:34:17 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id b5-v6so255904itj.1 for ; Wed, 04 Apr 2018 13:34: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; bh=k1pKaS709lgCzISYRbVgEQ55UUoLeVPFVDFneEgKMvU=; b=ZLOEV0f/RZLU9M/xpPZSovKVoV2GY2wfTuxYTwbHtfqyfe+SZUGTExy//HAdkNpkT4 BNcym33vqX7+xJEaKHf5T5T4WzN22PEEmymjrFmG4KdgRabxesNiOCree7W5iB0DZRM1 Iel7Q394YLZgKK47Hz+tqDecIdKh7b32C4CV7VYVaHwxXmX6iGatbeaJXKp5G4IBt3pG d5dPMiMTmYUUOFnzW1b1JAgFZaURvWBHzPeMXlqjntK1q5TYIxZebwXjlx8xu6C1RmWk GboqL9qTgdSUXQGOzDJk8UvQW7TZYhoTfuczkS6TlgsuBqpE7Sm+hhrNufYayosz7qPO 5X6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=k1pKaS709lgCzISYRbVgEQ55UUoLeVPFVDFneEgKMvU=; b=tuQXUx7/Pd3e1GAr4VDdMAIeB3X0dCPujwMzNzPGpUVb0T/DB8fptFaWffcpMh5DEp Q6WLia6seSVRDkZ0vWY3m2BcSMabicAuyNmxe36iVUvjPOwLNgERo5fcsxdW4hdAZRCV iezzHBz+02FfP+q5sHJgcUwVll9aHjS9E1rZ30h7dlYCeWSEzy/iP3CuS7QVf90VPumk 3ZRGWbt7HgLCAz7iWss+cjH7qCcGsZ/WCIlcNH3wh2V2tmyfJ01sWNUUZmXfGeBszUgR klhIJJZQ/6rKH/y2Xqe9iCL6i79cudMS9DQSrwSqeEuAzOIB7hnpZ2uoQ0+fSxajzwDe fofg== X-Gm-Message-State: ALQs6tDgCzMu0Bq18ezKBqshgUh0Zku46RpbD1TnfwLI5r+cid98f99U 5uTVvnIknvlIqa+hcG/ztToTchFWVfj43YdeF43Hn6x0 X-Google-Smtp-Source: AIpwx4/QCtfS2yKdgmkOt94Oev5fcsR2aLEbKPgkCy6RYfXxZUMmCCaNB6eiGB2Chmo9UfFQUngl3WqMMXxsdDMIDnc= X-Received: by 2002:a24:7088:: with SMTP id f130-v6mr10931990itc.39.1522874057020; Wed, 04 Apr 2018 13:34:17 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Apr 2018 22:34:16 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 4 Apr 2018 22:34:16 +0200 Message-ID: Subject: Re: Impact of hardware offloads on network stack performance Content-Type: multipart/alternative; boundary="00000000000034d9ea05690bbf5d" To: Praveen Balasubramanian To: IETF QUIC WG Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 20:34:21 -0000 --00000000000034d9ea05690bbf5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for sharing these numbers. My guess is that these offloads deal with kernel scheduling, memory cache issues, and interrupt scheduling. It probably has very little to do with crypto, TCP headers, and any other cpu sensitive processing. This is where netmap enters: you can transparently feed the data as it becomes available with very little sync work and you can also efficiently pipeline so you pass data to decryptor, then to app, with as little bus traffic as possible. No need to copy data or synchronize kernel space. For 1K packets you would use about 1000ns (3 cycles/byte) on crypto and this would happen in L1 cache. It would of course consume a core which a crypto offload would not, but that can be debated because with 18 core systems, your problem is memory and network more than CPU. My concern with PNE is for small packets and low latency where 1) an estimated 24ns for PN encryption and decryption becomes measurable if your network is fast enough. 2) any damage to the packet buffer cause all sorts of memory and cpu bus traffic issues. 1) is annoying. 2) is bad, completely avoidable but not as PR 1079 is formulated currently. 2) is also likely bad for hardware offload units as well. As to SRV-IO - I=E2=80=99m not familiar with it, but obviously there is som= e IO abstraction layer - the question is how you make it accessible to apps as opposed to device drivers that does nor work with you QUIC custom stack, and netmap is one option here. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 4 April 2018 at 22.15.52, Praveen Balasubramanian ( pravb=3D40microsoft.com@dmarc.ietf.org) wrote: Some comparative numbers from an out of box default settings Windows Server 2016 (released version) for a single connection with a microbenchmark tool: *Offloads enabled* *TCP gbps* *UDP gbps* *LSO + LRO + checksum* 24 3.6 *Checksum only* 7.6 3.6 *None* 5.6 2.3 This is for a fully bottlenecked CPU core -- *if you run lower data rates there is still a significant difference in Cycles/byte cost*. Same increased CPU cost applies for client systems going over high data rate Wifi and cellular. This is without any crypto. Once you add crypto the numbers become much worse *with crypto cost becoming dominant*. Adding another crypto step further exacerbates the problem. Hence crypto offload gains in importance followed by these batch offloads. If folks need any more numbers I=E2=80=99d be happy to provide them. Thanks --00000000000034d9ea05690bbf5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Thanks for sharing t= hese numbers.

My gues= s is that these offloads deal with kernel scheduling, memory cache issues, = and interrupt scheduling.

It probably has very little to do with crypto, TCP headers, and any ot= her cpu sensitive processing.

This is where netmap enters: you can transparently feed the data a= s it becomes available with very little sync work and you can also efficien= tly pipeline so you pass data to decryptor, then to app, with as little bus= traffic as possible. No need to copy data or synchronize kernel space.

For 1K packets you would= use about 1000ns (3 cycles/byte) on crypto and this would happen in L1 cac= he. It would of course consume a core which a crypto offload would not, but= that can be debated because with 18 core systems, your problem is memory a= nd network more than CPU.

My concern with PNE is for small packets and low latency where
1) an estimated 24ns= for PN encryption and decryption becomes measurable if your network is fas= t enough.
2) = any damage to the packet buffer cause all sorts of memory and cpu bus traff= ic issues.
1) is anno= ying. 2) is bad, completely avoidable but not as PR 1079 is formulated curr= ently.

2) is also lik= ely bad for hardware offload units as well.

As to SRV-IO - I=E2=80=99m not fa= miliar with it, but obviously there is some IO abstraction layer - the ques= tion is how you make it accessible to apps as opposed to device drivers tha= t does nor work with you QUIC custom stack, and netmap is one option here.<= div>
Kind Regards,
=
Mikkel Fahn=C3=B8= e J=C3=B8rgensen


On 4 April= 2018 at 22.15.52, Praveen Balasubramanian (pravb=3D40microsoft.com@dmarc.ietf.org) wrot= e:

Some comparative numbers from an out of box default = settings Windows Server 2016 (released version) for a single connection wit= h a microbenchmark tool:

=C2=A0

Offloads enabled

TCP gbps

UDP gbps

LSO + LRO + checksum

24

3.6

Checksum only

7.6

3.6

None

5.6

2.3

=C2=A0

This is for a fully bottlenecked CPU core -- if y= ou run lower data rates there is still a significant difference in Cycles/b= yte cost. Same increased CPU cost applies for client systems going over= high data rate Wifi and cellular.

=C2=A0

This is without any crypto. Once you add crypto the = numbers become much worse with crypto cost becoming dominant. Adding another crypto step furth= er exacerbates the problem. Hence crypto offload gains in importance follow= ed by these batch offloads.

=C2=A0

If folks need any more numbers I=E2=80=99d be happy = to provide them.

=C2=A0

Thanks

=C2=A0

--00000000000034d9ea05690bbf5d-- From nobody Wed Apr 4 14:09:56 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEAC127AD4 for ; Wed, 4 Apr 2018 14:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNwyyflET8fp for ; Wed, 4 Apr 2018 14:09:50 -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 24242126BF0 for ; Wed, 4 Apr 2018 14:09:50 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w34Kmhx3014092; Wed, 4 Apr 2018 22:09:42 +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=z4g/qu85T3HErJKGxcNs3p0GK84/nXU3kMfkHbLlmLI=; b=Oo5AFzOifihADv/sIV8huDoMAq3J7c4tklzhWoZ86+kY+ESmQ6KlzNGmfWXKUce3HGwh xoZ+DFvAS3IVo1ckVvktD1g/qgMIk/sYCFsGS3h0phC9UmtMw/DSnufaUedvEmGMSoVJ XTP8vW2RXSfzPOkpkkKSzhKjCBPRSzvDCcyx0G658Hk2lFMoy7cmxzcagdJZK863WYoE HGYSLmPDdIZo/3htd9ne+3+TaGv1k3Qwywo3MpYH+ZUdAuqO2IpfjqeQHmbYEcQScNc1 om9rqZ+M+JMro0vmU5EisvZ9BK1NWF+wq39uJStiKf0t3P2+E2z0ky9RboM6AsHkQlDO aw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2h4n5g2cx3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Apr 2018 22:09:41 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w34KkeDq011061; Wed, 4 Apr 2018 17:09:41 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2h25nvqwwj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 Apr 2018 17:09:40 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 4 Apr 2018 17:09:39 -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.1365.000; Wed, 4 Apr 2018 17:09:39 -0400 From: "Lubashev, Igor" To: Roberto Peon , Praveen Balasubramanian , =?iso-8859-1?Q?Mirja_K=FChlewind?= , Mark Nottingham CC: Lars Eggert , IETF QUIC WG Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GWvgm/QKk890OIh9EYaPY3H6PwqlkAgACTmoD//8ZYwIAATiQA///Dy6A= Date: Wed, 4 Apr 2018 21:09:39 +0000 Message-ID: <2b9b9481b97a4457a9bbdf430862e992@usma1ex-dag1mb5.msg.corp.akamai.com> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.5] Content-Type: multipart/alternative; boundary="_000_2b9b9481b97a4457a9bbdf430862e992usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804040204 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804040204 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 21:09:55 -0000 --_000_2b9b9481b97a4457a9bbdf430862e992usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable * An implementation that cared deeply about privacy would send packets = along both paths for some time. Devices would only be able to do so under certain conditions. But if the d= evice is able to transit on both path in an attempt to avoid CID linkage, i= t could use (2) "Per-CID offset" and retransmit the same packets (except fo= r padding and with randomized inter-packet intervals) on both paths. The Q= UIC peer would discard duplicates. The cost of privacy (sending duplicate packets) would then be paid only by = those who desire privacy and only for the short duration of the migration. * Igor From: Roberto Peon [mailto:fenix@fb.com] Sent: Wednesday, April 04, 2018 4:29 PM To: Lubashev, Igor ; Praveen Balasubramanian ; Mirja K=FChlewind ; Mark Not= tingham Cc: Lars Eggert ; IETF QUIC WG Subject: Re: Getting to consensus on packet number encryption PN encryption plus multiple (rotating) GUIDs specified on a per-path basis,= as discussed in Melbourne do seem able to provide substantively better pri= vacy. With such a scheme nothing appears to be shared from one 5-tuple+GUID= to another 5-tuple+GUID. An implementation that cared deeply about privacy would send packets along = both paths for some time. This doesn't seem like something we can reasonabl= e require with the protocol, but it can be allowed by the protocol. I am not particularly interested in seeing QUIC v1 become the most CPU effi= cient thing. I'd rather we release it, and continue iterating. Concentratin= g on features that prevent ossification furthers this goal and allows for a= n eventual (and possibly better) HW acceleration path later. -=3DR ________________________________ From: QUIC > on behalf = of Lubashev, Igor > Sent: Wednesday, April 4, 2018 12:55:47 PM To: Praveen Balasubramanian; Mirja K=FChlewind; Mark Nottingham Cc: Lars Eggert; IETF QUIC WG Subject: RE: Getting to consensus on packet number encryption To restate the options: (1) - Packet number encryption. (2) - Per-CID offset. (3) - Plain text PNs across connection migrations. (4) - Per-CID PN spaces. None of the alternatives mask the "connection migration" event from an on-p= ath observer. The "original" connection establishment is done via clearly = identifiable handshake packets on a 5-tuple before short-header packets sho= w up, while "connection migration" events are identifiable by the use of a = new CID with short-header packets on a new 5-tuple w/o preceding handshake = packets. As it was pointed out many times (especially by Brian), it is not that hard= to correlate cessation of packets from one 5-tuple and appearance of a new= post-"connection migration" 5-tuple, especially if destination IPs for bot= h are identical. Moreover, since devices that wish to maintain connections= during migration will likely migrate multiple connections, the on-path obs= erver will see a group of 5-tuples from the same IP cease activity, while a= similar group of post-"connection migration" 5-tuples appears from a diffe= rent IP, all with matched destination IPs. Given the above, I am left wondering if increasing the costs for content ho= sting, increasing per-packet power requirements for mobile and micro device= s, and making the Internet harder to troubleshoot and operate is worth the = mostly illusory privacy gains of (1). Patrick's "the privacy is a must hav= e" is a desire I share, but does (1) provide privacy against a sophisticate= d on-path observer? Yet, (2) seems simple enough and a good compromise. As Mike points out, it= allows an on-path observer who can link CIDs across "connection migrations= " to infer PNs. But if CIDs are already linked, there is no more privacy a= rgument to be made anyway. One thing (2) does not allow an on-path observe= r to do is to link CIDs via PN analysis. (Though it still seems like the p= rivacy gains from any of the above are mostly an illusion.) So my vote is = for (2). - Igor -----Original Message----- From: Praveen Balasubramanian [mailto:pravb=3D40microsoft.com@dmarc.ietf.or= g] Sent: Wednesday, April 04, 2018 3:15 PM To: Mirja K=FChlewind >; Mark Nottingham > Cc: Lars Eggert >; IETF QUIC WG > Subject: RE: Getting to consensus on packet number encryption I too disagree with the assessment of the situation. +1 to everything Mirja= said. >> there is no *requirement* that we produce a protocol that is able to be = accelerated by hardware. It is however a requirement for deployment that we be able to offload QUIC.= A large part of work we do in TCP is acceleration in software and hardware= ... If QUIC has to evolve from experiment to broad deployment performance i= s a key goal. This is brought up several times in TCP working group where w= e see proposals that wouldn't work with widely deployed software and hardwa= re accelerations. Whether we like it or not performance is a key requirement for QUIC on serv= ers and for datacenter scenarios. Even Ian mentioned before that he'd not w= ant to do PNE within DC and I agree. Most connections will also not be doin= g migration or using multi path so why pay the extra overhead in the common= case for no benefit? Since PNE doesn't affect the invariants (its simply an extra step post pack= etization and pre parsing), please explain why it would block progress on o= ther fronts? What is the list of things that get blocked? Please let us not rush into a design that impacts per packet processing cos= ts with no clear articulation of the problem and the benefits. >From what I can tell there is wide disagreement in the group and nothing r= esembling consensus. The fact that we have poor representation from hardwar= e developers and public cloud providers is further skewing the perception. My recommendations: 1. Leave the current draft as is. Make sure we have some provision for grea= sing the PN to prevent ossification. 2. Explore multiple PN spaces for connection migration (and eventually mult= ipath). 3. Make PNE an optional negotiated extension for implementations that want = to do connection migration in V1 with the caveat that we will revisit this = for V2 when we do multipath. 4. Solicit more feedback on the protocol from hardware vendors and public a= nd private cloud providers. I can try to loop in more folks but others shou= ld too. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mirja K=FChlewind Sent: Wednesday, April 4, 2018 3:27 AM To: Mark Nottingham > Cc: Lars Eggert >; IETF QUIC WG > Subject: Re: Getting to consensus on packet number encryption Hi Mark, without intending to state a technical opinion, I think I need to disagree = with your assessment of the situation. Please see below. > Am 04.04.2018 um 06:58 schrieb Mark Nottingham >: > > Hi everyone, > > The editors have told your chairs that this issue is starting to block pr= ogress on other aspects of QUIC. Coming to consensus on it soon (i.e., befo= re Stockholm, if possible) would be good. > > It looks like this thread has come to a natural pause. Reading through it= , I think we agree there are some unpleasant tradeoffs here, but so far we = have only one concrete proposal -- PR#1079. The other proposal is to use a random offset that can/should be changed whe= n the connection ID is changed. Which is mostly inline with what the draft = currently says. > > My AU$.05 - While we're chartered to produce a protocol that's encrypted = as much as operational concerns allow, I don't think this is what the charter say. The charter says "Providing alw= ays-secure transport, using TLS 1.3 by default." plus another paragraph tha= t talks about TLS1.3. It does not spell out the desire of some individual t= o "encrypt as much as possible". > and that privacy is a natural extension of that (especially in light of R= FC7258 and RFC6973), there is no *requirement* that we produce a protocol t= hat is able to be accelerated by hardware. Not there is no requirement that the protocol need to be accelerated by har= dware. However, not all requirement are listed in the charter. We as a grou= p have to define the requirement. However, there is of course an implicit r= equirement for all work in the IEFT that is must be deployable and serve th= e needs of those people who want to deploy it. > > That being the case, I think we need to ask ourselves if we believe that = inclusion of PR#1079 will significantly inhibit deployment of the protocol.= Based on the discussion so far, that doesn't seem to be the case, but I'd = be interested to hear what others think. Here my assessment is also different. There are multiple people that have r= aised concerns that this could hinder deployment. > > If we can get to consensus to incorporate the PR, and folks come back lat= er with a more hardware-friendly replacement that doesn't change the Invari= ants or increase linkability, I suspect the WG will be amenable to that. I don't think to just go with what we have even though there are concerns, = is the right approach and definitely not the approach that was chosen for o= ther proposals. In the sake of getting version v1 out quickly, I would thin= k that not incorporating another change that does not have consensus is the= proposer approach. Mirja > > What do folks think? > > Cheers, > > >> On 29 Mar 2018, at 11:39 am, Ian Swett > wrote: >> >> Thanks for the nice summary Jana. >> >> As much as I'd love to have easier crypto HW acceleration, I've ended up= arriving at the same conclusion. I don't want to bite off the work to do = proper multipath in QUIC v1, which I think is the only other reasonable opt= ion of those Christian outlined. >> >> If someone comes up with a way to transform packet number to make it non= -linkable, but doesn't have the downside of making hardware offload difficu= lt, then I'm open to it. But we've been talking about this for 2 months wi= thout any notable improvements over Martin's PR. >> >> Given we never talk about any issue only once in QUIC, I'm sure this wil= l come up again, but for the time being I think #1079 is the best option we= have. >> >> >> >> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar > wrote: >> A few quick thoughts as I catch up on this thread. >> >> I spent some time last week working through a design using multiple PN s= paces, and it is quite doable. I suspect we'll head towards multiple PN spa= ces as we consider multipath in the future. That said, there is complexity = (as Christian notes). This complexity may be warranted when doing multipath= in v2 or later, but I'm not convinced that this is necessary as a design p= rimitive for QUICv1. >> >> We may want to creatively use the PN bits in v2, say to encode a path ID= and a PN, for multipath. We want to retain flexibility in these bits going= into v2. We've used encryption to ensure that we don't lose flexibility el= sewhere in the header, and it follows that we should use PNE to retain flex= ibility in these bits as well. (Simplicity of design is the other value in = using PNE, since handling migration linkability is non-trivial without it.) >> >> This leaves the question of HW acceleration being at loggerheads with th= e design in PR #1079. First, I expect that the primary benefit of accelerat= ion will be in DC environments. Yes, there are some gains to be had in serv= ing the public Internet as well, but I'm unconvinced that this is the drivi= ng use case for hardware acceleration. I understand that others may disagre= e with me here. >> >> AFAIK, QUIC has not been used in DC environments yet. I expect there are= other things in the protocol that we'd want to change as we gain experienc= e deploying QUIC in DCs. Spinning up a new version to try QUIC within DCs i= s not only appropriate, I would recommend it. This allows for rapid iterati= ons internally, and the experience can drive subsequent changes to QUIC. It= 's what *I* would do if I was to deploy QUIC inside a DC. >> >> So, in short, I think we should go ahead with PR# 1079. This ensures tha= t future versions are guaranteed the flexibility to change the PN bits for = better support of HW acceleration or multipath or what-have-you. >> >> - jana >> >> On Mar 26, 2018 9:41 AM, "Christian Huitema" > wrote: >> >> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote: >>> Looking at https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__na01.= safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fen.wikipedia.= org-252Fwiki-252FAES-5Finstruction-5Fset-2523Intel-5Fand-5FAMD-5Fx86-5Farch= itecture-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C14f278ab3769469= a44f908d59a16a2d6-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C6365= 84344383959765-26sdata-3DaOHc7FZoIBCE1OlqmNpvdMM0ntLerZ3FpqESVj85zfE-253D-2= 6reserved-3D0&d=3DDwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf= 6TA&m=3Dym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=3DWkBplmuEwMxL-oezaQ4= rK1_9-0SXgkY1NJ_V3SPhYOU&e=3D it seems to imply a large range of server, de= sktop and mobile chips all have a CPU instruction set available to do AES a= cceleration and other similar operations (other instruction sets are also a= vailable). >>> >>> If we are considering the AES instructions then it looks like it is (or= at least will be in the near future) a sizeable proportion of the public i= nternet have it to be used. >>> >> >> Certainly, but that's not the current debate. PR #1079 is fully compatib= le with use of the AES instructions. The issue of the debate is that the me= chanism in PR #1079 required double buffering, first encrypt the payload, t= hen use the result of the encryption to encrypt the PN. This is not an issu= e in a software implementation that can readily access all bytes of the pac= ket from memory, but it may be an issue in some hardware implementations th= at are designed to do just one pass over the data. >> >> >> -- Christian Huitema >> >> >> > > -- > Mark Nottingham https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.mnot= .net-252F-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C14f278ab376946= 9a44f908d59a16a2d6-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636= 584344383959765-26sdata-3DRXba2TyvYz6otecEHoLCT4tZ2I7EodxDiyPxWrn-252FnAw-2= 53D-26reserved-3D0&d=3DDwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfy= oaCsf6TA&m=3Dym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=3Db_XyJvAQscNJNC= wHmgj11ep8Xbsf7PvhDvONVZe3PR0&e=3D > --_000_2b9b9481b97a4457a9bbdf430862e992usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
  • An implementation that c= ared deeply about privacy would send packets along both paths for some time= .

 

Devices would only be able to do so under certain co= nditions.  But if the device is able to transit on both path in an att= empt to avoid CID linkage, it could use (2) “Per-CID offset” an= d retransmit the same packets (except for padding and with randomized inter-packet intervals) on both paths.  The QUIC peer= would discard duplicates.

 

The cost of privacy (sending duplicate packets) woul= d then be paid only by those who desire privacy and only for the short dura= tion of the migration.

&n= bsp;

  • Igor

 

 

From: Roberto Peon [mailto:fenix@fb.com]
Sent: Wednesday, April 04, 2018 4:29 PM
To: Lubashev, Igor <ilubashe@akamai.com>; Praveen Balasubraman= ian <pravb@microsoft.com>; Mirja K=FChlewind <mirja.kuehlewind@tik= .ee.ethz.ch>; Mark Nottingham <mnot@mnot.net>
Cc: Lars Eggert <lars@eggert.org>; IETF QUIC WG <quic@ietf.= org>
Subject: Re: Getting to consensus on packet number encryption

 

PN encryption plus multiple= (rotating) GUIDs specified on a per-path basis, as discussed in Melbourne = do seem able to provide substantively better privacy. With such a scheme no= thing appears to be shared from one 5-tuple+GUID to another 5-tuple+GUID.

An implementation that care= d deeply about privacy would send packets along both paths for some time. T= his doesn't seem like something we can reasonable require with the protocol= , but it can be allowed by the protocol.

 

I am not particularly inter= ested in seeing QUIC v1 become the most CPU efficient thing. I'd rather we = release it, and continue iterating. Concentrating on features that prevent = ossification furthers this goal and allows for an eventual (and possibly better) HW acceleration path later. -=3DR

From: QUIC <q= uic-bounces@ietf.org> on behalf of Lubashev, Igor <ilubashe=3D40akamai.com@dmarc= ...ietf.org>
Sent: Wednesday, April 4, 2018 12:55:47 PM
To: Praveen Balasubramanian; Mirja K=FChlewind; Mark Nottingham
Cc: Lars Eggert; IETF QUIC WG
Subject: RE: Getting to consensus on packet number encryption=

 

To restate the option= s:

(1) - Packet number encryption.

(2) - Per-CID offset.

(3) - Plain text PNs across connection migrations.

(4) - Per-CID PN spaces.



None of the alternatives mask the “connection migration” event = from an on-path observer.  The “original” connection estab= lishment is done via clearly identifiable handshake packets on a 5-tuple be= fore short-header packets show up, while “connection migration” events are identifiable by the use of a new CID with short-header packets = on a new 5-tuple w/o preceding handshake packets.



As it was pointed out many times (especially by Brian), it is not that hard= to correlate cessation of packets from one 5-tuple and appearance of a new= post-“connection migration” 5-tuple, especially if destination= IPs for both are identical.  Moreover, since devices that wish to maintain connections during migration will likely mig= rate multiple connections, the on-path observer will see a group of 5-tuple= s from the same IP cease activity, while a similar group of post-“con= nection migration” 5-tuples appears from a different IP, all with matched destination IPs.



Given the above, I am left wondering if increasing the costs for content ho= sting, increasing per-packet power requirements for mobile and micro device= s, and making the Internet harder to troubleshoot and operate is worth the = mostly illusory privacy gains of (1).  Patrick’s “the privacy is a must have” is a d= esire I share, but does (1) provide privacy against a sophisticated on-path= observer?



Yet, (2) seems simple enough and a good compromise.  As Mike points ou= t, it allows an on-path observer who can link CIDs across “connection= migrations” to infer PNs.  But if CIDs are already linked, ther= e is no more privacy argument to be made anyway.  One thing (2) does not allow an on-path observer to do is to link CIDs via PN = analysis.  (Though it still seems like the privacy gains from any of t= he above are mostly an illusion.)  So my vote is for (2).



- Igor





-----Original Message-----

From: Praveen Balasubramanian [mailto:pravb=3D40microsoft.com@dmarc.ietf.org]

Sent: Wednesday, April 04, 2018 3:15 PM

To: Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Mark Nottingham <mnot@mnot.net>

Cc: Lars Eggert <lars@eggert.org&= gt;; IETF QUIC WG <quic@ietf.org>= ;

Subject: RE: Getting to consensus on packet number encryption



I too disagree with the assessment of the situation. +1 to everything M= irja said.



>> there is no *requirement* that we produce a protocol that is able = to be accelerated by hardware.

It is however a requirement for deployment that we be able to offload QUIC.= A large part of work we do in TCP is acceleration in software and hardware= ... If QUIC has to evolve from experiment to broad deployment performance i= s a key goal. This is brought up several times in TCP working group where we see proposals that wouldn̵= 7;t work with widely deployed software and hardware accelerations.



Whether we like it or not performance is a key requirement for QUIC on serv= ers and for datacenter scenarios. Even Ian mentioned before that he'd not w= ant to do PNE within DC and I agree. Most connections will also not be doin= g migration or using multi path so why pay the extra overhead in the common case for no benefit?



Since PNE doesn’t affect the invariants (its simply an extra step pos= t packetization and pre parsing), please explain why it would block progres= s on other fronts? What is the list of things that get blocked?



Please let us not rush into a design that impacts per packet processing cos= ts with no clear articulation of the problem and the benefits.



>From what I can tell there is wide disagreement in the group and nothin= g resembling consensus. The fact that we have poor representation from hard= ware developers and public cloud providers is further skewing the perceptio= n.



My recommendations:

1. Leave the current draft as is. Make sure we have some provision for grea= sing the PN to prevent ossification.

2. Explore multiple PN spaces for connection migration (and eventually mult= ipath).

3. Make PNE an optional negotiated extension for implementations that want = to do connection migration in V1 with the caveat that we will revisit this = for V2 when we do multipath.

4. Solicit more feedback on the protocol from hardware vendors and public a= nd private cloud providers. I can try to loop in more folks but others shou= ld too.



-----Original Message-----

From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Mirja K=FChlewind

Sent: Wednesday, April 4, 2018 3:27 AM

To: Mark Nottingham <mnot@mnot.net&= gt;

Cc: Lars Eggert <lars@eggert.org&= gt;; IETF QUIC WG <quic@ietf.org>= ;

Subject: Re: Getting to consensus on packet number encryption



Hi Mark,



without intending to state a technical opinion, I think I need to disagree = with your assessment of the situation. Please see below.



> Am 04.04.2018 um 06:58 schrieb Mark Nottingham <mnot@mnot.net>:

>

> Hi everyone,

>

> The editors have told your chairs that this issue is starting to block= progress on other aspects of QUIC. Coming to consensus on it soon (i.e., b= efore Stockholm, if possible) would be good.

>

> It looks like this thread has come to a natural pause. Reading through= it, I think we agree there are some unpleasant tradeoffs here, but so far = we have only one concrete proposal -- PR#1079.



The other proposal is to use a random offset that can/should be changed whe= n the connection ID is changed. Which is mostly inline with what the draft = currently says.

>

> My AU$.05 - While we're chartered to produce a protocol that's encrypt= ed as much as operational concerns allow,



I don’t think this is what the charter say. The charter says "Pr= oviding always-secure transport, using TLS 1.3 by default.“ plus anot= her paragraph that talks about TLS1.3. It does not spell out the desire of = some individual to „encrypt as much as possible“.



> and that privacy is a natural extension of that (especially in light o= f RFC7258 and RFC6973), there is no *requirement* that we produce a protoco= l that is able to be accelerated by hardware.



Not there is no requirement that the protocol need to be accelerated by har= dware. However, not all requirement are listed in the charter. We as a grou= p have to define the requirement. However, there is of course an implicit r= equirement for all work in the IEFT that is must be deployable and serve the needs of those people who want to= deploy it.



>

> That being the case, I think we need to ask ourselves if we believe th= at inclusion of PR#1079 will significantly inhibit deployment of the protoc= ol. Based on the discussion so far, that doesn't seem to be the case, but I= 'd be interested to hear what others think.



Here my assessment is also different. There are multiple people that have r= aised concerns that this could hinder deployment.

>

> If we can get to consensus to incorporate the PR, and folks come back = later with a more hardware-friendly replacement that doesn't change the Inv= ariants or increase linkability, I suspect the WG will be amenable to that.=



I don’t think to just go with what we have even though there are conc= erns, is the right approach and definitely not the approach that was chosen= for other proposals. In the sake of getting version v1 out quickly, I woul= d think that not incorporating another change that does not have consensus is the proposer approach.



Mirja







>

> What do folks think?

>

> Cheers,

>

>

>> On 29 Mar 2018, at 11:39 am, Ian Swett <ianswett=3D40google.com@dmarc.ietf.org> wrote:

>>

>> Thanks for the nice summary Jana.

>>

>> As much as I'd love to have easier crypto HW acceleration, I've en= ded up arriving at the same conclusion.  I don't want to bite off the = work to do proper multipath in QUIC v1, which I think is the only other rea= sonable option of those Christian outlined.

>>

>> If someone comes up with a way to transform packet number to make = it non-linkable, but doesn't have the downside of making hardware offload d= ifficult, then I'm open to it.  But we've been talking about this for = 2 months without any notable improvements over Martin's PR.

>>

>> Given we never talk about any issue only once in QUIC, I'm sure th= is will come up again, but for the time being I think #1079 is the best opt= ion we have.

>>

>>

>>

>> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar <jri.ietf@gmail.com> wrote:

>> A few quick thoughts as I catch up on this thread.

>>

>> I spent some time last week working through a design using multipl= e PN spaces, and it is quite doable. I suspect we'll head towards multiple = PN spaces as we consider multipath in the future. That said, there is compl= exity (as Christian notes). This complexity may be warranted when doing multipath in v2 or later, but I'm not convince= d that this is necessary as a design primitive for QUICv1.

>>

>> We may want to creatively use the PN bits in v2, say to encode a p= ath ID and a PN, for multipath. We want to retain flexibility in these bits= going into v2. We've used encryption to ensure that we don't lose flexibil= ity elsewhere in the header, and it follows that we should use PNE to retain flexibility in these bits as well. (Simpl= icity of design is the other value in using PNE, since handling migration l= inkability is non-trivial without it.)

>>

>> This leaves the question of HW acceleration being at loggerheads w= ith the design in PR #1079. First, I expect that the primary benefit of acc= eleration will be in DC environments. Yes, there are some gains to be had i= n serving the public Internet as well, but I'm unconvinced that this is the driving use case for hardware acceler= ation. I understand that others may disagree with me here.

>>

>> AFAIK, QUIC has not been used in DC environments yet. I expect the= re are other things in the protocol that we'd want to change as we gain exp= erience deploying QUIC in DCs. Spinning up a new version to try QUIC within= DCs is not only appropriate, I would recommend it. This allows for rapid iterations internally, and the experie= nce can drive subsequent changes to QUIC. It's what *I* would do if I was t= o deploy QUIC inside a DC.

>>

>> So, in short, I think we should go ahead with PR# 1079. This ensur= es that future versions are guaranteed the flexibility to change the PN bit= s for better support of HW acceleration or multipath or what-have-you.

>>

>> - jana

>>

>> On Mar 26, 2018 9:41 AM, "Christian Huitema" <huitema@huitema.net> wrote:

>>

>> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wro= te:

>>> Looking at https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__na01.safelinks.prote= ction.outlook.com_-3Furl-3Dhttps-253A-252F-252Fen.wikipedia.org-252Fwiki-25= 2FAES-5Finstruction-5Fset-2523Intel-5Fand-5FAMD-5Fx86-5Farchitecture-26data= -3D02-257C01-257Cpravb-2540microsoft.com-257C14f278ab3769469a44f908d59a16a2= d6-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636584344383959765-= 26sdata-3DaOHc7FZoIBCE1OlqmNpvdMM0ntLerZ3FpqESVj85zfE-253D-26reserved-3D0&a= mp;d=3DDwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf6TA= &m=3Dym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=3DWkBplmuEwMxL-o= ezaQ4rK1_9-0SXgkY1NJ_V3SPhYOU&e=3D it seems to imply a large range of server, desktop and mobile chips all ha= ve a CPU instruction set available to do AES acceleration and other similar= operations (other instruction sets are also available).

>>>

>>> If we are considering the AES instructions then it looks like = it is (or at least will be in the near future) a sizeable proportion of the= public internet have it to be used.

>>>

>>

>> Certainly, but that's not the current debate. PR #1079 is fully co= mpatible with use of the AES instructions. The issue of the debate is that = the mechanism in PR #1079 required double buffering, first encrypt the payl= oad, then use the result of the encryption to encrypt the PN. This is not an issue in a software implementation that = can readily access all bytes of the packet from memory, but it may be an is= sue in some hardware implementations that are designed to do just one pass = over the data.

>>

>>

>> -- Christian Huitema

>>

>>

>>

>

> --

> Mark Nottingham   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__na01.safelinks.prote= ction.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.mnot.net-252F-26data-3D0= 2-257C01-257Cpravb-2540microsoft.com-257C14f278ab3769469a44f908d59a16a2d6-2= 57C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636584344383959765-26sd= ata-3DRXba2TyvYz6otecEHoLCT4tZ2I7EodxDiyPxWrn-252FnAw-253D-26reserved-3D0&a= mp;d=3DDwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf6TA= &m=3Dym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=3Db_XyJvAQscNJNC= wHmgj11ep8Xbsf7PvhDvONVZe3PR0&e=3D

>


--_000_2b9b9481b97a4457a9bbdf430862e992usma1exdag1mb5msgcorpak_-- From nobody Wed Apr 4 14:28:30 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84EE126BF0 for ; Wed, 4 Apr 2018 14:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=mnot.net header.b=BWS9X6UR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YX5v4WFJ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A7tpYdwBMnH for ; Wed, 4 Apr 2018 14:28:25 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5377A120454 for ; Wed, 4 Apr 2018 14:28:25 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 50EED21EBD; Wed, 4 Apr 2018 17:28:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 04 Apr 2018 17:28:14 -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; s=fm2; bh=UDtZGYb+XbK8ZVOjT46OBdwyKsiTg wX+phGsYkK6yhA=; b=BWS9X6URGlMy+QQemQE0fO18zVv56OraOytQX8gaE26Mk KNFs7f4Nq4TdFp9jnFkL/dfOQd+6WaSz0aC/6AL7TpsCS+fXk8gedoHVAzrtiuej sSLEV6S1u4f4jzuHT+mYwNP6ghgfCgefyrciUMXYM5xZ5oH232dVyAEJ2McvLwG1 IpSd3l7CRt5lgQJZ92U2fUSsjSKzuzuQCwE8MUTuI8wy3mKe/sTvw6f9dRDkWqz+ 3pKLQA58+x3NSrYzFchn5wfr6OpJk0NdAd+66VVpb0qmFXT8YZQv7NjHFp2kdus0 TkN+22t2kCxUUdY9Vyt8djcWNVQJiMOwumQA/rpSA== 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; s=fm2; bh=UDtZGY b+XbK8ZVOjT46OBdwyKsiTgwX+phGsYkK6yhA=; b=YX5v4WFJzU9+rXUv4l3SLD r/ReHg1rRQAu1BPU4GvvJrQdVbhY2wUDKVrbbDOKBh/oxujGon6hIyWD/N0hxiL9 wRK9sbab/65+2I/XqWrqwDB78jmbmBzvfprDctEJpSTo3jQjGFfFHxuppKHsLT7j 3OKUdZJH59YCe8ns+AtOacWxdHp8YBzSmNih1uej5PJHzCy7e1WtyNpJ09MxJ3Sf 4MvL3l3f38hiKX1OZnmP96VPWBAi45gmtUralrHjqGa2toTgdqjUA2HgjukXvrJb DKhcThIAN+kcOu3uIoEYKER4ZiZhVycavAp73X1O6584zwLwirzZ5fzYpkIu5BXA == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id A41F710253; Wed, 4 Apr 2018 17:28:12 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Getting to consensus on packet number encryption From: Mark Nottingham In-Reply-To: <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> Date: Thu, 5 Apr 2018 07:28:10 +1000 Cc: Lars Eggert , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 21:28:29 -0000 Mirja, On 4 Apr 2018, at 8:27 pm, Mirja K=C3=BChlewind = wrote: >=20 > Hi Mark, >=20 > without intending to state a technical opinion, I think I need to = disagree with your assessment of the situation. Please see below. >=20 >> Am 04.04.2018 um 06:58 schrieb Mark Nottingham : >>=20 >> Hi everyone, >>=20 >> The editors have told your chairs that this issue is starting to = block progress on other aspects of QUIC. Coming to consensus on it soon = (i.e., before Stockholm, if possible) would be good. >>=20 >> It looks like this thread has come to a natural pause. Reading = through it, I think we agree there are some unpleasant tradeoffs here, = but so far we have only one concrete proposal -- PR#1079. >=20 > The other proposal is to use a random offset that can/should be = changed when the connection ID is changed. Which is mostly inline with = what the draft currently says. As I understand it, the status quo has caused a significant amount of = pain, complexity and potential bugs. PN encryption was proposed by = Kazuho in Melbourne as a way to work around that.=20 We can, of course, decide that the status quo is the right approach. = However, my current reading of the WG is that it isn't acceptable. >> My AU$.05 - While we're chartered to produce a protocol that's = encrypted as much as operational concerns allow, >=20 > I don=E2=80=99t think this is what the charter say. The charter says = "Providing always-secure transport, using TLS 1.3 by default.=E2=80=9C = plus another paragraph that talks about TLS1.3. It does not spell out = the desire of some individual to =E2=80=9Eencrypt as much as = possible=E2=80=9C.=20 I think that depends on how you read "always-secure." The charter also = says we will provide "confidentiality and integrity protection of both = application data and QUIC headers." >> and that privacy is a natural extension of that (especially in light = of RFC7258 and RFC6973), there is no *requirement* that we produce a = protocol that is able to be accelerated by hardware. >=20 > Not there is no requirement that the protocol need to be accelerated = by hardware. However, not all requirement are listed in the charter. We = as a group have to define the requirement. However, there is of course = an implicit requirement for all work in the IEFT that is must be = deployable and serve the needs of those people who want to deploy it. Yes - a discussion that I'm trying to draw out. Thanks. >> That being the case, I think we need to ask ourselves if we believe = that inclusion of PR#1079 will significantly inhibit deployment of the = protocol. Based on the discussion so far, that doesn't seem to be the = case, but I'd be interested to hear what others think. >=20 > Here my assessment is also different. There are multiple people that = have raised concerns that this could hinder deployment. As you know, we don't assess consensus just by the number of people that = have raised concerns, but also the technical merit of the arguments. So = far, the arguments have been all over the map, and I want them to = converge.=20 The data that's been provided has been very helpful, but we need to = evaluate that in the context of how QUICv1 will actually be deployed and = used -- something which a few threads have touched upon. Overall, I do not think it is a goal of QUIC to be deployable on any = system for any purpose; if we try to design it for all purposes, we're = going to fail. The question, then, is how much deployment / = implementation / adoption we need to make it succeed -- and to design = for that. >> If we can get to consensus to incorporate the PR, and folks come back = later with a more hardware-friendly replacement that doesn't change the = Invariants or increase linkability, I suspect the WG will be amenable to = that. >=20 > I don=E2=80=99t think to just go with what we have even though there = are concerns, is the right approach and definitely not the approach that = was chosen for other proposals. In the sake of getting version v1 out = quickly, I would think that not incorporating another change that does = not have consensus is the proposer approach. I wasn't proposing that we incorporate a change without consensus -- = please re-read my statement. You may disagree with how the chairs = eventually call consensus on this issue, and there are mechanisms for = you to appeal (or even DISCUSS) that, but it's premature to start that = now. That said -- One way to prove that PNE hurts deployability is to try it; = implementers have a very strong incentive to make sure their code can be = deployed, so if those who have concerns are correct, it's probably the = easiest way for them to be proven right. Thanks, > Mirja >=20 >=20 >=20 >>=20 >> What do folks think? >>=20 >> Cheers, >>=20 >>=20 >>> On 29 Mar 2018, at 11:39 am, Ian Swett = wrote: >>>=20 >>> Thanks for the nice summary Jana. >>>=20 >>> As much as I'd love to have easier crypto HW acceleration, I've = ended up arriving at the same conclusion. I don't want to bite off the = work to do proper multipath in QUIC v1, which I think is the only other = reasonable option of those Christian outlined. >>>=20 >>> If someone comes up with a way to transform packet number to make it = non-linkable, but doesn't have the downside of making hardware offload = difficult, then I'm open to it. But we've been talking about this for 2 = months without any notable improvements over Martin's PR. >>>=20 >>> Given we never talk about any issue only once in QUIC, I'm sure this = will come up again, but for the time being I think #1079 is the best = option we have. >>>=20 >>>=20 >>>=20 >>> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar = wrote: >>> A few quick thoughts as I catch up on this thread. >>>=20 >>> I spent some time last week working through a design using multiple = PN spaces, and it is quite doable. I suspect we'll head towards multiple = PN spaces as we consider multipath in the future. That said, there is = complexity (as Christian notes). This complexity may be warranted when = doing multipath in v2 or later, but I'm not convinced that this is = necessary as a design primitive for QUICv1.=20 >>>=20 >>> We may want to creatively use the PN bits in v2, say to encode a = path ID and a PN, for multipath. We want to retain flexibility in these = bits going into v2. We've used encryption to ensure that we don't lose = flexibility elsewhere in the header, and it follows that we should use = PNE to retain flexibility in these bits as well. (Simplicity of design = is the other value in using PNE, since handling migration linkability is = non-trivial without it.) >>>=20 >>> This leaves the question of HW acceleration being at loggerheads = with the design in PR #1079. First, I expect that the primary benefit of = acceleration will be in DC environments. Yes, there are some gains to be = had in serving the public Internet as well, but I'm unconvinced that = this is the driving use case for hardware acceleration. I understand = that others may disagree with me here. >>>=20 >>> AFAIK, QUIC has not been used in DC environments yet. I expect there = are other things in the protocol that we'd want to change as we gain = experience deploying QUIC in DCs. Spinning up a new version to try QUIC = within DCs is not only appropriate, I would recommend it. This allows = for rapid iterations internally, and the experience can drive subsequent = changes to QUIC. It's what *I* would do if I was to deploy QUIC inside a = DC. >>>=20 >>> So, in short, I think we should go ahead with PR# 1079. This ensures = that future versions are guaranteed the flexibility to change the PN = bits for better support of HW acceleration or multipath or = what-have-you. >>>=20 >>> - jana >>>=20 >>> On Mar 26, 2018 9:41 AM, "Christian Huitema" = wrote: >>>=20 >>> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) = wrote: >>>> Looking at = https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_archit= ecture it seems to imply a large range of server, desktop and mobile = chips all have a CPU instruction set available to do AES acceleration = and other similar operations (other instruction sets are also = available). >>>>=20 >>>> If we are considering the AES instructions then it looks like it is = (or at least will be in the near future) a sizeable proportion of the = public internet have it to be used. >>>>=20 >>>=20 >>> Certainly, but that's not the current debate. PR #1079 is fully = compatible with use of the AES instructions. The issue of the debate is = that the mechanism in PR #1079 required double buffering, first encrypt = the payload, then use the result of the encryption to encrypt the PN. = This is not an issue in a software implementation that can readily = access all bytes of the packet from memory, but it may be an issue in = some hardware implementations that are designed to do just one pass over = the data. >>>=20 >>>=20 >>> -- Christian Huitema >>>=20 >>>=20 >>>=20 >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Apr 4 14:44:05 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DC1120454 for ; Wed, 4 Apr 2018 14:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwAW1UYOvtMT for ; Wed, 4 Apr 2018 14:43:59 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BA5126BF0 for ; Wed, 4 Apr 2018 14:43:58 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 71-v6so630160ith.2 for ; Wed, 04 Apr 2018 14:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VnHa445pETr8gqWDyWFjBOOClfz6TPS8gkp1J98vb7U=; b=GYbquvgTuwrMTU6F3LxTNh4yu7nRDbFa7IbWUhH9J+88gYt/BdCE3uQSqysESPvLXw 8iCHexp0ghlxfpBA9WKpavH5RKaGkor9xD3wtMaHopEjFk78ZhmbiTlNPI4d0dkaUoEf CWm5dvUEL3YfKFZaArFNI+Cx97Y6RjDmVSb8VcXdL3MGxVlA45loBUAMMCrrNjZ4Adl6 4ZKvM0nEDetST5fvAhdl+BqQG2uHuyYff9dKzNnXhrWs/dPYZmDmTSvfj1rEKrDJ9Wf1 9vtfFKp5ARr1VxBB6/9QuSjeBdcMCYsZWZgesr0RNRPO5hEcNMJlX8xOjTJf1JrWPCTc yYNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VnHa445pETr8gqWDyWFjBOOClfz6TPS8gkp1J98vb7U=; b=J0o9oFxBdg4M/kvNukHGrM/tdtNf1WuKegol7OQ8vOEXpJpdYgJpaj7efdeF/4S7J4 6bCW7RLZlbxErgji/ROd7Y+/2cDyX6Anu6weTzfzrD4IjBR55pCaLy9A/iuBc33hdc3p bIshN4Ph1kEWfz1exwsPzy0ux5dWYywfIUvhbJ/OAXqcTtDg2lJoFvGwMr1dmw5N5dMw uX3KznfJ9de28FV+yGY0l17SoMIldWh3alcty+Bsm7MaGAwkGuv3lF/ySK+shVgXkD8Q Y89e5ATB5AXkRn0OzwVIBQYgaDFejj+y0+e6Xub3DUy3liIGt7b6rUKeApIRl8ybInDf XszA== X-Gm-Message-State: ALQs6tBZCW21b42eBOl8tqGSUfrsbxiUNZcd0dmKpLLzCex3xtHnN5v4 GDGEfhCWJ8cqgfDIm9pYXUt2vrWsdGXX3622vhpeL8Zx X-Google-Smtp-Source: AIpwx4/flVqsupdsi3uheyYLs2m7diKNpE8up16nvO4/sfxtwGKvPGblqLiO/oH67KHAxQGC3S3057RmdnbS8F/Nlgo= X-Received: by 2002:a24:45a2:: with SMTP id c34-v6mr11888662itd.31.1522878237866; Wed, 04 Apr 2018 14:43:57 -0700 (PDT) MIME-Version: 1.0 References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> In-Reply-To: From: Ian Swett Date: Wed, 04 Apr 2018 21:43:46 +0000 Message-ID: Subject: Re: Getting to consensus on packet number encryption To: Mark Nottingham Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Lars Eggert , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000067fef705690cb888" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 21:44:03 -0000 --00000000000067fef705690cb888 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As expressed previously, I tend to think PN encryption is the most pragmatic way forward at the moment. However, is anyone who would prefer a different solution(ie: packet number jumps or separate spaces) willing to send out a PR they think solves the link-ability issue PN encryption solves? My mental model is there are a fair number of thorny edge cases, but maybe if I saw them in a PR, it wouldn't be as scary as I think? On Wed, Apr 4, 2018 at 5:28 PM Mark Nottingham wrote: > Mirja, > > On 4 Apr 2018, at 8:27 pm, Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> wrote: > > > > Hi Mark, > > > > without intending to state a technical opinion, I think I need to > disagree with your assessment of the situation. Please see below. > > > >> Am 04.04.2018 um 06:58 schrieb Mark Nottingham : > >> > >> Hi everyone, > >> > >> The editors have told your chairs that this issue is starting to block > progress on other aspects of QUIC. Coming to consensus on it soon (i.e., > before Stockholm, if possible) would be good. > >> > >> It looks like this thread has come to a natural pause. Reading through > it, I think we agree there are some unpleasant tradeoffs here, but so far > we have only one concrete proposal -- PR#1079. > > > > The other proposal is to use a random offset that can/should be changed > when the connection ID is changed. Which is mostly inline with what the > draft currently says. > > As I understand it, the status quo has caused a significant amount of > pain, complexity and potential bugs. PN encryption was proposed by Kazuho > in Melbourne as a way to work around that. > > We can, of course, decide that the status quo is the right approach. > However, my current reading of the WG is that it isn't acceptable. > > > >> My AU$.05 - While we're chartered to produce a protocol that's > encrypted as much as operational concerns allow, > > > > I don=E2=80=99t think this is what the charter say. The charter says "P= roviding > always-secure transport, using TLS 1.3 by default.=E2=80=9C plus another = paragraph > that talks about TLS1.3. It does not spell out the desire of some > individual to =E2=80=9Eencrypt as much as possible=E2=80=9C. > > I think that depends on how you read "always-secure." The charter also > says we will provide "confidentiality and integrity protection of both > application data and QUIC headers." > > > >> and that privacy is a natural extension of that (especially in light o= f > RFC7258 and RFC6973), there is no *requirement* that we produce a protoco= l > that is able to be accelerated by hardware. > > > > Not there is no requirement that the protocol need to be accelerated by > hardware. However, not all requirement are listed in the charter. We as a > group have to define the requirement. However, there is of course an > implicit requirement for all work in the IEFT that is must be deployable > and serve the needs of those people who want to deploy it. > > Yes - a discussion that I'm trying to draw out. Thanks. > > > >> That being the case, I think we need to ask ourselves if we believe > that inclusion of PR#1079 will significantly inhibit deployment of the > protocol. Based on the discussion so far, that doesn't seem to be the cas= e, > but I'd be interested to hear what others think. > > > > Here my assessment is also different. There are multiple people that > have raised concerns that this could hinder deployment. > > As you know, we don't assess consensus just by the number of people that > have raised concerns, but also the technical merit of the arguments. So > far, the arguments have been all over the map, and I want them to converg= e. > > The data that's been provided has been very helpful, but we need to > evaluate that in the context of how QUICv1 will actually be deployed and > used -- something which a few threads have touched upon. > > Overall, I do not think it is a goal of QUIC to be deployable on any > system for any purpose; if we try to design it for all purposes, we're > going to fail. The question, then, is how much deployment / implementatio= n > / adoption we need to make it succeed -- and to design for that. > > > >> If we can get to consensus to incorporate the PR, and folks come back > later with a more hardware-friendly replacement that doesn't change the > Invariants or increase linkability, I suspect the WG will be amenable to > that. > > > > I don=E2=80=99t think to just go with what we have even though there ar= e > concerns, is the right approach and definitely not the approach that was > chosen for other proposals. In the sake of getting version v1 out quickly= , > I would think that not incorporating another change that does not have > consensus is the proposer approach. > > I wasn't proposing that we incorporate a change without consensus -- > please re-read my statement. You may disagree with how the chairs > eventually call consensus on this issue, and there are mechanisms for you > to appeal (or even DISCUSS) that, but it's premature to start that now. > > That said -- One way to prove that PNE hurts deployability is to try it; > implementers have a very strong incentive to make sure their code can be > deployed, so if those who have concerns are correct, it's probably the > easiest way for them to be proven right. > > Thanks, > > > > Mirja > > > > > > > >> > >> What do folks think? > >> > >> Cheers, > >> > >> > >>> On 29 Mar 2018, at 11:39 am, Ian Swett 40google.com@dmarc.ietf.org> wrote: > >>> > >>> Thanks for the nice summary Jana. > >>> > >>> As much as I'd love to have easier crypto HW acceleration, I've ended > up arriving at the same conclusion. I don't want to bite off the work to > do proper multipath in QUIC v1, which I think is the only other reasonabl= e > option of those Christian outlined. > >>> > >>> If someone comes up with a way to transform packet number to make it > non-linkable, but doesn't have the downside of making hardware offload > difficult, then I'm open to it. But we've been talking about this for 2 > months without any notable improvements over Martin's PR. > >>> > >>> Given we never talk about any issue only once in QUIC, I'm sure this > will come up again, but for the time being I think #1079 is the best opti= on > we have. > >>> > >>> > >>> > >>> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar > wrote: > >>> A few quick thoughts as I catch up on this thread. > >>> > >>> I spent some time last week working through a design using multiple P= N > spaces, and it is quite doable. I suspect we'll head towards multiple PN > spaces as we consider multipath in the future. That said, there is > complexity (as Christian notes). This complexity may be warranted when > doing multipath in v2 or later, but I'm not convinced that this is > necessary as a design primitive for QUICv1. > >>> > >>> We may want to creatively use the PN bits in v2, say to encode a path > ID and a PN, for multipath. We want to retain flexibility in these bits > going into v2. We've used encryption to ensure that we don't lose > flexibility elsewhere in the header, and it follows that we should use PN= E > to retain flexibility in these bits as well. (Simplicity of design is the > other value in using PNE, since handling migration linkability is > non-trivial without it.) > >>> > >>> This leaves the question of HW acceleration being at loggerheads with > the design in PR #1079. First, I expect that the primary benefit of > acceleration will be in DC environments. Yes, there are some gains to be > had in serving the public Internet as well, but I'm unconvinced that this > is the driving use case for hardware acceleration. I understand that othe= rs > may disagree with me here. > >>> > >>> AFAIK, QUIC has not been used in DC environments yet. I expect there > are other things in the protocol that we'd want to change as we gain > experience deploying QUIC in DCs. Spinning up a new version to try QUIC > within DCs is not only appropriate, I would recommend it. This allows for > rapid iterations internally, and the experience can drive subsequent > changes to QUIC. It's what *I* would do if I was to deploy QUIC inside a = DC. > >>> > >>> So, in short, I think we should go ahead with PR# 1079. This ensures > that future versions are guaranteed the flexibility to change the PN bits > for better support of HW acceleration or multipath or what-have-you. > >>> > >>> - jana > >>> > >>> On Mar 26, 2018 9:41 AM, "Christian Huitema" > wrote: > >>> > >>> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote: > >>>> Looking at > https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_archi= tecture > it seems to imply a large range of server, desktop and mobile chips all > have a CPU instruction set available to do AES acceleration and other > similar operations (other instruction sets are also available). > >>>> > >>>> If we are considering the AES instructions then it looks like it is > (or at least will be in the near future) a sizeable proportion of the > public internet have it to be used. > >>>> > >>> > >>> Certainly, but that's not the current debate. PR #1079 is fully > compatible with use of the AES instructions. The issue of the debate is > that the mechanism in PR #1079 required double buffering, first encrypt t= he > payload, then use the result of the encryption to encrypt the PN. This is > not an issue in a software implementation that can readily access all byt= es > of the packet from memory, but it may be an issue in some hardware > implementations that are designed to do just one pass over the data. > >>> > >>> > >>> -- Christian Huitema > >>> > >>> > >>> > >> > >> -- > >> Mark Nottingham https://www.mnot.net/ > >> > > > > -- > Mark Nottingham https://www.mnot.net/ > > --00000000000067fef705690cb888 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As expressed previously, I tend to think PN encryption is = the most pragmatic way forward at the moment.

However, i= s anyone who would prefer a different solution(ie: packet number jumps or s= eparate spaces) willing to send out a PR they think solves the link-ability= issue PN encryption solves?

My mental model is th= ere are a fair number of thorny edge cases, but maybe if I saw them in a PR= , it wouldn't be as scary as I think?

On Wed, Apr 4, 2018 at 5:28 PM Mark Nottingham &l= t;mnot@mnot.net> wrote:
Mirja,

On 4 Apr 2018, at 8:27 pm, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.= ch> wrote:
>
> Hi Mark,
>
> without intending to state a technical opinion, I think I need to disa= gree with your assessment of the situation. Please see below.
>
>> Am 04.04.2018 um 06:58 schrieb Mark Nottingham <mnot@mnot.net>:
>>
>> Hi everyone,
>>
>> The editors have told your chairs that this issue is starting to b= lock progress on other aspects of QUIC. Coming to consensus on it soon (i.e= ., before Stockholm, if possible) would be good.
>>
>> It looks like this thread has come to a natural pause. Reading thr= ough it, I think we agree there are some unpleasant tradeoffs here, but so = far we have only one concrete proposal -- PR#1079.
>
> The other proposal is to use a random offset that can/should be change= d when the connection ID is changed. Which is mostly inline with what the d= raft currently says.

As I understand it, the status quo has caused a significant amount of pain,= complexity and potential bugs. PN encryption was proposed by Kazuho in Mel= bourne as a way to work around that.

We can, of course, decide that the status quo is the right approach. Howeve= r, my current reading of the WG is that it isn't acceptable.


>> My AU$.05 - While we're chartered to produce a protocol that&#= 39;s encrypted as much as operational concerns allow,
>
> I don=E2=80=99t think this is what the charter say. The charter says &= quot;Providing always-secure transport, using TLS 1.3 by default.=E2=80=9C = plus another paragraph that talks about TLS1.3. It does not spell out the d= esire of some individual to =E2=80=9Eencrypt as much as possible=E2=80=9C.<= br>
I think that depends on how you read "always-secure." The charter= also says we will provide "confidentiality and integrity protection o= f both application data and QUIC headers."


>> and that privacy is a natural extension of that (especially in lig= ht of RFC7258 and RFC6973), there is no *requirement* that we produce a pro= tocol that is able to be accelerated by hardware.
>
> Not there is no requirement that the protocol need to be accelerated b= y hardware. However, not all requirement are listed in the charter. We as a= group have to define the requirement. However, there is of course an impli= cit requirement for all work in the IEFT that is must be deployable and ser= ve the needs of those people who want to deploy it.

Yes - a discussion that I'm trying to draw out. Thanks.


>> That being the case, I think we need to ask ourselves if we believ= e that inclusion of PR#1079 will significantly inhibit deployment of the pr= otocol. Based on the discussion so far, that doesn't seem to be the cas= e, but I'd be interested to hear what others think.
>
> Here my assessment is also different. There are multiple people that h= ave raised concerns that this could hinder deployment.

As you know, we don't assess consensus just by the number of people tha= t have raised concerns, but also the technical merit of the arguments. So f= ar, the arguments have been all over the map, and I want them to converge.<= br>
The data that's been provided has been very helpful, but we need to eva= luate that in the context of how QUICv1 will actually be deployed and used = -- something which a few threads have touched upon.

Overall, I do not think it is a goal of QUIC to be deployable on any system= for any purpose; if we try to design it for all purposes, we're going = to fail. The question, then, is how much deployment / implementation / adop= tion we need to make it succeed -- and to design for that.


>> If we can get to consensus to incorporate the PR, and folks come b= ack later with a more hardware-friendly replacement that doesn't change= the Invariants or increase linkability, I suspect the WG will be amenable = to that.
>
> I don=E2=80=99t think to just go with what we have even though there a= re concerns, is the right approach and definitely not the approach that was= chosen for other proposals. In the sake of getting version v1 out quickly,= I would think that not incorporating another change that does not have con= sensus is the proposer approach.

I wasn't proposing that we incorporate a change without consensus -- pl= ease re-read my statement. You may disagree with how the chairs eventually = call consensus on this issue, and there are mechanisms for you to appeal (o= r even DISCUSS) that, but it's premature to start that now.

That said -- One way to prove that PNE hurts deployability is to try it; im= plementers have a very strong incentive to make sure their code can be depl= oyed, so if those who have concerns are correct, it's probably the easi= est way for them to be proven right.

Thanks,


> Mirja
>
>
>
>>
>> What do folks think?
>>
>> Cheers,
>>
>>
>>> On 29 Mar 2018, at 11:39 am, Ian Swett <ianswett=3D40google.com@dmar= c.ietf.org> wrote:
>>>
>>> Thanks for the nice summary Jana.
>>>
>>> As much as I'd love to have easier crypto HW acceleration,= I've ended up arriving at the same conclusion.=C2=A0 I don't want = to bite off the work to do proper multipath in QUIC v1, which I think is th= e only other reasonable option of those Christian outlined.
>>>
>>> If someone comes up with a way to transform packet number to m= ake it non-linkable, but doesn't have the downside of making hardware o= ffload difficult, then I'm open to it.=C2=A0 But we've been talking= about this for 2 months without any notable improvements over Martin's= PR.
>>>
>>> Given we never talk about any issue only once in QUIC, I'm= sure this will come up again, but for the time being I think #1079 is the = best option we have.
>>>
>>>
>>>
>>> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar <jri.ietf@gmail.com> wrote= :
>>> A few quick thoughts as I catch up on this thread.
>>>
>>> I spent some time last week working through a design using mul= tiple PN spaces, and it is quite doable. I suspect we'll head towards m= ultiple PN spaces as we consider multipath in the future. That said, there = is complexity (as Christian notes). This complexity may be warranted when d= oing multipath in v2 or later, but I'm not convinced that this is neces= sary as a design primitive for QUICv1.
>>>
>>> We may want to creatively use the PN bits in v2, say to encode= a path ID and a PN, for multipath. We want to retain flexibility in these = bits going into v2. We've used encryption to ensure that we don't l= ose flexibility elsewhere in the header, and it follows that we should use = PNE to retain flexibility in these bits as well. (Simplicity of design is t= he other value in using PNE, since handling migration linkability is non-tr= ivial without it.)
>>>
>>> This leaves the question of HW acceleration being at loggerhea= ds with the design in PR #1079. First, I expect that the primary benefit of= acceleration will be in DC environments. Yes, there are some gains to be h= ad in serving the public Internet as well, but I'm unconvinced that thi= s is the driving use case for hardware acceleration. I understand that othe= rs may disagree with me here.
>>>
>>> AFAIK, QUIC has not been used in DC environments yet. I expect= there are other things in the protocol that we'd want to change as we = gain experience deploying QUIC in DCs. Spinning up a new version to try QUI= C within DCs is not only appropriate, I would recommend it. This allows for= rapid iterations internally, and the experience can drive subsequent chang= es to QUIC. It's what *I* would do if I was to deploy QUIC inside a DC.=
>>>
>>> So, in short, I think we should go ahead with PR# 1079. This e= nsures that future versions are guaranteed the flexibility to change the PN= bits for better support of HW acceleration or multipath or what-have-you.<= br> >>>
>>> - jana
>>>
>>> On Mar 26, 2018 9:41 AM, "Christian Huitema" <huitema@huitema.net> wrote:
>>>
>>> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge)= wrote:
>>>> Looking at https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86= _architecture it seems to imply a large range of server, desktop and mo= bile chips all have a CPU instruction set available to do AES acceleration = and other similar operations (other instruction sets are also available). >>>>
>>>> If we are considering the AES instructions then it looks l= ike it is (or at least will be in the near future) a sizeable proportion of= the public internet have it to be used.
>>>>
>>>
>>> Certainly, but that's not the current debate. PR #1079 is = fully compatible with use of the AES instructions. The issue of the debate = is that the mechanism in PR #1079 required double buffering, first encrypt = the payload, then use the result of the encryption to encrypt the PN. This = is not an issue in a software implementation that can readily access all by= tes of the packet from memory, but it may be an issue in some hardware impl= ementations that are designed to do just one pass over the data.
>>>
>>>
>>> -- Christian Huitema
>>>
>>>
>>>
>>
>> --
>> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>>
>

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

--00000000000067fef705690cb888-- From nobody Wed Apr 4 16:22:32 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DAA126C2F for ; Wed, 4 Apr 2018 16:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 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=-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 FIy_8h3z0sgU for ; Wed, 4 Apr 2018 16:22:27 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0117.outbound.protection.outlook.com [104.47.34.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 17C01126FB3 for ; Wed, 4 Apr 2018 16:22: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=KUg6pbGIZTovTma/ezuehJTWMlsSuX4JT2igMq1o+g0=; b=bZfzWhbcmfV1S+i3PXLITzlSVSg8Xdkn0yJpuh8LTQKQZN51ufTemIePXit6Dk7WF9pW3KOdNZyAsm4c2RDEc4ML5OjmYqTXu5iQCni9I0OAQRoRJx5a5lN3GDSFtVtQZeJUgoCKVjNUtV8uvm96JlOvfHW3SO0Q5ya2YY5V6gw= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0182.namprd21.prod.outlook.com (10.173.193.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 23:22:25 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 23:22:25 +0000 From: Praveen Balasubramanian To: Ian Swett , Mark Nottingham CC: Lars Eggert , IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwZ0sAgAC4ugCAAARcAIAAFTbw Date: Wed, 4 Apr 2018 23:22:25 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0182; 7:9nf6/sJUZp0KUsQH/iOwpayEYC/FmLXt0f7n5liPPJX1L9HcWE/ABKrQCu1VFksD9dFEb8xckmBuEYvq//i6i1h1D77idLNUI72Q8t8txyIbdctV3dX03sicZsQvnCresTf4Q6VtDfzjOa2B0k+pJa/VWewjdCxU9aOqfkLvegdacNMwl7UJ+LCbFA/wHI5gDqy81jaOQ1ds4K2VF0wa5yzhHToBfzisVIeABK1zBXv20/jBh17vuV/D4PqxnsLY; 20:x/VthzGyvQZowzWUSSD5g/WCDNPbmqKbQPt5H0jUWsVD6Ce7CuUmPbf4Qzjw5xKxhF2MN9uiMvqkJbf3mHZz/lZZp8BKEEhIe0caaLgAjLmnLmy/zTXhlT9Oqr0W3j1fZd47EiinNj+bOwbtJgnj/ssKShiR3Jd1iYgZXIJRe7A= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fc0f8b5d-7f4c-4612-ce18-08d59a82eceb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0182; x-ms-traffictypediagnostic: CY4PR21MB0182: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(189930954265078)(85827821059158)(100405760836317)(219752817060721)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0182; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0182; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39380400002)(376002)(396003)(39860400002)(189003)(51914003)(199004)(51444003)(53754006)(25786009)(186003)(33656002)(316002)(106356001)(59450400001)(53546011)(93886005)(561944003)(6506007)(22452003)(102836004)(6436002)(966005)(14454004)(606006)(105586002)(478600001)(81166006)(86362001)(236005)(97736004)(8936002)(6246003)(53936002)(9686003)(55016002)(6306002)(54896002)(7736002)(476003)(5660300001)(74316002)(81156014)(229853002)(8990500004)(11346002)(8676002)(10290500003)(446003)(4326008)(99286004)(54906003)(10090500001)(486006)(3660700001)(86612001)(68736007)(6116002)(110136005)(2906002)(19609705001)(46003)(3280700002)(5250100002)(790700001)(2900100001)(7696005)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0182; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: lD3fPuIRDZPJOZ0/Nzj88aowW+9qOTkCLQVaXiNczAAHa5h5owWjJdg5NQCYI2CgINq40RYT+pSaU7/ZsnH2+ON/PSIc5u2rYzbQkfPUqR5GdeWG1ezZQM3D2Eb10qgIEBc6IQdSsIF3FwIFxVUusGiNdhltZt3RPw3VQV90jrFtcuvq0mIvHx+3LQ35h150Nntf1xwwu3Ke+cFMIHwlzMDUpe+sB8TGXGcGaiwmSZGfzJo2BXtHh5460ZRYn5kU7y/BoHA7n2vlmezOF9pf+doONEr2DsPrbM0rfk6D15Vy4oh0Y+/gwUfvd+Be2PPeZ2gJdGgpvl+L8QAJDYn3EX/KySTl6qR8Q303jW0+jze67hyamsDKTP2rJH//MfTW0Rm6N01Yk0NEh5eLL9qE3j8BSkJQRDxdc/rMrTUDNnA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630FA0EDD343396AD414641B6A40CY4PR21MB0630namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc0f8b5d-7f4c-4612-ce18-08d59a82eceb X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 23:22:25.3155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0182 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 23:22:31 -0000 --_000_CY4PR21MB0630FA0EDD343396AD414641B6A40CY4PR21MB0630namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UE5FIGlzIG9uZSB3YXkgZm9yd2FyZCBmb3IgZG9pbmcgY29ubmVjdGlvbiBtaWdyYXRpb24gd2l0 aG91dCBsaW5rYWJpbGl0eS4gSSB3b3VsZG7igJl0IGNhbGwgaXQgdGhlIG1vc3QgcHJhZ21hdGlj IHNpbmNlIGl0IGhhcyBwZXJmb3JtYW5jZSBpbXBsaWNhdGlvbnMuDQoNCkFueSBvYmplY3Rpb25z IHRvIHRoZSBmb2xsb3dpbmc/DQoNCjEuIExlYXZlIHRoZSBjdXJyZW50IGRyYWZ0IGFzIGlzIGZv ciB0aGUgY29tbW9uIGNhc2UgKG5vIG1pZ3JhdGlvbiBubyBtdWx0aXBhdGgpLiBNYWtlIHN1cmUg d2UgaGF2ZSBzb21lIHByb3Zpc2lvbiBmb3IgZ3JlYXNpbmcgdGhlIFBOIHRvIHByZXZlbnQgb3Nz aWZpY2F0aW9uLiBJZiBQTiBqdW1wcyBhcmUgbmVlZGVkIGZvciB0aGlzIChhcGFydCBmcm9tIGEg cmFuZG9tIHN0YXJ0aW5nIFBOKSB3ZSBzaG91bGQgaGF2ZSBhIFBSIG1vZGlmeWluZyBjdXJyZW50 IGRyYWZ0Lg0KDQoyLiBGb3IgY29ubmVjdGlvbiBtaWdyYXRpb24gdGhlIG9wdGlvbnMgYXJlOg0K DQphLiBFeHBsb3JlIG11bHRpcGxlIFBOIHNwYWNlcyBmb3IgY29ubmVjdGlvbiBtaWdyYXRpb24g KGFuZCBldmVudHVhbGx5IG11bHRpcGF0aCksIE9SDQoNCmIuIE1ha2UgUE5FIChhbmQgaGVuY2Ug Y29ubmVjdGlvbiBtaWdyYXRpb24pIGFuIG9wdGlvbmFsIG5lZ290aWF0ZWQgZXh0ZW5zaW9uIGlu IFYxIHdpdGggdGhlIGNhdmVhdCB0aGF0IHdlIHdpbGwgIHJldmlzaXQgdGhpcyAgZm9yIFYyIHdo ZW4gd2UgZG8gbXVsdGlwYXRoLiBUaGlzIGlzIHJlcXVpcmVkIGFueXdheXMgYmVjYXVzZSBzZXJ2 ZXJzIG11c3QgYmUgYWJsZSB0byB0ZWxsIGNsaWVudCB0aGF0IHRoZXkgY2Fubm90IHN1cHBvcnQg bWlncmF0aW9uIHNpbmNlIHRoZXkgYXJlIGJlaGluZCBhIGxlZ2FjeSBsb2FkIGJhbGFuY2VyLg0K DQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBJYW4gU3dldHQNClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxOCAyOjQ0IFBNDQpUbzog TWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0Pg0KQ2M6IExhcnMgRWdnZXJ0IDxsYXJzQGVn Z2VydC5vcmc+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNaXJqYSBLw7xobGV3aW5k IDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPg0KU3ViamVjdDogUmU6IEdldHRpbmcg dG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpBcyBleHByZXNzZWQg cHJldmlvdXNseSwgSSB0ZW5kIHRvIHRoaW5rIFBOIGVuY3J5cHRpb24gaXMgdGhlIG1vc3QgcHJh Z21hdGljIHdheSBmb3J3YXJkIGF0IHRoZSBtb21lbnQuDQoNCkhvd2V2ZXIsIGlzIGFueW9uZSB3 aG8gd291bGQgcHJlZmVyIGEgZGlmZmVyZW50IHNvbHV0aW9uKGllOiBwYWNrZXQgbnVtYmVyIGp1 bXBzIG9yIHNlcGFyYXRlIHNwYWNlcykgd2lsbGluZyB0byBzZW5kIG91dCBhIFBSIHRoZXkgdGhp bmsgc29sdmVzIHRoZSBsaW5rLWFiaWxpdHkgaXNzdWUgUE4gZW5jcnlwdGlvbiBzb2x2ZXM/DQoN Ck15IG1lbnRhbCBtb2RlbCBpcyB0aGVyZSBhcmUgYSBmYWlyIG51bWJlciBvZiB0aG9ybnkgZWRn ZSBjYXNlcywgYnV0IG1heWJlIGlmIEkgc2F3IHRoZW0gaW4gYSBQUiwgaXQgd291bGRuJ3QgYmUg YXMgc2NhcnkgYXMgSSB0aGluaz8NCg0KT24gV2VkLCBBcHIgNCwgMjAxOCBhdCA1OjI4IFBNIE1h cmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldDxtYWlsdG86bW5vdEBtbm90Lm5ldD4+IHdyb3Rl Og0KTWlyamEsDQoNCk9uIDQgQXByIDIwMTgsIGF0IDg6MjcgcG0sIE1pcmphIEvDvGhsZXdpbmQg PG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8bWFpbHRvOm1pcmphLi5rdWVobGV3aW5k QHRpay5lZS5ldGh6LmNoPj4gd3JvdGU6DQo+DQo+IEhpIE1hcmssDQo+DQo+IHdpdGhvdXQgaW50 ZW5kaW5nIHRvIHN0YXRlIGEgdGVjaG5pY2FsIG9waW5pb24sIEkgdGhpbmsgSSBuZWVkIHRvIGRp c2FncmVlIHdpdGggeW91ciBhc3Nlc3NtZW50IG9mIHRoZSBzaXR1YXRpb24uIFBsZWFzZSBzZWUg YmVsb3cuDQo+DQo+PiBBbSAwNC4wNC4yMDE4IHVtIDA2OjU4IHNjaHJpZWIgTWFyayBOb3R0aW5n aGFtIDxtbm90QG1ub3QubmV0PG1haWx0bzptbm90QG1ub3QubmV0Pj46DQo+Pg0KPj4gSGkgZXZl cnlvbmUsDQo+Pg0KPj4gVGhlIGVkaXRvcnMgaGF2ZSB0b2xkIHlvdXIgY2hhaXJzIHRoYXQgdGhp cyBpc3N1ZSBpcyBzdGFydGluZyB0byBibG9jayBwcm9ncmVzcyBvbiBvdGhlciBhc3BlY3RzIG9m IFFVSUMuIENvbWluZyB0byBjb25zZW5zdXMgb24gaXQgc29vbiAoaS5lLi4sIGJlZm9yZSBTdG9j a2hvbG0sIGlmIHBvc3NpYmxlKSB3b3VsZCBiZSBnb29kLg0KPj4NCj4+IEl0IGxvb2tzIGxpa2Ug dGhpcyB0aHJlYWQgaGFzIGNvbWUgdG8gYSBuYXR1cmFsIHBhdXNlLiBSZWFkaW5nIHRocm91Z2gg aXQsIEkgdGhpbmsgd2UgYWdyZWUgdGhlcmUgYXJlIHNvbWUgdW5wbGVhc2FudCB0cmFkZW9mZnMg aGVyZSwgYnV0IHNvIGZhciB3ZSBoYXZlIG9ubHkgb25lIGNvbmNyZXRlIHByb3Bvc2FsIC0tIFBS IzEwNzkuDQo+DQo+IFRoZSBvdGhlciBwcm9wb3NhbCBpcyB0byB1c2UgYSByYW5kb20gb2Zmc2V0 IHRoYXQgY2FuL3Nob3VsZCBiZSBjaGFuZ2VkIHdoZW4gdGhlIGNvbm5lY3Rpb24gSUQgaXMgY2hh bmdlZC4gV2hpY2ggaXMgbW9zdGx5IGlubGluZSB3aXRoIHdoYXQgdGhlIGRyYWZ0IGN1cnJlbnRs eSBzYXlzLg0KDQpBcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBzdGF0dXMgcXVvIGhhcyBjYXVzZWQg YSBzaWduaWZpY2FudCBhbW91bnQgb2YgcGFpbiwgY29tcGxleGl0eSBhbmQgcG90ZW50aWFsIGJ1 Z3MuIFBOIGVuY3J5cHRpb24gd2FzIHByb3Bvc2VkIGJ5IEthenVobyBpbiBNZWxib3VybmUgYXMg YSB3YXkgdG8gd29yayBhcm91bmQgdGhhdC4NCg0KV2UgY2FuLCBvZiBjb3Vyc2UsIGRlY2lkZSB0 aGF0IHRoZSBzdGF0dXMgcXVvIGlzIHRoZSByaWdodCBhcHByb2FjaC4gSG93ZXZlciwgbXkgY3Vy cmVudCByZWFkaW5nIG9mIHRoZSBXRyBpcyB0aGF0IGl0IGlzbid0IGFjY2VwdGFibGUuDQoNCg0K Pj4gTXkgQVUkLjA1IC0gV2hpbGUgd2UncmUgY2hhcnRlcmVkIHRvIHByb2R1Y2UgYSBwcm90b2Nv bCB0aGF0J3MgZW5jcnlwdGVkIGFzIG11Y2ggYXMgb3BlcmF0aW9uYWwgY29uY2VybnMgYWxsb3cs DQo+DQo+IEkgZG9u4oCZdCB0aGluayB0aGlzIGlzIHdoYXQgdGhlIGNoYXJ0ZXIgc2F5LiBUaGUg Y2hhcnRlciBzYXlzICJQcm92aWRpbmcgYWx3YXlzLXNlY3VyZSB0cmFuc3BvcnQsIHVzaW5nIFRM UyAxLjMgYnkgZGVmYXVsdC7igJwgcGx1cyBhbm90aGVyIHBhcmFncmFwaCB0aGF0IHRhbGtzIGFi b3V0IFRMUzEuMy4gSXQgZG9lcyBub3Qgc3BlbGwgb3V0IHRoZSBkZXNpcmUgb2Ygc29tZSBpbmRp dmlkdWFsIHRvIOKAnmVuY3J5cHQgYXMgbXVjaCBhcyBwb3NzaWJsZeKAnC4NCg0KSSB0aGluayB0 aGF0IGRlcGVuZHMgb24gaG93IHlvdSByZWFkICJhbHdheXMtc2VjdXJlLiIgVGhlIGNoYXJ0ZXIg YWxzbyBzYXlzIHdlIHdpbGwgcHJvdmlkZSAiY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkg cHJvdGVjdGlvbiBvZiBib3RoIGFwcGxpY2F0aW9uIGRhdGEgYW5kIFFVSUMgaGVhZGVycy4iDQoN Cg0KPj4gYW5kIHRoYXQgcHJpdmFjeSBpcyBhIG5hdHVyYWwgZXh0ZW5zaW9uIG9mIHRoYXQgKGVz cGVjaWFsbHkgaW4gbGlnaHQgb2YgUkZDNzI1OCBhbmQgUkZDNjk3MyksIHRoZXJlIGlzIG5vICpy ZXF1aXJlbWVudCogdGhhdCB3ZSBwcm9kdWNlIGEgcHJvdG9jb2wgdGhhdCBpcyBhYmxlIHRvIGJl IGFjY2VsZXJhdGVkIGJ5IGhhcmR3YXJlLg0KPg0KPiBOb3QgdGhlcmUgaXMgbm8gcmVxdWlyZW1l bnQgdGhhdCB0aGUgcHJvdG9jb2wgbmVlZCB0byBiZSBhY2NlbGVyYXRlZCBieSBoYXJkd2FyZS4g SG93ZXZlciwgbm90IGFsbCByZXF1aXJlbWVudCBhcmUgbGlzdGVkIGluIHRoZSBjaGFydGVyLiBX ZSBhcyBhIGdyb3VwIGhhdmUgdG8gZGVmaW5lIHRoZSByZXF1aXJlbWVudC4gSG93ZXZlciwgdGhl cmUgaXMgb2YgY291cnNlIGFuIGltcGxpY2l0IHJlcXVpcmVtZW50IGZvciBhbGwgd29yayBpbiB0 aGUgSUVGVCB0aGF0IGlzIG11c3QgYmUgZGVwbG95YWJsZSBhbmQgc2VydmUgdGhlIG5lZWRzIG9m IHRob3NlIHBlb3BsZSB3aG8gd2FudCB0byBkZXBsb3kgaXQuDQoNClllcyAtIGEgZGlzY3Vzc2lv biB0aGF0IEknbSB0cnlpbmcgdG8gZHJhdyBvdXQuIFRoYW5rcy4NCg0KDQo+PiBUaGF0IGJlaW5n IHRoZSBjYXNlLCBJIHRoaW5rIHdlIG5lZWQgdG8gYXNrIG91cnNlbHZlcyBpZiB3ZSBiZWxpZXZl IHRoYXQgaW5jbHVzaW9uIG9mIFBSIzEwNzkgd2lsbCBzaWduaWZpY2FudGx5IGluaGliaXQgZGVw bG95bWVudCBvZiB0aGUgcHJvdG9jb2wuIEJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIHNvIGZhciwg dGhhdCBkb2Vzbid0IHNlZW0gdG8gYmUgdGhlIGNhc2UsIGJ1dCBJJ2QgYmUgaW50ZXJlc3RlZCB0 byBoZWFyIHdoYXQgb3RoZXJzIHRoaW5rLg0KPg0KPiBIZXJlIG15IGFzc2Vzc21lbnQgaXMgYWxz byBkaWZmZXJlbnQuIFRoZXJlIGFyZSBtdWx0aXBsZSBwZW9wbGUgdGhhdCBoYXZlIHJhaXNlZCBj b25jZXJucyB0aGF0IHRoaXMgY291bGQgaGluZGVyIGRlcGxveW1lbnQuDQoNCkFzIHlvdSBrbm93 LCB3ZSBkb24ndCBhc3Nlc3MgY29uc2Vuc3VzIGp1c3QgYnkgdGhlIG51bWJlciBvZiBwZW9wbGUg dGhhdCBoYXZlIHJhaXNlZCBjb25jZXJucywgYnV0IGFsc28gdGhlIHRlY2huaWNhbCBtZXJpdCBv ZiB0aGUgYXJndW1lbnRzLiBTbyBmYXIsIHRoZSBhcmd1bWVudHMgaGF2ZSBiZWVuIGFsbCBvdmVy IHRoZSBtYXAsIGFuZCBJIHdhbnQgdGhlbSB0byBjb252ZXJnZS4NCg0KVGhlIGRhdGEgdGhhdCdz IGJlZW4gcHJvdmlkZWQgaGFzIGJlZW4gdmVyeSBoZWxwZnVsLCBidXQgd2UgbmVlZCB0byBldmFs dWF0ZSB0aGF0IGluIHRoZSBjb250ZXh0IG9mIGhvdyBRVUlDdjEgd2lsbCBhY3R1YWxseSBiZSBk ZXBsb3llZCBhbmQgdXNlZCAtLSBzb21ldGhpbmcgd2hpY2ggYSBmZXcgdGhyZWFkcyBoYXZlIHRv dWNoZWQgdXBvbi4NCg0KT3ZlcmFsbCwgSSBkbyBub3QgdGhpbmsgaXQgaXMgYSBnb2FsIG9mIFFV SUMgdG8gYmUgZGVwbG95YWJsZSBvbiBhbnkgc3lzdGVtIGZvciBhbnkgcHVycG9zZTsgaWYgd2Ug dHJ5IHRvIGRlc2lnbiBpdCBmb3IgYWxsIHB1cnBvc2VzLCB3ZSdyZSBnb2luZyB0byBmYWlsLiBU aGUgcXVlc3Rpb24sIHRoZW4sIGlzIGhvdyBtdWNoIGRlcGxveW1lbnQgLyBpbXBsZW1lbnRhdGlv biAvIGFkb3B0aW9uIHdlIG5lZWQgdG8gbWFrZSBpdCBzdWNjZWVkIC0tIGFuZCB0byBkZXNpZ24g Zm9yIHRoYXQuDQoNCg0KPj4gSWYgd2UgY2FuIGdldCB0byBjb25zZW5zdXMgdG8gaW5jb3Jwb3Jh dGUgdGhlIFBSLCBhbmQgZm9sa3MgY29tZSBiYWNrIGxhdGVyIHdpdGggYSBtb3JlIGhhcmR3YXJl LWZyaWVuZGx5IHJlcGxhY2VtZW50IHRoYXQgZG9lc24ndCBjaGFuZ2UgdGhlIEludmFyaWFudHMg b3IgaW5jcmVhc2UgbGlua2FiaWxpdHksIEkgc3VzcGVjdCB0aGUgV0cgd2lsbCBiZSBhbWVuYWJs ZSB0byB0aGF0Lg0KPg0KPiBJIGRvbuKAmXQgdGhpbmsgdG8ganVzdCBnbyB3aXRoIHdoYXQgd2Ug aGF2ZSBldmVuIHRob3VnaCB0aGVyZSBhcmUgY29uY2VybnMsIGlzIHRoZSByaWdodCBhcHByb2Fj aCBhbmQgZGVmaW5pdGVseSBub3QgdGhlIGFwcHJvYWNoIHRoYXQgd2FzIGNob3NlbiBmb3Igb3Ro ZXIgcHJvcG9zYWxzLiBJbiB0aGUgc2FrZSBvZiBnZXR0aW5nIHZlcnNpb24gdjEgb3V0IHF1aWNr bHksIEkgd291bGQgdGhpbmsgdGhhdCBub3QgaW5jb3Jwb3JhdGluZyBhbm90aGVyIGNoYW5nZSB0 aGF0IGRvZXMgbm90IGhhdmUgY29uc2Vuc3VzIGlzIHRoZSBwcm9wb3NlciBhcHByb2FjaC4NCg0K SSB3YXNuJ3QgcHJvcG9zaW5nIHRoYXQgd2UgaW5jb3Jwb3JhdGUgYSBjaGFuZ2Ugd2l0aG91dCBj b25zZW5zdXMgLS0gcGxlYXNlIHJlLXJlYWQgbXkgc3RhdGVtZW50LiBZb3UgbWF5IGRpc2FncmVl IHdpdGggaG93IHRoZSBjaGFpcnMgZXZlbnR1YWxseSBjYWxsIGNvbnNlbnN1cyBvbiB0aGlzIGlz c3VlLCBhbmQgdGhlcmUgYXJlIG1lY2hhbmlzbXMgZm9yIHlvdSB0byBhcHBlYWwgKG9yIGV2ZW4g RElTQ1VTUykgdGhhdCwgYnV0IGl0J3MgcHJlbWF0dXJlIHRvIHN0YXJ0IHRoYXQgbm93Lg0KDQpU aGF0IHNhaWQgLS0gT25lIHdheSB0byBwcm92ZSB0aGF0IFBORSBodXJ0cyBkZXBsb3lhYmlsaXR5 IGlzIHRvIHRyeSBpdDsgaW1wbGVtZW50ZXJzIGhhdmUgYSB2ZXJ5IHN0cm9uZyBpbmNlbnRpdmUg dG8gbWFrZSBzdXJlIHRoZWlyIGNvZGUgY2FuIGJlIGRlcGxveWVkLCBzbyBpZiB0aG9zZSB3aG8g aGF2ZSBjb25jZXJucyBhcmUgY29ycmVjdCwgaXQncyBwcm9iYWJseSB0aGUgZWFzaWVzdCB3YXkg Zm9yIHRoZW0gdG8gYmUgcHJvdmVuIHJpZ2h0Lg0KDQpUaGFua3MsDQoNCg0KPiBNaXJqYQ0KPg0K Pg0KPg0KPj4NCj4+IFdoYXQgZG8gZm9sa3MgdGhpbms/DQo+Pg0KPj4gQ2hlZXJzLA0KPj4NCj4+ DQo+Pj4gT24gMjkgTWFyIDIwMTgsIGF0IDExOjM5IGFtLCBJYW4gU3dldHQgPGlhbnN3ZXR0PTQw Z29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYu b3JnPj4gd3JvdGU6DQo+Pj4NCj4+PiBUaGFua3MgZm9yIHRoZSBuaWNlIHN1bW1hcnkgSmFuYS4N Cj4+Pg0KPj4+IEFzIG11Y2ggYXMgSSdkIGxvdmUgdG8gaGF2ZSBlYXNpZXIgY3J5cHRvIEhXIGFj Y2VsZXJhdGlvbiwgSSd2ZSBlbmRlZCB1cCBhcnJpdmluZyBhdCB0aGUgc2FtZSBjb25jbHVzaW9u LiAgSSBkb24ndCB3YW50IHRvIGJpdGUgb2ZmIHRoZSB3b3JrIHRvIGRvIHByb3BlciBtdWx0aXBh dGggaW4gUVVJQyB2MSwgd2hpY2ggSSB0aGluayBpcyB0aGUgb25seSBvdGhlciByZWFzb25hYmxl IG9wdGlvbiBvZiB0aG9zZSBDaHJpc3RpYW4gb3V0bGluZWQuDQo+Pj4NCj4+PiBJZiBzb21lb25l IGNvbWVzIHVwIHdpdGggYSB3YXkgdG8gdHJhbnNmb3JtIHBhY2tldCBudW1iZXIgdG8gbWFrZSBp dCBub24tbGlua2FibGUsIGJ1dCBkb2Vzbid0IGhhdmUgdGhlIGRvd25zaWRlIG9mIG1ha2luZyBo YXJkd2FyZSBvZmZsb2FkIGRpZmZpY3VsdCwgdGhlbiBJJ20gb3BlbiB0byBpdC4gIEJ1dCB3ZSd2 ZSBiZWVuIHRhbGtpbmcgYWJvdXQgdGhpcyBmb3IgMiBtb250aHMgd2l0aG91dCBhbnkgbm90YWJs ZSBpbXByb3ZlbWVudHMgb3ZlciBNYXJ0aW4ncyBQUi4NCj4+Pg0KPj4+IEdpdmVuIHdlIG5ldmVy IHRhbGsgYWJvdXQgYW55IGlzc3VlIG9ubHkgb25jZSBpbiBRVUlDLCBJJ20gc3VyZSB0aGlzIHdp bGwgY29tZSB1cCBhZ2FpbiwgYnV0IGZvciB0aGUgdGltZSBiZWluZyBJIHRoaW5rICMxMDc5IGlz IHRoZSBiZXN0IG9wdGlvbiB3ZSBoYXZlLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IE9uIFdlZCwgTWFy IDI4LCAyMDE4IGF0IDg6MDMgUE0gSmFuYSBJeWVuZ2FyIDxqcmkuaWV0ZkBnbWFpbC5jb208bWFp bHRvOmpyaS5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+IEEgZmV3IHF1aWNrIHRob3VnaHRz IGFzIEkgY2F0Y2ggdXAgb24gdGhpcyB0aHJlYWQuDQo+Pj4NCj4+PiBJIHNwZW50IHNvbWUgdGlt ZSBsYXN0IHdlZWsgd29ya2luZyB0aHJvdWdoIGEgZGVzaWduIHVzaW5nIG11bHRpcGxlIFBOIHNw YWNlcywgYW5kIGl0IGlzIHF1aXRlIGRvYWJsZS4gSSBzdXNwZWN0IHdlJ2xsIGhlYWQgdG93YXJk cyBtdWx0aXBsZSBQTiBzcGFjZXMgYXMgd2UgY29uc2lkZXIgbXVsdGlwYXRoIGluIHRoZSBmdXR1 cmUuIFRoYXQgc2FpZCwgdGhlcmUgaXMgY29tcGxleGl0eSAoYXMgQ2hyaXN0aWFuIG5vdGVzKS4g VGhpcyBjb21wbGV4aXR5IG1heSBiZSB3YXJyYW50ZWQgd2hlbiBkb2luZyBtdWx0aXBhdGggaW4g djIgb3IgbGF0ZXIsIGJ1dCBJJ20gbm90IGNvbnZpbmNlZCB0aGF0IHRoaXMgaXMgbmVjZXNzYXJ5 IGFzIGEgZGVzaWduIHByaW1pdGl2ZSBmb3IgUVVJQ3YxLg0KPj4+DQo+Pj4gV2UgbWF5IHdhbnQg dG8gY3JlYXRpdmVseSB1c2UgdGhlIFBOIGJpdHMgaW4gdjIsIHNheSB0byBlbmNvZGUgYSBwYXRo IElEIGFuZCBhIFBOLCBmb3IgbXVsdGlwYXRoLiBXZSB3YW50IHRvIHJldGFpbiBmbGV4aWJpbGl0 eSBpbiB0aGVzZSBiaXRzIGdvaW5nIGludG8gdjIuIFdlJ3ZlIHVzZWQgZW5jcnlwdGlvbiB0byBl bnN1cmUgdGhhdCB3ZSBkb24ndCBsb3NlIGZsZXhpYmlsaXR5IGVsc2V3aGVyZSBpbiB0aGUgaGVh ZGVyLCBhbmQgaXQgZm9sbG93cyB0aGF0IHdlIHNob3VsZCB1c2UgUE5FIHRvIHJldGFpbiBmbGV4 aWJpbGl0eSBpbiB0aGVzZSBiaXRzIGFzIHdlbGwuIChTaW1wbGljaXR5IG9mIGRlc2lnbiBpcyB0 aGUgb3RoZXIgdmFsdWUgaW4gdXNpbmcgUE5FLCBzaW5jZSBoYW5kbGluZyBtaWdyYXRpb24gbGlu a2FiaWxpdHkgaXMgbm9uLXRyaXZpYWwgd2l0aG91dCBpdC4pDQo+Pj4NCj4+PiBUaGlzIGxlYXZl cyB0aGUgcXVlc3Rpb24gb2YgSFcgYWNjZWxlcmF0aW9uIGJlaW5nIGF0IGxvZ2dlcmhlYWRzIHdp dGggdGhlIGRlc2lnbiBpbiBQUiAjMTA3OS4gRmlyc3QsIEkgZXhwZWN0IHRoYXQgdGhlIHByaW1h cnkgYmVuZWZpdCBvZiBhY2NlbGVyYXRpb24gd2lsbCBiZSBpbiBEQyBlbnZpcm9ubWVudHMuIFll cywgdGhlcmUgYXJlIHNvbWUgZ2FpbnMgdG8gYmUgaGFkIGluIHNlcnZpbmcgdGhlIHB1YmxpYyBJ bnRlcm5ldCBhcyB3ZWxsLCBidXQgSSdtIHVuY29udmluY2VkIHRoYXQgdGhpcyBpcyB0aGUgZHJp dmluZyB1c2UgY2FzZSBmb3IgaGFyZHdhcmUgYWNjZWxlcmF0aW9uLiBJIHVuZGVyc3RhbmQgdGhh dCBvdGhlcnMgbWF5IGRpc2FncmVlIHdpdGggbWUgaGVyZS4NCj4+Pg0KPj4+IEFGQUlLLCBRVUlD IGhhcyBub3QgYmVlbiB1c2VkIGluIERDIGVudmlyb25tZW50cyB5ZXQuIEkgZXhwZWN0IHRoZXJl IGFyZSBvdGhlciB0aGluZ3MgaW4gdGhlIHByb3RvY29sIHRoYXQgd2UnZCB3YW50IHRvIGNoYW5n ZSBhcyB3ZSBnYWluIGV4cGVyaWVuY2UgZGVwbG95aW5nIFFVSUMgaW4gRENzLiBTcGlubmluZyB1 cCBhIG5ldyB2ZXJzaW9uIHRvIHRyeSBRVUlDIHdpdGhpbiBEQ3MgaXMgbm90IG9ubHkgYXBwcm9w cmlhdGUsIEkgd291bGQgcmVjb21tZW5kIGl0LiBUaGlzIGFsbG93cyBmb3IgcmFwaWQgaXRlcmF0 aW9ucyBpbnRlcm5hbGx5LCBhbmQgdGhlIGV4cGVyaWVuY2UgY2FuIGRyaXZlIHN1YnNlcXVlbnQg Y2hhbmdlcyB0byBRVUlDLiBJdCdzIHdoYXQgKkkqIHdvdWxkIGRvIGlmIEkgd2FzIHRvIGRlcGxv eSBRVUlDIGluc2lkZSBhIERDLg0KPj4+DQo+Pj4gU28sIGluIHNob3J0LCBJIHRoaW5rIHdlIHNo b3VsZCBnbyBhaGVhZCB3aXRoIFBSIyAxMDc5LiBUaGlzIGVuc3VyZXMgdGhhdCBmdXR1cmUgdmVy c2lvbnMgYXJlIGd1YXJhbnRlZWQgdGhlIGZsZXhpYmlsaXR5IHRvIGNoYW5nZSB0aGUgUE4gYml0 cyBmb3IgYmV0dGVyIHN1cHBvcnQgb2YgSFcgYWNjZWxlcmF0aW9uIG9yIG11bHRpcGF0aCBvciB3 aGF0LWhhdmUteW91Lg0KPj4+DQo+Pj4gLSBqYW5hDQo+Pj4NCj4+PiBPbiBNYXIgMjYsIDIwMTgg OTo0MSBBTSwgIkNocmlzdGlhbiBIdWl0ZW1hIiA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86 aHVpdGVtYUBodWl0ZW1hLm5ldD4+IHdyb3RlOg0KPj4+DQo+Pj4gT24gMy8yNi8yMDE4IDg6MjAg QU0sIFN3aW5kZWxscywgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSkgd3JvdGU6DQo+Pj4+ IExvb2tpbmcgYXQgaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvQUVTX2luc3RydWN0aW9u X3NldCNJbnRlbF9hbmRfQU1EX3g4Nl9hcmNoaXRlY3R1cmU8aHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZlbi53aWtpcGVkaWEu b3JnJTJGd2lraSUyRkFFU19pbnN0cnVjdGlvbl9zZXQlMjNJbnRlbF9hbmRfQU1EX3g4Nl9hcmNo aXRlY3R1cmUmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDYWQyNmY1MmQ5 ZDFhNDI2MGI2OTMwOGQ1OWE3NTMyODUlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM2NTg0NzUwNTMwMDMzMzI1JnNkYXRhPXlHcVdiQk1NOTh0SDVBMjJrQlc0 S1pGaHh4QmdiRGg0NE15Q0tRT1JORDAlM0QmcmVzZXJ2ZWQ9MD4gaXQgc2VlbXMgdG8gaW1wbHkg YSBsYXJnZSByYW5nZSBvZiBzZXJ2ZXIsIGRlc2t0b3AgYW5kIG1vYmlsZSBjaGlwcyBhbGwgaGF2 ZSBhIENQVSBpbnN0cnVjdGlvbiBzZXQgYXZhaWxhYmxlIHRvIGRvIEFFUyBhY2NlbGVyYXRpb24g YW5kIG90aGVyIHNpbWlsYXIgb3BlcmF0aW9ucyAob3RoZXIgaW5zdHJ1Y3Rpb24gc2V0cyBhcmUg YWxzbyBhdmFpbGFibGUpLg0KPj4+Pg0KPj4+PiBJZiB3ZSBhcmUgY29uc2lkZXJpbmcgdGhlIEFF UyBpbnN0cnVjdGlvbnMgdGhlbiBpdCBsb29rcyBsaWtlIGl0IGlzIChvciBhdCBsZWFzdCB3aWxs IGJlIGluIHRoZSBuZWFyIGZ1dHVyZSkgYSBzaXplYWJsZSBwcm9wb3J0aW9uIG9mIHRoZSBwdWJs aWMgaW50ZXJuZXQgaGF2ZSBpdCB0byBiZSB1c2VkLg0KPj4+Pg0KPj4+DQo+Pj4gQ2VydGFpbmx5 LCBidXQgdGhhdCdzIG5vdCB0aGUgY3VycmVudCBkZWJhdGUuIFBSICMxMDc5IGlzIGZ1bGx5IGNv bXBhdGlibGUgd2l0aCB1c2Ugb2YgdGhlIEFFUyBpbnN0cnVjdGlvbnMuIFRoZSBpc3N1ZSBvZiB0 aGUgZGViYXRlIGlzIHRoYXQgdGhlIG1lY2hhbmlzbSBpbiBQUiAjMTA3OSByZXF1aXJlZCBkb3Vi bGUgYnVmZmVyaW5nLCBmaXJzdCBlbmNyeXB0IHRoZSBwYXlsb2FkLCB0aGVuIHVzZSB0aGUgcmVz dWx0IG9mIHRoZSBlbmNyeXB0aW9uIHRvIGVuY3J5cHQgdGhlIFBOLiBUaGlzIGlzIG5vdCBhbiBp c3N1ZSBpbiBhIHNvZnR3YXJlIGltcGxlbWVudGF0aW9uIHRoYXQgY2FuIHJlYWRpbHkgYWNjZXNz IGFsbCBieXRlcyBvZiB0aGUgcGFja2V0IGZyb20gbWVtb3J5LCBidXQgaXQgbWF5IGJlIGFuIGlz c3VlIGluIHNvbWUgaGFyZHdhcmUgaW1wbGVtZW50YXRpb25zIHRoYXQgYXJlIGRlc2lnbmVkIHRv IGRvIGp1c3Qgb25lIHBhc3Mgb3ZlciB0aGUgZGF0YS4NCj4+Pg0KPj4+DQo+Pj4gLS0gQ2hyaXN0 aWFuIEh1aXRlbWENCj4+Pg0KPj4+DQo+Pj4NCj4+DQo+PiAtLQ0KPj4gTWFyayBOb3R0aW5naGFt ICAgaHR0cHM6Ly93d3cubW5vdC5uZXQvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lm1ub3QubmV0JTJGJmRhdGE9MDIl N0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3Q2FkMjZmNTJkOWQxYTQyNjBiNjkzMDhkNTlh NzUzMjg1JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjU4 NDc1MDUzMDAzMzMyNSZzZGF0YT1aZFNWVWxSR2VRZTg1ajJEeldtRzhKSU1UVnUwa0NLWFYlMkJN SVpvOTloMFElM0QmcmVzZXJ2ZWQ9MD4NCj4+DQo+DQoNCi0tDQpNYXJrIE5vdHRpbmdoYW0gICBo dHRwczovL3d3dy5tbm90Lm5ldC88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cubW5vdC5uZXQlMkYmZGF0YT0wMiU3QzAx JTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDYWQyNmY1MmQ5ZDFhNDI2MGI2OTMwOGQ1OWE3NTMy ODUlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTg0NzUw NTMwMDMzMzI1JnNkYXRhPVpkU1ZVbFJHZVFlODVqMkR6V21HOEpJTVRWdTBrQ0tYViUyQk1JWm85 OWgwUSUzRCZyZXNlcnZlZD0wPg0K --_000_CY4PR21MB0630FA0EDD343396AD414641B6A40CY4PR21MB0630namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFp blRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UE5FIGlzIG9uZSB3YXkgZm9yd2FyZCBmb3IgZG9pbmcg Y29ubmVjdGlvbiBtaWdyYXRpb24gd2l0aG91dCBsaW5rYWJpbGl0eS4gSSB3b3VsZG7igJl0IGNh bGwgaXQgdGhlIG1vc3QgcHJhZ21hdGljIHNpbmNlIGl0IGhhcyBwZXJmb3JtYW5jZSBpbXBsaWNh dGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFueSBvYmplY3Rpb25zIHRvIHRoZSBmb2xs b3dpbmc/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xLiBMZWF2ZSB0 aGUgY3VycmVudCBkcmFmdCBhcyBpcyBmb3IgdGhlIGNvbW1vbiBjYXNlIChubyBtaWdyYXRpb24g bm8gbXVsdGlwYXRoKS4gTWFrZSBzdXJlIHdlIGhhdmUgc29tZSBwcm92aXNpb24gZm9yIGdyZWFz aW5nIHRoZSBQTiB0byBwcmV2ZW50IG9zc2lmaWNhdGlvbi4gSWYgUE4ganVtcHMgYXJlIG5lZWRl ZCBmb3IgdGhpcyAoYXBhcnQgZnJvbSBhIHJhbmRvbSBzdGFydGluZyBQTikgd2Ugc2hvdWxkDQog aGF2ZSBhIFBSIG1vZGlmeWluZyBjdXJyZW50IGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Mi4gRm9yIGNvbm5lY3Rpb24gbWlncmF0aW9uIHRoZSBvcHRpb25z IGFyZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJ0ZXh0 LWluZGVudDouNWluIj5hLiBFeHBsb3JlIG11bHRpcGxlIFBOIHNwYWNlcyBmb3IgY29ubmVjdGlv biBtaWdyYXRpb24gKGFuZCBldmVudHVhbGx5IG11bHRpcGF0aCksIE9SPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Yi4gTWFr ZSBQTkUgKGFuZCBoZW5jZSBjb25uZWN0aW9uIG1pZ3JhdGlvbikgYW4gb3B0aW9uYWwgbmVnb3Rp YXRlZCBleHRlbnNpb24gaW4gVjEgd2l0aCB0aGUgY2F2ZWF0IHRoYXQgd2Ugd2lsbCAmbmJzcDty ZXZpc2l0IHRoaXMgJm5ic3A7Zm9yIFYyIHdoZW4gd2UgZG8gbXVsdGlwYXRoLg0KPGk+VGhpcyBp cyByZXF1aXJlZCBhbnl3YXlzIGJlY2F1c2Ugc2VydmVycyBtdXN0IGJlIGFibGUgdG8gdGVsbCBj bGllbnQgdGhhdCB0aGV5IGNhbm5vdCBzdXBwb3J0IG1pZ3JhdGlvbiBzaW5jZSB0aGV5IGFyZSBi ZWhpbmQgYSBsZWdhY3kgbG9hZCBiYWxhbmNlci48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+ IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9i PklhbiBTd2V0dDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTggMjo0 NCBQTTxicj4NCjxiPlRvOjwvYj4gTWFyayBOb3R0aW5naGFtICZsdDttbm90QG1ub3QubmV0Jmd0 Ozxicj4NCjxiPkNjOjwvYj4gTGFycyBFZ2dlcnQgJmx0O2xhcnNAZWdnZXJ0Lm9yZyZndDs7IElF VEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1pcmphIEvDvGhsZXdpbmQgJmx0O21p cmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGV4cHJlc3NlZCBwcmV2aW91c2x5LCBJIHRlbmQg dG8gdGhpbmsgUE4gZW5jcnlwdGlvbiBpcyB0aGUgbW9zdCBwcmFnbWF0aWMgd2F5IGZvcndhcmQg YXQgdGhlIG1vbWVudC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhvd2V2ZXIsIGlzIGFueW9uZSB3aG8gd291bGQgcHJlZmVyIGEgZGlmZmVyZW50IHNvbHV0 aW9uKGllOiBwYWNrZXQgbnVtYmVyIGp1bXBzIG9yIHNlcGFyYXRlIHNwYWNlcykgd2lsbGluZyB0 byBzZW5kIG91dCBhIFBSIHRoZXkgdGhpbmsgc29sdmVzIHRoZSBsaW5rLWFiaWxpdHkgaXNzdWUg UE4gZW5jcnlwdGlvbiBzb2x2ZXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk15IG1lbnRhbCBtb2RlbCBpcyB0aGVyZSBhcmUgYSBmYWlyIG51 bWJlciBvZiB0aG9ybnkgZWRnZSBjYXNlcywgYnV0IG1heWJlIGlmIEkgc2F3IHRoZW0gaW4gYSBQ UiwgaXQgd291bGRuJ3QgYmUgYXMgc2NhcnkgYXMgSSB0aGluaz88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBcHIgNCwgMjAxOCBh dCA1OjI4IFBNIE1hcmsgTm90dGluZ2hhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1ub3RAbW5vdC5u ZXQiPm1ub3RAbW5vdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk1pcmphLDxicj4NCjxi cj4NCk9uIDQgQXByIDIwMTgsIGF0IDg6MjcgcG0sIE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhy ZWY9Im1haWx0bzptaXJqYS4ua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCIgdGFyZ2V0PSJfYmxh bmsiPm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7PGJyPg0KJmd0OyBIaSBNYXJrLDxicj4NCiZndDs8YnI+DQomZ3Q7IHdpdGhvdXQgaW50ZW5k aW5nIHRvIHN0YXRlIGEgdGVjaG5pY2FsIG9waW5pb24sIEkgdGhpbmsgSSBuZWVkIHRvIGRpc2Fn cmVlIHdpdGggeW91ciBhc3Nlc3NtZW50IG9mIHRoZSBzaXR1YXRpb24uIFBsZWFzZSBzZWUgYmVs b3cuPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IEFtIDA0LjA0LjIwMTggdW0gMDY6NTggc2Nocmll YiBNYXJrIE5vdHRpbmdoYW0gJmx0OzxhIGhyZWY9Im1haWx0bzptbm90QG1ub3QubmV0IiB0YXJn ZXQ9Il9ibGFuayI+bW5vdEBtbm90Lm5ldDwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgSGkgZXZlcnlvbmUsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgZWRpdG9y cyBoYXZlIHRvbGQgeW91ciBjaGFpcnMgdGhhdCB0aGlzIGlzc3VlIGlzIHN0YXJ0aW5nIHRvIGJs b2NrIHByb2dyZXNzIG9uIG90aGVyIGFzcGVjdHMgb2YgUVVJQy4gQ29taW5nIHRvIGNvbnNlbnN1 cyBvbiBpdCBzb29uIChpLmUuLiwgYmVmb3JlIFN0b2NraG9sbSwgaWYgcG9zc2libGUpIHdvdWxk IGJlIGdvb2QuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJdCBsb29rcyBsaWtlIHRoaXMg dGhyZWFkIGhhcyBjb21lIHRvIGEgbmF0dXJhbCBwYXVzZS4gUmVhZGluZyB0aHJvdWdoIGl0LCBJ IHRoaW5rIHdlIGFncmVlIHRoZXJlIGFyZSBzb21lIHVucGxlYXNhbnQgdHJhZGVvZmZzIGhlcmUs IGJ1dCBzbyBmYXIgd2UgaGF2ZSBvbmx5IG9uZSBjb25jcmV0ZSBwcm9wb3NhbCAtLSBQUiMxMDc5 Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBvdGhlciBwcm9wb3NhbCBpcyB0byB1c2UgYSByYW5k b20gb2Zmc2V0IHRoYXQgY2FuL3Nob3VsZCBiZSBjaGFuZ2VkIHdoZW4gdGhlIGNvbm5lY3Rpb24g SUQgaXMgY2hhbmdlZC4gV2hpY2ggaXMgbW9zdGx5IGlubGluZSB3aXRoIHdoYXQgdGhlIGRyYWZ0 IGN1cnJlbnRseSBzYXlzLjxicj4NCjxicj4NCkFzIEkgdW5kZXJzdGFuZCBpdCwgdGhlIHN0YXR1 cyBxdW8gaGFzIGNhdXNlZCBhIHNpZ25pZmljYW50IGFtb3VudCBvZiBwYWluLCBjb21wbGV4aXR5 IGFuZCBwb3RlbnRpYWwgYnVncy4gUE4gZW5jcnlwdGlvbiB3YXMgcHJvcG9zZWQgYnkgS2F6dWhv IGluIE1lbGJvdXJuZSBhcyBhIHdheSB0byB3b3JrIGFyb3VuZCB0aGF0Ljxicj4NCjxicj4NCldl IGNhbiwgb2YgY291cnNlLCBkZWNpZGUgdGhhdCB0aGUgc3RhdHVzIHF1byBpcyB0aGUgcmlnaHQg YXBwcm9hY2guIEhvd2V2ZXIsIG15IGN1cnJlbnQgcmVhZGluZyBvZiB0aGUgV0cgaXMgdGhhdCBp dCBpc24ndCBhY2NlcHRhYmxlLjxicj4NCjxicj4NCjxicj4NCiZndDsmZ3Q7IE15IEFVJC4wNSAt IFdoaWxlIHdlJ3JlIGNoYXJ0ZXJlZCB0byBwcm9kdWNlIGEgcHJvdG9jb2wgdGhhdCdzIGVuY3J5 cHRlZCBhcyBtdWNoIGFzIG9wZXJhdGlvbmFsIGNvbmNlcm5zIGFsbG93LDxicj4NCiZndDs8YnI+ DQomZ3Q7IEkgZG9u4oCZdCB0aGluayB0aGlzIGlzIHdoYXQgdGhlIGNoYXJ0ZXIgc2F5LiBUaGUg Y2hhcnRlciBzYXlzICZxdW90O1Byb3ZpZGluZyBhbHdheXMtc2VjdXJlIHRyYW5zcG9ydCwgdXNp bmcgVExTIDEuMyBieSBkZWZhdWx0LuKAnCBwbHVzIGFub3RoZXIgcGFyYWdyYXBoIHRoYXQgdGFs a3MgYWJvdXQgVExTMS4zLiBJdCBkb2VzIG5vdCBzcGVsbCBvdXQgdGhlIGRlc2lyZSBvZiBzb21l IGluZGl2aWR1YWwgdG8g4oCeZW5jcnlwdCBhcyBtdWNoIGFzIHBvc3NpYmxl4oCcLjxicj4NCjxi cj4NCkkgdGhpbmsgdGhhdCBkZXBlbmRzIG9uIGhvdyB5b3UgcmVhZCAmcXVvdDthbHdheXMtc2Vj dXJlLiZxdW90OyBUaGUgY2hhcnRlciBhbHNvIHNheXMgd2Ugd2lsbCBwcm92aWRlICZxdW90O2Nv bmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IHByb3RlY3Rpb24gb2YgYm90aCBhcHBsaWNhdGlv biBkYXRhIGFuZCBRVUlDIGhlYWRlcnMuJnF1b3Q7PGJyPg0KPGJyPg0KPGJyPg0KJmd0OyZndDsg YW5kIHRoYXQgcHJpdmFjeSBpcyBhIG5hdHVyYWwgZXh0ZW5zaW9uIG9mIHRoYXQgKGVzcGVjaWFs bHkgaW4gbGlnaHQgb2YgUkZDNzI1OCBhbmQgUkZDNjk3MyksIHRoZXJlIGlzIG5vICpyZXF1aXJl bWVudCogdGhhdCB3ZSBwcm9kdWNlIGEgcHJvdG9jb2wgdGhhdCBpcyBhYmxlIHRvIGJlIGFjY2Vs ZXJhdGVkIGJ5IGhhcmR3YXJlLjxicj4NCiZndDs8YnI+DQomZ3Q7IE5vdCB0aGVyZSBpcyBubyBy ZXF1aXJlbWVudCB0aGF0IHRoZSBwcm90b2NvbCBuZWVkIHRvIGJlIGFjY2VsZXJhdGVkIGJ5IGhh cmR3YXJlLiBIb3dldmVyLCBub3QgYWxsIHJlcXVpcmVtZW50IGFyZSBsaXN0ZWQgaW4gdGhlIGNo YXJ0ZXIuIFdlIGFzIGEgZ3JvdXAgaGF2ZSB0byBkZWZpbmUgdGhlIHJlcXVpcmVtZW50LiBIb3dl dmVyLCB0aGVyZSBpcyBvZiBjb3Vyc2UgYW4gaW1wbGljaXQgcmVxdWlyZW1lbnQgZm9yIGFsbCB3 b3JrIGluIHRoZQ0KIElFRlQgdGhhdCBpcyBtdXN0IGJlIGRlcGxveWFibGUgYW5kIHNlcnZlIHRo ZSBuZWVkcyBvZiB0aG9zZSBwZW9wbGUgd2hvIHdhbnQgdG8gZGVwbG95IGl0Ljxicj4NCjxicj4N ClllcyAtIGEgZGlzY3Vzc2lvbiB0aGF0IEknbSB0cnlpbmcgdG8gZHJhdyBvdXQuIFRoYW5rcy48 YnI+DQo8YnI+DQo8YnI+DQomZ3Q7Jmd0OyBUaGF0IGJlaW5nIHRoZSBjYXNlLCBJIHRoaW5rIHdl IG5lZWQgdG8gYXNrIG91cnNlbHZlcyBpZiB3ZSBiZWxpZXZlIHRoYXQgaW5jbHVzaW9uIG9mIFBS IzEwNzkgd2lsbCBzaWduaWZpY2FudGx5IGluaGliaXQgZGVwbG95bWVudCBvZiB0aGUgcHJvdG9j b2wuIEJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIHNvIGZhciwgdGhhdCBkb2Vzbid0IHNlZW0gdG8g YmUgdGhlIGNhc2UsIGJ1dCBJJ2QgYmUgaW50ZXJlc3RlZCB0byBoZWFyIHdoYXQgb3RoZXJzDQog dGhpbmsuPGJyPg0KJmd0Ozxicj4NCiZndDsgSGVyZSBteSBhc3Nlc3NtZW50IGlzIGFsc28gZGlm ZmVyZW50LiBUaGVyZSBhcmUgbXVsdGlwbGUgcGVvcGxlIHRoYXQgaGF2ZSByYWlzZWQgY29uY2Vy bnMgdGhhdCB0aGlzIGNvdWxkIGhpbmRlciBkZXBsb3ltZW50Ljxicj4NCjxicj4NCkFzIHlvdSBr bm93LCB3ZSBkb24ndCBhc3Nlc3MgY29uc2Vuc3VzIGp1c3QgYnkgdGhlIG51bWJlciBvZiBwZW9w bGUgdGhhdCBoYXZlIHJhaXNlZCBjb25jZXJucywgYnV0IGFsc28gdGhlIHRlY2huaWNhbCBtZXJp dCBvZiB0aGUgYXJndW1lbnRzLiBTbyBmYXIsIHRoZSBhcmd1bWVudHMgaGF2ZSBiZWVuIGFsbCBv dmVyIHRoZSBtYXAsIGFuZCBJIHdhbnQgdGhlbSB0byBjb252ZXJnZS48YnI+DQo8YnI+DQpUaGUg ZGF0YSB0aGF0J3MgYmVlbiBwcm92aWRlZCBoYXMgYmVlbiB2ZXJ5IGhlbHBmdWwsIGJ1dCB3ZSBu ZWVkIHRvIGV2YWx1YXRlIHRoYXQgaW4gdGhlIGNvbnRleHQgb2YgaG93IFFVSUN2MSB3aWxsIGFj dHVhbGx5IGJlIGRlcGxveWVkIGFuZCB1c2VkIC0tIHNvbWV0aGluZyB3aGljaCBhIGZldyB0aHJl YWRzIGhhdmUgdG91Y2hlZCB1cG9uLjxicj4NCjxicj4NCk92ZXJhbGwsIEkgZG8gbm90IHRoaW5r IGl0IGlzIGEgZ29hbCBvZiBRVUlDIHRvIGJlIGRlcGxveWFibGUgb24gYW55IHN5c3RlbSBmb3Ig YW55IHB1cnBvc2U7IGlmIHdlIHRyeSB0byBkZXNpZ24gaXQgZm9yIGFsbCBwdXJwb3Nlcywgd2Un cmUgZ29pbmcgdG8gZmFpbC4gVGhlIHF1ZXN0aW9uLCB0aGVuLCBpcyBob3cgbXVjaCBkZXBsb3lt ZW50IC8gaW1wbGVtZW50YXRpb24gLyBhZG9wdGlvbiB3ZSBuZWVkIHRvIG1ha2UgaXQgc3VjY2Vl ZCAtLSBhbmQNCiB0byBkZXNpZ24gZm9yIHRoYXQuPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyZndDsg SWYgd2UgY2FuIGdldCB0byBjb25zZW5zdXMgdG8gaW5jb3Jwb3JhdGUgdGhlIFBSLCBhbmQgZm9s a3MgY29tZSBiYWNrIGxhdGVyIHdpdGggYSBtb3JlIGhhcmR3YXJlLWZyaWVuZGx5IHJlcGxhY2Vt ZW50IHRoYXQgZG9lc24ndCBjaGFuZ2UgdGhlIEludmFyaWFudHMgb3IgaW5jcmVhc2UgbGlua2Fi aWxpdHksIEkgc3VzcGVjdCB0aGUgV0cgd2lsbCBiZSBhbWVuYWJsZSB0byB0aGF0Ljxicj4NCiZn dDs8YnI+DQomZ3Q7IEkgZG9u4oCZdCB0aGluayB0byBqdXN0IGdvIHdpdGggd2hhdCB3ZSBoYXZl IGV2ZW4gdGhvdWdoIHRoZXJlIGFyZSBjb25jZXJucywgaXMgdGhlIHJpZ2h0IGFwcHJvYWNoIGFu ZCBkZWZpbml0ZWx5IG5vdCB0aGUgYXBwcm9hY2ggdGhhdCB3YXMgY2hvc2VuIGZvciBvdGhlciBw cm9wb3NhbHMuIEluIHRoZSBzYWtlIG9mIGdldHRpbmcgdmVyc2lvbiB2MSBvdXQgcXVpY2tseSwg SSB3b3VsZCB0aGluayB0aGF0IG5vdCBpbmNvcnBvcmF0aW5nIGFub3RoZXINCiBjaGFuZ2UgdGhh dCBkb2VzIG5vdCBoYXZlIGNvbnNlbnN1cyBpcyB0aGUgcHJvcG9zZXIgYXBwcm9hY2guPGJyPg0K PGJyPg0KSSB3YXNuJ3QgcHJvcG9zaW5nIHRoYXQgd2UgaW5jb3Jwb3JhdGUgYSBjaGFuZ2Ugd2l0 aG91dCBjb25zZW5zdXMgLS0gcGxlYXNlIHJlLXJlYWQgbXkgc3RhdGVtZW50LiBZb3UgbWF5IGRp c2FncmVlIHdpdGggaG93IHRoZSBjaGFpcnMgZXZlbnR1YWxseSBjYWxsIGNvbnNlbnN1cyBvbiB0 aGlzIGlzc3VlLCBhbmQgdGhlcmUgYXJlIG1lY2hhbmlzbXMgZm9yIHlvdSB0byBhcHBlYWwgKG9y IGV2ZW4gRElTQ1VTUykgdGhhdCwgYnV0IGl0J3MgcHJlbWF0dXJlDQogdG8gc3RhcnQgdGhhdCBu b3cuPGJyPg0KPGJyPg0KVGhhdCBzYWlkIC0tIE9uZSB3YXkgdG8gcHJvdmUgdGhhdCBQTkUgaHVy dHMgZGVwbG95YWJpbGl0eSBpcyB0byB0cnkgaXQ7IGltcGxlbWVudGVycyBoYXZlIGEgdmVyeSBz dHJvbmcgaW5jZW50aXZlIHRvIG1ha2Ugc3VyZSB0aGVpciBjb2RlIGNhbiBiZSBkZXBsb3llZCwg c28gaWYgdGhvc2Ugd2hvIGhhdmUgY29uY2VybnMgYXJlIGNvcnJlY3QsIGl0J3MgcHJvYmFibHkg dGhlIGVhc2llc3Qgd2F5IGZvciB0aGVtIHRvIGJlIHByb3ZlbiByaWdodC48YnI+DQo8YnI+DQpU aGFua3MsPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBNaXJqYTxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2hhdCBkbyBmb2xrcyB0aGluaz88 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9uIDI5IE1hciAyMDE4LCBhdCAxMTozOSBhbSwgSWFu IFN3ZXR0ICZsdDtpYW5zd2V0dD08YSBocmVmPSJtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZn dDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFRoYW5rcyBmb3Ig dGhlIG5pY2Ugc3VtbWFyeSBKYW5hLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyBBcyBtdWNoIGFzIEknZCBsb3ZlIHRvIGhhdmUgZWFzaWVyIGNyeXB0byBIVyBhY2NlbGVyYXRp b24sIEkndmUgZW5kZWQgdXAgYXJyaXZpbmcgYXQgdGhlIHNhbWUgY29uY2x1c2lvbi4mbmJzcDsg SSBkb24ndCB3YW50IHRvIGJpdGUgb2ZmIHRoZSB3b3JrIHRvIGRvIHByb3BlciBtdWx0aXBhdGgg aW4gUVVJQyB2MSwgd2hpY2ggSSB0aGluayBpcyB0aGUgb25seSBvdGhlciByZWFzb25hYmxlIG9w dGlvbiBvZiB0aG9zZSBDaHJpc3RpYW4gb3V0bGluZWQuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7IElmIHNvbWVvbmUgY29tZXMgdXAgd2l0aCBhIHdheSB0byB0cmFuc2Zvcm0g cGFja2V0IG51bWJlciB0byBtYWtlIGl0IG5vbi1saW5rYWJsZSwgYnV0IGRvZXNuJ3QgaGF2ZSB0 aGUgZG93bnNpZGUgb2YgbWFraW5nIGhhcmR3YXJlIG9mZmxvYWQgZGlmZmljdWx0LCB0aGVuIEkn bSBvcGVuIHRvIGl0LiZuYnNwOyBCdXQgd2UndmUgYmVlbiB0YWxraW5nIGFib3V0IHRoaXMgZm9y IDIgbW9udGhzIHdpdGhvdXQgYW55IG5vdGFibGUgaW1wcm92ZW1lbnRzDQogb3ZlciBNYXJ0aW4n cyBQUi48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgR2l2ZW4gd2UgbmV2ZXIg dGFsayBhYm91dCBhbnkgaXNzdWUgb25seSBvbmNlIGluIFFVSUMsIEknbSBzdXJlIHRoaXMgd2ls bCBjb21lIHVwIGFnYWluLCBidXQgZm9yIHRoZSB0aW1lIGJlaW5nIEkgdGhpbmsgIzEwNzkgaXMg dGhlIGJlc3Qgb3B0aW9uIHdlIGhhdmUuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9uIFdlZCwgTWFyIDI4LCAy MDE4IGF0IDg6MDMgUE0gSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpLmlldGZA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+anJpLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KJmd0OyZndDsmZ3Q7IEEgZmV3IHF1aWNrIHRob3VnaHRzIGFzIEkgY2F0Y2ggdXAg b24gdGhpcyB0aHJlYWQuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEkgc3Bl bnQgc29tZSB0aW1lIGxhc3Qgd2VlayB3b3JraW5nIHRocm91Z2ggYSBkZXNpZ24gdXNpbmcgbXVs dGlwbGUgUE4gc3BhY2VzLCBhbmQgaXQgaXMgcXVpdGUgZG9hYmxlLiBJIHN1c3BlY3Qgd2UnbGwg aGVhZCB0b3dhcmRzIG11bHRpcGxlIFBOIHNwYWNlcyBhcyB3ZSBjb25zaWRlciBtdWx0aXBhdGgg aW4gdGhlIGZ1dHVyZS4gVGhhdCBzYWlkLCB0aGVyZSBpcyBjb21wbGV4aXR5IChhcyBDaHJpc3Rp YW4gbm90ZXMpLiBUaGlzIGNvbXBsZXhpdHkNCiBtYXkgYmUgd2FycmFudGVkIHdoZW4gZG9pbmcg bXVsdGlwYXRoIGluIHYyIG9yIGxhdGVyLCBidXQgSSdtIG5vdCBjb252aW5jZWQgdGhhdCB0aGlz IGlzIG5lY2Vzc2FyeSBhcyBhIGRlc2lnbiBwcmltaXRpdmUgZm9yIFFVSUN2MS48YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgV2UgbWF5IHdhbnQgdG8gY3JlYXRpdmVseSB1c2Ug dGhlIFBOIGJpdHMgaW4gdjIsIHNheSB0byBlbmNvZGUgYSBwYXRoIElEIGFuZCBhIFBOLCBmb3Ig bXVsdGlwYXRoLiBXZSB3YW50IHRvIHJldGFpbiBmbGV4aWJpbGl0eSBpbiB0aGVzZSBiaXRzIGdv aW5nIGludG8gdjIuIFdlJ3ZlIHVzZWQgZW5jcnlwdGlvbiB0byBlbnN1cmUgdGhhdCB3ZSBkb24n dCBsb3NlIGZsZXhpYmlsaXR5IGVsc2V3aGVyZSBpbiB0aGUgaGVhZGVyLCBhbmQgaXQgZm9sbG93 cw0KIHRoYXQgd2Ugc2hvdWxkIHVzZSBQTkUgdG8gcmV0YWluIGZsZXhpYmlsaXR5IGluIHRoZXNl IGJpdHMgYXMgd2VsbC4gKFNpbXBsaWNpdHkgb2YgZGVzaWduIGlzIHRoZSBvdGhlciB2YWx1ZSBp biB1c2luZyBQTkUsIHNpbmNlIGhhbmRsaW5nIG1pZ3JhdGlvbiBsaW5rYWJpbGl0eSBpcyBub24t dHJpdmlhbCB3aXRob3V0IGl0Lik8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg VGhpcyBsZWF2ZXMgdGhlIHF1ZXN0aW9uIG9mIEhXIGFjY2VsZXJhdGlvbiBiZWluZyBhdCBsb2dn ZXJoZWFkcyB3aXRoIHRoZSBkZXNpZ24gaW4gUFIgIzEwNzkuIEZpcnN0LCBJIGV4cGVjdCB0aGF0 IHRoZSBwcmltYXJ5IGJlbmVmaXQgb2YgYWNjZWxlcmF0aW9uIHdpbGwgYmUgaW4gREMgZW52aXJv bm1lbnRzLiBZZXMsIHRoZXJlIGFyZSBzb21lIGdhaW5zIHRvIGJlIGhhZCBpbiBzZXJ2aW5nIHRo ZSBwdWJsaWMgSW50ZXJuZXQgYXMgd2VsbCwNCiBidXQgSSdtIHVuY29udmluY2VkIHRoYXQgdGhp cyBpcyB0aGUgZHJpdmluZyB1c2UgY2FzZSBmb3IgaGFyZHdhcmUgYWNjZWxlcmF0aW9uLiBJIHVu ZGVyc3RhbmQgdGhhdCBvdGhlcnMgbWF5IGRpc2FncmVlIHdpdGggbWUgaGVyZS48YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQUZBSUssIFFVSUMgaGFzIG5vdCBiZWVuIHVzZWQg aW4gREMgZW52aXJvbm1lbnRzIHlldC4gSSBleHBlY3QgdGhlcmUgYXJlIG90aGVyIHRoaW5ncyBp biB0aGUgcHJvdG9jb2wgdGhhdCB3ZSdkIHdhbnQgdG8gY2hhbmdlIGFzIHdlIGdhaW4gZXhwZXJp ZW5jZSBkZXBsb3lpbmcgUVVJQyBpbiBEQ3MuIFNwaW5uaW5nIHVwIGEgbmV3IHZlcnNpb24gdG8g dHJ5IFFVSUMgd2l0aGluIERDcyBpcyBub3Qgb25seSBhcHByb3ByaWF0ZSwgSSB3b3VsZA0KIHJl Y29tbWVuZCBpdC4gVGhpcyBhbGxvd3MgZm9yIHJhcGlkIGl0ZXJhdGlvbnMgaW50ZXJuYWxseSwg YW5kIHRoZSBleHBlcmllbmNlIGNhbiBkcml2ZSBzdWJzZXF1ZW50IGNoYW5nZXMgdG8gUVVJQy4g SXQncyB3aGF0ICpJKiB3b3VsZCBkbyBpZiBJIHdhcyB0byBkZXBsb3kgUVVJQyBpbnNpZGUgYSBE Qy48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgU28sIGluIHNob3J0LCBJIHRo aW5rIHdlIHNob3VsZCBnbyBhaGVhZCB3aXRoIFBSIyAxMDc5LiBUaGlzIGVuc3VyZXMgdGhhdCBm dXR1cmUgdmVyc2lvbnMgYXJlIGd1YXJhbnRlZWQgdGhlIGZsZXhpYmlsaXR5IHRvIGNoYW5nZSB0 aGUgUE4gYml0cyBmb3IgYmV0dGVyIHN1cHBvcnQgb2YgSFcgYWNjZWxlcmF0aW9uIG9yIG11bHRp cGF0aCBvciB3aGF0LWhhdmUteW91Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyAtIGphbmE8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT24gTWFyIDI2LCAy MDE4IDk6NDEgQU0sICZxdW90O0NocmlzdGlhbiBIdWl0ZW1hJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh1aXRlbWFAaHVpdGVt YS5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg T24gMy8yNi8yMDE4IDg6MjAgQU0sIFN3aW5kZWxscywgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJy aWRnZSkgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBMb29raW5nIGF0IDxhIGhyZWY9Imh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGZW4ud2lraXBlZGlhLm9yZyUyRndpa2klMkZBRVNfaW5zdHJ1Y3Rpb25fc2V0JTIzSW50 ZWxfYW5kX0FNRF94ODZfYXJjaGl0ZWN0dXJlJmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1p Y3Jvc29mdC5jb20lN0NhZDI2ZjUyZDlkMWE0MjYwYjY5MzA4ZDU5YTc1MzI4NSU3QzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY1ODQ3NTA1MzAwMzMzMjUmYW1w O3NkYXRhPXlHcVdiQk1NOTh0SDVBMjJrQlc0S1pGaHh4QmdiRGg0NE15Q0tRT1JORDAlM0QmYW1w O3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93 aWtpL0FFU19pbnN0cnVjdGlvbl9zZXQjSW50ZWxfYW5kX0FNRF94ODZfYXJjaGl0ZWN0dXJlPC9h PiBpdCBzZWVtcyB0byBpbXBseSBhIGxhcmdlIHJhbmdlIG9mIHNlcnZlciwgZGVza3RvcCBhbmQg bW9iaWxlIGNoaXBzIGFsbCBoYXZlIGEgQ1BVIGluc3RydWN0aW9uIHNldCBhdmFpbGFibGUgdG8g ZG8gQUVTIGFjY2VsZXJhdGlvbiBhbmQgb3RoZXIgc2ltaWxhciBvcGVyYXRpb25zIChvdGhlciBp bnN0cnVjdGlvbg0KIHNldHMgYXJlIGFsc28gYXZhaWxhYmxlKS48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJZiB3ZSBhcmUgY29uc2lkZXJpbmcgdGhlIEFFUyBp bnN0cnVjdGlvbnMgdGhlbiBpdCBsb29rcyBsaWtlIGl0IGlzIChvciBhdCBsZWFzdCB3aWxsIGJl IGluIHRoZSBuZWFyIGZ1dHVyZSkgYSBzaXplYWJsZSBwcm9wb3J0aW9uIG9mIHRoZSBwdWJsaWMg aW50ZXJuZXQgaGF2ZSBpdCB0byBiZSB1c2VkLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQ2VydGFpbmx5LCBidXQgdGhhdCdzIG5vdCB0 aGUgY3VycmVudCBkZWJhdGUuIFBSICMxMDc5IGlzIGZ1bGx5IGNvbXBhdGlibGUgd2l0aCB1c2Ug b2YgdGhlIEFFUyBpbnN0cnVjdGlvbnMuIFRoZSBpc3N1ZSBvZiB0aGUgZGViYXRlIGlzIHRoYXQg dGhlIG1lY2hhbmlzbSBpbiBQUiAjMTA3OSByZXF1aXJlZCBkb3VibGUgYnVmZmVyaW5nLCBmaXJz dCBlbmNyeXB0IHRoZSBwYXlsb2FkLCB0aGVuIHVzZSB0aGUgcmVzdWx0IG9mIHRoZSBlbmNyeXB0 aW9uDQogdG8gZW5jcnlwdCB0aGUgUE4uIFRoaXMgaXMgbm90IGFuIGlzc3VlIGluIGEgc29mdHdh cmUgaW1wbGVtZW50YXRpb24gdGhhdCBjYW4gcmVhZGlseSBhY2Nlc3MgYWxsIGJ5dGVzIG9mIHRo ZSBwYWNrZXQgZnJvbSBtZW1vcnksIGJ1dCBpdCBtYXkgYmUgYW4gaXNzdWUgaW4gc29tZSBoYXJk d2FyZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhcmUgZGVzaWduZWQgdG8gZG8ganVzdCBvbmUgcGFz cyBvdmVyIHRoZSBkYXRhLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyAtLSBDaHJpc3RpYW4gSHVpdGVtYTxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgLS08YnI+DQomZ3Q7Jmd0OyBNYXJrIE5vdHRpbmdoYW0mbmJzcDsgJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ3d3cubW5vdC5uZXQlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9z b2Z0LmNvbSU3Q2FkMjZmNTJkOWQxYTQyNjBiNjkzMDhkNTlhNzUzMjg1JTdDNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjU4NDc1MDUzMDAzMzMyNSZhbXA7c2Rh dGE9WmRTVlVsUkdlUWU4NWoyRHpXbUc4SklNVFZ1MGtDS1hWJTJCTUlabzk5aDBRJTNEJmFtcDty ZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cubW5vdC5uZXQvPC9hPjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0Ozxicj4NCjxicj4NCi0tPGJyPg0KTWFyayBOb3R0aW5naGFtJm5i c3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lm1ub3QubmV0JTJGJmFtcDtkYXRhPTAyJTdD MDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0NhZDI2ZjUyZDlkMWE0MjYwYjY5MzA4ZDU5YTc1 MzI4NSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY1ODQ3 NTA1MzAwMzMzMjUmYW1wO3NkYXRhPVpkU1ZVbFJHZVFlODVqMkR6V21HOEpJTVRWdTBrQ0tYViUy Qk1JWm85OWgwUSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 Lm1ub3QubmV0LzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB0630FA0EDD343396AD414641B6A40CY4PR21MB0630namp_-- From nobody Wed Apr 4 16:22:50 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0712312D86C for ; Wed, 4 Apr 2018 16:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522884152; bh=KUg6pbGIZTovTma/ezuehJTWMlsSuX4JT2igMq1o+g0=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=w/XVYggDJ1HJKZ98v6Cx2SOZRTJFyE4MAamrw4uAeVAGvDnN4YcbejHPR6QgPktjs d/yfBpr2kQbqUeKfOSwCC7w4Ju3W6SpGb0Zqf3Ox9HNGnk8BukVKeic/SGej3tvEjG iv27btt5ptP3FIejVvpINUPLoiiR94Tr1XB4rkqM= X-Mailbox-Line: From pravb@microsoft.com Wed Apr 4 16:22:31 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CDE126FB3; Wed, 4 Apr 2018 16:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522884151; bh=KUg6pbGIZTovTma/ezuehJTWMlsSuX4JT2igMq1o+g0=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=ShEiaK8TsAzzlVcRSR7opvPWGMu6MOnXOZdM1xkmL9nPm4tNMgZV1vyS06lT/JVmv G/Zb3DfsBroCyqIZrsORZORKeo6WRq3cZIeHFPhuCI+NHaRTF+XtNBQjn/E5OBzhnm kzJda6X2hAWCPs/lgxH2mMWoY6XJivYtiA8Yvn6c= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85596126C2F for ; Wed, 4 Apr 2018 16:22: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=unavailable 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 F1_zN42vYOYn for ; Wed, 4 Apr 2018 16:22:28 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe41::710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969C3127909 for ; Wed, 4 Apr 2018 16:22: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=KUg6pbGIZTovTma/ezuehJTWMlsSuX4JT2igMq1o+g0=; b=bZfzWhbcmfV1S+i3PXLITzlSVSg8Xdkn0yJpuh8LTQKQZN51ufTemIePXit6Dk7WF9pW3KOdNZyAsm4c2RDEc4ML5OjmYqTXu5iQCni9I0OAQRoRJx5a5lN3GDSFtVtQZeJUgoCKVjNUtV8uvm96JlOvfHW3SO0Q5ya2YY5V6gw= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0182.namprd21.prod.outlook.com (10.173.193.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 23:22:25 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 23:22:25 +0000 From: Praveen Balasubramanian CC: Lars Eggert , IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwZ0sAgAC4ugCAAARcAIAAFTbw Date: Wed, 4 Apr 2018 23:22:25 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0182; 7:9nf6/sJUZp0KUsQH/iOwpayEYC/FmLXt0f7n5liPPJX1L9HcWE/ABKrQCu1VFksD9dFEb8xckmBuEYvq//i6i1h1D77idLNUI72Q8t8txyIbdctV3dX03sicZsQvnCresTf4Q6VtDfzjOa2B0k+pJa/VWewjdCxU9aOqfkLvegdacNMwl7UJ+LCbFA/wHI5gDqy81jaOQ1ds4K2VF0wa5yzhHToBfzisVIeABK1zBXv20/jBh17vuV/D4PqxnsLY; 20:x/VthzGyvQZowzWUSSD5g/WCDNPbmqKbQPt5H0jUWsVD6Ce7CuUmPbf4Qzjw5xKxhF2MN9uiMvqkJbf3mHZz/lZZp8BKEEhIe0caaLgAjLmnLmy/zTXhlT9Oqr0W3j1fZd47EiinNj+bOwbtJgnj/ssKShiR3Jd1iYgZXIJRe7A= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fc0f8b5d-7f4c-4612-ce18-08d59a82eceb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0182; x-ms-traffictypediagnostic: CY4PR21MB0182: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(189930954265078)(85827821059158)(100405760836317)(219752817060721)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0182; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0182; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39380400002)(376002)(396003)(39860400002)(189003)(51914003)(199004)(51444003)(53754006)(25786009)(186003)(33656002)(316002)(106356001)(59450400001)(53546011)(93886005)(561944003)(6506007)(22452003)(102836004)(6436002)(966005)(14454004)(606006)(105586002)(478600001)(81166006)(86362001)(236005)(97736004)(8936002)(6246003)(53936002)(9686003)(55016002)(6306002)(54896002)(7736002)(476003)(5660300001)(74316002)(81156014)(229853002)(8990500004)(11346002)(8676002)(10290500003)(446003)(4326008)(99286004)(54906003)(10090500001)(486006)(3660700001)(86612001)(68736007)(6116002)(110136005)(2906002)(19609705001)(46003)(3280700002)(5250100002)(790700001)(2900100001)(7696005)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0182; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: lD3fPuIRDZPJOZ0/Nzj88aowW+9qOTkCLQVaXiNczAAHa5h5owWjJdg5NQCYI2CgINq40RYT+pSaU7/ZsnH2+ON/PSIc5u2rYzbQkfPUqR5GdeWG1ezZQM3D2Eb10qgIEBc6IQdSsIF3FwIFxVUusGiNdhltZt3RPw3VQV90jrFtcuvq0mIvHx+3LQ35h150Nntf1xwwu3Ke+cFMIHwlzMDUpe+sB8TGXGcGaiwmSZGfzJo2BXtHh5460ZRYn5kU7y/BoHA7n2vlmezOF9pf+doONEr2DsPrbM0rfk6D15Vy4oh0Y+/gwUfvd+Be2PPeZ2gJdGgpvl+L8QAJDYn3EX/KySTl6qR8Q303jW0+jze67hyamsDKTP2rJH//MfTW0Rm6N01Yk0NEh5eLL9qE3j8BSkJQRDxdc/rMrTUDNnA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630FA0EDD343396AD414641B6A40CY4PR21MB0630namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc0f8b5d-7f4c-4612-ce18-08d59a82eceb X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 23:22:25.3155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0182 To: Ian Swett To: Mark Nottingham Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 23:22:32 -0000 X-List-Received-Date: Wed, 04 Apr 2018 23:22:32 -0000 --_000_CY4PR21MB0630FA0EDD343396AD414641B6A40CY4PR21MB0630namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UE5FIGlzIG9uZSB3YXkgZm9yd2FyZCBmb3IgZG9pbmcgY29ubmVjdGlvbiBtaWdyYXRpb24gd2l0 aG91dCBsaW5rYWJpbGl0eS4gSSB3b3VsZG7igJl0IGNhbGwgaXQgdGhlIG1vc3QgcHJhZ21hdGlj IHNpbmNlIGl0IGhhcyBwZXJmb3JtYW5jZSBpbXBsaWNhdGlvbnMuDQoNCkFueSBvYmplY3Rpb25z IHRvIHRoZSBmb2xsb3dpbmc/DQoNCjEuIExlYXZlIHRoZSBjdXJyZW50IGRyYWZ0IGFzIGlzIGZv ciB0aGUgY29tbW9uIGNhc2UgKG5vIG1pZ3JhdGlvbiBubyBtdWx0aXBhdGgpLiBNYWtlIHN1cmUg d2UgaGF2ZSBzb21lIHByb3Zpc2lvbiBmb3IgZ3JlYXNpbmcgdGhlIFBOIHRvIHByZXZlbnQgb3Nz aWZpY2F0aW9uLiBJZiBQTiBqdW1wcyBhcmUgbmVlZGVkIGZvciB0aGlzIChhcGFydCBmcm9tIGEg cmFuZG9tIHN0YXJ0aW5nIFBOKSB3ZSBzaG91bGQgaGF2ZSBhIFBSIG1vZGlmeWluZyBjdXJyZW50 IGRyYWZ0Lg0KDQoyLiBGb3IgY29ubmVjdGlvbiBtaWdyYXRpb24gdGhlIG9wdGlvbnMgYXJlOg0K DQphLiBFeHBsb3JlIG11bHRpcGxlIFBOIHNwYWNlcyBmb3IgY29ubmVjdGlvbiBtaWdyYXRpb24g KGFuZCBldmVudHVhbGx5IG11bHRpcGF0aCksIE9SDQoNCmIuIE1ha2UgUE5FIChhbmQgaGVuY2Ug Y29ubmVjdGlvbiBtaWdyYXRpb24pIGFuIG9wdGlvbmFsIG5lZ290aWF0ZWQgZXh0ZW5zaW9uIGlu IFYxIHdpdGggdGhlIGNhdmVhdCB0aGF0IHdlIHdpbGwgIHJldmlzaXQgdGhpcyAgZm9yIFYyIHdo ZW4gd2UgZG8gbXVsdGlwYXRoLiBUaGlzIGlzIHJlcXVpcmVkIGFueXdheXMgYmVjYXVzZSBzZXJ2 ZXJzIG11c3QgYmUgYWJsZSB0byB0ZWxsIGNsaWVudCB0aGF0IHRoZXkgY2Fubm90IHN1cHBvcnQg bWlncmF0aW9uIHNpbmNlIHRoZXkgYXJlIGJlaGluZCBhIGxlZ2FjeSBsb2FkIGJhbGFuY2VyLg0K DQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBJYW4gU3dldHQNClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxOCAyOjQ0IFBNDQpUbzog TWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0Pg0KQ2M6IExhcnMgRWdnZXJ0IDxsYXJzQGVn Z2VydC5vcmc+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNaXJqYSBLw7xobGV3aW5k IDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPg0KU3ViamVjdDogUmU6IEdldHRpbmcg dG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpBcyBleHByZXNzZWQg cHJldmlvdXNseSwgSSB0ZW5kIHRvIHRoaW5rIFBOIGVuY3J5cHRpb24gaXMgdGhlIG1vc3QgcHJh Z21hdGljIHdheSBmb3J3YXJkIGF0IHRoZSBtb21lbnQuDQoNCkhvd2V2ZXIsIGlzIGFueW9uZSB3 aG8gd291bGQgcHJlZmVyIGEgZGlmZmVyZW50IHNvbHV0aW9uKGllOiBwYWNrZXQgbnVtYmVyIGp1 bXBzIG9yIHNlcGFyYXRlIHNwYWNlcykgd2lsbGluZyB0byBzZW5kIG91dCBhIFBSIHRoZXkgdGhp bmsgc29sdmVzIHRoZSBsaW5rLWFiaWxpdHkgaXNzdWUgUE4gZW5jcnlwdGlvbiBzb2x2ZXM/DQoN Ck15IG1lbnRhbCBtb2RlbCBpcyB0aGVyZSBhcmUgYSBmYWlyIG51bWJlciBvZiB0aG9ybnkgZWRn ZSBjYXNlcywgYnV0IG1heWJlIGlmIEkgc2F3IHRoZW0gaW4gYSBQUiwgaXQgd291bGRuJ3QgYmUg YXMgc2NhcnkgYXMgSSB0aGluaz8NCg0KT24gV2VkLCBBcHIgNCwgMjAxOCBhdCA1OjI4IFBNIE1h cmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldDxtYWlsdG86bW5vdEBtbm90Lm5ldD4+IHdyb3Rl Og0KTWlyamEsDQoNCk9uIDQgQXByIDIwMTgsIGF0IDg6MjcgcG0sIE1pcmphIEvDvGhsZXdpbmQg PG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8bWFpbHRvOm1pcmphLi5rdWVobGV3aW5k QHRpay5lZS5ldGh6LmNoPj4gd3JvdGU6DQo+DQo+IEhpIE1hcmssDQo+DQo+IHdpdGhvdXQgaW50 ZW5kaW5nIHRvIHN0YXRlIGEgdGVjaG5pY2FsIG9waW5pb24sIEkgdGhpbmsgSSBuZWVkIHRvIGRp c2FncmVlIHdpdGggeW91ciBhc3Nlc3NtZW50IG9mIHRoZSBzaXR1YXRpb24uIFBsZWFzZSBzZWUg YmVsb3cuDQo+DQo+PiBBbSAwNC4wNC4yMDE4IHVtIDA2OjU4IHNjaHJpZWIgTWFyayBOb3R0aW5n aGFtIDxtbm90QG1ub3QubmV0PG1haWx0bzptbm90QG1ub3QubmV0Pj46DQo+Pg0KPj4gSGkgZXZl cnlvbmUsDQo+Pg0KPj4gVGhlIGVkaXRvcnMgaGF2ZSB0b2xkIHlvdXIgY2hhaXJzIHRoYXQgdGhp cyBpc3N1ZSBpcyBzdGFydGluZyB0byBibG9jayBwcm9ncmVzcyBvbiBvdGhlciBhc3BlY3RzIG9m IFFVSUMuIENvbWluZyB0byBjb25zZW5zdXMgb24gaXQgc29vbiAoaS5lLi4sIGJlZm9yZSBTdG9j a2hvbG0sIGlmIHBvc3NpYmxlKSB3b3VsZCBiZSBnb29kLg0KPj4NCj4+IEl0IGxvb2tzIGxpa2Ug dGhpcyB0aHJlYWQgaGFzIGNvbWUgdG8gYSBuYXR1cmFsIHBhdXNlLiBSZWFkaW5nIHRocm91Z2gg aXQsIEkgdGhpbmsgd2UgYWdyZWUgdGhlcmUgYXJlIHNvbWUgdW5wbGVhc2FudCB0cmFkZW9mZnMg aGVyZSwgYnV0IHNvIGZhciB3ZSBoYXZlIG9ubHkgb25lIGNvbmNyZXRlIHByb3Bvc2FsIC0tIFBS IzEwNzkuDQo+DQo+IFRoZSBvdGhlciBwcm9wb3NhbCBpcyB0byB1c2UgYSByYW5kb20gb2Zmc2V0 IHRoYXQgY2FuL3Nob3VsZCBiZSBjaGFuZ2VkIHdoZW4gdGhlIGNvbm5lY3Rpb24gSUQgaXMgY2hh bmdlZC4gV2hpY2ggaXMgbW9zdGx5IGlubGluZSB3aXRoIHdoYXQgdGhlIGRyYWZ0IGN1cnJlbnRs eSBzYXlzLg0KDQpBcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBzdGF0dXMgcXVvIGhhcyBjYXVzZWQg YSBzaWduaWZpY2FudCBhbW91bnQgb2YgcGFpbiwgY29tcGxleGl0eSBhbmQgcG90ZW50aWFsIGJ1 Z3MuIFBOIGVuY3J5cHRpb24gd2FzIHByb3Bvc2VkIGJ5IEthenVobyBpbiBNZWxib3VybmUgYXMg YSB3YXkgdG8gd29yayBhcm91bmQgdGhhdC4NCg0KV2UgY2FuLCBvZiBjb3Vyc2UsIGRlY2lkZSB0 aGF0IHRoZSBzdGF0dXMgcXVvIGlzIHRoZSByaWdodCBhcHByb2FjaC4gSG93ZXZlciwgbXkgY3Vy cmVudCByZWFkaW5nIG9mIHRoZSBXRyBpcyB0aGF0IGl0IGlzbid0IGFjY2VwdGFibGUuDQoNCg0K Pj4gTXkgQVUkLjA1IC0gV2hpbGUgd2UncmUgY2hhcnRlcmVkIHRvIHByb2R1Y2UgYSBwcm90b2Nv bCB0aGF0J3MgZW5jcnlwdGVkIGFzIG11Y2ggYXMgb3BlcmF0aW9uYWwgY29uY2VybnMgYWxsb3cs DQo+DQo+IEkgZG9u4oCZdCB0aGluayB0aGlzIGlzIHdoYXQgdGhlIGNoYXJ0ZXIgc2F5LiBUaGUg Y2hhcnRlciBzYXlzICJQcm92aWRpbmcgYWx3YXlzLXNlY3VyZSB0cmFuc3BvcnQsIHVzaW5nIFRM UyAxLjMgYnkgZGVmYXVsdC7igJwgcGx1cyBhbm90aGVyIHBhcmFncmFwaCB0aGF0IHRhbGtzIGFi b3V0IFRMUzEuMy4gSXQgZG9lcyBub3Qgc3BlbGwgb3V0IHRoZSBkZXNpcmUgb2Ygc29tZSBpbmRp dmlkdWFsIHRvIOKAnmVuY3J5cHQgYXMgbXVjaCBhcyBwb3NzaWJsZeKAnC4NCg0KSSB0aGluayB0 aGF0IGRlcGVuZHMgb24gaG93IHlvdSByZWFkICJhbHdheXMtc2VjdXJlLiIgVGhlIGNoYXJ0ZXIg YWxzbyBzYXlzIHdlIHdpbGwgcHJvdmlkZSAiY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkg cHJvdGVjdGlvbiBvZiBib3RoIGFwcGxpY2F0aW9uIGRhdGEgYW5kIFFVSUMgaGVhZGVycy4iDQoN Cg0KPj4gYW5kIHRoYXQgcHJpdmFjeSBpcyBhIG5hdHVyYWwgZXh0ZW5zaW9uIG9mIHRoYXQgKGVz cGVjaWFsbHkgaW4gbGlnaHQgb2YgUkZDNzI1OCBhbmQgUkZDNjk3MyksIHRoZXJlIGlzIG5vICpy ZXF1aXJlbWVudCogdGhhdCB3ZSBwcm9kdWNlIGEgcHJvdG9jb2wgdGhhdCBpcyBhYmxlIHRvIGJl IGFjY2VsZXJhdGVkIGJ5IGhhcmR3YXJlLg0KPg0KPiBOb3QgdGhlcmUgaXMgbm8gcmVxdWlyZW1l bnQgdGhhdCB0aGUgcHJvdG9jb2wgbmVlZCB0byBiZSBhY2NlbGVyYXRlZCBieSBoYXJkd2FyZS4g SG93ZXZlciwgbm90IGFsbCByZXF1aXJlbWVudCBhcmUgbGlzdGVkIGluIHRoZSBjaGFydGVyLiBX ZSBhcyBhIGdyb3VwIGhhdmUgdG8gZGVmaW5lIHRoZSByZXF1aXJlbWVudC4gSG93ZXZlciwgdGhl cmUgaXMgb2YgY291cnNlIGFuIGltcGxpY2l0IHJlcXVpcmVtZW50IGZvciBhbGwgd29yayBpbiB0 aGUgSUVGVCB0aGF0IGlzIG11c3QgYmUgZGVwbG95YWJsZSBhbmQgc2VydmUgdGhlIG5lZWRzIG9m IHRob3NlIHBlb3BsZSB3aG8gd2FudCB0byBkZXBsb3kgaXQuDQoNClllcyAtIGEgZGlzY3Vzc2lv biB0aGF0IEknbSB0cnlpbmcgdG8gZHJhdyBvdXQuIFRoYW5rcy4NCg0KDQo+PiBUaGF0IGJlaW5n IHRoZSBjYXNlLCBJIHRoaW5rIHdlIG5lZWQgdG8gYXNrIG91cnNlbHZlcyBpZiB3ZSBiZWxpZXZl IHRoYXQgaW5jbHVzaW9uIG9mIFBSIzEwNzkgd2lsbCBzaWduaWZpY2FudGx5IGluaGliaXQgZGVw bG95bWVudCBvZiB0aGUgcHJvdG9jb2wuIEJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIHNvIGZhciwg dGhhdCBkb2Vzbid0IHNlZW0gdG8gYmUgdGhlIGNhc2UsIGJ1dCBJJ2QgYmUgaW50ZXJlc3RlZCB0 byBoZWFyIHdoYXQgb3RoZXJzIHRoaW5rLg0KPg0KPiBIZXJlIG15IGFzc2Vzc21lbnQgaXMgYWxz byBkaWZmZXJlbnQuIFRoZXJlIGFyZSBtdWx0aXBsZSBwZW9wbGUgdGhhdCBoYXZlIHJhaXNlZCBj b25jZXJucyB0aGF0IHRoaXMgY291bGQgaGluZGVyIGRlcGxveW1lbnQuDQoNCkFzIHlvdSBrbm93 LCB3ZSBkb24ndCBhc3Nlc3MgY29uc2Vuc3VzIGp1c3QgYnkgdGhlIG51bWJlciBvZiBwZW9wbGUg dGhhdCBoYXZlIHJhaXNlZCBjb25jZXJucywgYnV0IGFsc28gdGhlIHRlY2huaWNhbCBtZXJpdCBv ZiB0aGUgYXJndW1lbnRzLiBTbyBmYXIsIHRoZSBhcmd1bWVudHMgaGF2ZSBiZWVuIGFsbCBvdmVy IHRoZSBtYXAsIGFuZCBJIHdhbnQgdGhlbSB0byBjb252ZXJnZS4NCg0KVGhlIGRhdGEgdGhhdCdz IGJlZW4gcHJvdmlkZWQgaGFzIGJlZW4gdmVyeSBoZWxwZnVsLCBidXQgd2UgbmVlZCB0byBldmFs dWF0ZSB0aGF0IGluIHRoZSBjb250ZXh0IG9mIGhvdyBRVUlDdjEgd2lsbCBhY3R1YWxseSBiZSBk ZXBsb3llZCBhbmQgdXNlZCAtLSBzb21ldGhpbmcgd2hpY2ggYSBmZXcgdGhyZWFkcyBoYXZlIHRv dWNoZWQgdXBvbi4NCg0KT3ZlcmFsbCwgSSBkbyBub3QgdGhpbmsgaXQgaXMgYSBnb2FsIG9mIFFV SUMgdG8gYmUgZGVwbG95YWJsZSBvbiBhbnkgc3lzdGVtIGZvciBhbnkgcHVycG9zZTsgaWYgd2Ug dHJ5IHRvIGRlc2lnbiBpdCBmb3IgYWxsIHB1cnBvc2VzLCB3ZSdyZSBnb2luZyB0byBmYWlsLiBU aGUgcXVlc3Rpb24sIHRoZW4sIGlzIGhvdyBtdWNoIGRlcGxveW1lbnQgLyBpbXBsZW1lbnRhdGlv biAvIGFkb3B0aW9uIHdlIG5lZWQgdG8gbWFrZSBpdCBzdWNjZWVkIC0tIGFuZCB0byBkZXNpZ24g Zm9yIHRoYXQuDQoNCg0KPj4gSWYgd2UgY2FuIGdldCB0byBjb25zZW5zdXMgdG8gaW5jb3Jwb3Jh dGUgdGhlIFBSLCBhbmQgZm9sa3MgY29tZSBiYWNrIGxhdGVyIHdpdGggYSBtb3JlIGhhcmR3YXJl LWZyaWVuZGx5IHJlcGxhY2VtZW50IHRoYXQgZG9lc24ndCBjaGFuZ2UgdGhlIEludmFyaWFudHMg b3IgaW5jcmVhc2UgbGlua2FiaWxpdHksIEkgc3VzcGVjdCB0aGUgV0cgd2lsbCBiZSBhbWVuYWJs ZSB0byB0aGF0Lg0KPg0KPiBJIGRvbuKAmXQgdGhpbmsgdG8ganVzdCBnbyB3aXRoIHdoYXQgd2Ug aGF2ZSBldmVuIHRob3VnaCB0aGVyZSBhcmUgY29uY2VybnMsIGlzIHRoZSByaWdodCBhcHByb2Fj aCBhbmQgZGVmaW5pdGVseSBub3QgdGhlIGFwcHJvYWNoIHRoYXQgd2FzIGNob3NlbiBmb3Igb3Ro ZXIgcHJvcG9zYWxzLiBJbiB0aGUgc2FrZSBvZiBnZXR0aW5nIHZlcnNpb24gdjEgb3V0IHF1aWNr bHksIEkgd291bGQgdGhpbmsgdGhhdCBub3QgaW5jb3Jwb3JhdGluZyBhbm90aGVyIGNoYW5nZSB0 aGF0IGRvZXMgbm90IGhhdmUgY29uc2Vuc3VzIGlzIHRoZSBwcm9wb3NlciBhcHByb2FjaC4NCg0K SSB3YXNuJ3QgcHJvcG9zaW5nIHRoYXQgd2UgaW5jb3Jwb3JhdGUgYSBjaGFuZ2Ugd2l0aG91dCBj b25zZW5zdXMgLS0gcGxlYXNlIHJlLXJlYWQgbXkgc3RhdGVtZW50LiBZb3UgbWF5IGRpc2FncmVl IHdpdGggaG93IHRoZSBjaGFpcnMgZXZlbnR1YWxseSBjYWxsIGNvbnNlbnN1cyBvbiB0aGlzIGlz c3VlLCBhbmQgdGhlcmUgYXJlIG1lY2hhbmlzbXMgZm9yIHlvdSB0byBhcHBlYWwgKG9yIGV2ZW4g RElTQ1VTUykgdGhhdCwgYnV0IGl0J3MgcHJlbWF0dXJlIHRvIHN0YXJ0IHRoYXQgbm93Lg0KDQpU aGF0IHNhaWQgLS0gT25lIHdheSB0byBwcm92ZSB0aGF0IFBORSBodXJ0cyBkZXBsb3lhYmlsaXR5 IGlzIHRvIHRyeSBpdDsgaW1wbGVtZW50ZXJzIGhhdmUgYSB2ZXJ5IHN0cm9uZyBpbmNlbnRpdmUg dG8gbWFrZSBzdXJlIHRoZWlyIGNvZGUgY2FuIGJlIGRlcGxveWVkLCBzbyBpZiB0aG9zZSB3aG8g aGF2ZSBjb25jZXJucyBhcmUgY29ycmVjdCwgaXQncyBwcm9iYWJseSB0aGUgZWFzaWVzdCB3YXkg Zm9yIHRoZW0gdG8gYmUgcHJvdmVuIHJpZ2h0Lg0KDQpUaGFua3MsDQoNCg0KPiBNaXJqYQ0KPg0K Pg0KPg0KPj4NCj4+IFdoYXQgZG8gZm9sa3MgdGhpbms/DQo+Pg0KPj4gQ2hlZXJzLA0KPj4NCj4+ DQo+Pj4gT24gMjkgTWFyIDIwMTgsIGF0IDExOjM5IGFtLCBJYW4gU3dldHQgPGlhbnN3ZXR0PTQw Z29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYu b3JnPj4gd3JvdGU6DQo+Pj4NCj4+PiBUaGFua3MgZm9yIHRoZSBuaWNlIHN1bW1hcnkgSmFuYS4N Cj4+Pg0KPj4+IEFzIG11Y2ggYXMgSSdkIGxvdmUgdG8gaGF2ZSBlYXNpZXIgY3J5cHRvIEhXIGFj Y2VsZXJhdGlvbiwgSSd2ZSBlbmRlZCB1cCBhcnJpdmluZyBhdCB0aGUgc2FtZSBjb25jbHVzaW9u LiAgSSBkb24ndCB3YW50IHRvIGJpdGUgb2ZmIHRoZSB3b3JrIHRvIGRvIHByb3BlciBtdWx0aXBh dGggaW4gUVVJQyB2MSwgd2hpY2ggSSB0aGluayBpcyB0aGUgb25seSBvdGhlciByZWFzb25hYmxl IG9wdGlvbiBvZiB0aG9zZSBDaHJpc3RpYW4gb3V0bGluZWQuDQo+Pj4NCj4+PiBJZiBzb21lb25l IGNvbWVzIHVwIHdpdGggYSB3YXkgdG8gdHJhbnNmb3JtIHBhY2tldCBudW1iZXIgdG8gbWFrZSBp dCBub24tbGlua2FibGUsIGJ1dCBkb2Vzbid0IGhhdmUgdGhlIGRvd25zaWRlIG9mIG1ha2luZyBo YXJkd2FyZSBvZmZsb2FkIGRpZmZpY3VsdCwgdGhlbiBJJ20gb3BlbiB0byBpdC4gIEJ1dCB3ZSd2 ZSBiZWVuIHRhbGtpbmcgYWJvdXQgdGhpcyBmb3IgMiBtb250aHMgd2l0aG91dCBhbnkgbm90YWJs ZSBpbXByb3ZlbWVudHMgb3ZlciBNYXJ0aW4ncyBQUi4NCj4+Pg0KPj4+IEdpdmVuIHdlIG5ldmVy IHRhbGsgYWJvdXQgYW55IGlzc3VlIG9ubHkgb25jZSBpbiBRVUlDLCBJJ20gc3VyZSB0aGlzIHdp bGwgY29tZSB1cCBhZ2FpbiwgYnV0IGZvciB0aGUgdGltZSBiZWluZyBJIHRoaW5rICMxMDc5IGlz IHRoZSBiZXN0IG9wdGlvbiB3ZSBoYXZlLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IE9uIFdlZCwgTWFy IDI4LCAyMDE4IGF0IDg6MDMgUE0gSmFuYSBJeWVuZ2FyIDxqcmkuaWV0ZkBnbWFpbC5jb208bWFp bHRvOmpyaS5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+IEEgZmV3IHF1aWNrIHRob3VnaHRz IGFzIEkgY2F0Y2ggdXAgb24gdGhpcyB0aHJlYWQuDQo+Pj4NCj4+PiBJIHNwZW50IHNvbWUgdGlt ZSBsYXN0IHdlZWsgd29ya2luZyB0aHJvdWdoIGEgZGVzaWduIHVzaW5nIG11bHRpcGxlIFBOIHNw YWNlcywgYW5kIGl0IGlzIHF1aXRlIGRvYWJsZS4gSSBzdXNwZWN0IHdlJ2xsIGhlYWQgdG93YXJk cyBtdWx0aXBsZSBQTiBzcGFjZXMgYXMgd2UgY29uc2lkZXIgbXVsdGlwYXRoIGluIHRoZSBmdXR1 cmUuIFRoYXQgc2FpZCwgdGhlcmUgaXMgY29tcGxleGl0eSAoYXMgQ2hyaXN0aWFuIG5vdGVzKS4g VGhpcyBjb21wbGV4aXR5IG1heSBiZSB3YXJyYW50ZWQgd2hlbiBkb2luZyBtdWx0aXBhdGggaW4g djIgb3IgbGF0ZXIsIGJ1dCBJJ20gbm90IGNvbnZpbmNlZCB0aGF0IHRoaXMgaXMgbmVjZXNzYXJ5 IGFzIGEgZGVzaWduIHByaW1pdGl2ZSBmb3IgUVVJQ3YxLg0KPj4+DQo+Pj4gV2UgbWF5IHdhbnQg dG8gY3JlYXRpdmVseSB1c2UgdGhlIFBOIGJpdHMgaW4gdjIsIHNheSB0byBlbmNvZGUgYSBwYXRo IElEIGFuZCBhIFBOLCBmb3IgbXVsdGlwYXRoLiBXZSB3YW50IHRvIHJldGFpbiBmbGV4aWJpbGl0 eSBpbiB0aGVzZSBiaXRzIGdvaW5nIGludG8gdjIuIFdlJ3ZlIHVzZWQgZW5jcnlwdGlvbiB0byBl bnN1cmUgdGhhdCB3ZSBkb24ndCBsb3NlIGZsZXhpYmlsaXR5IGVsc2V3aGVyZSBpbiB0aGUgaGVh ZGVyLCBhbmQgaXQgZm9sbG93cyB0aGF0IHdlIHNob3VsZCB1c2UgUE5FIHRvIHJldGFpbiBmbGV4 aWJpbGl0eSBpbiB0aGVzZSBiaXRzIGFzIHdlbGwuIChTaW1wbGljaXR5IG9mIGRlc2lnbiBpcyB0 aGUgb3RoZXIgdmFsdWUgaW4gdXNpbmcgUE5FLCBzaW5jZSBoYW5kbGluZyBtaWdyYXRpb24gbGlu a2FiaWxpdHkgaXMgbm9uLXRyaXZpYWwgd2l0aG91dCBpdC4pDQo+Pj4NCj4+PiBUaGlzIGxlYXZl cyB0aGUgcXVlc3Rpb24gb2YgSFcgYWNjZWxlcmF0aW9uIGJlaW5nIGF0IGxvZ2dlcmhlYWRzIHdp dGggdGhlIGRlc2lnbiBpbiBQUiAjMTA3OS4gRmlyc3QsIEkgZXhwZWN0IHRoYXQgdGhlIHByaW1h cnkgYmVuZWZpdCBvZiBhY2NlbGVyYXRpb24gd2lsbCBiZSBpbiBEQyBlbnZpcm9ubWVudHMuIFll cywgdGhlcmUgYXJlIHNvbWUgZ2FpbnMgdG8gYmUgaGFkIGluIHNlcnZpbmcgdGhlIHB1YmxpYyBJ bnRlcm5ldCBhcyB3ZWxsLCBidXQgSSdtIHVuY29udmluY2VkIHRoYXQgdGhpcyBpcyB0aGUgZHJp dmluZyB1c2UgY2FzZSBmb3IgaGFyZHdhcmUgYWNjZWxlcmF0aW9uLiBJIHVuZGVyc3RhbmQgdGhh dCBvdGhlcnMgbWF5IGRpc2FncmVlIHdpdGggbWUgaGVyZS4NCj4+Pg0KPj4+IEFGQUlLLCBRVUlD IGhhcyBub3QgYmVlbiB1c2VkIGluIERDIGVudmlyb25tZW50cyB5ZXQuIEkgZXhwZWN0IHRoZXJl IGFyZSBvdGhlciB0aGluZ3MgaW4gdGhlIHByb3RvY29sIHRoYXQgd2UnZCB3YW50IHRvIGNoYW5n ZSBhcyB3ZSBnYWluIGV4cGVyaWVuY2UgZGVwbG95aW5nIFFVSUMgaW4gRENzLiBTcGlubmluZyB1 cCBhIG5ldyB2ZXJzaW9uIHRvIHRyeSBRVUlDIHdpdGhpbiBEQ3MgaXMgbm90IG9ubHkgYXBwcm9w cmlhdGUsIEkgd291bGQgcmVjb21tZW5kIGl0LiBUaGlzIGFsbG93cyBmb3IgcmFwaWQgaXRlcmF0 aW9ucyBpbnRlcm5hbGx5LCBhbmQgdGhlIGV4cGVyaWVuY2UgY2FuIGRyaXZlIHN1YnNlcXVlbnQg Y2hhbmdlcyB0byBRVUlDLiBJdCdzIHdoYXQgKkkqIHdvdWxkIGRvIGlmIEkgd2FzIHRvIGRlcGxv eSBRVUlDIGluc2lkZSBhIERDLg0KPj4+DQo+Pj4gU28sIGluIHNob3J0LCBJIHRoaW5rIHdlIHNo b3VsZCBnbyBhaGVhZCB3aXRoIFBSIyAxMDc5LiBUaGlzIGVuc3VyZXMgdGhhdCBmdXR1cmUgdmVy c2lvbnMgYXJlIGd1YXJhbnRlZWQgdGhlIGZsZXhpYmlsaXR5IHRvIGNoYW5nZSB0aGUgUE4gYml0 cyBmb3IgYmV0dGVyIHN1cHBvcnQgb2YgSFcgYWNjZWxlcmF0aW9uIG9yIG11bHRpcGF0aCBvciB3 aGF0LWhhdmUteW91Lg0KPj4+DQo+Pj4gLSBqYW5hDQo+Pj4NCj4+PiBPbiBNYXIgMjYsIDIwMTgg OTo0MSBBTSwgIkNocmlzdGlhbiBIdWl0ZW1hIiA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86 aHVpdGVtYUBodWl0ZW1hLm5ldD4+IHdyb3RlOg0KPj4+DQo+Pj4gT24gMy8yNi8yMDE4IDg6MjAg QU0sIFN3aW5kZWxscywgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSkgd3JvdGU6DQo+Pj4+ IExvb2tpbmcgYXQgaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvQUVTX2luc3RydWN0aW9u X3NldCNJbnRlbF9hbmRfQU1EX3g4Nl9hcmNoaXRlY3R1cmU8aHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZlbi53aWtpcGVkaWEu b3JnJTJGd2lraSUyRkFFU19pbnN0cnVjdGlvbl9zZXQlMjNJbnRlbF9hbmRfQU1EX3g4Nl9hcmNo aXRlY3R1cmUmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDYWQyNmY1MmQ5 ZDFhNDI2MGI2OTMwOGQ1OWE3NTMyODUlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM2NTg0NzUwNTMwMDMzMzI1JnNkYXRhPXlHcVdiQk1NOTh0SDVBMjJrQlc0 S1pGaHh4QmdiRGg0NE15Q0tRT1JORDAlM0QmcmVzZXJ2ZWQ9MD4gaXQgc2VlbXMgdG8gaW1wbHkg YSBsYXJnZSByYW5nZSBvZiBzZXJ2ZXIsIGRlc2t0b3AgYW5kIG1vYmlsZSBjaGlwcyBhbGwgaGF2 ZSBhIENQVSBpbnN0cnVjdGlvbiBzZXQgYXZhaWxhYmxlIHRvIGRvIEFFUyBhY2NlbGVyYXRpb24g YW5kIG90aGVyIHNpbWlsYXIgb3BlcmF0aW9ucyAob3RoZXIgaW5zdHJ1Y3Rpb24gc2V0cyBhcmUg YWxzbyBhdmFpbGFibGUpLg0KPj4+Pg0KPj4+PiBJZiB3ZSBhcmUgY29uc2lkZXJpbmcgdGhlIEFF UyBpbnN0cnVjdGlvbnMgdGhlbiBpdCBsb29rcyBsaWtlIGl0IGlzIChvciBhdCBsZWFzdCB3aWxs IGJlIGluIHRoZSBuZWFyIGZ1dHVyZSkgYSBzaXplYWJsZSBwcm9wb3J0aW9uIG9mIHRoZSBwdWJs aWMgaW50ZXJuZXQgaGF2ZSBpdCB0byBiZSB1c2VkLg0KPj4+Pg0KPj4+DQo+Pj4gQ2VydGFpbmx5 LCBidXQgdGhhdCdzIG5vdCB0aGUgY3VycmVudCBkZWJhdGUuIFBSICMxMDc5IGlzIGZ1bGx5IGNv bXBhdGlibGUgd2l0aCB1c2Ugb2YgdGhlIEFFUyBpbnN0cnVjdGlvbnMuIFRoZSBpc3N1ZSBvZiB0 aGUgZGViYXRlIGlzIHRoYXQgdGhlIG1lY2hhbmlzbSBpbiBQUiAjMTA3OSByZXF1aXJlZCBkb3Vi bGUgYnVmZmVyaW5nLCBmaXJzdCBlbmNyeXB0IHRoZSBwYXlsb2FkLCB0aGVuIHVzZSB0aGUgcmVz dWx0IG9mIHRoZSBlbmNyeXB0aW9uIHRvIGVuY3J5cHQgdGhlIFBOLiBUaGlzIGlzIG5vdCBhbiBp c3N1ZSBpbiBhIHNvZnR3YXJlIGltcGxlbWVudGF0aW9uIHRoYXQgY2FuIHJlYWRpbHkgYWNjZXNz IGFsbCBieXRlcyBvZiB0aGUgcGFja2V0IGZyb20gbWVtb3J5LCBidXQgaXQgbWF5IGJlIGFuIGlz c3VlIGluIHNvbWUgaGFyZHdhcmUgaW1wbGVtZW50YXRpb25zIHRoYXQgYXJlIGRlc2lnbmVkIHRv IGRvIGp1c3Qgb25lIHBhc3Mgb3ZlciB0aGUgZGF0YS4NCj4+Pg0KPj4+DQo+Pj4gLS0gQ2hyaXN0 aWFuIEh1aXRlbWENCj4+Pg0KPj4+DQo+Pj4NCj4+DQo+PiAtLQ0KPj4gTWFyayBOb3R0aW5naGFt ICAgaHR0cHM6Ly93d3cubW5vdC5uZXQvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lm1ub3QubmV0JTJGJmRhdGE9MDIl N0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3Q2FkMjZmNTJkOWQxYTQyNjBiNjkzMDhkNTlh NzUzMjg1JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjU4 NDc1MDUzMDAzMzMyNSZzZGF0YT1aZFNWVWxSR2VRZTg1ajJEeldtRzhKSU1UVnUwa0NLWFYlMkJN SVpvOTloMFElM0QmcmVzZXJ2ZWQ9MD4NCj4+DQo+DQoNCi0tDQpNYXJrIE5vdHRpbmdoYW0gICBo dHRwczovL3d3dy5tbm90Lm5ldC88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cubW5vdC5uZXQlMkYmZGF0YT0wMiU3QzAx JTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDYWQyNmY1MmQ5ZDFhNDI2MGI2OTMwOGQ1OWE3NTMy ODUlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTg0NzUw NTMwMDMzMzI1JnNkYXRhPVpkU1ZVbFJHZVFlODVqMkR6V21HOEpJTVRWdTBrQ0tYViUyQk1JWm85 OWgwUSUzRCZyZXNlcnZlZD0wPg0K --_000_CY4PR21MB0630FA0EDD343396AD414641B6A40CY4PR21MB0630namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFp blRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UE5FIGlzIG9uZSB3YXkgZm9yd2FyZCBmb3IgZG9pbmcg Y29ubmVjdGlvbiBtaWdyYXRpb24gd2l0aG91dCBsaW5rYWJpbGl0eS4gSSB3b3VsZG7igJl0IGNh bGwgaXQgdGhlIG1vc3QgcHJhZ21hdGljIHNpbmNlIGl0IGhhcyBwZXJmb3JtYW5jZSBpbXBsaWNh dGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFueSBvYmplY3Rpb25zIHRvIHRoZSBmb2xs b3dpbmc/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xLiBMZWF2ZSB0 aGUgY3VycmVudCBkcmFmdCBhcyBpcyBmb3IgdGhlIGNvbW1vbiBjYXNlIChubyBtaWdyYXRpb24g bm8gbXVsdGlwYXRoKS4gTWFrZSBzdXJlIHdlIGhhdmUgc29tZSBwcm92aXNpb24gZm9yIGdyZWFz aW5nIHRoZSBQTiB0byBwcmV2ZW50IG9zc2lmaWNhdGlvbi4gSWYgUE4ganVtcHMgYXJlIG5lZWRl ZCBmb3IgdGhpcyAoYXBhcnQgZnJvbSBhIHJhbmRvbSBzdGFydGluZyBQTikgd2Ugc2hvdWxkDQog aGF2ZSBhIFBSIG1vZGlmeWluZyBjdXJyZW50IGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Mi4gRm9yIGNvbm5lY3Rpb24gbWlncmF0aW9uIHRoZSBvcHRpb25z IGFyZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJ0ZXh0 LWluZGVudDouNWluIj5hLiBFeHBsb3JlIG11bHRpcGxlIFBOIHNwYWNlcyBmb3IgY29ubmVjdGlv biBtaWdyYXRpb24gKGFuZCBldmVudHVhbGx5IG11bHRpcGF0aCksIE9SPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Yi4gTWFr ZSBQTkUgKGFuZCBoZW5jZSBjb25uZWN0aW9uIG1pZ3JhdGlvbikgYW4gb3B0aW9uYWwgbmVnb3Rp YXRlZCBleHRlbnNpb24gaW4gVjEgd2l0aCB0aGUgY2F2ZWF0IHRoYXQgd2Ugd2lsbCAmbmJzcDty ZXZpc2l0IHRoaXMgJm5ic3A7Zm9yIFYyIHdoZW4gd2UgZG8gbXVsdGlwYXRoLg0KPGk+VGhpcyBp cyByZXF1aXJlZCBhbnl3YXlzIGJlY2F1c2Ugc2VydmVycyBtdXN0IGJlIGFibGUgdG8gdGVsbCBj bGllbnQgdGhhdCB0aGV5IGNhbm5vdCBzdXBwb3J0IG1pZ3JhdGlvbiBzaW5jZSB0aGV5IGFyZSBi ZWhpbmQgYSBsZWdhY3kgbG9hZCBiYWxhbmNlci48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+ IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9i PklhbiBTd2V0dDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTggMjo0 NCBQTTxicj4NCjxiPlRvOjwvYj4gTWFyayBOb3R0aW5naGFtICZsdDttbm90QG1ub3QubmV0Jmd0 Ozxicj4NCjxiPkNjOjwvYj4gTGFycyBFZ2dlcnQgJmx0O2xhcnNAZWdnZXJ0Lm9yZyZndDs7IElF VEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1pcmphIEvDvGhsZXdpbmQgJmx0O21p cmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGV4cHJlc3NlZCBwcmV2aW91c2x5LCBJIHRlbmQg dG8gdGhpbmsgUE4gZW5jcnlwdGlvbiBpcyB0aGUgbW9zdCBwcmFnbWF0aWMgd2F5IGZvcndhcmQg YXQgdGhlIG1vbWVudC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhvd2V2ZXIsIGlzIGFueW9uZSB3aG8gd291bGQgcHJlZmVyIGEgZGlmZmVyZW50IHNvbHV0 aW9uKGllOiBwYWNrZXQgbnVtYmVyIGp1bXBzIG9yIHNlcGFyYXRlIHNwYWNlcykgd2lsbGluZyB0 byBzZW5kIG91dCBhIFBSIHRoZXkgdGhpbmsgc29sdmVzIHRoZSBsaW5rLWFiaWxpdHkgaXNzdWUg UE4gZW5jcnlwdGlvbiBzb2x2ZXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk15IG1lbnRhbCBtb2RlbCBpcyB0aGVyZSBhcmUgYSBmYWlyIG51 bWJlciBvZiB0aG9ybnkgZWRnZSBjYXNlcywgYnV0IG1heWJlIGlmIEkgc2F3IHRoZW0gaW4gYSBQ UiwgaXQgd291bGRuJ3QgYmUgYXMgc2NhcnkgYXMgSSB0aGluaz88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBcHIgNCwgMjAxOCBh dCA1OjI4IFBNIE1hcmsgTm90dGluZ2hhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1ub3RAbW5vdC5u ZXQiPm1ub3RAbW5vdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk1pcmphLDxicj4NCjxi cj4NCk9uIDQgQXByIDIwMTgsIGF0IDg6MjcgcG0sIE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhy ZWY9Im1haWx0bzptaXJqYS4ua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCIgdGFyZ2V0PSJfYmxh bmsiPm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7PGJyPg0KJmd0OyBIaSBNYXJrLDxicj4NCiZndDs8YnI+DQomZ3Q7IHdpdGhvdXQgaW50ZW5k aW5nIHRvIHN0YXRlIGEgdGVjaG5pY2FsIG9waW5pb24sIEkgdGhpbmsgSSBuZWVkIHRvIGRpc2Fn cmVlIHdpdGggeW91ciBhc3Nlc3NtZW50IG9mIHRoZSBzaXR1YXRpb24uIFBsZWFzZSBzZWUgYmVs b3cuPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IEFtIDA0LjA0LjIwMTggdW0gMDY6NTggc2Nocmll YiBNYXJrIE5vdHRpbmdoYW0gJmx0OzxhIGhyZWY9Im1haWx0bzptbm90QG1ub3QubmV0IiB0YXJn ZXQ9Il9ibGFuayI+bW5vdEBtbm90Lm5ldDwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgSGkgZXZlcnlvbmUsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgZWRpdG9y cyBoYXZlIHRvbGQgeW91ciBjaGFpcnMgdGhhdCB0aGlzIGlzc3VlIGlzIHN0YXJ0aW5nIHRvIGJs b2NrIHByb2dyZXNzIG9uIG90aGVyIGFzcGVjdHMgb2YgUVVJQy4gQ29taW5nIHRvIGNvbnNlbnN1 cyBvbiBpdCBzb29uIChpLmUuLiwgYmVmb3JlIFN0b2NraG9sbSwgaWYgcG9zc2libGUpIHdvdWxk IGJlIGdvb2QuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJdCBsb29rcyBsaWtlIHRoaXMg dGhyZWFkIGhhcyBjb21lIHRvIGEgbmF0dXJhbCBwYXVzZS4gUmVhZGluZyB0aHJvdWdoIGl0LCBJ IHRoaW5rIHdlIGFncmVlIHRoZXJlIGFyZSBzb21lIHVucGxlYXNhbnQgdHJhZGVvZmZzIGhlcmUs IGJ1dCBzbyBmYXIgd2UgaGF2ZSBvbmx5IG9uZSBjb25jcmV0ZSBwcm9wb3NhbCAtLSBQUiMxMDc5 Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBvdGhlciBwcm9wb3NhbCBpcyB0byB1c2UgYSByYW5k b20gb2Zmc2V0IHRoYXQgY2FuL3Nob3VsZCBiZSBjaGFuZ2VkIHdoZW4gdGhlIGNvbm5lY3Rpb24g SUQgaXMgY2hhbmdlZC4gV2hpY2ggaXMgbW9zdGx5IGlubGluZSB3aXRoIHdoYXQgdGhlIGRyYWZ0 IGN1cnJlbnRseSBzYXlzLjxicj4NCjxicj4NCkFzIEkgdW5kZXJzdGFuZCBpdCwgdGhlIHN0YXR1 cyBxdW8gaGFzIGNhdXNlZCBhIHNpZ25pZmljYW50IGFtb3VudCBvZiBwYWluLCBjb21wbGV4aXR5 IGFuZCBwb3RlbnRpYWwgYnVncy4gUE4gZW5jcnlwdGlvbiB3YXMgcHJvcG9zZWQgYnkgS2F6dWhv IGluIE1lbGJvdXJuZSBhcyBhIHdheSB0byB3b3JrIGFyb3VuZCB0aGF0Ljxicj4NCjxicj4NCldl IGNhbiwgb2YgY291cnNlLCBkZWNpZGUgdGhhdCB0aGUgc3RhdHVzIHF1byBpcyB0aGUgcmlnaHQg YXBwcm9hY2guIEhvd2V2ZXIsIG15IGN1cnJlbnQgcmVhZGluZyBvZiB0aGUgV0cgaXMgdGhhdCBp dCBpc24ndCBhY2NlcHRhYmxlLjxicj4NCjxicj4NCjxicj4NCiZndDsmZ3Q7IE15IEFVJC4wNSAt IFdoaWxlIHdlJ3JlIGNoYXJ0ZXJlZCB0byBwcm9kdWNlIGEgcHJvdG9jb2wgdGhhdCdzIGVuY3J5 cHRlZCBhcyBtdWNoIGFzIG9wZXJhdGlvbmFsIGNvbmNlcm5zIGFsbG93LDxicj4NCiZndDs8YnI+ DQomZ3Q7IEkgZG9u4oCZdCB0aGluayB0aGlzIGlzIHdoYXQgdGhlIGNoYXJ0ZXIgc2F5LiBUaGUg Y2hhcnRlciBzYXlzICZxdW90O1Byb3ZpZGluZyBhbHdheXMtc2VjdXJlIHRyYW5zcG9ydCwgdXNp bmcgVExTIDEuMyBieSBkZWZhdWx0LuKAnCBwbHVzIGFub3RoZXIgcGFyYWdyYXBoIHRoYXQgdGFs a3MgYWJvdXQgVExTMS4zLiBJdCBkb2VzIG5vdCBzcGVsbCBvdXQgdGhlIGRlc2lyZSBvZiBzb21l IGluZGl2aWR1YWwgdG8g4oCeZW5jcnlwdCBhcyBtdWNoIGFzIHBvc3NpYmxl4oCcLjxicj4NCjxi cj4NCkkgdGhpbmsgdGhhdCBkZXBlbmRzIG9uIGhvdyB5b3UgcmVhZCAmcXVvdDthbHdheXMtc2Vj dXJlLiZxdW90OyBUaGUgY2hhcnRlciBhbHNvIHNheXMgd2Ugd2lsbCBwcm92aWRlICZxdW90O2Nv bmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IHByb3RlY3Rpb24gb2YgYm90aCBhcHBsaWNhdGlv biBkYXRhIGFuZCBRVUlDIGhlYWRlcnMuJnF1b3Q7PGJyPg0KPGJyPg0KPGJyPg0KJmd0OyZndDsg YW5kIHRoYXQgcHJpdmFjeSBpcyBhIG5hdHVyYWwgZXh0ZW5zaW9uIG9mIHRoYXQgKGVzcGVjaWFs bHkgaW4gbGlnaHQgb2YgUkZDNzI1OCBhbmQgUkZDNjk3MyksIHRoZXJlIGlzIG5vICpyZXF1aXJl bWVudCogdGhhdCB3ZSBwcm9kdWNlIGEgcHJvdG9jb2wgdGhhdCBpcyBhYmxlIHRvIGJlIGFjY2Vs ZXJhdGVkIGJ5IGhhcmR3YXJlLjxicj4NCiZndDs8YnI+DQomZ3Q7IE5vdCB0aGVyZSBpcyBubyBy ZXF1aXJlbWVudCB0aGF0IHRoZSBwcm90b2NvbCBuZWVkIHRvIGJlIGFjY2VsZXJhdGVkIGJ5IGhh cmR3YXJlLiBIb3dldmVyLCBub3QgYWxsIHJlcXVpcmVtZW50IGFyZSBsaXN0ZWQgaW4gdGhlIGNo YXJ0ZXIuIFdlIGFzIGEgZ3JvdXAgaGF2ZSB0byBkZWZpbmUgdGhlIHJlcXVpcmVtZW50LiBIb3dl dmVyLCB0aGVyZSBpcyBvZiBjb3Vyc2UgYW4gaW1wbGljaXQgcmVxdWlyZW1lbnQgZm9yIGFsbCB3 b3JrIGluIHRoZQ0KIElFRlQgdGhhdCBpcyBtdXN0IGJlIGRlcGxveWFibGUgYW5kIHNlcnZlIHRo ZSBuZWVkcyBvZiB0aG9zZSBwZW9wbGUgd2hvIHdhbnQgdG8gZGVwbG95IGl0Ljxicj4NCjxicj4N ClllcyAtIGEgZGlzY3Vzc2lvbiB0aGF0IEknbSB0cnlpbmcgdG8gZHJhdyBvdXQuIFRoYW5rcy48 YnI+DQo8YnI+DQo8YnI+DQomZ3Q7Jmd0OyBUaGF0IGJlaW5nIHRoZSBjYXNlLCBJIHRoaW5rIHdl IG5lZWQgdG8gYXNrIG91cnNlbHZlcyBpZiB3ZSBiZWxpZXZlIHRoYXQgaW5jbHVzaW9uIG9mIFBS IzEwNzkgd2lsbCBzaWduaWZpY2FudGx5IGluaGliaXQgZGVwbG95bWVudCBvZiB0aGUgcHJvdG9j b2wuIEJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIHNvIGZhciwgdGhhdCBkb2Vzbid0IHNlZW0gdG8g YmUgdGhlIGNhc2UsIGJ1dCBJJ2QgYmUgaW50ZXJlc3RlZCB0byBoZWFyIHdoYXQgb3RoZXJzDQog dGhpbmsuPGJyPg0KJmd0Ozxicj4NCiZndDsgSGVyZSBteSBhc3Nlc3NtZW50IGlzIGFsc28gZGlm ZmVyZW50LiBUaGVyZSBhcmUgbXVsdGlwbGUgcGVvcGxlIHRoYXQgaGF2ZSByYWlzZWQgY29uY2Vy bnMgdGhhdCB0aGlzIGNvdWxkIGhpbmRlciBkZXBsb3ltZW50Ljxicj4NCjxicj4NCkFzIHlvdSBr bm93LCB3ZSBkb24ndCBhc3Nlc3MgY29uc2Vuc3VzIGp1c3QgYnkgdGhlIG51bWJlciBvZiBwZW9w bGUgdGhhdCBoYXZlIHJhaXNlZCBjb25jZXJucywgYnV0IGFsc28gdGhlIHRlY2huaWNhbCBtZXJp dCBvZiB0aGUgYXJndW1lbnRzLiBTbyBmYXIsIHRoZSBhcmd1bWVudHMgaGF2ZSBiZWVuIGFsbCBv dmVyIHRoZSBtYXAsIGFuZCBJIHdhbnQgdGhlbSB0byBjb252ZXJnZS48YnI+DQo8YnI+DQpUaGUg ZGF0YSB0aGF0J3MgYmVlbiBwcm92aWRlZCBoYXMgYmVlbiB2ZXJ5IGhlbHBmdWwsIGJ1dCB3ZSBu ZWVkIHRvIGV2YWx1YXRlIHRoYXQgaW4gdGhlIGNvbnRleHQgb2YgaG93IFFVSUN2MSB3aWxsIGFj dHVhbGx5IGJlIGRlcGxveWVkIGFuZCB1c2VkIC0tIHNvbWV0aGluZyB3aGljaCBhIGZldyB0aHJl YWRzIGhhdmUgdG91Y2hlZCB1cG9uLjxicj4NCjxicj4NCk92ZXJhbGwsIEkgZG8gbm90IHRoaW5r IGl0IGlzIGEgZ29hbCBvZiBRVUlDIHRvIGJlIGRlcGxveWFibGUgb24gYW55IHN5c3RlbSBmb3Ig YW55IHB1cnBvc2U7IGlmIHdlIHRyeSB0byBkZXNpZ24gaXQgZm9yIGFsbCBwdXJwb3Nlcywgd2Un cmUgZ29pbmcgdG8gZmFpbC4gVGhlIHF1ZXN0aW9uLCB0aGVuLCBpcyBob3cgbXVjaCBkZXBsb3lt ZW50IC8gaW1wbGVtZW50YXRpb24gLyBhZG9wdGlvbiB3ZSBuZWVkIHRvIG1ha2UgaXQgc3VjY2Vl ZCAtLSBhbmQNCiB0byBkZXNpZ24gZm9yIHRoYXQuPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyZndDsg SWYgd2UgY2FuIGdldCB0byBjb25zZW5zdXMgdG8gaW5jb3Jwb3JhdGUgdGhlIFBSLCBhbmQgZm9s a3MgY29tZSBiYWNrIGxhdGVyIHdpdGggYSBtb3JlIGhhcmR3YXJlLWZyaWVuZGx5IHJlcGxhY2Vt ZW50IHRoYXQgZG9lc24ndCBjaGFuZ2UgdGhlIEludmFyaWFudHMgb3IgaW5jcmVhc2UgbGlua2Fi aWxpdHksIEkgc3VzcGVjdCB0aGUgV0cgd2lsbCBiZSBhbWVuYWJsZSB0byB0aGF0Ljxicj4NCiZn dDs8YnI+DQomZ3Q7IEkgZG9u4oCZdCB0aGluayB0byBqdXN0IGdvIHdpdGggd2hhdCB3ZSBoYXZl IGV2ZW4gdGhvdWdoIHRoZXJlIGFyZSBjb25jZXJucywgaXMgdGhlIHJpZ2h0IGFwcHJvYWNoIGFu ZCBkZWZpbml0ZWx5IG5vdCB0aGUgYXBwcm9hY2ggdGhhdCB3YXMgY2hvc2VuIGZvciBvdGhlciBw cm9wb3NhbHMuIEluIHRoZSBzYWtlIG9mIGdldHRpbmcgdmVyc2lvbiB2MSBvdXQgcXVpY2tseSwg SSB3b3VsZCB0aGluayB0aGF0IG5vdCBpbmNvcnBvcmF0aW5nIGFub3RoZXINCiBjaGFuZ2UgdGhh dCBkb2VzIG5vdCBoYXZlIGNvbnNlbnN1cyBpcyB0aGUgcHJvcG9zZXIgYXBwcm9hY2guPGJyPg0K PGJyPg0KSSB3YXNuJ3QgcHJvcG9zaW5nIHRoYXQgd2UgaW5jb3Jwb3JhdGUgYSBjaGFuZ2Ugd2l0 aG91dCBjb25zZW5zdXMgLS0gcGxlYXNlIHJlLXJlYWQgbXkgc3RhdGVtZW50LiBZb3UgbWF5IGRp c2FncmVlIHdpdGggaG93IHRoZSBjaGFpcnMgZXZlbnR1YWxseSBjYWxsIGNvbnNlbnN1cyBvbiB0 aGlzIGlzc3VlLCBhbmQgdGhlcmUgYXJlIG1lY2hhbmlzbXMgZm9yIHlvdSB0byBhcHBlYWwgKG9y IGV2ZW4gRElTQ1VTUykgdGhhdCwgYnV0IGl0J3MgcHJlbWF0dXJlDQogdG8gc3RhcnQgdGhhdCBu b3cuPGJyPg0KPGJyPg0KVGhhdCBzYWlkIC0tIE9uZSB3YXkgdG8gcHJvdmUgdGhhdCBQTkUgaHVy dHMgZGVwbG95YWJpbGl0eSBpcyB0byB0cnkgaXQ7IGltcGxlbWVudGVycyBoYXZlIGEgdmVyeSBz dHJvbmcgaW5jZW50aXZlIHRvIG1ha2Ugc3VyZSB0aGVpciBjb2RlIGNhbiBiZSBkZXBsb3llZCwg c28gaWYgdGhvc2Ugd2hvIGhhdmUgY29uY2VybnMgYXJlIGNvcnJlY3QsIGl0J3MgcHJvYmFibHkg dGhlIGVhc2llc3Qgd2F5IGZvciB0aGVtIHRvIGJlIHByb3ZlbiByaWdodC48YnI+DQo8YnI+DQpU aGFua3MsPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBNaXJqYTxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2hhdCBkbyBmb2xrcyB0aGluaz88 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9uIDI5IE1hciAyMDE4LCBhdCAxMTozOSBhbSwgSWFu IFN3ZXR0ICZsdDtpYW5zd2V0dD08YSBocmVmPSJtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZn dDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFRoYW5rcyBmb3Ig dGhlIG5pY2Ugc3VtbWFyeSBKYW5hLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyBBcyBtdWNoIGFzIEknZCBsb3ZlIHRvIGhhdmUgZWFzaWVyIGNyeXB0byBIVyBhY2NlbGVyYXRp b24sIEkndmUgZW5kZWQgdXAgYXJyaXZpbmcgYXQgdGhlIHNhbWUgY29uY2x1c2lvbi4mbmJzcDsg SSBkb24ndCB3YW50IHRvIGJpdGUgb2ZmIHRoZSB3b3JrIHRvIGRvIHByb3BlciBtdWx0aXBhdGgg aW4gUVVJQyB2MSwgd2hpY2ggSSB0aGluayBpcyB0aGUgb25seSBvdGhlciByZWFzb25hYmxlIG9w dGlvbiBvZiB0aG9zZSBDaHJpc3RpYW4gb3V0bGluZWQuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7IElmIHNvbWVvbmUgY29tZXMgdXAgd2l0aCBhIHdheSB0byB0cmFuc2Zvcm0g cGFja2V0IG51bWJlciB0byBtYWtlIGl0IG5vbi1saW5rYWJsZSwgYnV0IGRvZXNuJ3QgaGF2ZSB0 aGUgZG93bnNpZGUgb2YgbWFraW5nIGhhcmR3YXJlIG9mZmxvYWQgZGlmZmljdWx0LCB0aGVuIEkn bSBvcGVuIHRvIGl0LiZuYnNwOyBCdXQgd2UndmUgYmVlbiB0YWxraW5nIGFib3V0IHRoaXMgZm9y IDIgbW9udGhzIHdpdGhvdXQgYW55IG5vdGFibGUgaW1wcm92ZW1lbnRzDQogb3ZlciBNYXJ0aW4n cyBQUi48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgR2l2ZW4gd2UgbmV2ZXIg dGFsayBhYm91dCBhbnkgaXNzdWUgb25seSBvbmNlIGluIFFVSUMsIEknbSBzdXJlIHRoaXMgd2ls bCBjb21lIHVwIGFnYWluLCBidXQgZm9yIHRoZSB0aW1lIGJlaW5nIEkgdGhpbmsgIzEwNzkgaXMg dGhlIGJlc3Qgb3B0aW9uIHdlIGhhdmUuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9uIFdlZCwgTWFyIDI4LCAy MDE4IGF0IDg6MDMgUE0gSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpLmlldGZA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+anJpLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KJmd0OyZndDsmZ3Q7IEEgZmV3IHF1aWNrIHRob3VnaHRzIGFzIEkgY2F0Y2ggdXAg b24gdGhpcyB0aHJlYWQuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEkgc3Bl bnQgc29tZSB0aW1lIGxhc3Qgd2VlayB3b3JraW5nIHRocm91Z2ggYSBkZXNpZ24gdXNpbmcgbXVs dGlwbGUgUE4gc3BhY2VzLCBhbmQgaXQgaXMgcXVpdGUgZG9hYmxlLiBJIHN1c3BlY3Qgd2UnbGwg aGVhZCB0b3dhcmRzIG11bHRpcGxlIFBOIHNwYWNlcyBhcyB3ZSBjb25zaWRlciBtdWx0aXBhdGgg aW4gdGhlIGZ1dHVyZS4gVGhhdCBzYWlkLCB0aGVyZSBpcyBjb21wbGV4aXR5IChhcyBDaHJpc3Rp YW4gbm90ZXMpLiBUaGlzIGNvbXBsZXhpdHkNCiBtYXkgYmUgd2FycmFudGVkIHdoZW4gZG9pbmcg bXVsdGlwYXRoIGluIHYyIG9yIGxhdGVyLCBidXQgSSdtIG5vdCBjb252aW5jZWQgdGhhdCB0aGlz IGlzIG5lY2Vzc2FyeSBhcyBhIGRlc2lnbiBwcmltaXRpdmUgZm9yIFFVSUN2MS48YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgV2UgbWF5IHdhbnQgdG8gY3JlYXRpdmVseSB1c2Ug dGhlIFBOIGJpdHMgaW4gdjIsIHNheSB0byBlbmNvZGUgYSBwYXRoIElEIGFuZCBhIFBOLCBmb3Ig bXVsdGlwYXRoLiBXZSB3YW50IHRvIHJldGFpbiBmbGV4aWJpbGl0eSBpbiB0aGVzZSBiaXRzIGdv aW5nIGludG8gdjIuIFdlJ3ZlIHVzZWQgZW5jcnlwdGlvbiB0byBlbnN1cmUgdGhhdCB3ZSBkb24n dCBsb3NlIGZsZXhpYmlsaXR5IGVsc2V3aGVyZSBpbiB0aGUgaGVhZGVyLCBhbmQgaXQgZm9sbG93 cw0KIHRoYXQgd2Ugc2hvdWxkIHVzZSBQTkUgdG8gcmV0YWluIGZsZXhpYmlsaXR5IGluIHRoZXNl IGJpdHMgYXMgd2VsbC4gKFNpbXBsaWNpdHkgb2YgZGVzaWduIGlzIHRoZSBvdGhlciB2YWx1ZSBp biB1c2luZyBQTkUsIHNpbmNlIGhhbmRsaW5nIG1pZ3JhdGlvbiBsaW5rYWJpbGl0eSBpcyBub24t dHJpdmlhbCB3aXRob3V0IGl0Lik8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg VGhpcyBsZWF2ZXMgdGhlIHF1ZXN0aW9uIG9mIEhXIGFjY2VsZXJhdGlvbiBiZWluZyBhdCBsb2dn ZXJoZWFkcyB3aXRoIHRoZSBkZXNpZ24gaW4gUFIgIzEwNzkuIEZpcnN0LCBJIGV4cGVjdCB0aGF0 IHRoZSBwcmltYXJ5IGJlbmVmaXQgb2YgYWNjZWxlcmF0aW9uIHdpbGwgYmUgaW4gREMgZW52aXJv bm1lbnRzLiBZZXMsIHRoZXJlIGFyZSBzb21lIGdhaW5zIHRvIGJlIGhhZCBpbiBzZXJ2aW5nIHRo ZSBwdWJsaWMgSW50ZXJuZXQgYXMgd2VsbCwNCiBidXQgSSdtIHVuY29udmluY2VkIHRoYXQgdGhp cyBpcyB0aGUgZHJpdmluZyB1c2UgY2FzZSBmb3IgaGFyZHdhcmUgYWNjZWxlcmF0aW9uLiBJIHVu ZGVyc3RhbmQgdGhhdCBvdGhlcnMgbWF5IGRpc2FncmVlIHdpdGggbWUgaGVyZS48YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQUZBSUssIFFVSUMgaGFzIG5vdCBiZWVuIHVzZWQg aW4gREMgZW52aXJvbm1lbnRzIHlldC4gSSBleHBlY3QgdGhlcmUgYXJlIG90aGVyIHRoaW5ncyBp biB0aGUgcHJvdG9jb2wgdGhhdCB3ZSdkIHdhbnQgdG8gY2hhbmdlIGFzIHdlIGdhaW4gZXhwZXJp ZW5jZSBkZXBsb3lpbmcgUVVJQyBpbiBEQ3MuIFNwaW5uaW5nIHVwIGEgbmV3IHZlcnNpb24gdG8g dHJ5IFFVSUMgd2l0aGluIERDcyBpcyBub3Qgb25seSBhcHByb3ByaWF0ZSwgSSB3b3VsZA0KIHJl Y29tbWVuZCBpdC4gVGhpcyBhbGxvd3MgZm9yIHJhcGlkIGl0ZXJhdGlvbnMgaW50ZXJuYWxseSwg YW5kIHRoZSBleHBlcmllbmNlIGNhbiBkcml2ZSBzdWJzZXF1ZW50IGNoYW5nZXMgdG8gUVVJQy4g SXQncyB3aGF0ICpJKiB3b3VsZCBkbyBpZiBJIHdhcyB0byBkZXBsb3kgUVVJQyBpbnNpZGUgYSBE Qy48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgU28sIGluIHNob3J0LCBJIHRo aW5rIHdlIHNob3VsZCBnbyBhaGVhZCB3aXRoIFBSIyAxMDc5LiBUaGlzIGVuc3VyZXMgdGhhdCBm dXR1cmUgdmVyc2lvbnMgYXJlIGd1YXJhbnRlZWQgdGhlIGZsZXhpYmlsaXR5IHRvIGNoYW5nZSB0 aGUgUE4gYml0cyBmb3IgYmV0dGVyIHN1cHBvcnQgb2YgSFcgYWNjZWxlcmF0aW9uIG9yIG11bHRp cGF0aCBvciB3aGF0LWhhdmUteW91Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyAtIGphbmE8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT24gTWFyIDI2LCAy MDE4IDk6NDEgQU0sICZxdW90O0NocmlzdGlhbiBIdWl0ZW1hJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh1aXRlbWFAaHVpdGVt YS5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg T24gMy8yNi8yMDE4IDg6MjAgQU0sIFN3aW5kZWxscywgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJy aWRnZSkgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBMb29raW5nIGF0IDxhIGhyZWY9Imh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGZW4ud2lraXBlZGlhLm9yZyUyRndpa2klMkZBRVNfaW5zdHJ1Y3Rpb25fc2V0JTIzSW50 ZWxfYW5kX0FNRF94ODZfYXJjaGl0ZWN0dXJlJmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1p Y3Jvc29mdC5jb20lN0NhZDI2ZjUyZDlkMWE0MjYwYjY5MzA4ZDU5YTc1MzI4NSU3QzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY1ODQ3NTA1MzAwMzMzMjUmYW1w O3NkYXRhPXlHcVdiQk1NOTh0SDVBMjJrQlc0S1pGaHh4QmdiRGg0NE15Q0tRT1JORDAlM0QmYW1w O3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93 aWtpL0FFU19pbnN0cnVjdGlvbl9zZXQjSW50ZWxfYW5kX0FNRF94ODZfYXJjaGl0ZWN0dXJlPC9h PiBpdCBzZWVtcyB0byBpbXBseSBhIGxhcmdlIHJhbmdlIG9mIHNlcnZlciwgZGVza3RvcCBhbmQg bW9iaWxlIGNoaXBzIGFsbCBoYXZlIGEgQ1BVIGluc3RydWN0aW9uIHNldCBhdmFpbGFibGUgdG8g ZG8gQUVTIGFjY2VsZXJhdGlvbiBhbmQgb3RoZXIgc2ltaWxhciBvcGVyYXRpb25zIChvdGhlciBp bnN0cnVjdGlvbg0KIHNldHMgYXJlIGFsc28gYXZhaWxhYmxlKS48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJZiB3ZSBhcmUgY29uc2lkZXJpbmcgdGhlIEFFUyBp bnN0cnVjdGlvbnMgdGhlbiBpdCBsb29rcyBsaWtlIGl0IGlzIChvciBhdCBsZWFzdCB3aWxsIGJl IGluIHRoZSBuZWFyIGZ1dHVyZSkgYSBzaXplYWJsZSBwcm9wb3J0aW9uIG9mIHRoZSBwdWJsaWMg aW50ZXJuZXQgaGF2ZSBpdCB0byBiZSB1c2VkLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQ2VydGFpbmx5LCBidXQgdGhhdCdzIG5vdCB0 aGUgY3VycmVudCBkZWJhdGUuIFBSICMxMDc5IGlzIGZ1bGx5IGNvbXBhdGlibGUgd2l0aCB1c2Ug b2YgdGhlIEFFUyBpbnN0cnVjdGlvbnMuIFRoZSBpc3N1ZSBvZiB0aGUgZGViYXRlIGlzIHRoYXQg dGhlIG1lY2hhbmlzbSBpbiBQUiAjMTA3OSByZXF1aXJlZCBkb3VibGUgYnVmZmVyaW5nLCBmaXJz dCBlbmNyeXB0IHRoZSBwYXlsb2FkLCB0aGVuIHVzZSB0aGUgcmVzdWx0IG9mIHRoZSBlbmNyeXB0 aW9uDQogdG8gZW5jcnlwdCB0aGUgUE4uIFRoaXMgaXMgbm90IGFuIGlzc3VlIGluIGEgc29mdHdh cmUgaW1wbGVtZW50YXRpb24gdGhhdCBjYW4gcmVhZGlseSBhY2Nlc3MgYWxsIGJ5dGVzIG9mIHRo ZSBwYWNrZXQgZnJvbSBtZW1vcnksIGJ1dCBpdCBtYXkgYmUgYW4gaXNzdWUgaW4gc29tZSBoYXJk d2FyZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhcmUgZGVzaWduZWQgdG8gZG8ganVzdCBvbmUgcGFz cyBvdmVyIHRoZSBkYXRhLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyAtLSBDaHJpc3RpYW4gSHVpdGVtYTxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgLS08YnI+DQomZ3Q7Jmd0OyBNYXJrIE5vdHRpbmdoYW0mbmJzcDsgJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ3d3cubW5vdC5uZXQlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9z b2Z0LmNvbSU3Q2FkMjZmNTJkOWQxYTQyNjBiNjkzMDhkNTlhNzUzMjg1JTdDNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjU4NDc1MDUzMDAzMzMyNSZhbXA7c2Rh dGE9WmRTVlVsUkdlUWU4NWoyRHpXbUc4SklNVFZ1MGtDS1hWJTJCTUlabzk5aDBRJTNEJmFtcDty ZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cubW5vdC5uZXQvPC9hPjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0Ozxicj4NCjxicj4NCi0tPGJyPg0KTWFyayBOb3R0aW5naGFtJm5i c3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lm1ub3QubmV0JTJGJmFtcDtkYXRhPTAyJTdD MDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0NhZDI2ZjUyZDlkMWE0MjYwYjY5MzA4ZDU5YTc1 MzI4NSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY1ODQ3 NTA1MzAwMzMzMjUmYW1wO3NkYXRhPVpkU1ZVbFJHZVFlODVqMkR6V21HOEpJTVRWdTBrQ0tYViUy Qk1JWm85OWgwUSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 Lm1ub3QubmV0LzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB0630FA0EDD343396AD414641B6A40CY4PR21MB0630namp_-- From nobody Wed Apr 4 16:27:29 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBF012D86C for ; Wed, 4 Apr 2018 16:27:28 -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=v+jH80RU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Jn2Wyu8r Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzmwe4Vg3fUA for ; Wed, 4 Apr 2018 16:27:26 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FA2612D880 for ; Wed, 4 Apr 2018 16:27:26 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1F11021EF4; Wed, 4 Apr 2018 19:27:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 04 Apr 2018 19:27:24 -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; s=fm2; bh=UFBXJLzCcPKpswb1+qUssoHZdgYKl p7Q22Y+qUEkauE=; b=v+jH80RU712Mtr/9zfFrg1w9VM9xpyEemA24v3TZM57eh X2RlCMk28axhI7Pd6Q1dsv92H5LqmbZTNbkYPQIV6DJdw2Hly77BxMT2rFBiZryx Dbp6OQEJjj5ARkWdoWDkvA6g8B7PwHRBq61fZVsn1aYkGTQ3AJy5jvlVwZN/n5cq t7KE5BCk6dFgIbv4ulQVpDpg1gulLihpBr5cZplrc2Gppi3linUfa7boS4+eW4f0 HPa5q3Qgz1/U8DjmqNJNpfFMC1XVdf3yXEMwRTuBj+YDrU52fdcoFpEgZFTDEaYw SG+a/IRAcorrhJA1Hoxn2Z169uQY2NUMYqCSNGkCg== 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; s=fm2; bh=UFBXJL zCcPKpswb1+qUssoHZdgYKlp7Q22Y+qUEkauE=; b=Jn2Wyu8rqRWUm9xfX5EuUT yk15ekxNuCemaSbhd51WX13+bR1ZG0ytf2S+DCZ6UqQR3GJ7+r73Uf920gnj+yFe g7pL5ZoiQumTpguhKY84kdWwh1Y25kLSctXDghk9mh+6Q0FPLdDhaZqkY3ATZor2 V3iN+tGQvsLMhRX/AmOqvAzWGTeeMczVnsVsqdhobWtcaPoJWUFW552LKDAQQq2q HOjMpOfdpMFAgLEUIIs/BacUANUQHXW2xrmOn9mVrSgTTBdmMElRWWdd+kNGKVH1 TgpVDMSmrftfLEAS9STqlX/iXVVwAOTjmcWFIioXvK9DsSTmIcwHt/4Ke36sldzg == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F12910255; Wed, 4 Apr 2018 19:27:21 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Getting to consensus on packet number encryption From: Mark Nottingham In-Reply-To: Date: Thu, 5 Apr 2018 09:27:19 +1000 Cc: Ian Swett , Lars Eggert , IETF QUIC WG , =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Transfer-Encoding: quoted-printable Message-Id: <9F724A02-0131-43DB-B1D1-0BFCEEE898D5@mnot.net> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> To: Praveen Balasubramanian X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 23:27:29 -0000 Hi Praveen, On 5 Apr 2018, at 9:22 am, Praveen Balasubramanian = wrote: >=20 > PNE is one way forward for doing connection migration without = linkability. I wouldn=E2=80=99t call it the most pragmatic since it has = performance implications. > =20 > Any objections to the following? > 1. Leave the current draft as is for the common case (no migration no = multipath). Just noting -- one of the things that came up in Melbourne was that = migration for the "parking lot problem" -- i.e., wifi to cellular, or = vice versa -- *is* in-scope for QUICv1, in many people's minds.=20 > Make sure we have some provision for greasing the PN to prevent = ossification. If PN jumps are needed for this (apart from a random = starting PN) we should have a PR modifying current draft. > 2. For connection migration the options are: > a. Explore multiple PN spaces for connection migration (and eventually = multipath), OR > b. Make PNE (and hence connection migration) an optional negotiated = extension in V1 with the caveat that we will revisit this for V2 when = we do multipath. This is required anyways because servers must be able = to tell client that they cannot support migration since they are behind = a legacy load balancer. -- Mark Nottingham https://www.mnot.net/ From nobody Wed Apr 4 16:27:42 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E134412D885 for ; Wed, 4 Apr 2018 16:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522884449; bh=xL6bzZ9EQfEGlEPZpVL/fkiahhWpLcTSfpt1BM2pWJE=; h=Subject:From:In-Reply-To:Date:References:To:Cc:Cc:Cc:Cc; b=rlLqnzz5awtSXMkYNKYOZSzWuA8DitFnQoBr0UOnmroIIWrXP9o5CQTvizJhf/Xu2 +3TnX0FTTVXP/xS0l/rRmnWQR5Pji4FQguktIdrb7cStX5OOLyKNxvWn51twob/Ngf iH9D4zUyuS4edp1UPYo/H3fju7hS+BEhlNeX34Wc= X-Mailbox-Line: From mnot@mnot.net Wed Apr 4 16:27:29 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 925A5126FB3; Wed, 4 Apr 2018 16:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522884449; bh=xL6bzZ9EQfEGlEPZpVL/fkiahhWpLcTSfpt1BM2pWJE=; h=Subject:From:In-Reply-To:Date:References:To:Cc:Cc:Cc:Cc; b=rlLqnzz5awtSXMkYNKYOZSzWuA8DitFnQoBr0UOnmroIIWrXP9o5CQTvizJhf/Xu2 +3TnX0FTTVXP/xS0l/rRmnWQR5Pji4FQguktIdrb7cStX5OOLyKNxvWn51twob/Ngf iH9D4zUyuS4edp1UPYo/H3fju7hS+BEhlNeX34Wc= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707FA12D86C for ; Wed, 4 Apr 2018 16:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=v+jH80RU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Jn2Wyu8r Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ibttUGSyAmm for ; Wed, 4 Apr 2018 16:27:26 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DA4A126FB3 for ; Wed, 4 Apr 2018 16:27:26 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1F11021EF4; Wed, 4 Apr 2018 19:27:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 04 Apr 2018 19:27:24 -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; s=fm2; bh=UFBXJLzCcPKpswb1+qUssoHZdgYKl p7Q22Y+qUEkauE=; b=v+jH80RU712Mtr/9zfFrg1w9VM9xpyEemA24v3TZM57eh X2RlCMk28axhI7Pd6Q1dsv92H5LqmbZTNbkYPQIV6DJdw2Hly77BxMT2rFBiZryx Dbp6OQEJjj5ARkWdoWDkvA6g8B7PwHRBq61fZVsn1aYkGTQ3AJy5jvlVwZN/n5cq t7KE5BCk6dFgIbv4ulQVpDpg1gulLihpBr5cZplrc2Gppi3linUfa7boS4+eW4f0 HPa5q3Qgz1/U8DjmqNJNpfFMC1XVdf3yXEMwRTuBj+YDrU52fdcoFpEgZFTDEaYw SG+a/IRAcorrhJA1Hoxn2Z169uQY2NUMYqCSNGkCg== 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; s=fm2; bh=UFBXJL zCcPKpswb1+qUssoHZdgYKlp7Q22Y+qUEkauE=; b=Jn2Wyu8rqRWUm9xfX5EuUT yk15ekxNuCemaSbhd51WX13+bR1ZG0ytf2S+DCZ6UqQR3GJ7+r73Uf920gnj+yFe g7pL5ZoiQumTpguhKY84kdWwh1Y25kLSctXDghk9mh+6Q0FPLdDhaZqkY3ATZor2 V3iN+tGQvsLMhRX/AmOqvAzWGTeeMczVnsVsqdhobWtcaPoJWUFW552LKDAQQq2q HOjMpOfdpMFAgLEUIIs/BacUANUQHXW2xrmOn9mVrSgTTBdmMElRWWdd+kNGKVH1 TgpVDMSmrftfLEAS9STqlX/iXVVwAOTjmcWFIioXvK9DsSTmIcwHt/4Ke36sldzg == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F12910255; Wed, 4 Apr 2018 19:27:21 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Getting to consensus on packet number encryption From: Mark Nottingham In-Reply-To: Date: Thu, 5 Apr 2018 09:27:19 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <9F724A02-0131-43DB-B1D1-0BFCEEE898D5@mnot.net> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> To: Praveen Balasubramanian X-Mailer: Apple Mail (2.3445.6.18) Cc: Ian Swett Cc: Lars Eggert Cc: IETF QUIC WG Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 23:27:30 -0000 Hi Praveen, On 5 Apr 2018, at 9:22 am, Praveen Balasubramanian = wrote: >=20 > PNE is one way forward for doing connection migration without = linkability. I wouldn=E2=80=99t call it the most pragmatic since it has = performance implications. > =20 > Any objections to the following? > 1. Leave the current draft as is for the common case (no migration no = multipath). Just noting -- one of the things that came up in Melbourne was that = migration for the "parking lot problem" -- i.e., wifi to cellular, or = vice versa -- *is* in-scope for QUICv1, in many people's minds.=20 > Make sure we have some provision for greasing the PN to prevent = ossification. If PN jumps are needed for this (apart from a random = starting PN) we should have a PR modifying current draft. > 2. For connection migration the options are: > a. Explore multiple PN spaces for connection migration (and eventually = multipath), OR > b. Make PNE (and hence connection migration) an optional negotiated = extension in V1 with the caveat that we will revisit this for V2 when = we do multipath. This is required anyways because servers must be able = to tell client that they cannot support migration since they are behind = a legacy load balancer. -- Mark Nottingham https://www.mnot.net/ From nobody Wed Apr 4 16:39:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4940126FB3 for ; Wed, 4 Apr 2018 16:39:10 -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 (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 9y9VhmuoiqLg for ; Wed, 4 Apr 2018 16:39:08 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0098.outbound.protection.outlook.com [104.47.38.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF6E126C2F for ; Wed, 4 Apr 2018 16:39:08 -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=KqNDlV/G3Q+MEVUr4PEHuzp0BpgXV0/hXXpOMIKfKVE=; b=G+cOLTVcgYTohvP0c24hjFz3DBloxzlqM7rG7m/qUJQUlNCPp/51Ya6eSYO6DbAByyH7YLdoJIQVzgKOXxCB2HvSqM1PEiOu1CUxbj5Otp9xM+xgCPNMI/SsbJ+ndqhOsgvC0cjasvSeSgZCqDiaLvW8qNiia9PNqhuZvy9PXDQ= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0822.namprd21.prod.outlook.com (10.173.192.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 23:39:05 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 23:39:05 +0000 From: Praveen Balasubramanian To: Mark Nottingham CC: Ian Swett , Lars Eggert , IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwZ0sAgAC4ugCAAARcAIAAFTbwgAAHuICAAAJF8A== Date: Wed, 4 Apr 2018 23:39:05 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <9F724A02-0131-43DB-B1D1-0BFCEEE898D5@mnot.net> In-Reply-To: <9F724A02-0131-43DB-B1D1-0BFCEEE898D5@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0822; 7:X2VkQJOA2UrTVwN7E3IVC73ZwnbfJ9jyKmAE/Z4DVBxkbALeKaxfSYWOxNBb9TIxkppTaDCA2SLBygRXLJHLAcpuUKrngpKwNc7XX1vPXWYHaW9dJ5fGjmiJUNxtgu04dUS637tM4HZF8g8Q/1y49o3X/TnwpcVMCLS4SjqG+dyogEccnnG8wxRJw27qkCkHXhSWzCAacztM/+yTNHwIUF4d1P7aZVqpdMnYV6gjHdwO0Ns06Wg07UfopP7g6Q+O; 20:agkVid5YADXqtcD4PxqWUEQ+XuJjhLjruOwSXGCt+6rh2of5gxl+BWQQSUtR4a5cjjcc2v6fUVNSYTzT8YIWUbBqiGciRMbQDb5CQ3gdEfaq2CpW5RaHj7Nogtv9PJI/foxNxw5X3ehdbDT9qE2akxtt5VGEnmCsMQeih8GPtLU= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 38213b7c-1633-4e00-ad4c-08d59a854105 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0822; x-ms-traffictypediagnostic: CY4PR21MB0822: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(189930954265078)(100405760836317)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0822; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0822; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(346002)(366004)(396003)(376002)(13464003)(199004)(189003)(53546011)(6506007)(102836004)(54906003)(6116002)(186003)(11346002)(446003)(99286004)(93886005)(25786009)(10290500003)(476003)(486006)(46003)(6436002)(4326008)(7696005)(76176011)(106356001)(86612001)(33656002)(9686003)(55016002)(6306002)(97736004)(14454004)(3280700002)(68736007)(53936002)(2900100001)(5660300001)(81166006)(81156014)(105586002)(8676002)(8936002)(74316002)(6246003)(10090500001)(8990500004)(2906002)(86362001)(3660700001)(229853002)(22452003)(316002)(5250100002)(478600001)(6916009)(966005)(7736002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0822; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: qu5KjDgK/HUGMfWsz9szXCige3PIvevJhzKZ3zOLMHjjXubgNskw0IBRtxxBHI4E+IOlthf9NR3Tgm2eQ6+PciMS7AdpUTOOpzymlPpyXVIh0FxhJG5uVYfcnF3RFv6G2bb2n/AtcoyQXRNArlBk1LD6XuUDB0Y9LeX5yT8aYQqepk3rxW2nS8mGvnkXsLtsdIkVWhRVrvRtFDxq7jYVX/ieyfDUqjP4AeA1jMKbHIxn92QImD7b1gm2ToS8+FjIsswbpFSVC8ya3vE08z6sx1sUQZtCVY/5HWtL7x/ENLOU94xSAyzDC8Zo0gxdtoXF1djuUF3UREKCIu05F2T+mfN2W+8G+rKczQOdXff7tK3ucLhFmLc5gzUSS7lwlF3MP+UnZdyA/zt4/E7k2PCLuNV4pHHMtkGicxjU4xM3Tdo= 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-Network-Message-Id: 38213b7c-1633-4e00-ad4c-08d59a854105 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 23:39:05.3621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0822 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 23:39:11 -0000 WWVzIEkgYW0gbm90IG9wcG9zZWQgdG8gaW5jbHVkaW5nIG1pZ3JhdGlvbiBpbiBWMSBpZiBpdHMg YSBuZWdvdGlhdGVkIG9wdGlvbi4gQnkgImxlYXZlIHRoZSBkcmFmdCBhcyBpcyIgSSBtZWFudCBp dCBmb3IgY29ubmVjdGlvbnMgdGhhdCB3aWxsIG5vdCBtaWdyYXRlLiBQYXJraW5nIGxvdCBwcm9i bGVtLyBtaWdyYXRpb24gIGRvZXNu4oCZdCBhcHBseSB0bzogZGV2aWNlcyBjb25uZWN0ZWQgdG8g anVzdCBvbmUgbmV0d29yaywgT1MgcG9saWN5IHByZXZlbnRpbmcgYWdncmVzc2l2ZSB1c2Ugb2Yg bWV0ZXJlZCBuZXR3b3JrcywgZGVza3RvcHMgYW5kIGxhcHRvcHMgd2l0aCBqdXN0IHdpZmkgb3Ig ZXRoZXJuZXQsIGFsbCBkYXRhY2VudGVyIHNlcnZlcnMsIGFuZCBJbnRlcm5ldCBmYWNpbmcgc2Vy dmVycyBiZWhpbmQgbGVnYWN5IGxvYWQgYmFsYW5jZXJzLiBJdOKAmXMgbm90IHVuaXZlcnNhbC4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcmsgTm90dGluZ2hhbSBbbWFp bHRvOm1ub3RAbW5vdC5uZXRdIA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDE4IDQ6Mjcg UE0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4NCkNj OiBJYW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz47IExhcnMg RWdnZXJ0IDxsYXJzQGVnZ2VydC5vcmc+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBN aXJqYSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPg0KU3ViamVj dDogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0K DQpIaSBQcmF2ZWVuLA0KDQpPbiA1IEFwciAyMDE4LCBhdCA5OjIyIGFtLCBQcmF2ZWVuIEJhbGFz dWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+IA0KPiBQTkUgaXMgb25l IHdheSBmb3J3YXJkIGZvciBkb2luZyBjb25uZWN0aW9uIG1pZ3JhdGlvbiB3aXRob3V0IGxpbmth YmlsaXR5LiBJIHdvdWxkbuKAmXQgY2FsbCBpdCB0aGUgbW9zdCBwcmFnbWF0aWMgc2luY2UgaXQg aGFzIHBlcmZvcm1hbmNlIGltcGxpY2F0aW9ucy4NCj4gIA0KPiBBbnkgb2JqZWN0aW9ucyB0byB0 aGUgZm9sbG93aW5nPw0KPiAxLiBMZWF2ZSB0aGUgY3VycmVudCBkcmFmdCBhcyBpcyBmb3IgdGhl IGNvbW1vbiBjYXNlIChubyBtaWdyYXRpb24gbm8gbXVsdGlwYXRoKS4NCg0KSnVzdCBub3Rpbmcg LS0gb25lIG9mIHRoZSB0aGluZ3MgdGhhdCBjYW1lIHVwIGluIE1lbGJvdXJuZSB3YXMgdGhhdCBt aWdyYXRpb24gZm9yIHRoZSAicGFya2luZyBsb3QgcHJvYmxlbSIgLS0gaS5lLiwgd2lmaSB0byBj ZWxsdWxhciwgb3IgdmljZSB2ZXJzYSAtLSAqaXMqIGluLXNjb3BlIGZvciBRVUlDdjEsIGluIG1h bnkgcGVvcGxlJ3MgbWluZHMuIA0KDQo+IE1ha2Ugc3VyZSB3ZSBoYXZlIHNvbWUgcHJvdmlzaW9u IGZvciBncmVhc2luZyB0aGUgUE4gdG8gcHJldmVudCBvc3NpZmljYXRpb24uIElmIFBOIGp1bXBz IGFyZSBuZWVkZWQgZm9yIHRoaXMgKGFwYXJ0IGZyb20gYSByYW5kb20gc3RhcnRpbmcgUE4pIHdl IHNob3VsZCBoYXZlIGEgUFIgbW9kaWZ5aW5nIGN1cnJlbnQgZHJhZnQuDQo+IDIuIEZvciBjb25u ZWN0aW9uIG1pZ3JhdGlvbiB0aGUgb3B0aW9ucyBhcmU6DQo+IGEuIEV4cGxvcmUgbXVsdGlwbGUg UE4gc3BhY2VzIGZvciBjb25uZWN0aW9uIG1pZ3JhdGlvbiAoYW5kIGV2ZW50dWFsbHkgDQo+IG11 bHRpcGF0aCksIE9SIGIuIE1ha2UgUE5FIChhbmQgaGVuY2UgY29ubmVjdGlvbiBtaWdyYXRpb24p IGFuIG9wdGlvbmFsIG5lZ290aWF0ZWQgZXh0ZW5zaW9uIGluIFYxIHdpdGggdGhlIGNhdmVhdCB0 aGF0IHdlIHdpbGwgIHJldmlzaXQgdGhpcyAgZm9yIFYyIHdoZW4gd2UgZG8gbXVsdGlwYXRoLiBU aGlzIGlzIHJlcXVpcmVkIGFueXdheXMgYmVjYXVzZSBzZXJ2ZXJzIG11c3QgYmUgYWJsZSB0byB0 ZWxsIGNsaWVudCB0aGF0IHRoZXkgY2Fubm90IHN1cHBvcnQgbWlncmF0aW9uIHNpbmNlIHRoZXkg YXJlIGJlaGluZCBhIGxlZ2FjeSBsb2FkIGJhbGFuY2VyLg0KDQotLQ0KTWFyayBOb3R0aW5naGFt ICAgaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cubW5vdC5uZXQlMkYmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3Nv ZnQuY29tJTdDMWFjMTcwOGMyZjAyNGQzY2U5NjYwOGQ1OWE4M2EwMTAlN0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTg0ODEyNDgzNTg2NzQ2JnNkYXRhPXBN VnNueXNDa0ZGa3ZzbUZqYUR3dURXS3NoUEJ5Y1c4WERZYkE3MHNVM0ElM0QmcmVzZXJ2ZWQ9MA0K DQo= From nobody Wed Apr 4 16:39:18 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8190D12D880 for ; Wed, 4 Apr 2018 16:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522885151; bh=KqNDlV/G3Q+MEVUr4PEHuzp0BpgXV0/hXXpOMIKfKVE=; h=From:To:Subject:Date:References:In-Reply-To:Cc:Cc:Cc:Cc; b=UfIJ+IIsc4Bw0+Ss3J98b2O9vnqcNDZdfSKAv8RqTf2E3cOULRLi6rG0oM81CrgGa /7U3ViaW0pmqr8Yq+av8vN9XLUCs8g3xOMLnxjTcHfu8qE+Fk0U9P5N2KvOgk59Iah yAthFLVZOK/P/jqWeo7zDE+ocb7OJHqHe6zqxIWs= X-Mailbox-Line: From pravb@microsoft.com Wed Apr 4 16:39:11 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 352D51200A0; Wed, 4 Apr 2018 16:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522885151; bh=KqNDlV/G3Q+MEVUr4PEHuzp0BpgXV0/hXXpOMIKfKVE=; h=From:To:Subject:Date:References:In-Reply-To:Cc:Cc:Cc:Cc; b=UfIJ+IIsc4Bw0+Ss3J98b2O9vnqcNDZdfSKAv8RqTf2E3cOULRLi6rG0oM81CrgGa /7U3ViaW0pmqr8Yq+av8vN9XLUCs8g3xOMLnxjTcHfu8qE+Fk0U9P5N2KvOgk59Iah yAthFLVZOK/P/jqWeo7zDE+ocb7OJHqHe6zqxIWs= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18085127909 for ; Wed, 4 Apr 2018 16:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 T6r4QcbLwl00 for ; Wed, 4 Apr 2018 16:39:08 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on070a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::70a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021671200A0 for ; Wed, 4 Apr 2018 16:39:07 -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=KqNDlV/G3Q+MEVUr4PEHuzp0BpgXV0/hXXpOMIKfKVE=; b=G+cOLTVcgYTohvP0c24hjFz3DBloxzlqM7rG7m/qUJQUlNCPp/51Ya6eSYO6DbAByyH7YLdoJIQVzgKOXxCB2HvSqM1PEiOu1CUxbj5Otp9xM+xgCPNMI/SsbJ+ndqhOsgvC0cjasvSeSgZCqDiaLvW8qNiia9PNqhuZvy9PXDQ= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0822.namprd21.prod.outlook.com (10.173.192.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 23:39:05 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 23:39:05 +0000 From: Praveen Balasubramanian To: Mark Nottingham Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwZ0sAgAC4ugCAAARcAIAAFTbwgAAHuICAAAJF8A== Date: Wed, 4 Apr 2018 23:39:05 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <9F724A02-0131-43DB-B1D1-0BFCEEE898D5@mnot.net> In-Reply-To: <9F724A02-0131-43DB-B1D1-0BFCEEE898D5@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0822; 7:X2VkQJOA2UrTVwN7E3IVC73ZwnbfJ9jyKmAE/Z4DVBxkbALeKaxfSYWOxNBb9TIxkppTaDCA2SLBygRXLJHLAcpuUKrngpKwNc7XX1vPXWYHaW9dJ5fGjmiJUNxtgu04dUS637tM4HZF8g8Q/1y49o3X/TnwpcVMCLS4SjqG+dyogEccnnG8wxRJw27qkCkHXhSWzCAacztM/+yTNHwIUF4d1P7aZVqpdMnYV6gjHdwO0Ns06Wg07UfopP7g6Q+O; 20:agkVid5YADXqtcD4PxqWUEQ+XuJjhLjruOwSXGCt+6rh2of5gxl+BWQQSUtR4a5cjjcc2v6fUVNSYTzT8YIWUbBqiGciRMbQDb5CQ3gdEfaq2CpW5RaHj7Nogtv9PJI/foxNxw5X3ehdbDT9qE2akxtt5VGEnmCsMQeih8GPtLU= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 38213b7c-1633-4e00-ad4c-08d59a854105 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0822; x-ms-traffictypediagnostic: CY4PR21MB0822: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(189930954265078)(100405760836317)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0822; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0822; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(346002)(366004)(396003)(376002)(13464003)(199004)(189003)(53546011)(6506007)(102836004)(54906003)(6116002)(186003)(11346002)(446003)(99286004)(93886005)(25786009)(10290500003)(476003)(486006)(46003)(6436002)(4326008)(7696005)(76176011)(106356001)(86612001)(33656002)(9686003)(55016002)(6306002)(97736004)(14454004)(3280700002)(68736007)(53936002)(2900100001)(5660300001)(81166006)(81156014)(105586002)(8676002)(8936002)(74316002)(6246003)(10090500001)(8990500004)(2906002)(86362001)(3660700001)(229853002)(22452003)(316002)(5250100002)(478600001)(6916009)(966005)(7736002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0822; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: qu5KjDgK/HUGMfWsz9szXCige3PIvevJhzKZ3zOLMHjjXubgNskw0IBRtxxBHI4E+IOlthf9NR3Tgm2eQ6+PciMS7AdpUTOOpzymlPpyXVIh0FxhJG5uVYfcnF3RFv6G2bb2n/AtcoyQXRNArlBk1LD6XuUDB0Y9LeX5yT8aYQqepk3rxW2nS8mGvnkXsLtsdIkVWhRVrvRtFDxq7jYVX/ieyfDUqjP4AeA1jMKbHIxn92QImD7b1gm2ToS8+FjIsswbpFSVC8ya3vE08z6sx1sUQZtCVY/5HWtL7x/ENLOU94xSAyzDC8Zo0gxdtoXF1djuUF3UREKCIu05F2T+mfN2W+8G+rKczQOdXff7tK3ucLhFmLc5gzUSS7lwlF3MP+UnZdyA/zt4/E7k2PCLuNV4pHHMtkGicxjU4xM3Tdo= 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-Network-Message-Id: 38213b7c-1633-4e00-ad4c-08d59a854105 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 23:39:05.3621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0822 Cc: Ian Swett Cc: Lars Eggert Cc: IETF QUIC WG Cc: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 23:39:11 -0000 WWVzIEkgYW0gbm90IG9wcG9zZWQgdG8gaW5jbHVkaW5nIG1pZ3JhdGlvbiBpbiBWMSBpZiBpdHMg YSBuZWdvdGlhdGVkIG9wdGlvbi4gQnkgImxlYXZlIHRoZSBkcmFmdCBhcyBpcyIgSSBtZWFudCBp dCBmb3IgY29ubmVjdGlvbnMgdGhhdCB3aWxsIG5vdCBtaWdyYXRlLiBQYXJraW5nIGxvdCBwcm9i bGVtLyBtaWdyYXRpb24gIGRvZXNu4oCZdCBhcHBseSB0bzogZGV2aWNlcyBjb25uZWN0ZWQgdG8g anVzdCBvbmUgbmV0d29yaywgT1MgcG9saWN5IHByZXZlbnRpbmcgYWdncmVzc2l2ZSB1c2Ugb2Yg bWV0ZXJlZCBuZXR3b3JrcywgZGVza3RvcHMgYW5kIGxhcHRvcHMgd2l0aCBqdXN0IHdpZmkgb3Ig ZXRoZXJuZXQsIGFsbCBkYXRhY2VudGVyIHNlcnZlcnMsIGFuZCBJbnRlcm5ldCBmYWNpbmcgc2Vy dmVycyBiZWhpbmQgbGVnYWN5IGxvYWQgYmFsYW5jZXJzLiBJdOKAmXMgbm90IHVuaXZlcnNhbC4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcmsgTm90dGluZ2hhbSBbbWFp bHRvOm1ub3RAbW5vdC5uZXRdIA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDE4IDQ6Mjcg UE0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4NCkNj OiBJYW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz47IExhcnMg RWdnZXJ0IDxsYXJzQGVnZ2VydC5vcmc+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBN aXJqYSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPg0KU3ViamVj dDogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0K DQpIaSBQcmF2ZWVuLA0KDQpPbiA1IEFwciAyMDE4LCBhdCA5OjIyIGFtLCBQcmF2ZWVuIEJhbGFz dWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+IA0KPiBQTkUgaXMgb25l IHdheSBmb3J3YXJkIGZvciBkb2luZyBjb25uZWN0aW9uIG1pZ3JhdGlvbiB3aXRob3V0IGxpbmth YmlsaXR5LiBJIHdvdWxkbuKAmXQgY2FsbCBpdCB0aGUgbW9zdCBwcmFnbWF0aWMgc2luY2UgaXQg aGFzIHBlcmZvcm1hbmNlIGltcGxpY2F0aW9ucy4NCj4gIA0KPiBBbnkgb2JqZWN0aW9ucyB0byB0 aGUgZm9sbG93aW5nPw0KPiAxLiBMZWF2ZSB0aGUgY3VycmVudCBkcmFmdCBhcyBpcyBmb3IgdGhl IGNvbW1vbiBjYXNlIChubyBtaWdyYXRpb24gbm8gbXVsdGlwYXRoKS4NCg0KSnVzdCBub3Rpbmcg LS0gb25lIG9mIHRoZSB0aGluZ3MgdGhhdCBjYW1lIHVwIGluIE1lbGJvdXJuZSB3YXMgdGhhdCBt aWdyYXRpb24gZm9yIHRoZSAicGFya2luZyBsb3QgcHJvYmxlbSIgLS0gaS5lLiwgd2lmaSB0byBj ZWxsdWxhciwgb3IgdmljZSB2ZXJzYSAtLSAqaXMqIGluLXNjb3BlIGZvciBRVUlDdjEsIGluIG1h bnkgcGVvcGxlJ3MgbWluZHMuIA0KDQo+IE1ha2Ugc3VyZSB3ZSBoYXZlIHNvbWUgcHJvdmlzaW9u IGZvciBncmVhc2luZyB0aGUgUE4gdG8gcHJldmVudCBvc3NpZmljYXRpb24uIElmIFBOIGp1bXBz IGFyZSBuZWVkZWQgZm9yIHRoaXMgKGFwYXJ0IGZyb20gYSByYW5kb20gc3RhcnRpbmcgUE4pIHdl IHNob3VsZCBoYXZlIGEgUFIgbW9kaWZ5aW5nIGN1cnJlbnQgZHJhZnQuDQo+IDIuIEZvciBjb25u ZWN0aW9uIG1pZ3JhdGlvbiB0aGUgb3B0aW9ucyBhcmU6DQo+IGEuIEV4cGxvcmUgbXVsdGlwbGUg UE4gc3BhY2VzIGZvciBjb25uZWN0aW9uIG1pZ3JhdGlvbiAoYW5kIGV2ZW50dWFsbHkgDQo+IG11 bHRpcGF0aCksIE9SIGIuIE1ha2UgUE5FIChhbmQgaGVuY2UgY29ubmVjdGlvbiBtaWdyYXRpb24p IGFuIG9wdGlvbmFsIG5lZ290aWF0ZWQgZXh0ZW5zaW9uIGluIFYxIHdpdGggdGhlIGNhdmVhdCB0 aGF0IHdlIHdpbGwgIHJldmlzaXQgdGhpcyAgZm9yIFYyIHdoZW4gd2UgZG8gbXVsdGlwYXRoLiBU aGlzIGlzIHJlcXVpcmVkIGFueXdheXMgYmVjYXVzZSBzZXJ2ZXJzIG11c3QgYmUgYWJsZSB0byB0 ZWxsIGNsaWVudCB0aGF0IHRoZXkgY2Fubm90IHN1cHBvcnQgbWlncmF0aW9uIHNpbmNlIHRoZXkg YXJlIGJlaGluZCBhIGxlZ2FjeSBsb2FkIGJhbGFuY2VyLg0KDQotLQ0KTWFyayBOb3R0aW5naGFt ICAgaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cubW5vdC5uZXQlMkYmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3Nv ZnQuY29tJTdDMWFjMTcwOGMyZjAyNGQzY2U5NjYwOGQ1OWE4M2EwMTAlN0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTg0ODEyNDgzNTg2NzQ2JnNkYXRhPXBN VnNueXNDa0ZGa3ZzbUZqYUR3dURXS3NoUEJ5Y1c4WERZYkE3MHNVM0ElM0QmcmVzZXJ2ZWQ9MA0K DQo= From nobody Wed Apr 4 16:40:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02345127909 for ; Wed, 4 Apr 2018 16:40:30 -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 pkkl0aqY6SSL for ; Wed, 4 Apr 2018 16:40:28 -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 384BF126C2F for ; Wed, 4 Apr 2018 16:40:28 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id d5so28363276iob.9 for ; Wed, 04 Apr 2018 16:40:28 -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=XF4xzNHVMtk1f72oQ662Z/5AfOktPn0FCHnbuHF0ynQ=; b=Y8fZSnDjJ8fZdoa4Tr4LA50O4M/3GBOGL7jqfODCAUZDeGguoZ5LjC9vV63pAVLeLc F9QbBDQ7Dch9r8cz9v4TKpwU+vt6XpSw7y3Lk++WkWQEts37HAH1QyKPNgMmnA2bWfY+ Iq1Th7oSFnwwNtW2fUY8wL1SdzZGO/kWbGK/nbt7XhpBWc8jQ7XC18WSixPT97au/TKt 7CFU1kGzF0Xi/vZxHm6mGXFwjtFOSEIPRW1ZPfSl1KQzU2T27PpsKVaQl2exnprnM9J3 96N/B617G1iENTAuia5u/NF8MIkQ4t/g8DXhIrRLS99NSNrzmiMjigJAtYHJg3d7Gt1Y eK5A== 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=XF4xzNHVMtk1f72oQ662Z/5AfOktPn0FCHnbuHF0ynQ=; b=ME72RsDpkJYO2faPgpEx8S3uvNW82r4RiVbBynGFfkj3vHqVwnkImEB6q2TlPSuAYw giUVxa11GsjKOATlGO1/zIcZTkoViONPyY9rvM/jQeo8XT5qErK8RxlQYsK7ye3NQvZy 38QSw/9tVBljlM0Xl7+BaSNcjURViQXkFhuCrrexPKwGHmXZ5RGjZaxwWlSdT7xJGlJ5 Nr1xHsc23M3RXEjBAbyhEr7Tw1K5TZZer8mRfXX4nuxLtvFs59H0JIOyKa5e6kk7O9tt KbhezMEjJ/DWrmrTZifzzU+l7kEERHNpqMO7CqdaLyzvGaH2HZQCrOIaoJjIJppfTPr8 jFrw== X-Gm-Message-State: ALQs6tAFpwInaQWlDR21GqU7KOU7PhLSAnccWZ8dnmsD8W26+Jl3CNDS G3GvxLNLO0bt2muWfd03xJ3PFC8KsGwo2fd00Po= X-Google-Smtp-Source: AIpwx48beI+xl+hGF5kJ925mI2Euqg659rXSS2e4cv1fNb0qbD7Sr8L+iueXb0ozUMZTowm/fm/OcK0CnN+PBzs1CoY= X-Received: by 10.107.14.12 with SMTP id 12mr17655748ioo.209.1522885227616; Wed, 04 Apr 2018 16:40:27 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 5 Apr 2018 01:40:26 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 5 Apr 2018 01:40:26 +0200 Message-ID: Subject: RE: Getting to consensus on packet number encryption To: Praveen Balasubramanian , Ian Swett , Mark Nottingham Cc: Lars Eggert , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113fa9b0069db905690e59ec" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 23:40:30 -0000 --001a113fa9b0069db905690e59ec Content-Type: text/plain; charset="UTF-8" Without pro / con anything: Optional privacy does not work. In part it cannot be retrofitted when the need arise, in part it can be incriminating to enable. On 5 April 2018 at 01.22.38, Praveen Balasubramanian ( pravb=40microsoft.com@dmarc.ietf.org) wrote: Make PNE (and hence connection migration) an optional negotiated extension in V1 --001a113fa9b0069db905690e59ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Without pro / con an= ything:

<= /div>
Optional priv= acy does not work. In part it cannot be retrofitted when the need arise, in= part it can be incriminating to enable.

On 5 April 2018 at 01.22.38, Praveen Balasubramanian (<= a href=3D"mailto:pravb=3D40microsoft.com@dmarc.ietf.org">pravb=3D40microsof= t.com@dmarc.ietf.org) wrote:
Make PNE (and hen= ce connection migration) an optional negotiated extension in V1=C2=A0
--001a113fa9b0069db905690e59ec-- From nobody Wed Apr 4 16:40:41 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 162C2126C2F for ; Wed, 4 Apr 2018 16:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522885231; bh=XF4xzNHVMtk1f72oQ662Z/5AfOktPn0FCHnbuHF0ynQ=; h=From:In-Reply-To:References:Date:Subject:Cc:To:To:To; b=Bfc5uzlxZiHT0uGPzlpjtU2E4OPKrrsxE32Vuhu5kPsYGp6+/rOjrDpez2qJ8w8vD qqPfeZBiD2uPpkz8JjgL18ye9rtH4aTLmPSkRKQGisSqwXnSmm2xNVRnahxTWdqcAl ZON4Nkha0V4CXxT2CdqpSkc9jSF7zxfXku5ROHUI= X-Mailbox-Line: From mikkelfj@gmail.com Wed Apr 4 16:40:30 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D450D126FB3; Wed, 4 Apr 2018 16:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522885230; bh=XF4xzNHVMtk1f72oQ662Z/5AfOktPn0FCHnbuHF0ynQ=; h=From:In-Reply-To:References:Date:Subject:Cc:To:To:To; b=lHN5G7awO8IMG8oXNJhm7I4ewYHWuulZBi8Z/76EtOs7e/vqobw6pYHUBsCNWYKGb cxfjP7fLgxO3qhcSMKYGIYtfVBfMj7WqxtNleVJ8qfXv8fkIGSglEn1kOnBoY4AU2Z vL34NHJZD3fm0C0DiW8f8FOF4mVp0fb1zqcGXR0o= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2628126C2F; Wed, 4 Apr 2018 16:40:30 -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=unavailable 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 lT0dpXJMVt3k; Wed, 4 Apr 2018 16:40:28 -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 7F6CB126FB3; Wed, 4 Apr 2018 16:40:28 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id x77so22132118ioi.2; Wed, 04 Apr 2018 16:40:28 -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=XF4xzNHVMtk1f72oQ662Z/5AfOktPn0FCHnbuHF0ynQ=; b=Y8fZSnDjJ8fZdoa4Tr4LA50O4M/3GBOGL7jqfODCAUZDeGguoZ5LjC9vV63pAVLeLc F9QbBDQ7Dch9r8cz9v4TKpwU+vt6XpSw7y3Lk++WkWQEts37HAH1QyKPNgMmnA2bWfY+ Iq1Th7oSFnwwNtW2fUY8wL1SdzZGO/kWbGK/nbt7XhpBWc8jQ7XC18WSixPT97au/TKt 7CFU1kGzF0Xi/vZxHm6mGXFwjtFOSEIPRW1ZPfSl1KQzU2T27PpsKVaQl2exnprnM9J3 96N/B617G1iENTAuia5u/NF8MIkQ4t/g8DXhIrRLS99NSNrzmiMjigJAtYHJg3d7Gt1Y eK5A== 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=XF4xzNHVMtk1f72oQ662Z/5AfOktPn0FCHnbuHF0ynQ=; b=ZZnBOWmlzjHunDF3B5XZSZVLCBflZTYFjM+op8vOrPHkLbEPfJqcrSMoonYx3DszbC S4MFgCjgIUHQQVbb7WaWJ2415GpO7VA7eCvj/NrT0plP+wv9B0j4+nJwUF4LDlWteRNG 8bHZmYxhXdg+qjJLb/W8DgK5kZgDdlzdALAq2GxNHDLExhYTC9OlHWYtkBvYHvW/kjum zpauKFhoBP5J05vtva+M+BG3iUHUgambyxp+s6JwPbfDUF+E/pOudbBGj5zd/Z9g0PfI 9e2eOgyMxCVTmmwCjq+8meAPcmTzt+x5S+nEJCUowvtkF3w8VKQyQQzygYc9rmcxJkgB i8Tg== X-Gm-Message-State: ALQs6tAXQuBrcVUmL9Zcsm6VDnyNOJkPRV/UFo8xKxbQmTDfcT5PZLsx Iwe1ZnsTGcCFv2uLSkdEi2qMypqXD3QPs0oxfWyZo8r4 X-Google-Smtp-Source: AIpwx48beI+xl+hGF5kJ925mI2Euqg659rXSS2e4cv1fNb0qbD7Sr8L+iueXb0ozUMZTowm/fm/OcK0CnN+PBzs1CoY= X-Received: by 10.107.14.12 with SMTP id 12mr17655748ioo.209.1522885227616; Wed, 04 Apr 2018 16:40:27 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 5 Apr 2018 01:40:26 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 5 Apr 2018 01:40:26 +0200 Message-ID: Subject: RE: Getting to consensus on packet number encryption Cc: Lars Eggert , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113fa9b0069db905690e59ec" To: Praveen Balasubramanian To: Ian Swett To: Mark Nottingham Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 23:40:31 -0000 --001a113fa9b0069db905690e59ec Content-Type: text/plain; charset="UTF-8" Without pro / con anything: Optional privacy does not work. In part it cannot be retrofitted when the need arise, in part it can be incriminating to enable. On 5 April 2018 at 01.22.38, Praveen Balasubramanian ( pravb=40microsoft.com@dmarc.ietf.org) wrote: Make PNE (and hence connection migration) an optional negotiated extension in V1 --001a113fa9b0069db905690e59ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Without pro / con an= ything:

<= /div>
Optional priv= acy does not work. In part it cannot be retrofitted when the need arise, in= part it can be incriminating to enable.

On 5 April 2018 at 01.22.38, Praveen Balasubramanian (<= a href=3D"mailto:pravb=3D40microsoft.com@dmarc.ietf.org">pravb=3D40microsof= t.com@dmarc.ietf.org) wrote:
Make PNE (and hen= ce connection migration) an optional negotiated extension in V1=C2=A0
--001a113fa9b0069db905690e59ec-- From nobody Wed Apr 4 16:42:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B357127909 for ; Wed, 4 Apr 2018 16:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522885346; bh=+butTXL5SPoWoQ6K5Ja5XkbLvM5X5y05RVFLsBGnl+8=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To:To; b=f0fPBKSTl/OQycuQZcPYHczDeznDHnXLQV5sR9ra/sYnls8R3L+YW8XItSeEaajbE PSoet2uyIbaO8348mSEzLAXWOFvgXOl+Q7sg+RNyp8pd+m3gvWbmNJZ0w7Nymxb/rR V/3PaXHr2XT0Sq4CUrJFYXFQbrNVKpPK//XNFxVI= X-Mailbox-Line: From pravb@microsoft.com Wed Apr 4 16:42:26 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E38E0126C2F; Wed, 4 Apr 2018 16:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522885345; bh=+butTXL5SPoWoQ6K5Ja5XkbLvM5X5y05RVFLsBGnl+8=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To:To; b=s8cEkcWv6Hw1wOsnsTZimSerxNZWUP2oHBAnU7a11dY7AqBE/8U965HbCRVtfd6vn Wz8zFyxgybqIMisCQEOJw8frtVqKwvdpOmS2QddmNOcNRnA8FjNlEwNTw3EQ+MwSAN ecMzHw3OXi2PXZQ1kPumUr/ZsXnuk/1gqQBc4BLw= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90C0126FB3; Wed, 4 Apr 2018 16:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 yUd6kmDppxX8; Wed, 4 Apr 2018 16:42:24 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on071a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe44::71a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDE7126C2F; Wed, 4 Apr 2018 16:42:24 -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=+butTXL5SPoWoQ6K5Ja5XkbLvM5X5y05RVFLsBGnl+8=; b=JX3PB1vVZruPcxW5MroFQ0ZhiKvFEhXxQXy7AqGorj/XACwjFjhfMsEOz3NTChL4wATie0MyhwYQomeAw8RvkqgeP6elVBDJKkW8nYdqLlDmCDWf5XERx8QzuHdb/aAToB2JJ6GhW389FCg/cMYU1h36g0s68u9TlUPFTVc3h4s= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 23:42:21 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 23:42:21 +0000 From: Praveen Balasubramanian CC: Lars Eggert , IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwZ0sAgAC4ugCAAARcAIAAFTbwgAALYgCAAAAgYA== Date: Wed, 4 Apr 2018 23:42:21 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0504; 7:MABVt17fEmZmb+o1Q7Vg9GWTsX9ujZSCzMT8bM4WR5uEyUeJES0hXeDWdYvy39LDEBodnlT8Xfp+N0LXTVAncvwTtEH1KSEZMAQFLCL5iT8L+MhhOFd3a1L9fP10Bvcfe8dZOx8SnOjUJqepyyvT6qSLGRrQNGAwx2iP1ntBhjD3rWQLl2Fiyei9/eubsZvT9lU/HjmRdu0AQX8Htc8gXUntigBEx+4ssZ02XOoVXVb4nCwufglAkw9887eXOlU2; 20:IZbv9dKshaXsqIR/XE34lxFzYe0TBKUVuh2hIADWsCimpYdUASOczOkLATWqt+J6PZ7x8xqNzsO0MdfRIQYx/rvY91dpMBcXXYv3tfDFdL3jXz69prT/ROcvdQtYJvtJ+1wbe1S6ZiDfYlfa24aF/Jwkj/wKpEoMyEH4CYEQc7M= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c7f65638-6851-40f1-bd57-08d59a85b619 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0504; x-ms-traffictypediagnostic: CY4PR21MB0504: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0504; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0504; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(376002)(396003)(39380400002)(189003)(199004)(8936002)(22452003)(86362001)(81156014)(81166006)(186003)(4326008)(790700001)(39060400002)(86612001)(316002)(6246003)(68736007)(6436002)(7736002)(8990500004)(53936002)(54896002)(236005)(6306002)(9686003)(55016002)(93886005)(74316002)(2900100001)(33656002)(106356001)(478600001)(5660300001)(229853002)(53546011)(102836004)(6506007)(10290500003)(7696005)(3280700002)(76176011)(19609705001)(14454004)(5250100002)(10090500001)(2906002)(3660700001)(99286004)(6116002)(11346002)(8676002)(25786009)(110136005)(476003)(105586002)(97736004)(486006)(54906003)(446003)(46003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0504; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: OrClT9vkKt8GgXXXjnWkpgjl1eg3tpqa3TjccbZ3xEE2c7GBuFmx8M3Llg6WrLrGCZRMRSru6uk4XkdII8wPxlti75c+xM09hG9U4e6lo6wlswFa8On11s+PsxYDq5I+//mAwJ8F5Y2WqYg1r9pps2FJlNaURU/ATWjhBGEPbyYm7MSCDblfo5wpn4n/gFYxfzA5xLY3LB226nKs7SKgFb8xca1fchWLXpidZOwF2X5HDaFeVWMlAA0zKWXxUc2+AEEeXl7ev0FKc9ltFbYRPMVmYCHtx50BT2VLLmVuN2YUXpasOT+oYaWFaYnNaUBFK9OkMcF22K01hpJGoLEjShapFl3bdwoVXkgqP6yWsRohA4MUEX48WhGVmvFl3XUe5d2q9QTxytMiNN9wI0h1oCcYWSroEzjNvqJaKZ9BLHc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40CY4PR21MB0630namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c7f65638-6851-40f1-bd57-08d59a85b619 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 23:42:21.7379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0504 To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= To: Praveen Balasubramanian To: Ian Swett To: Mark Nottingham Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 23:42:26 -0000 --_000_CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40CY4PR21MB0630namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBpcyB0aGUgcHJpdmFjeSBpc3N1ZSBpZiB5b3UgYXJlIG5vdCBkb2luZyBtaWdyYXRpb24/ IE1pZ3JhdGlvbiArIFBORSAob3IgbXVsdGlwbGUgUE4gc3BhY2VzKSBzaG91bGQgZ28gaGFuZCBp biBoYW5kLg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KU2VudDogV2VkbmVzZGF5LCBBcHJp bCA0LCAyMDE4IDQ6NDAgUE0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmI9NDBt aWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdvb2ds ZS5jb21AZG1hcmMuaWV0Zi5vcmc+OyBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ+DQpD YzogTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRm Lm9yZz47IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+ DQpTdWJqZWN0OiBSRTogR2V0dGluZyB0byBjb25zZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNy eXB0aW9uDQoNCldpdGhvdXQgcHJvIC8gY29uIGFueXRoaW5nOg0KDQpPcHRpb25hbCBwcml2YWN5 IGRvZXMgbm90IHdvcmsuIEluIHBhcnQgaXQgY2Fubm90IGJlIHJldHJvZml0dGVkIHdoZW4gdGhl IG5lZWQgYXJpc2UsIGluIHBhcnQgaXQgY2FuIGJlIGluY3JpbWluYXRpbmcgdG8gZW5hYmxlLg0K DQpPbiA1IEFwcmlsIDIwMTggYXQgMDEuMjIuMzgsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIChw cmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnByYXZiPTQwbWljcm9z b2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4pIHdyb3RlOg0KTWFrZSBQTkUgKGFuZCBoZW5jZSBjb25u ZWN0aW9uIG1pZ3JhdGlvbikgYW4gb3B0aW9uYWwgbmVnb3RpYXRlZCBleHRlbnNpb24gaW4gVjEN Cg== --_000_CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40CY4PR21MB0630namp_ 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 emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBw bGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFj ZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XaGF0IGlzIHRoZSBwcml2YWN5IGlzc3VlIGlmIHlvdSBhcmUgbm90IGRvaW5n IG1pZ3JhdGlvbj8gTWlncmF0aW9uICYjNDM7IFBORSAob3IgbXVsdGlwbGUgUE4gc3BhY2VzKSBz aG91bGQgZ28gaGFuZCBpbiBoYW5kLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+TWlra2VsIEZhaG7DuGUgSsO4 cmdlbnNlbjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTggNDo0MCBQ TTxicj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiPTQwbWlj cm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs7IElhbiBTd2V0dCAmbHQ7aWFuc3dldHQ9NDBn b29nbGUuY29tQGRtYXJjLmlldGYub3JnJmd0OzsgTWFyayBOb3R0aW5naGFtICZsdDttbm90QG1u b3QubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTGFycyBFZ2dlcnQgJmx0O2xhcnNAZWdnZXJ0Lm9y ZyZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1pcmphIEvDvGhsZXdp bmQgJmx0O21pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gmZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJFOiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5cHRp b248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldpdGhvdXQgcHJvIC8gY29uIGFueXRo aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9t Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PcHRpb25hbCBwcml2YWN5 IGRvZXMgbm90IHdvcmsuIEluIHBhcnQgaXQgY2Fubm90IGJlIHJldHJvZml0dGVkIHdoZW4gdGhl IG5lZWQgYXJpc2UsIGluIHBhcnQgaXQgY2FuIGJlIGluY3JpbWluYXRpbmcgdG8gZW5hYmxlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiA1IEFwcmlsIDIwMTggYXQgMDEu MjIuMzgsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICg8YSBocmVmPSJtYWlsdG86cHJhdmI9NDBt aWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIj5wcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMu aWV0Zi5vcmc8L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3Jv dW5kOndoaXRlIj5NYWtlIFBORSAoYW5kIGhlbmNlIGNvbm5lY3Rpb24gbWlncmF0aW9uKSBhbiBv cHRpb25hbCBuZWdvdGlhdGVkIGV4dGVuc2lvbiBpbiBWMTxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40CY4PR21MB0630namp_-- From nobody Wed Apr 4 16:42:35 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D965E126C2F for ; Wed, 4 Apr 2018 16:42:26 -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=unavailable 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 qvpklaEwEvZV for ; Wed, 4 Apr 2018 16:42:23 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0124.outbound.protection.outlook.com [104.47.36.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C10B21200A0 for ; Wed, 4 Apr 2018 16:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+butTXL5SPoWoQ6K5Ja5XkbLvM5X5y05RVFLsBGnl+8=; b=JX3PB1vVZruPcxW5MroFQ0ZhiKvFEhXxQXy7AqGorj/XACwjFjhfMsEOz3NTChL4wATie0MyhwYQomeAw8RvkqgeP6elVBDJKkW8nYdqLlDmCDWf5XERx8QzuHdb/aAToB2JJ6GhW389FCg/cMYU1h36g0s68u9TlUPFTVc3h4s= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 23:42:21 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 23:42:21 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Praveen Balasubramanian , Ian Swett , Mark Nottingham CC: Lars Eggert , IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwZ0sAgAC4ugCAAARcAIAAFTbwgAALYgCAAAAgYA== Date: Wed, 4 Apr 2018 23:42:21 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0504; 7:MABVt17fEmZmb+o1Q7Vg9GWTsX9ujZSCzMT8bM4WR5uEyUeJES0hXeDWdYvy39LDEBodnlT8Xfp+N0LXTVAncvwTtEH1KSEZMAQFLCL5iT8L+MhhOFd3a1L9fP10Bvcfe8dZOx8SnOjUJqepyyvT6qSLGRrQNGAwx2iP1ntBhjD3rWQLl2Fiyei9/eubsZvT9lU/HjmRdu0AQX8Htc8gXUntigBEx+4ssZ02XOoVXVb4nCwufglAkw9887eXOlU2; 20:IZbv9dKshaXsqIR/XE34lxFzYe0TBKUVuh2hIADWsCimpYdUASOczOkLATWqt+J6PZ7x8xqNzsO0MdfRIQYx/rvY91dpMBcXXYv3tfDFdL3jXz69prT/ROcvdQtYJvtJ+1wbe1S6ZiDfYlfa24aF/Jwkj/wKpEoMyEH4CYEQc7M= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c7f65638-6851-40f1-bd57-08d59a85b619 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0504; x-ms-traffictypediagnostic: CY4PR21MB0504: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0504; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0504; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(376002)(396003)(39380400002)(189003)(199004)(8936002)(22452003)(86362001)(81156014)(81166006)(186003)(4326008)(790700001)(39060400002)(86612001)(316002)(6246003)(68736007)(6436002)(7736002)(8990500004)(53936002)(54896002)(236005)(6306002)(9686003)(55016002)(93886005)(74316002)(2900100001)(33656002)(106356001)(478600001)(5660300001)(229853002)(53546011)(102836004)(6506007)(10290500003)(7696005)(3280700002)(76176011)(19609705001)(14454004)(5250100002)(10090500001)(2906002)(3660700001)(99286004)(6116002)(11346002)(8676002)(25786009)(110136005)(476003)(105586002)(97736004)(486006)(54906003)(446003)(46003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0504; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: OrClT9vkKt8GgXXXjnWkpgjl1eg3tpqa3TjccbZ3xEE2c7GBuFmx8M3Llg6WrLrGCZRMRSru6uk4XkdII8wPxlti75c+xM09hG9U4e6lo6wlswFa8On11s+PsxYDq5I+//mAwJ8F5Y2WqYg1r9pps2FJlNaURU/ATWjhBGEPbyYm7MSCDblfo5wpn4n/gFYxfzA5xLY3LB226nKs7SKgFb8xca1fchWLXpidZOwF2X5HDaFeVWMlAA0zKWXxUc2+AEEeXl7ev0FKc9ltFbYRPMVmYCHtx50BT2VLLmVuN2YUXpasOT+oYaWFaYnNaUBFK9OkMcF22K01hpJGoLEjShapFl3bdwoVXkgqP6yWsRohA4MUEX48WhGVmvFl3XUe5d2q9QTxytMiNN9wI0h1oCcYWSroEzjNvqJaKZ9BLHc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40CY4PR21MB0630namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c7f65638-6851-40f1-bd57-08d59a85b619 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 23:42:21.7379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0504 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Apr 2018 23:42:27 -0000 --_000_CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40CY4PR21MB0630namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBpcyB0aGUgcHJpdmFjeSBpc3N1ZSBpZiB5b3UgYXJlIG5vdCBkb2luZyBtaWdyYXRpb24/ IE1pZ3JhdGlvbiArIFBORSAob3IgbXVsdGlwbGUgUE4gc3BhY2VzKSBzaG91bGQgZ28gaGFuZCBp biBoYW5kLg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KU2VudDogV2VkbmVzZGF5LCBBcHJp bCA0LCAyMDE4IDQ6NDAgUE0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmI9NDBt aWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdvb2ds ZS5jb21AZG1hcmMuaWV0Zi5vcmc+OyBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ+DQpD YzogTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRm Lm9yZz47IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+ DQpTdWJqZWN0OiBSRTogR2V0dGluZyB0byBjb25zZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNy eXB0aW9uDQoNCldpdGhvdXQgcHJvIC8gY29uIGFueXRoaW5nOg0KDQpPcHRpb25hbCBwcml2YWN5 IGRvZXMgbm90IHdvcmsuIEluIHBhcnQgaXQgY2Fubm90IGJlIHJldHJvZml0dGVkIHdoZW4gdGhl IG5lZWQgYXJpc2UsIGluIHBhcnQgaXQgY2FuIGJlIGluY3JpbWluYXRpbmcgdG8gZW5hYmxlLg0K DQpPbiA1IEFwcmlsIDIwMTggYXQgMDEuMjIuMzgsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIChw cmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnByYXZiPTQwbWljcm9z b2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4pIHdyb3RlOg0KTWFrZSBQTkUgKGFuZCBoZW5jZSBjb25u ZWN0aW9uIG1pZ3JhdGlvbikgYW4gb3B0aW9uYWwgbmVnb3RpYXRlZCBleHRlbnNpb24gaW4gVjEN Cg== --_000_CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40CY4PR21MB0630namp_ 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 emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBw bGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFj ZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XaGF0IGlzIHRoZSBwcml2YWN5IGlzc3VlIGlmIHlvdSBhcmUgbm90IGRvaW5n IG1pZ3JhdGlvbj8gTWlncmF0aW9uICYjNDM7IFBORSAob3IgbXVsdGlwbGUgUE4gc3BhY2VzKSBz aG91bGQgZ28gaGFuZCBpbiBoYW5kLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+TWlra2VsIEZhaG7DuGUgSsO4 cmdlbnNlbjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTggNDo0MCBQ TTxicj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiPTQwbWlj cm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs7IElhbiBTd2V0dCAmbHQ7aWFuc3dldHQ9NDBn b29nbGUuY29tQGRtYXJjLmlldGYub3JnJmd0OzsgTWFyayBOb3R0aW5naGFtICZsdDttbm90QG1u b3QubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTGFycyBFZ2dlcnQgJmx0O2xhcnNAZWdnZXJ0Lm9y ZyZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1pcmphIEvDvGhsZXdp bmQgJmx0O21pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gmZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJFOiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5cHRp b248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldpdGhvdXQgcHJvIC8gY29uIGFueXRo aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9t Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PcHRpb25hbCBwcml2YWN5 IGRvZXMgbm90IHdvcmsuIEluIHBhcnQgaXQgY2Fubm90IGJlIHJldHJvZml0dGVkIHdoZW4gdGhl IG5lZWQgYXJpc2UsIGluIHBhcnQgaXQgY2FuIGJlIGluY3JpbWluYXRpbmcgdG8gZW5hYmxlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiA1IEFwcmlsIDIwMTggYXQgMDEu MjIuMzgsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICg8YSBocmVmPSJtYWlsdG86cHJhdmI9NDBt aWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIj5wcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMu aWV0Zi5vcmc8L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3Jv dW5kOndoaXRlIj5NYWtlIFBORSAoYW5kIGhlbmNlIGNvbm5lY3Rpb24gbWlncmF0aW9uKSBhbiBv cHRpb25hbCBuZWdvdGlhdGVkIGV4dGVuc2lvbiBpbiBWMTxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40CY4PR21MB0630namp_-- From nobody Wed Apr 4 17:44:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDCB1241F3 for ; Wed, 4 Apr 2018 17:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGTJXDnmN8cx for ; Wed, 4 Apr 2018 17:44:37 -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 1CA131201F2 for ; Wed, 4 Apr 2018 17:44:36 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx61.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1f3t10-0002zT-Gk for quic@ietf.org; Thu, 05 Apr 2018 02:44:35 +0200 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f3t0x-0002o4-W4 for quic@ietf.org; Wed, 04 Apr 2018 20:44:32 -0400 Received: (qmail 25598 invoked from network); 5 Apr 2018 00:44:28 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.61]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Apr 2018 00:44:28 -0000 To: quic@ietf.org References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> From: Christian Huitema Openpgp: preference=signencrypt Message-ID: <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net> Date: Wed, 4 Apr 2018 17:44:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------60E5D3046C8B501C3D9E6328" Content-Language: en-US Subject: Re: Getting to consensus on packet number encryption X-Originating-IP: 168.144.250.177 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.21) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5uGfiTwkXa4orbxipGVkwn9602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViwi0e2F4hhkxRCMAyBDRWts7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBo86SAdJ6bLtg5NStMc8F1x/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpUMghVcCxYGhncxAP/ZLBkEYa+a8mnXc/MAfIKlnj6Ntq8Av81//VeS B2jeNYjPTHuU2yw6z85L3UyCdO+oQ3S7VPd90DA1c/ZLOZZo7XGPVfWv8HL1YL3Zn8TE/e4IMjT6 4dZYZAAUgQSn0n4YsmwRv0RwnfgFPg0ja1g9il7QHeggKW28pboyZCmKkHUYXak3tdFgdrO8406e 9bSAHUYdj1WvR1o7bHgReqnxkLzf+HtB4/4Pbrz2QtFuyl+Sh6fpQ3qZejKJfUGfjTTOjHFDfqb5 R4VemuUI6bcEARsm0FlT7Jswx8bNhhAZMlhFDwKNZy58uobCIkCdwVDO83SGTnM2K/9iKCD9v589 nVS3hWSdEOMftBjsWb6BDQzjSsHUIomTnJwT4ky6b7E7Hukt2Ge4B8NG0VKlrY+34Zmj+F/tjlrZ UvGhhjiSam0tWhQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 00:44:40 -0000 This is a multi-part message in MIME format. --------------60E5D3046C8B501C3D9E6328 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If we are in the business of repeating our positions, so be it. I am pretty much on the same line as Patrick and others: 1) Privacy is not optional. And yes, removing "linkability through PN" is important, because when the connection ID and the source address also change, the only other cue for linkability is timing. Timing can be addressed by having overlapping connections. 2) Packet number encryption is the simplest of the many options presented so far. It is in particular much simpler to implement than the "predictable offset" scheme presented in previous drafts. 3) I am happy to discuss alternatives that appear simpler to implement in hardware, but so far the only plausible alternative is to insert an extra nonce in the packet header. Given birthday paradoxes and all that, this probably requires 8 extra bytes of overhead per packet, which is not very attractive. -- Christian Huitema On 4/4/2018 4:42 PM, Praveen Balasubramanian wrote: > > What is the privacy issue if you are not doing migration? Migration + > PNE (or multiple PN spaces) should go hand in hand. > > =C2=A0 > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel > Fahn=C3=B8e J=C3=B8rgensen > *Sent:* Wednesday, April 4, 2018 4:40 PM > *To:* Praveen Balasubramanian ;= > Ian Swett ; Mark Nottingham > > *Cc:* Lars Eggert ; IETF QUIC WG ; > Mirja K=C3=BChlewind > *Subject:* RE: Getting to consensus on packet number encryption > > =C2=A0 > > Without pro / con anything: > > =C2=A0 > > Optional privacy does not work. In part it cannot be retrofitted when > the need arise, in part it can be incriminating to enable. > > =C2=A0 > > On 5 April 2018 at 01.22.38, Praveen Balasubramanian > (pravb=3D40microsoft.com@dmarc.ietf.org > ) wrote: > > Make PNE (and hence connection migration) an optional negotiated > extension in V1=C2=A0 > --------------60E5D3046C8B501C3D9E6328 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

If we are in the business of repeating our positions, so be it. I am pretty much on the same line as Patrick and others:

1) Privacy is not optional. And yes, removing "linkability through PN" is important, because when the connection ID and the source address also change, the only other cue for linkability is timing. Timing can be addressed by having overlapping connections.

2) Packet number encryption is the simplest of the many options presented so far. It is in particular much simpler to implement than the "predictable offset" scheme presented in previous drafts.

3) I am happy to discuss alternatives that appear simpler to implement in hardware, but so far the only plausible alternative is to insert an extra nonce in the packet header. Given birthday paradoxes and all that, this probably requires 8 extra bytes of overhead per packet, which is not very attractive.

-- Christian Huitema


On 4/4/2018 4:42 PM, Praveen Balasubramanian wrote:

What is the privacy issue if you are not doing migration? Migration + PNE (or multiple PN spaces) should go hand in hand.

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahnøe Jørgensen
Sent: Wednesday, April 4, 2018 4:40 PM
To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>; Ian Swett <ianswett=40google.com@dmarc.ietf.org>; Mark Nottingham <mnot@mnot.net>
Cc: Lars Eggert <lars@eggert.org>; IETF QUIC WG <quic@ietf.org>; Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Subject: RE: Getting to consensus on packet number encryption

 

Without pro / con anything:

 

Optional privacy does not work. In part it cannot be retrofitted when the need arise, in part it can be incriminating to enable.

 

On 5 April 2018 at 01.22.38, Praveen Balasubramanian (pravb=40microsoft.com@dmarc.ietf.org) wrote:

Make PNE (and hence connection migration) an optional negotiated extension in V1 


--------------60E5D3046C8B501C3D9E6328-- From nobody Wed Apr 4 17:57:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41381201F2 for ; Wed, 4 Apr 2018 17:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hal4GanVapIu for ; Wed, 4 Apr 2018 17:57:40 -0700 (PDT) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4951126FB3 for ; Wed, 4 Apr 2018 17:57:39 -0700 (PDT) Received: by mail-pl0-x22c.google.com with SMTP id s10-v6so14735619plp.0 for ; Wed, 04 Apr 2018 17:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XTWM+W1xV1a9c4fcE6zTwoi55TAvLsnQoqs2fMJ0Ooo=; b=brAHMF6DJyPekuDICdxGIyFZmnOHcBStD9rVEzJW/nrjKufhYRGuDflo3f8RvgSRU0 5nCCtsiDYdB76OUppr/zhuDdinqIBWbL7GCVbK6Fw3QBrwVTCyXijemEKdStEK7chckw EmkJpGiHC56IVMcVRPNYkK0wj8KNSyIdaDleeC6FLPts97MWaZb1ZybCTDbME1WjdtHw SAoalRR7lwEf/elLgT/xrhUefIHGTc3sCvdC37IWcaV97Vu2xkVKcaESlxdHoq4Ko+R8 4SttNjNpwj4meIKP+CbZK2my0+FQRXZJzfoeLvN/YlQrzo3DLgyv+DS3SAmiilef2tOz DBfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=XTWM+W1xV1a9c4fcE6zTwoi55TAvLsnQoqs2fMJ0Ooo=; b=LvxSBFEzT3pBojfOyTra/NR2XJp+cm3yI5Ho+qENVXjnDbVSlYTxfYSs0hhg+jY8FK n8YYuiMFm2Ob/qmynFtlDi8WYwVpX3zrNlJ0TN9AIvh8L4cZws0Pp54CrSS2WtzB8tmg HlGEDOy87mi6HR08yoxSTR2Wsth8LGdbcERGY8rskOfj2qCpjGK+WqdA37ymN7+1z/Sx Ts7ghmvAHhLcVfX1L8O3R/umHyxUI0KBRIf8FwYy6TUHS0YNx9edj3tZpsAO4AWc6feq GDyzf/YWUZ5AdrzCx1as63NsZ+ODxYF4eKs+3v6WZymQf8k3YQmxs0iqOhZuIy9029SF N/6w== X-Gm-Message-State: AElRT7FhANt0SAUIGZSf680CapRumM+9ztlD8l1KBu2ZD2ZfS1wbUN9P cpx37EIzRH6ODQPaJEflQMecvFG7/hDtvWQcQVA= X-Google-Smtp-Source: AIpwx49ICZjnxdEOih2uh4/Gxd2AHGELW8aIxYr99W3NjprjzKToTy3bBaxZaFfENcrZlU1a6hpxClVVtbMUnvWmlvg= X-Received: by 2002:a17:902:52a4:: with SMTP id a33-v6mr13683593pli.371.1522889859241; Wed, 04 Apr 2018 17:57:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Wed, 4 Apr 2018 17:57:38 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> From: Kazuho Oku Date: Thu, 5 Apr 2018 09:57:38 +0900 Message-ID: Subject: Re: Getting to consensus on packet number encryption To: Patrick McManus Cc: Mark Nottingham , Lars Eggert , 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, 05 Apr 2018 00:57:43 -0000 I support adoption of #1079 for three reasons. One reason is that privacy is a required feature as Patrick has suggested. The other reason is simplicity as others have pointed out. The third reason is that without PNE there is a certain risk of QUIC failing to reach one of the chartered goals: preventing head-of-line blocking. In TCP, we have seen middleboxes trying to do clever things using the way sequence number increases, including packet reordering. Unless we encrypt PN in QUIC, there is fair chance that middleboxes would start doing the same. A middlebox reordering (or queuing) the QUIC packets by observing PN *is* causing head-of-line blocking since it prevents (or delays) packets being processed in different order at the receiver at the earliest possible moment. Note that middlebox vendors are known to make certain assumptions based on what they see on the wire rather than what is written down in the specification. Therefore, stating that middlebox should not do that is not a solution here. It is true that #1079 has issues with hardware crypto offload. I am happy to support switching to a better encryption scheme (if we find one) at any moment; e.g., during the standardization of QUICv1, or as an extension to v1, or part of vX. But as stated, I think that PNE is a MUST for us. That makes me prefer adopting #1079 and then, if possible, swaping it with a better solution. 2018-04-04 21:54 GMT+09:00 Patrick McManus : > I think its time to move forward with 1079. > > btw I think its wrong to characterize this as perf vs privacy - its cpu vs > bandwidth, the privacy is a must have. > > 1079 costs cpu (both in hw and sw) and in my mind it really competes with > either a multipath-pn-scheme (which we'll table for v2) or a one pass scheme > with a new nonce rather than making the packet number do double duty. The > latter is bandwidth tax and I'd rather pay the cpu cost. > > The only serious alternative to me is to take the timeline hit and work out > multiple packet number spaces for v1 (which are likely part of multipath > anyhow). > > -P > > > On Wed, Apr 4, 2018 at 12:58 AM, Mark Nottingham wrote: >> >> Hi everyone, >> >> The editors have told your chairs that this issue is starting to block >> progress on other aspects of QUIC. Coming to consensus on it soon (i.e., >> before Stockholm, if possible) would be good. >> >> It looks like this thread has come to a natural pause. Reading through it, >> I think we agree there are some unpleasant tradeoffs here, but so far we >> have only one concrete proposal -- PR#1079. >> >> My AU$.05 - While we're chartered to produce a protocol that's encrypted >> as much as operational concerns allow, and that privacy is a natural >> extension of that (especially in light of RFC7258 and RFC6973), there is no >> *requirement* that we produce a protocol that is able to be accelerated by >> hardware. >> >> That being the case, I think we need to ask ourselves if we believe that >> inclusion of PR#1079 will significantly inhibit deployment of the protocol. >> Based on the discussion so far, that doesn't seem to be the case, but I'd be >> interested to hear what others think. >> >> If we can get to consensus to incorporate the PR, and folks come back >> later with a more hardware-friendly replacement that doesn't change the >> Invariants or increase linkability, I suspect the WG will be amenable to >> that. >> >> What do folks think? >> >> Cheers, >> >> >> > On 29 Mar 2018, at 11:39 am, Ian Swett >> > wrote: >> > >> > Thanks for the nice summary Jana. >> > >> > As much as I'd love to have easier crypto HW acceleration, I've ended up >> > arriving at the same conclusion. I don't want to bite off the work to do >> > proper multipath in QUIC v1, which I think is the only other reasonable >> > option of those Christian outlined. >> > >> > If someone comes up with a way to transform packet number to make it >> > non-linkable, but doesn't have the downside of making hardware offload >> > difficult, then I'm open to it. But we've been talking about this for 2 >> > months without any notable improvements over Martin's PR. >> > >> > Given we never talk about any issue only once in QUIC, I'm sure this >> > will come up again, but for the time being I think #1079 is the best option >> > we have. >> > >> > >> > >> > On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar wrote: >> > A few quick thoughts as I catch up on this thread. >> > >> > I spent some time last week working through a design using multiple PN >> > spaces, and it is quite doable. I suspect we'll head towards multiple PN >> > spaces as we consider multipath in the future. That said, there is >> > complexity (as Christian notes). This complexity may be warranted when doing >> > multipath in v2 or later, but I'm not convinced that this is necessary as a >> > design primitive for QUICv1. >> > >> > We may want to creatively use the PN bits in v2, say to encode a path ID >> > and a PN, for multipath. We want to retain flexibility in these bits going >> > into v2. We've used encryption to ensure that we don't lose flexibility >> > elsewhere in the header, and it follows that we should use PNE to retain >> > flexibility in these bits as well. (Simplicity of design is the other value >> > in using PNE, since handling migration linkability is non-trivial without >> > it.) >> > >> > This leaves the question of HW acceleration being at loggerheads with >> > the design in PR #1079. First, I expect that the primary benefit of >> > acceleration will be in DC environments. Yes, there are some gains to be had >> > in serving the public Internet as well, but I'm unconvinced that this is the >> > driving use case for hardware acceleration. I understand that others may >> > disagree with me here. >> > >> > AFAIK, QUIC has not been used in DC environments yet. I expect there are >> > other things in the protocol that we'd want to change as we gain experience >> > deploying QUIC in DCs. Spinning up a new version to try QUIC within DCs is >> > not only appropriate, I would recommend it. This allows for rapid iterations >> > internally, and the experience can drive subsequent changes to QUIC. It's >> > what *I* would do if I was to deploy QUIC inside a DC. >> > >> > So, in short, I think we should go ahead with PR# 1079. This ensures >> > that future versions are guaranteed the flexibility to change the PN bits >> > for better support of HW acceleration or multipath or what-have-you. >> > >> > - jana >> > >> > On Mar 26, 2018 9:41 AM, "Christian Huitema" >> > wrote: >> > >> > On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote: >> >> Looking at >> >> https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_architecture >> >> it seems to imply a large range of server, desktop and mobile chips all have >> >> a CPU instruction set available to do AES acceleration and other similar >> >> operations (other instruction sets are also available). >> >> >> >> If we are considering the AES instructions then it looks like it is (or >> >> at least will be in the near future) a sizeable proportion of the public >> >> internet have it to be used. >> >> >> > >> > Certainly, but that's not the current debate. PR #1079 is fully >> > compatible with use of the AES instructions. The issue of the debate is that >> > the mechanism in PR #1079 required double buffering, first encrypt the >> > payload, then use the result of the encryption to encrypt the PN. This is >> > not an issue in a software implementation that can readily access all bytes >> > of the packet from memory, but it may be an issue in some hardware >> > implementations that are designed to do just one pass over the data. >> > >> > >> > -- Christian Huitema >> > >> > >> > >> >> -- >> Mark Nottingham https://www.mnot.net/ >> > -- Kazuho Oku From nobody Wed Apr 4 21:35:42 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD593126CD8 for ; Wed, 4 Apr 2018 21:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0N2M-yG0fzR9 for ; Wed, 4 Apr 2018 21:35:39 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C37126C89 for ; Wed, 4 Apr 2018 21:35:35 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id h26-v6so25806823otj.12 for ; Wed, 04 Apr 2018 21:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GxoQDw6WCjVziBdJXchk5sjfmW4yVKiYkN1oeJjRujw=; b=Lj9UXdf1Q5BIQjb41IWQO3T4VQwGCXrWEl88RS2dHbOIOcmUG2m+1Rq4OywdFhGfh8 u84K5KFcFwbmUYy+5CiHIR9gsDYgCO3HlrPM+xE05UqX7Gfc1nVIY+jhDpToA7KP5u1w 2HjJTNUOgBLrJRNoiJYx2w8d+rOaQd29h36XGn7o2pE18NX7SvEtdxQrTKyR3MLXMjPq R73LBwEB3z+TmbPjuVsyXlAfzN3yDsMRZfBilJ7SOo9ybp69N92tKWIzWWdnx2Nslzyg ez6YU6rw1Oe5P+ImUjvP4/bIVjt1xifZWBL8ceRpQdwCiGBXOmcp6bpDtfvpjPb5tmmO tu0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=GxoQDw6WCjVziBdJXchk5sjfmW4yVKiYkN1oeJjRujw=; b=tA4TbccI0RyUhZRR6JYD4xxe8IvvdhdI7UoI5GzXzNJm5jUBIcnhZMcl9vO7fA8wtz EQIxcFiKersUHTGLkz0QwmUdP+jFqB/uSRyC3cgXYHdA89St78jViZjcO8SzCKjt/Ot8 Vu7MonFssKcnqHD2Sjz6kImSp/X457dTDRYmh9h8lxWBjlP+VrmbwTNrCxzTHPbcRyoc gkTumUd1nUJEkBS0O34uSIwuFoDwsSZeqOuuE/FzNaIvRf1gG0kgsVLvacuWlhEr/fCC vudMcCMZF3rDDFb5+dcTYRO2nGNmfFQiha5PO3qXydf5ewCwbM9QKYMMZI6in00qSRer dl1Q== X-Gm-Message-State: ALQs6tA3bEvs7Tk0U5QRV2+RSPdt8U507SYKmnqqQLruqje2i7jNgHQO FpQiexy06wjV5+3OY3ZGCoQ+9wqxc1BtnoWhJY8= X-Google-Smtp-Source: AIpwx4/qdjUA+B1h3OpYsWKendXWeF3OOLTbOG5IRMul2WnwhcP/0ctywnhWJxhviGQEvRcjjt0N0X/wR98Qx4At3dY= X-Received: by 2002:a9d:4c81:: with SMTP id m1-v6mr7487964otf.396.1522902934643; Wed, 04 Apr 2018 21:35:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 21:35:34 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> From: Martin Thomson Date: Thu, 5 Apr 2018 14:35:34 +1000 Message-ID: Subject: Re: Getting to consensus on packet number encryption To: Kazuho Oku Cc: Patrick McManus , Lars Eggert , Mark Nottingham , 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, 05 Apr 2018 04:35:41 -0000 On Thu, Apr 5, 2018 at 10:57 AM, Kazuho Oku wrote: > It is true that #1079 has issues with hardware crypto offload. I am > happy to support switching to a better encryption scheme (if we find > one) at any moment; e.g., during the standardization of QUICv1, or as > an extension to v1, or part of vX. Until this came up, I hadn't considered the use of an extension/transport parameter to negotiate a new scheme, but it's obvious. This fits best with my view of things. If that means that we get the DC-QUIC option that turns the packet number encryption function into identity or some cheaper function, then I think that's an OK outcome. We should stop pretending that one size fits all is achievable; it's not been the case for years already. FWIW, what I got from the info that Praveen and Ian have shared is that there are enough problems to solve with UDP that worrying about the performance hit from encryption is premature. From nobody Wed Apr 4 23:00:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA21E126D74 for ; Wed, 4 Apr 2018 23:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522908050; bh=XO2Uq2rnqnjRilKpK8vKjxkeRbZbzrPZui1XepvQJbA=; h=From:In-Reply-To:References:Date:Subject:Cc:To:To:To:To; b=fNMNPDU6t67k+T63J2dDvBuJ+ccoeLZVelXUmJ4OcuxmeALK0SBzr0xYwk/2BlD3X Z0LObtoaB+keDNUL/RmAByfW19Pu/YIjmc1RsSS+9K+gfznsrbq4jPILnmTcKZVb6u m9iSg67VOT33DNGonyGHM/LJAsBOCtHOTc9zWGFk= X-Mailbox-Line: From mikkelfj@gmail.com Wed Apr 4 23:00:50 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C0E126C26; Wed, 4 Apr 2018 23:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522908050; bh=XO2Uq2rnqnjRilKpK8vKjxkeRbZbzrPZui1XepvQJbA=; h=From:In-Reply-To:References:Date:Subject:Cc:To:To:To:To; b=fNMNPDU6t67k+T63J2dDvBuJ+ccoeLZVelXUmJ4OcuxmeALK0SBzr0xYwk/2BlD3X Z0LObtoaB+keDNUL/RmAByfW19Pu/YIjmc1RsSS+9K+gfznsrbq4jPILnmTcKZVb6u m9iSg67VOT33DNGonyGHM/LJAsBOCtHOTc9zWGFk= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514F2126D73; Wed, 4 Apr 2018 23:00:50 -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 yb78pJMmeWbd; Wed, 4 Apr 2018 23:00:48 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5395A126C26; Wed, 4 Apr 2018 23:00:48 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id f6-v6so1454056ita.2; Wed, 04 Apr 2018 23:00:48 -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=XO2Uq2rnqnjRilKpK8vKjxkeRbZbzrPZui1XepvQJbA=; b=F5XALocfYBc/Mi6OgylMgzG7aWQRMbM2hTMidFYXdKrwYQMMKIZgqftIHHHCkbGTR7 Ytd+K+c6nJ3cCzXcWMNzmJ3Iy3vqvFK+dLeFzYrhO1A6tP2Wu/LjaHEwCff9BpfXzNux eJp31zpMWN1NKeHbYV8sdjZKikIdVrw7vepNcg1ZGh6MFP97Zn8dVmlQJVX9nfudZ59z BHaXj0WoBWQoubSw6+Q4XLOGffrOjSDJKmFTBSTIIYv4l0uvA6JgwZWlM9KxZVFnbA8i hUOTasYn2jsK9sKtIuNNubzRmndI1rWO6FsmqF8pUD+Er8nt+W1l35xWqsq8F0E9MQqF N3IA== 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=XO2Uq2rnqnjRilKpK8vKjxkeRbZbzrPZui1XepvQJbA=; b=jHLAx1jyolBCkpQcu+VgLmpdBK19hbzHcr6jpkbfI8hXTGWgRhYPtWwZHZeSkJQFqX LZBU1XhKKuoLrhacoBPSCn+RB+vfPRp8Cu1WwdLPMlVNDiDsz7ZSVR4MWBaQI4PYDxMP ni49hpJfbyrJoxcQnm3gY1QKKCtjyu7srjUQKdy5rSGeskAwsMnQO0iE4ZbIuQpu0Uw3 oEZNqdSz8vmS4z4A2y7oeRD5MbNOmidDRcNY+zVEuwGzVTNzasA5a9gCKzoyxnp9QISn NwcIcazU1Rwgpn54REcfk5LAaua30Dj5xpSrrLsFs1mpCOOKQT6jMScJXlT3+r0W16yL PmHA== X-Gm-Message-State: ALQs6tA4vzV+T1ZNq49CH6Oxd11buhSowJ7FwAGWOtkki/co25RBxQ4/ P0EUGiWXcA6RN2wsgSMNbaQEJGtDj0OYC5Yoa4c= X-Google-Smtp-Source: AIpwx4+FwObLj74AZpKua6dvdwJ2MDX8/hBehHY2Qu73EnaDlT/XiO8led2FLhw1SnpSc8CHmq919aDdmksbfpNv89M= X-Received: by 2002:a24:e4f:: with SMTP id 76-v6mr1505866ite.80.1522908047611; Wed, 04 Apr 2018 23:00:47 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 5 Apr 2018 08:00:46 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 5 Apr 2018 08:00:46 +0200 Message-ID: Subject: RE: Getting to consensus on packet number encryption Cc: Lars Eggert , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000341d0c056913a903" To: Praveen Balasubramanian To: Praveen Balasubramanian To: Mark Nottingham To: Ian Swett Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 06:00:51 -0000 --000000000000341d0c056913a903 Content-Type: text/plain; charset="UTF-8" When I said no pro / con, I meant: if you think that PN is always required for privacy, then it does not work to negotiate. If everyone agrees that that is not an issue, then negotiation is an option. It may then be tied with additional requirements such as never supporting migration or NAT rebinding and requiring termination if that is violated. If everyone does not agree on this, then negotiation is not a solution the problem because privacy is not negotiable. Personally I believe privacy is not an issue if you isolate PN, but even if many might agree on that the might still argue it is difficult to do (correctly). There is also the concern raised by some that packet reordering in transit could happen without PN - this is always an issue - but is it worth the cost, and is it still a real concern for a protocol that was not designed to be strictly ordered? How does WebRTC work in this context? On 5 April 2018 at 01.42.23, Praveen Balasubramanian (pravb@microsoft.com) wrote: What is the privacy issue if you are not doing migration? Migration + PNE (or multiple PN spaces) should go hand in hand. --000000000000341d0c056913a903 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = When I said no pro /= con, I meant: if you think that PN is always required for privacy, then it= does not work to negotiate. If everyone agrees that that is not an issue, = then negotiation is an option. It may then be tied with additional requirem= ents such as never supporting migration or NAT rebinding and requiring term= ination if that is violated. If everyone does not agree on this, then negot= iation is not a solution the problem because privacy is not negotiable.

Personally I believe privacy is not an issue if you isola= te PN, but even if many might agree on that the might still argue it is dif= ficult to do (correctly).

There is also the concern rais= ed by some that packet reordering in transit could happen without PN - this= is always an issue - but is it worth the cost, and is it still a real conc= ern for a protocol that was not designed to be strictly ordered? How does W= ebRTC work in this context?


On 5 April 2018 at 01.42.23, Praveen Balasubramanian = (pravb@microsoft.com) wrote:

=
What is the privacy issue if you are not doing migratio= n? Migration + PNE (or multiple PN spaces) should go hand in hand.
--000000000000341d0c056913a903-- From nobody Wed Apr 4 23:00:58 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFDB126C26 for ; Wed, 4 Apr 2018 23:00:51 -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=unavailable 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 cC-Vkq-2fViG for ; Wed, 4 Apr 2018 23:00:48 -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 50206124207 for ; Wed, 4 Apr 2018 23:00:48 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id 142-v6so1430265itl.5 for ; Wed, 04 Apr 2018 23:00:48 -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=XO2Uq2rnqnjRilKpK8vKjxkeRbZbzrPZui1XepvQJbA=; b=F5XALocfYBc/Mi6OgylMgzG7aWQRMbM2hTMidFYXdKrwYQMMKIZgqftIHHHCkbGTR7 Ytd+K+c6nJ3cCzXcWMNzmJ3Iy3vqvFK+dLeFzYrhO1A6tP2Wu/LjaHEwCff9BpfXzNux eJp31zpMWN1NKeHbYV8sdjZKikIdVrw7vepNcg1ZGh6MFP97Zn8dVmlQJVX9nfudZ59z BHaXj0WoBWQoubSw6+Q4XLOGffrOjSDJKmFTBSTIIYv4l0uvA6JgwZWlM9KxZVFnbA8i hUOTasYn2jsK9sKtIuNNubzRmndI1rWO6FsmqF8pUD+Er8nt+W1l35xWqsq8F0E9MQqF N3IA== 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=XO2Uq2rnqnjRilKpK8vKjxkeRbZbzrPZui1XepvQJbA=; b=cXhP0ZlfZMcDcbGKm0PB6DW2ziEjdrUnLHjT/DQ9DCr2J9d7bkxm0FYUAcgZTS4Ltq 7i17QaOX9Y5Z+EVP+mhoV29zzIdURNBMIXkk2p0hN69SJwAwlxY4OQK0F2Qt3yzNOjF5 7uH4+1qQp3JLEFbpHtYmFudAqOkXLEuCkLf7G+u5B9vtG4ke9S9vbYMzKEVCReACYAhu 6jPM5l3ZjWgRouqSplRwAEW9dpLt3s5G1veActtzE7UHs8N8vJxyfiUG5+9kU/qW6Q5N XmdJjKQcLpDg1WCrf6H1D9gCmOGxOMVzOBVja+JB2NfcOjNWkhoav4SFYcKoy3dFs38q Ly2g== X-Gm-Message-State: ALQs6tBr8sngXwgPoRN7gFT5Fn5H8cCfOMsOM3BZbcQN2/tzsXOfusHM rvQOVpGsDqOJWS1ZqJ9qNOG3yNDL7d2NlkIq/Zs= X-Google-Smtp-Source: AIpwx4+FwObLj74AZpKua6dvdwJ2MDX8/hBehHY2Qu73EnaDlT/XiO8led2FLhw1SnpSc8CHmq919aDdmksbfpNv89M= X-Received: by 2002:a24:e4f:: with SMTP id 76-v6mr1505866ite.80.1522908047611; Wed, 04 Apr 2018 23:00:47 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 5 Apr 2018 08:00:46 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 5 Apr 2018 08:00:46 +0200 Message-ID: Subject: RE: Getting to consensus on packet number encryption To: Praveen Balasubramanian , Praveen Balasubramanian , Mark Nottingham , Ian Swett Cc: Lars Eggert , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000341d0c056913a903" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 06:00:51 -0000 --000000000000341d0c056913a903 Content-Type: text/plain; charset="UTF-8" When I said no pro / con, I meant: if you think that PN is always required for privacy, then it does not work to negotiate. If everyone agrees that that is not an issue, then negotiation is an option. It may then be tied with additional requirements such as never supporting migration or NAT rebinding and requiring termination if that is violated. If everyone does not agree on this, then negotiation is not a solution the problem because privacy is not negotiable. Personally I believe privacy is not an issue if you isolate PN, but even if many might agree on that the might still argue it is difficult to do (correctly). There is also the concern raised by some that packet reordering in transit could happen without PN - this is always an issue - but is it worth the cost, and is it still a real concern for a protocol that was not designed to be strictly ordered? How does WebRTC work in this context? On 5 April 2018 at 01.42.23, Praveen Balasubramanian (pravb@microsoft.com) wrote: What is the privacy issue if you are not doing migration? Migration + PNE (or multiple PN spaces) should go hand in hand. --000000000000341d0c056913a903 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = When I said no pro /= con, I meant: if you think that PN is always required for privacy, then it= does not work to negotiate. If everyone agrees that that is not an issue, = then negotiation is an option. It may then be tied with additional requirem= ents such as never supporting migration or NAT rebinding and requiring term= ination if that is violated. If everyone does not agree on this, then negot= iation is not a solution the problem because privacy is not negotiable.

Personally I believe privacy is not an issue if you isola= te PN, but even if many might agree on that the might still argue it is dif= ficult to do (correctly).

There is also the concern rais= ed by some that packet reordering in transit could happen without PN - this= is always an issue - but is it worth the cost, and is it still a real conc= ern for a protocol that was not designed to be strictly ordered? How does W= ebRTC work in this context?


On 5 April 2018 at 01.42.23, Praveen Balasubramanian = (pravb@microsoft.com) wrote:

=
What is the privacy issue if you are not doing migratio= n? Migration + PNE (or multiple PN spaces) should go hand in hand.
--000000000000341d0c056913a903-- From nobody Wed Apr 4 23:10:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EA2124207 for ; Wed, 4 Apr 2018 23:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7abMSC904mg for ; Wed, 4 Apr 2018 23:10:20 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id DEB6D1200FC for ; Wed, 4 Apr 2018 23:10:19 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w356ACN4023820; Thu, 5 Apr 2018 08:10:12 +0200 Date: Thu, 5 Apr 2018 08:10:12 +0200 From: Willy Tarreau To: Mark Nottingham Cc: Mirja =?iso-8859-1?Q?K=FChlewind?= , Lars Eggert , IETF QUIC WG Subject: Re: Getting to consensus on packet number encryption Message-ID: <20180405061012.GA23708@1wt.eu> References: <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 06:10:22 -0000 On Thu, Apr 05, 2018 at 07:28:10AM +1000, Mark Nottingham wrote: > Overall, I do not think it is a goal of QUIC to be deployable on any system > for any purpose; if we try to design it for all purposes, we're going to > fail. The question, then, is how much deployment / implementation / adoption > we need to make it succeed -- and to design for that. I totally agree with you here. It's also why my -1 is a weak one (rather a warning than a -1 in fact because I consider that robustness is more important than prevention against linkability). we know that whatever we'll produce, solutions will adapt if they want to adopt it, and if the the risks are too high for adopters (such as increased sensitivity do DDoS), adopters will simply roll back for the time it takes to find a solution. > That said -- One way to prove that PNE hurts deployability is to try it; > implementers have a very strong incentive to make sure their code can be > deployed, so if those who have concerns are correct, it's probably the > easiest way for them to be proven right. I disagree on this approach. That's exactly what led us to release HPACK with an inefficient encoding and with unsorted header fields. We all know that deployment speed varies a lot between participants, and that those with most concerns are also those with less ability to prove their concerns. Specifically, single-ended implementations often face less issues than intermediaries and are much easier to implement. And once the least concerned ones consider that it works well enough for them, the protocol is locked and it's forbidden to improve or even it. We need not to repeat our mistakes. I think that the direction taken in this thread is more pragmatic : technical and philosophical concerns are exchanged, weighted and the decision will be taken based on this. Regarding the performance issues, several of us noted that there are options by adopting negociable algorithms, or as I proposed, to use a single AES round instead of all of them, which will be reasonably cheap on modern systems. Cheers, Willy From nobody Wed Apr 4 23:53:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB391126579 for ; Wed, 4 Apr 2018 23:53:38 -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 T1c6btyAGW0x for ; Wed, 4 Apr 2018 23:53:35 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52984120725 for ; Wed, 4 Apr 2018 23:53:35 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E49E4340E75; Thu, 5 Apr 2018 08:53:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.8388); Thu, 5 Apr 2018 08:53:33 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 5 Apr 2018 08:53:33 +0200 (CEST) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50680374; Thu, 05 Apr 2018 08:53:33 +0200 From: "Brian Trammell (IETF)" Message-Id: <3E5BCB0F-DEDE-4EBA-80DF-31E49764C0FE@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_E6AF5EFA-1AD8-4D46-B79C-5BDEEF9813E9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Getting to consensus on packet number encryption Date: Thu, 5 Apr 2018 08:53:31 +0200 In-Reply-To: Cc: Kazuho Oku , Lars Eggert , Mark Nottingham , IETF QUIC WG , Patrick McManus To: Martin Thomson References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 06:53:39 -0000 --Apple-Mail=_E6AF5EFA-1AD8-4D46-B79C-5BDEEF9813E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 5 Apr 2018, at 06:35, Martin Thomson = wrote: >=20 > On Thu, Apr 5, 2018 at 10:57 AM, Kazuho Oku = wrote: >> It is true that #1079 has issues with hardware crypto offload. I am >> happy to support switching to a better encryption scheme (if we find >> one) at any moment; e.g., during the standardization of QUICv1, or as >> an extension to v1, or part of vX. >=20 > Until this came up, I hadn't considered the use of an > extension/transport parameter to negotiate a new scheme, but it's > obvious. This fits best with my view of things. >=20 > If that means that we get the DC-QUIC option that turns the packet > number encryption function into identity or some cheaper function, > then I think that's an OK outcome. We should stop pretending that one > size fits all is achievable; it's not been the case for years already. other than "please, please don't call it DC-QUIC", this approach (packet = number encoding/encryption scheme as a transport parameter) sounds like = a very good approach to me. There are details here, of course... > FWIW, what I got from the info that Praveen and Ian have shared is > that there are enough problems to solve with UDP that worrying about > the performance hit from encryption is premature. This was my intuition as well. However, fixing kernel interface issues (as are at the root of UDP = performance problems, as well as the lack of ECN signaling from = userland) takes time, so those of us with hands on kernels should be = working to fix those issues we *know* we will have should be working to = fix them now. Fixing hardware issues -- let's face it, we'll probably = never have full transport offload for QUIC, given the flexibility at the = core of its design philosophy, but crypto offload is a good target -- = takes longer, so anything we think we need for V2/V3, we need to start = thinking about now. IOW it's all premature, but the prematurity in this case is an = externality, unless we think we know enough to decide that crypto = offload isn't worth it for QUIC. (Obviously, I don't think we do) Cheers, Brian --Apple-Mail=_E6AF5EFA-1AD8-4D46-B79C-5BDEEF9813E9 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlrFx+sACgkQihK3vwvq RqPDCQ//RvsF2Gs/6lwtFFk7pKJyrWLBWCjDKvT9oESU7Twb0szN0Bz/pLJy22kh O1DBkP6p1zdnkFVrMbY9Usf36qMZSWVhKSbkMQHnZgtKkHG9MzYS0ih+kET3hxoH z/75MsL6aHC6J7sJu293uk/mSR8k8wI+hI9ohVrOOJeULqOXChcGmDWTIAS63Dwb T5BMD9Qxg6DSJieYEsZ4S8CNOJriNZtWv2lAIK9ygak8xzW1WZ0//x7wfxqkFRpz wAFatdwjLIDtlbzgVIVmqCbAGSV03cODWfq3i6K907iAQmEjEbZKRptJ6Rm1I6Ks gv+J9DidevYEP+psJbJCgtw9v1cOeiyJMTVfqju9/B0FBftX1MQ0hgflZv+qhodk 3tZ0LsY6n7W3SYMNlzUBSSAby11pbwiO0jjXABrCaCwCSDVtbHwatKh0NgT+Cj8L vaMU1iF19QbcDsIXklI17PiQpjpyYFVx5Kg6tKHUkUb/YI30zuUIOl2I/HG2omOm 6IPTQrK0EEaC8sMmC9JB3fruhww7sG9ZuILjLllgGaGJVuuL/GQX8IduHbSNVPfx MXuX9HtEjEUDu3Gs0/aMGtHtJzruLZbsX02N/aKH8XFGlNY3f3iNTxbMwxF9in/A gZqSX2GxTcKWo0zPxkwRJ+XQMywaliEqiYnGWBrNWrbioagFegA= =2c3F -----END PGP SIGNATURE----- --Apple-Mail=_E6AF5EFA-1AD8-4D46-B79C-5BDEEF9813E9-- From nobody Thu Apr 5 00:01:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD1C126579 for ; Thu, 5 Apr 2018 00:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyob2oOq3bTQ for ; Thu, 5 Apr 2018 00:01:42 -0700 (PDT) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) (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 778DB120725 for ; Thu, 5 Apr 2018 00:01:42 -0700 (PDT) Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 40GtzS1gN7z1qwBw; Thu, 5 Apr 2018 09:01:40 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 40GtzS16r7z1qqkw; Thu, 5 Apr 2018 09:01:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id Y0aaBO-kI159; Thu, 5 Apr 2018 09:01:34 +0200 (CEST) X-Auth-Info: IRCGPn5qo08ALZ40SiPVTGHgnAeJvvWkKL+XTqV+gtZfAnXX2H+MLLfz01GwaxwS Received: from eggert.org (ppp-188-174-87-39.dynamic.mnet-online.de [188.174.87.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Thu, 5 Apr 2018 09:01:34 +0200 (CEST) Received: from [IPv6:2001:a61:360d:b01:d59d:14f1:aab2:4af7] (unknown [IPv6:2001:a61:360d:b01:d59d:14f1:aab2:4af7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 8CBE51B241E9; Thu, 5 Apr 2018 09:01:26 +0200 (CEST) From: Lars Eggert Message-Id: <0F07FB8F-A8D0-4F2B-8ED8-7230DF99EE7C@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_96D453F0-A627-49AE-B953-26516217BC52"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: ECN signaling from userland Re: Getting to consensus on packet number encryption Date: Thu, 5 Apr 2018 09:01:25 +0200 In-Reply-To: <3E5BCB0F-DEDE-4EBA-80DF-31E49764C0FE@trammell.ch> Cc: Martin Thomson , Kazuho Oku , Mark Nottingham , IETF QUIC WG , Patrick McManus To: Brian Trammell References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <3E5BCB0F-DEDE-4EBA-80DF-31E49764C0FE@trammell.ch> X-MailScanner-ID: 8CBE51B241E9.A184E X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 07:01:47 -0000 --Apple-Mail=_96D453F0-A627-49AE-B953-26516217BC52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2018-4-5, at 8:53, Brian Trammell (IETF) wrote: > However, fixing kernel interface issues (as are at the root of UDP = performance problems, as well as the lack of ECN signaling from = userland) takes time FWIW, ECN signaling is mostly only an issue on Windows at the moment. = Most other stacks can do this via ancillary data on sendmsg/recvmsg. I = have tested Linux, FreeBSD and Darwin and they work (modulo a bug in = Darwin on TX that Apple is looking into.) Lars --Apple-Mail=_96D453F0-A627-49AE-B953-26516217BC52 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----- iQIzBAEBCgAdFiEEDrrUO3PMwKM8fddaHbmKvSnuNPgFAlrFycUACgkQHbmKvSnu NPhFoQ//VnmpuroiTlcBIOtrftb6SBQet2RkCvRPPe2N+LsZnavfvZVyXJe7ulx4 9nkRWZFZIc1Y+Ul7EZ06uw92TbI7a1IZMBlCp3+Zk2vLiXk6OQL7Jiq/zlIl/zYp zAfBA5Ma8RBEKaL9E/7KWEu2YQH6l+5mX1elXuk0nlh64w+UkwFSNXcgfkEwzRst 7vQ6+vNKGu8lnTo5D9sPKPAbYwHm/Nvt2ia9QmFpAXuWyw4V0XxNfy/ENEN5IaJe ik6fw3F0ifeEVWjJVpVQYuE7+38n6BrfqxqaVwAGvYvjT98TN4swTJsteJQT7VlF xtJqmNvQmxx+eJtQVDBkDM0yBaCY1H3S6cjyJ0LZWLBtsoZR0z11gRM0UbY2BsCZ 9dp9Yn6f1PvcDluOV9LAuycQZTSFXKyhzG1hTfDHbLj+aPDkbMKxTX012LuTJI+w PqCoJjtsSDhVDES5JPUHwzrNd84K3Kymd4/M1/qfrbDkJ0KdppJO2h949j1/T1+n 0tWABKQDDnNospy9e1swVYek7gpEADsTaorBjDNTwyOye4oI86GqysQSxrDSUS/z NCk4/belkDk7Sw72dAaSuZnzjls1k0kQ4fO4JM6C14mtvM9dqZfn0qDtQ/c7CTcB 8kBrmJQ+9FDY1jJ09q5Xu2k8TCL0a/oaC9bmDMkzNp4UUZMO+bg= =8l5B -----END PGP SIGNATURE----- --Apple-Mail=_96D453F0-A627-49AE-B953-26516217BC52-- From nobody Thu Apr 5 00:03:03 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8993D126579 for ; Thu, 5 Apr 2018 00:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKwrdkA3ZbRT for ; Thu, 5 Apr 2018 00:03:00 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6117B120725 for ; Thu, 5 Apr 2018 00:03:00 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2BAB734113D; Thu, 5 Apr 2018 09:02:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.9710); Thu, 5 Apr 2018 09:02:59 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 5 Apr 2018 09:02:59 +0200 (CEST) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50681968; Thu, 05 Apr 2018 09:02:59 +0200 From: "Brian Trammell (IETF)" Message-Id: <8F38C971-5E0C-4C6D-B67F-7186D88AF034@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_8236C9B5-00D7-4AA5-B4EE-B824F2D95241"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: ECN signaling from userland Re: Getting to consensus on packet number encryption Date: Thu, 5 Apr 2018 09:02:58 +0200 In-Reply-To: <0F07FB8F-A8D0-4F2B-8ED8-7230DF99EE7C@eggert.org> Cc: Martin Thomson , Kazuho Oku , Mark Nottingham , IETF QUIC WG , Patrick McManus To: Lars Eggert References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <3E5BCB0F-DEDE-4EBA-80DF-31E49764C0FE@trammell.ch> <0F07FB8F-A8D0-4F2B-8ED8-7230DF99EE7C@eggert.org> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 07:03:03 -0000 --Apple-Mail=_8236C9B5-00D7-4AA5-B4EE-B824F2D95241 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 5 Apr 2018, at 09:01, Lars Eggert wrote: >=20 > Hi, >=20 > On 2018-4-5, at 8:53, Brian Trammell (IETF) wrote: >> However, fixing kernel interface issues (as are at the root of UDP = performance problems, as well as the lack of ECN signaling from = userland) takes time >=20 > FWIW, ECN signaling is mostly only an issue on Windows at the moment. = Most other stacks can do this via ancillary data on sendmsg/recvmsg. I = have tested Linux, FreeBSD and Darwin and they work (modulo a bug in = Darwin on TX that Apple is looking into.) Ah, I thought this was a more widely spread problem. Okay, cool, we can = focus more on making UDP not suck then. :) Thanks, cheers, Brian --Apple-Mail=_8236C9B5-00D7-4AA5-B4EE-B824F2D95241 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlrFyiIACgkQihK3vwvq RqO5kRAAmaLUT/Fu5omGpwoSFHif0+G1y6TMF0dDdbhzqANWs8x9Ts1+w/iXOHnK y6juvCmE+2lC9ehDAb/xTTnt+KS5H/4evH5bQZ+ckrzFJLQrJfUlE13i8bznT00A 9NJC3OP1CMe16rElV6ci2QfmI1aPHB2KQiy7IW7g3ayglJ/GtjCdULDjj+RE7T01 cz26fkfrWlDMmONtDNzuYkqEHZsAzL9KED3XTmbER8Vzz7wL73YFP2Jh6E9V42J7 GfGw1/BgupUy4luFNDpuykSJgE+tMDgrgUeizBozHyTUZArOJ6VodsjMue2z6hOi n/KxR3IHRwdKIU4ya0acLxOsTMDxOE8/uZMbCQz9zWlOiLQ9nlhUub9dt2IgtIfH 9eEJOVZG9QLH7r5s8QoWFH0C29to6/SYTUNnvH9GPf/PmNNI013xZqXlaeUcpyOx IGZaVnHXcqC+2xOSo/dsSPghf1+9RjFmqpB7c+N2v/s02sUzGRJ1lQM9Ixmm+G6+ HxFqfVJcZ/ognqkUmUjj4ecw7Fhhx+dfBdy8Ywx+yMPkODMe/DZimZaXwExXWjwZ STv/XVaIGPIfQAkbwVE8FUTG8zxP5bA1vAen6AggyGAtWOEpVxBYcB23GGO+PEvF uILFQy2k+M9okHqwBEIFswqBNINf+jtn8vDs04K7TASHUgh/yB4= =JgJ1 -----END PGP SIGNATURE----- --Apple-Mail=_8236C9B5-00D7-4AA5-B4EE-B824F2D95241-- From nobody Thu Apr 5 00:24:42 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F925126DC2 for ; Thu, 5 Apr 2018 00:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUdgHQnUpZaF for ; Thu, 5 Apr 2018 00:24:40 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55A2120725 for ; Thu, 5 Apr 2018 00:24:39 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 34D93160B86; Thu, 5 Apr 2018 09:24:38 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 17D9118007F; Thu, 5 Apr 2018 09:24:38 +0200 (CEST) Received: from lat6466.rd.francetelecom.fr (10.168.234.2) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 5 Apr 2018 09:24:38 +0200 Message-ID: <23265_1522913078_5AC5CF36_23265_2_2_5AC5CF37.5000809@orange.com> Date: Thu, 5 Apr 2018 09:24:39 +0200 From: Reply-To: Alexandre Ferrieux Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Christian Huitema CC: Subject: Re: Getting to consensus on packet number encryption References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net> In-Reply-To: <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.2] Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 07:24:41 -0000 On 05/04/2018 02:44, Christian Huitema wrote: > 3) I am happy to discuss alternatives that appear simpler to implement in > hardware, but so far the only plausible alternative is to insert an extra nonce > in the packet header. Given birthday paradoxes and all that, this probably > requires 8 extra bytes of overhead per packet, which is not very attractive. Can you quantify "not very attractive" ? Given the complex ramifications of the alternatives, is it wise to shy away from an 8-byte overhead ? TCP options like timestamps weigh the same and survived... _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Thu Apr 5 00:43:26 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A81126DC2 for ; Thu, 5 Apr 2018 00:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwhyH6CgLg0n for ; Thu, 5 Apr 2018 00:43:22 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F35120725 for ; Thu, 5 Apr 2018 00:43:22 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id 188-v6so21682730oih.8 for ; Thu, 05 Apr 2018 00:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7NQ9owGve2xlWYhri9kmCPylJwRx//gqzRszTA15EnA=; b=oYvP1vHqOkNSgFL5T0sGCvzyweMXOkqo0c0QiEAl0rlmBpOijpaENgmx1onHmCrG59 rbtevwwpBq7p/Cwm3QIRSXvlU2lTu8NFAVJC4UvaBAvwcDWcIvG8OkreNzyMC7iyeja8 uW2pVAxLfThwN6kspV43YOya7Bsuz5QZ1qp/bs3YERdg99DO16t4ALWq2y32SBiHnSzH pv25kDFzNDFqaAIEO+TuYoZvY0mhWO6KmQn6PAlcGy5Dznj3F+lFbbLMqEkDWMo+nQ6W exXZKrVLvDDBX+d33H2JzekZvr3s4Qs4iFIbWSeWnP167BtAzHc19U4Z0IBvvtR5JtdC dCtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=7NQ9owGve2xlWYhri9kmCPylJwRx//gqzRszTA15EnA=; b=WByq8n3Hwz4q6vc6nQ+HEVBSwoI/GoUlFFs7y9TmjzGbHbkAFWCcXLNKCNfr4fwH00 x0nPmhV+4nl4G1T+Ox09soSMM8u91lUWdY74tomNhsMMsYHDU60utn/Ek9OcDHm/tY+N Xi4CYGMoY7FecmuYNuUy2Z+VhvQVEgy8z/kJP5i5fReqdEJGV2D050UTKFRp/xZmGCum y8QPsyOsPr+lEZnOIhKT5X16l67lFj/JiWAkjk6odfo7PtgG7g5GX2m83Bm4KqRyOvfh rWYPjhqnuWF+LlyAoPw04nTSKB3WGXbViFkjb4z85QPJPDym2aewyLApEFKzpSD3d+91 ph3Q== X-Gm-Message-State: ALQs6tBzEPWfWhbusoVfiCkoEDvJsP/vPJ6TKcU0OIDmPXwo6k8YQSw1 QMlU3frMwPgmgT/zVyUJSMcvA/CFJXJrm7QN+ini9g== X-Google-Smtp-Source: AIpwx48g8dagfAwpFuuHByx8JXxV9dt/IPY0Y8Spusj17GR4BVmkCBntheVRe/16phk7NC96LAX81ysPoVZiOOu5sHg= X-Received: by 2002:aca:b3d4:: with SMTP id c203-v6mr12692600oif.91.1522914201476; Thu, 05 Apr 2018 00:43:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Thu, 5 Apr 2018 00:42:41 -0700 (PDT) In-Reply-To: <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net> From: Eric Rescorla Date: Thu, 5 Apr 2018 00:42:41 -0700 Message-ID: Subject: Re: Getting to consensus on packet number encryption To: Christian Huitema Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000000b628056915181e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 07:43:25 -0000 --00000000000000b628056915181e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 4, 2018 at 5:44 PM, Christian Huitema wrote: > If we are in the business of repeating our positions, so be it. I am > pretty much on the same line as Patrick and others: > > 1) Privacy is not optional. And yes, removing "linkability through PN" is > important, because when the connection ID and the source address also > change, the only other cue for linkability is timing. Timing can be > addressed by having overlapping connections. > > 2) Packet number encryption is the simplest of the many options presented > so far. It is in particular much simpler to implement than the "predictab= le > offset" scheme presented in previous drafts. > > 3) I am happy to discuss alternatives that appear simpler to implement in > hardware, but so far the only plausible alternative is to insert an extra > nonce in the packet header. Given birthday paradoxes and all that, this > probably requires 8 extra bytes of overhead per packet, which is not very > attractive. > 8 seems pretty close to the line unless we are going to rekey *very* frequently. Probably more like 12 bytes. In any case, I concur that we should do PN encryption and IMO PR#1079 is the best -- or at least close to the best -- design we have. I would prefer to land it, and then if we find something better later, we can improve it then. -Ekr -- Christian Huitema > > On 4/4/2018 4:42 PM, Praveen Balasubramanian wrote: > > What is the privacy issue if you are not doing migration? Migration + PNE > (or multiple PN spaces) should go hand in hand. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Mikkel Fahn=C3=B8e J=C3=B8rgensen > *Sent:* Wednesday, April 4, 2018 4:40 PM > *To:* Praveen Balasubramanian > ; Ian Swett > > ; Mark Nottingham > > *Cc:* Lars Eggert ; IETF QUIC WG > ; Mirja K=C3=BChlewind > > *Subject:* RE: Getting to consensus on packet number encryption > > > > Without pro / con anything: > > > > Optional privacy does not work. In part it cannot be retrofitted when the > need arise, in part it can be incriminating to enable. > > > > On 5 April 2018 at 01.22.38, Praveen Balasubramanian ( > pravb=3D40microsoft.com@dmarc.ietf.org) wrote: > > Make PNE (and hence connection migration) an optional negotiated extensio= n > in V1 > > > --00000000000000b628056915181e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 4, 2018 at 5:44 PM, Christian Huitema <= ;huitema@huitema.n= et> wrote:
=20 =20 =20

If we are in the business of repeating our positions, so be it. I am pretty much on the same line as Patrick and others:

1) Privacy is not optional. And yes, removing "linkability through PN" is important, because when the connection ID and the source address also change, the only other cue for linkability is timing. Timing can be addressed by having overlapping connections.

2) Packet number encryption is the simplest of the many options presented so far. It is in particular much simpler to implement than the "predictable offset" scheme presented in previous = drafts.

3) I am happy to discuss alternatives that appear simpler to implement in hardware, but so far the only plausible alternative is to insert an extra nonce in the packet header. Given birthday paradoxes and all that, this probably requires 8 extra bytes of overhead per packet, which is not very attractive.

8 seems pretty close to the line unless we are going to rekey *ver= y* frequently. Probably more like 12 bytes.

In any= case, I concur that we should do PN encryption and IMO PR#1079 is the best= -- or at least close to the best -- design we have. I would prefer to land= it, and then if we find something better later, we can improve it then.

-Ekr

-- Christian Huitema


On 4/4/2018 4:42 P= M, Praveen Balasubramanian wrote:
=20 =20 =20

What is the privacy issue if you are not doing migration? Migration + PNE (or multiple PN spaces) should go hand in hand.

=C2=A0

From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen
Sent: Wednesday, April 4, 2018 4:40 PM
To: Praveen Balasubramanian <pr= avb=3D40microsoft.com@dmarc.ietf.org>; Ian Swett <ia= nswett=3D40google.com@dmarc.ietf.org>; Mark Nottingham <mnot@mnot.net>= ;
Cc: Lars Eggert <la= rs@eggert.org>; IETF QUIC WG <quic@ietf.org>; M= irja K=C3=BChlewind <mirja.kue= hlewind@tik.ee.ethz.ch>
Subject: RE: Getting to consensus on packet number encryption

=C2=A0

Without pro / con anything:

=C2=A0

Optional privacy does not work. In part it cannot be retrofitted when the need arise, in part it can be incriminating to enable.

=C2=A0

On 5 April 2018 at 01.22.38, Praveen Balasubramanian (pravb=3D4= 0microsoft.com@dmarc.ietf.org) wrote:

Make PNE (and hence connection migration) an optional negotiated extension in V1=C2=A0



--00000000000000b628056915181e-- From nobody Thu Apr 5 00:56:44 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214861200F1 for ; Thu, 5 Apr 2018 00:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 NlWAyU2q3v9f for ; Thu, 5 Apr 2018 00:56:40 -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 88CAD120725 for ; Thu, 5 Apr 2018 00:56:40 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id v13so29495343iob.6 for ; Thu, 05 Apr 2018 00:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=77wDua7EjMqyaj3I0eZgZmOkkRNS8AxzMxfITbrX+Ww=; b=C7SkJZaDu9NDZy7kLoO0WPXZM7Fjqb1mm6eKhLacmNp6ALxYiF9gc/DkmhM8TQAmip uxhATnsBA0yY8YTGLV8bi9Ai+/kPCnU6bWRyQm/PWrt0g2Y8bcpqDXbDEYioCdxxeViw 6/0fiDUydPUWv02BhbvHc28UCH9kzQxysjVS3GHXKlQHUD10PNhABdmj3TsEXUWkbA8q U8Ua9Zr9tyq1idliVVdUZheUaip6zuwXNK+jzD0uRTfczS/l6SIkyYQD4Z2fd9F0kPND kqsgN7yVgyvCpc2hN6lbIdjDK7zhn5PBKYKjtM25apFOMZXuTISMgYCvZtwIu9OXs9kO 31rg== 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:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=77wDua7EjMqyaj3I0eZgZmOkkRNS8AxzMxfITbrX+Ww=; b=iD70qNRV0OBjsnijK0WIYrpcnFslp3qrMncX/jS2d+A+oLq1BajH36kaAoammXckru DBn7TjSQzuRRmzix/kcgLiVQ5ES1gf9rcsHYZHcsz9ROcGoW5nfrMMyxGskJMAeP/8C1 5yVO77YL8aKENxL7MGRA+LbhbmhRqcG2t0zNprf+9DY7eefQrXBsFlP5SvlL/E4WGHWW 1VNp1UiZ6a9lC2YSfwS+HrF2nlqtvJGVSBr7vYRjaHEr6fNznARGM0DZbyufuHldEmE/ yevm4OkiBGqNvS8mEn0O5JGmcACpran4a+U1hrjTSi9pjs+gaC9hyesDiKkt0skxwgbN w/iw== X-Gm-Message-State: ALQs6tCI4lnLHcjtnOKSQWg1b41PwnFaCWGVp8BtnxUJATFMynf+W0Bu joa/ss4HEQY/BJUm1YyvaxaN6EV6oiU= X-Google-Smtp-Source: AIpwx4/kD8DvdHVM4duo3+rHf57iMWnn6Ch61CdEIY6aNrimx0HqkCM7olyYb2YrVYchLP7FHXZTug== X-Received: by 10.107.169.81 with SMTP id s78mr18716618ioe.83.1522914999688; Thu, 05 Apr 2018 00:56:39 -0700 (PDT) Received: from [100.98.202.194] (sp1-72-3-166.msc.spmode.ne.jp. [1.72.3.166]) by smtp.gmail.com with ESMTPSA id w80-v6sm3646817ita.16.2018.04.05.00.56.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 00:56:38 -0700 (PDT) From: Kazuho Oku X-Google-Original-From: Kazuho Oku Content-Type: multipart/alternative; boundary=Apple-Mail-32F7D8EF-8F53-4441-864C-68DC8D6094D0 Mime-Version: 1.0 (1.0) Subject: Re: Getting to consensus on packet number encryption X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Thu, 5 Apr 2018 16:56:36 +0900 Cc: Praveen Balasubramanian , Lars Eggert , IETF QUIC WG , =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Transfer-Encoding: 7bit Message-Id: <022A1A49-1E9B-4428-8EAE-4C16843715AA@gmail.com> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 07:56:43 -0000 --Apple-Mail-32F7D8EF-8F53-4441-864C-68DC8D6094D0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 2018/04/05 15:00=E3=80=81Mikkel Fahn=C3=B8e J=C3=B8rgensen =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > There is also the concern raised by some that packet reordering in transit= could happen without PN - this is always an issue - but is it worth the cos= t, and is it still a real concern for a protocol that was not designed to be= strictly ordered? I agree that reordering by middleboxes *might not* happen. But I would also a= rgue that we should encrypt the PN if we think reordering *might* happen. If we encrypt PN now, we will have the chance to revisit the design in the f= uture versions of QUIC. But if we ship without PNE and then find out middleb= oxes start using the PN under the assumption that they are sent in-order, we= would forever be forced to stick to them sent in-order, in cleartext.=20 Ossification closes the door to future modifications. > How does WebRTC work in this context? >=20 >=20 >> On 5 April 2018 at 01.42.23, Praveen Balasubramanian (pravb@microsoft.com= ) wrote: >>=20 >> What is the privacy issue if you are not doing migration? Migration + PNE= (or multiple PN spaces) should go hand in hand. --Apple-Mail-32F7D8EF-8F53-4441-864C-68DC8D6094D0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 2018/04/05 15:00=E3=80=81Mikkel Fahn=C3=B8e= J=C3=B8rgensen <mikkelfj@gmail.com= >=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

=
There is also the concern raised by some that packet reordering in tran= sit could happen without PN - this is always an issue - but is it worth the c= ost, and is it still a real concern for a protocol that was not designed to b= e strictly ordered?

I agree that reord= ering by middleboxes *might not* happen. But I would also argue that we shou= ld encrypt the PN if we think reordering *might* happen.

If we encrypt PN now, we will have the chance to revisit the design in the f= uture versions of QUIC. But if we ship without PNE and then find out middleb= oxes start using the PN under the assumption that they are sent in-order, we= would forever be forced to stick to them sent in-order, in cleartext. =

Ossification closes the door to future modifications.


How does WebRTC wor= k in this context?


On 5 April 2018 at 01.42.23, Praveen Balasubramanian (pravb@microsoft.com) wrote:

What is the privacy issue if you are not doing migration? Migration + PNE= (or multiple PN spaces) should go hand in hand.
= --Apple-Mail-32F7D8EF-8F53-4441-864C-68DC8D6094D0-- From nobody Thu Apr 5 01:52:50 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA12F126DED for ; Thu, 5 Apr 2018 01:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuB7fX64tWRL for ; Thu, 5 Apr 2018 01:52:46 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [IPv6:2620:10a:4005:8000:2306::c]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B5A126DC2 for ; Thu, 5 Apr 2018 01:52:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.48,410,1517904000"; d="asc'?scan'208";a="251604481" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx143-out.netapp.com with ESMTP; 05 Apr 2018 01:52:45 -0700 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 5 Apr 2018 01:51:54 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Thu, 5 Apr 2018 01:51:53 -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=MsygTQZQDT/NnT/e/vAwZcPVv9Jq9layiV1MuObiU9M=; b=hKFGBNoqp5nAVg+4nkGJXkKpLePnfRhSnifUukzM/7S/O4pHbi5kSIh1d2tub54GrTP35pqOEMbfX0a3YJ7P22hiq8KTdgjTd8LcN82lN3PBk9V00SGNPdgMmC7VImLLR8dS3YmnHvwQ1i5xaDXGaJRFUUzgybv5+36g9T+exg8= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1730.namprd06.prod.outlook.com (10.162.224.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Thu, 5 Apr 2018 08:51:52 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::fcd6:68ad:7a0:55c2]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::fcd6:68ad:7a0:55c2%4]) with mapi id 15.20.0653.013; Thu, 5 Apr 2018 08:51:52 +0000 From: "Eggert, Lars" To: QUIC WG Subject: Re: Doodle poll for May 2018 remote interop day Thread-Topic: Doodle poll for May 2018 remote interop day Thread-Index: AQHTxZiTQvN4V8CATE+TRAFkrR9/OaPx63yA Date: Thu, 5 Apr 2018 08:51:52 +0000 Message-ID: <5BBA8305-8870-4F74-9456-A4232CA5C3C2@netapp.com> References: <9C605165-D6F0-4ECC-9C49-41C059324603@netapp.com> <5D489CC6-2C35-4486-86DE-95CCC7A3C21D@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.3445.6.18) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:360d:b01:d59d:14f1:aab2:4af7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1730; 7:qq3GBOEQDTDyJRu/skK2o8Okf8hiVSVhN0mqBOqkd738mBd6/MuEsy+kSjj2CkM6104zCUVnYQLpPprppo5j9/vxwUNUwnKD/rCyeGAlbgRnWi0LJYO2cm23TjUPCEwkZ3zq/VVtD9X8zhBblmJqgi1j4Fa4X9++Ax6aNx+o2hv6OAI7FD7F6QnDtL/TBSQyOQ8zfp4ZsM46PIrFX1/WRI0ZDTDWujOP8ScNJWQC1f1DVOT24Sa9a0WGsAPbM9Hq x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5ecd418a-17f8-4e50-f551-08d59ad279f6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(49563074)(7193020); SRVR:BLUPR06MB1730; x-ms-traffictypediagnostic: BLUPR06MB1730: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60409825278598); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(3002001)(10201501046)(6055026)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:BLUPR06MB1730; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1730; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(39380400002)(346002)(396003)(199004)(189003)(377424004)(6486002)(6116002)(7736002)(33656002)(305945005)(6246003)(25786009)(2900100001)(68736007)(186003)(6512007)(478600001)(6306002)(57306001)(99286004)(36756003)(76176011)(4001150100001)(59450400001)(6506007)(97736004)(53546011)(102836004)(53936002)(476003)(486006)(6436002)(316002)(5660300001)(3660700001)(105586002)(2616005)(99936001)(8676002)(50226002)(83716003)(8936002)(46003)(2906002)(3280700002)(82746002)(5250100002)(81166006)(81156014)(446003)(11346002)(229853002)(86362001)(966005)(6916009)(106356001)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1730; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 0ePPnimS4s0uBTXoan2SVZaiw48aHviTrzq4JR2J5ttRevtFatflcB1p0cHKXIRZW70yTxegxiGIM8hFHxHtROdoKt0buPYrO2FeDQk7Js7kpdxYj9jYejaFSSeArtUhu/L1eXzXNE5ZtQCntxnAxX9fMWrN3AViXmHlQHBwM0ixTqtKiG7dhoWhxy1q9jo2Kmv+pgDWAE3fCrmXWbH8op5Jcgz+b0Nf+QC6cL5lAnVRiqGMbZs2a8ZBpHn/rHumX2keyLuzBs3m9n2gY00l7eiiNmNJnQuMGlJsHUOIF93K8ekgwFWZYEAGLLIi6nP5xy4SBhCkj9hm0YmX8LzjgdoQ3Jqot13tReafWxuusyPSO/gfEpSSGWpwRn3I3xsuNlnch1CAt6z2HlqwedS4koYXmJj57Fhfdw4zwrX6kwI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_EE344B23-BF89-42A4-9157-CB985C90A4DC"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5ecd418a-17f8-4e50-f551-08d59ad279f6 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 08:51:52.0248 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1730 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, 05 Apr 2018 08:52:48 -0000 --Apple-Mail=_EE344B23-BF89-42A4-9157-CB985C90A4DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, reminder to please fill this out ASAP, if you have a stack to test. At = the moment, May 17 is in the lead. Lars > On 2018-3-27, at 8:55, Eggert, Lars wrote: >=20 > Hi, >=20 > Please indicate your availability, if you have a stack you wish to = test: https://doodle.com/poll/9ymcx2aymwkrydau >=20 > (This will be a remote/virtual interop day. Next physical one will be = at the interim in Kista in June.) >=20 > Lars >=20 --Apple-Mail=_EE344B23-BF89-42A4-9157-CB985C90A4DC 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlrF46cACgkQVLXDCb9w wVe7Fg/+K9NG79n3abrB0K9062ATX950KVG+A3XvKs5DtSO+TZZhHFHMmmS5OHYq 3me+VFNo3/xFOX6DYeqQWBFJNDy3l+egE10eUylj6woVCOrZ0Gtdnpshdn1aZBJi cmClr30cYqQ35YHgZgKCYN0KfbuCk629h2LTpYJ8Eiqw6gnVjV3NB3nV4McsBsjw jzeM0VG+LNnZn9zTpnTErN8pQSKSkPxy2AYb6MCDYgmWVQepZX7jsqHLpP0yUFaa iZqaQ2yd4u6cgUjcW5GuASknER9p/fAhQfLxQGdv5NhgQ1xjw7Se5NhG8eAYc+MZ 6uH49OMI4rQ/YTN73LXV5Y20JoZ51FZSbkcnYbUG0GdcgjvEXV/oB7BtCR/zNDSU n3HPNdA8nJ0/nbJ1mmoPLOSdrAw97he1YTMx41OpwBhrl1w0M1bL15+Doz1ywfaH b609j4Tp1Db4GH1E02uLsQVRPS/OuoGtxxbWp2DTbAGpSiFql+/vEsbIx4lSzLtM abhfeELhzyQyAB+efAV5qRSjL0e+OQLu3X0JZ57jlWL6rz0qtZMe5jwTjN3NCoCM AczX4ly1njgQw8qzRoCvzyyZG0xnSAzkMf88SvsY1LPBBHCmZ+XhpfPLaP2j1oSH NuFRHzb93lFMqUeAmV98hBzCN/MYDFnydUeKnjzhp6o1oDPFKJM= =dEuH -----END PGP SIGNATURE----- --Apple-Mail=_EE344B23-BF89-42A4-9157-CB985C90A4DC-- From nobody Thu Apr 5 02:27:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F2B12702E for ; Thu, 5 Apr 2018 02:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT0C0w9mpuI7 for ; Thu, 5 Apr 2018 02:27:00 -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 EBA8C126579 for ; Thu, 5 Apr 2018 02:26:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 40GyC6208PzMphp; Thu, 5 Apr 2018 11:26:58 +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 IMj6fGhgG9C3; Thu, 5 Apr 2018 11:26:57 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.24] (i577BCEF2.versanet.de [87.123.206.242]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 5 Apr 2018 11:26:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Getting to consensus on packet number encryption From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net> Date: Thu, 5 Apr 2018 11:26:53 +0200 Cc: quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3445.5.20) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 09:27:02 -0000 Let me repeat another position then as well: > Am 05.04.2018 um 02:44 schrieb Christian Huitema = : >=20 > If we are in the business of repeating our positions, so be it. I am = pretty much on the same line as Patrick and others: >=20 > 1) Privacy is not optional. And yes, removing "linkability through PN" = is important, because when the connection ID and the source address also = change, the only other cue for linkability is timing. Timing can be = addressed by having overlapping connections. >=20 Timing doesn=E2=80=99t help here either because you still have the same = destination IP, both port numbers and the fact that a migrated = connection does not have a handshake. If we want to address the = linkability problem, we would need to do much more, probably baring more = hits on performance.=20 I thought we discussed this already endlessly and concluded that PNE = does not help linkability. Then an argument for ossification was broad up. However, we really = cannot compare the situation here with TCP. With TCP everything is in = the clear incl. also the retransmissions. In case of MPTCP this was = rather the problem the the seq# because if you=E2=80=99d use the same = seq# number space on both connections it would like loss but without a = retransmission. Further boxes that reorder, usually do that in situation = where packets were transmitted for a known reason out-of order = previously, e.g. when multiple paths are used in the network. The = recommendation we still give in the IETF transport area is that in such = a situation the scheduling should not be done on a per-packet level but = per-flow. However, those scheme that do per-packet scheduling usually = also apply mechanism to re-order afterwards. They can just use the TCP = seq# for that but for non-TCP they would simply add their own = encapsulation with a seq#=E2=80=A6 Please keep in mind that even if an (unencrypted) PN gets ossified by = the network, in case of QUIC that does not mean that we can=E2=80=99t change the = transport machinery anymore. Currently the exposed PN is also used for = congestion control and retransmission, however, we can still add another = PN in the encrypted part and resolved the fact that the current PN is = overloaded for different functions. Currently, I really still don=E2=80=99t see the benefit of PNE but only = additional complexity and known performance degradation. Mirja From nobody Thu Apr 5 02:58:45 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6CC126BF3 for ; Thu, 5 Apr 2018 02:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8z2rg3OmMKh for ; Thu, 5 Apr 2018 02:58:42 -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 213AD124205 for ; Thu, 5 Apr 2018 02:58:32 -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 w359vSQS005768 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Apr 2018 11:57:28 +0200 Received: from teststation.net.t-labs.tu-berlin.de ([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 1f41dO-0006WY-Gn; Thu, 05 Apr 2018 11:56:46 +0200 From: "Philipp S. Tiesel" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9DDAD3B0-42BD-4116-8244-423D0B33D64A" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Getting to consensus on packet number encryption Date: Thu, 5 Apr 2018 11:57:27 +0200 In-Reply-To: <022A1A49-1E9B-4428-8EAE-4C16843715AA@gmail.com> Cc: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Praveen Balasubramanian , IETF QUIC WG , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Lars Eggert To: Kazuho Oku References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <022A1A49-1E9B-4428-8EAE-4C16843715AA@gmail.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 09:58:44 -0000 --Apple-Mail=_9DDAD3B0-42BD-4116-8244-423D0B33D64A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5. Apr 2018, at 09:56, Kazuho Oku wrote: >=20 > 2018/04/05 15:00=E3=80=81Mikkel Fahn=C3=B8e J=C3=B8rgensen = >=E3=81=AE=E3=83=A1=E3=83=BC= =E3=83=AB: >=20 >> There is also the concern raised by some that packet reordering in = transit could happen without PN - this is always an issue - but is it = worth the cost, and is it still a real concern for a protocol that was = not designed to be strictly ordered? >=20 > I agree that reordering by middleboxes *might not* happen. But I would = also argue that we should encrypt the PN if we think reordering *might* = happen. >=20 > If we encrypt PN now, we will have the chance to revisit the design in = the future versions of QUIC. But if we ship without PNE and then find = out middleboxes start using the PN under the assumption that they are = sent in-order, we would forever be forced to stick to them sent = in-order, in cleartext.=20 >=20 > Ossification closes the door to future modifications. For the case of the PN, I also see this problem, but (inspired by = Brian),=20 I started thinking of this from a different perspective: What if we think of the "clear PN" as a path signal, which is = coincidentally used as PN in the transport in v1. For me, the consequences seem the following: - It instantly becomes somewhat of an invariant, for which we can = clearly define behaviour (monotonically increasing, jumps infrequent, =E2=80=A6)=20 - Need to design the "clear PN=E2=80=9D for space efficiency =E2=80=93 = use a variable length integer that can reduce to one byte if we have a "transport PN" in = the encrypted part in v2 Maybe a =E2=80=9Cfaster=E2=80=9D way forward without needing to feel = ossified. >=20 >=20 >> How does WebRTC work in this context? >>=20 >>=20 >> On 5 April 2018 at 01.42.23, Praveen Balasubramanian = (pravb@microsoft.com ) wrote: >>=20 >>> What is the privacy issue if you are not doing migration? Migration = + PNE (or multiple PN spaces) should go hand in hand. AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' --Apple-Mail=_9DDAD3B0-42BD-4116-8244-423D0B33D64A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 5. Apr 2018, at 09:56, Kazuho Oku <kazuhooku@gmail.com>= wrote:

2018/04/05 = 15:00=E3=80=81Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

There is also the = concern raised by some that packet reordering in transit could happen = without PN - this is always an issue - but is it worth the cost, and is = it still a real concern for a protocol that was not designed to be = strictly ordered?

I agree that reordering by middleboxes *might not* = happen. But I would also argue that we should encrypt the PN if we think = reordering *might* happen.

If we encrypt = PN now, we will have the chance to revisit the design in the future = versions of QUIC. But if we ship without PNE and then find out = middleboxes start using the PN under the assumption that they are sent = in-order, we would forever be forced to stick to them sent in-order, in = cleartext. 

Ossification closes the door to future = modifications.

For the case of the PN, I also see this problem, = but (inspired by Brian), 
I started thinking of this from = a different perspective:

What if we = think of the "clear PN" as a path signal, which is coincidentally used = as PN in the transport in v1.
For me, the consequences seem = the following:
 - It instantly becomes somewhat of an = invariant, for which we can clearly define
  =  behaviour (monotonically increasing, jumps infrequent, = =E2=80=A6) 
 - Need to design the "clear PN=E2=80=9D = for space efficiency =E2=80=93 use a variable length
  =  integer that can reduce to one byte if we have a "transport PN" in = the encrypted
   part in v2

Maybe a =E2=80=9Cfaster=E2=80=9D way forward = without needing to feel ossified.



How does WebRTC work in this = context?


On 5 April 2018 at 01.42.23, Praveen = Balasubramanian (pravb@microsoft.com) wrote:

What is the privacy issue if you = are not doing migration? Migration + PNE (or multiple PN spaces) should = go hand in = hand.

AVE!
  Philipp S. Tiesel / phils=E2=80=A6-- 
   {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----,
  =     wenn w eine   aube ist dn      man au = dran dre en                 =   |
           o   =   Schr        an muss     hc   =       h   (Kurt Schwitters) |
:wq! =  <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----'

= --Apple-Mail=_9DDAD3B0-42BD-4116-8244-423D0B33D64A-- From nobody Thu Apr 5 05:14:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A72126CC7 for ; Thu, 5 Apr 2018 05:14: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHlNvLEWqpFo for ; Thu, 5 Apr 2018 05:14:15 -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 2CFD8124BE8 for ; Thu, 5 Apr 2018 05:14:15 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w35CA8D7021318; Thu, 5 Apr 2018 13:14:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=RCdjVqOqa1hohgxWO1akbpAkgvf/w55wfyZW8WmUZlE=; b=XJsqib8SHEuKH5RpCHe/5r8AhSEx+87xChKIZIkENYOzVH45rHcX77Yo4J5Kl5VLg/Mf Vo84UQ0r8SZFI9wheKwNMc/8fwucjZE1xjvPeHUW91p2sXLb8c31mR7iA4G1uSDbu52f RLPV+FGrlftNSmKeyY5RTIr3O9AV8DCwO7nfbb6C8Iwrfd/khwyHam7+MxEmpwk9JwH8 3EMCBmOd3tVFuxfN1M0xvPya90x/FlCs6SkpS5kRTt07eVBMuXO4Umualkf4mQx3GxiY 73MP33YBzr9z5D8c2RC9IMOkSBa8l1u1IW/z44S2N0v9+FBj6KYEH9sRF3q5ZGeFRfJt ug== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2h58k29982-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 13:14:12 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w35C70so002995; Thu, 5 Apr 2018 08:14:11 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint1.akamai.com with ESMTP id 2h25nvt92r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 08:14:10 -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.1365.1; Thu, 5 Apr 2018 08:14:10 -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.1365.000; Thu, 5 Apr 2018 08:14:10 -0400 From: "Lubashev, Igor" To: "quic@ietf.org" , "martenseemann@gmail.com" Subject: RE: Implicitly opened streams and exposing stream IDs Thread-Topic: Implicitly opened streams and exposing stream IDs Thread-Index: AQHTynfbGUCX+ewXh0mMrL6WkO0VQ6PyGkT0 Date: Thu, 5 Apr 2018 12:14:09 +0000 Message-ID: <42531619e25b4a4cbd16e77fb1859fde@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_42531619e25b4a4cbd16e77fb1859fdeusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=775 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050129 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=710 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050129 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 12:14:18 -0000 --_000_42531619e25b4a4cbd16e77fb1859fdeusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is not a QUIC transport draft concern. This is a question of QUIC libr= ary API design. Your API may choose to have Accept return streams in order.= My API may choose to have Accept return streams as they come in (and expos= e steam IDs). As long as the transport draft requires that streams are CREA= TED in order (as it does now), both API designs are valid. It would be a matter of a very different draft to standardize QUIC APIs (li= ke we have for POSIX) so an application can be easily ported to use a diffe= rent vendor's QUIC libraries. - Igor -----Original Message----- From: Marten Seemann [martenseemann@gmail.com] Received: Monday, 02 Apr 2018, 7:43AM To: QUIC WG [quic@ietf.org] Subject: Implicitly opened streams and exposing stream IDs Recently, the implicit opening of streams (i.e. that when a receiver receiv= es a frame for stream N+4, it can assume that stream N was already opened, = but the packet might have been reordered) was removed from the draft. I thi= nk this change has some consequences that we haven't discussed so far. For the purpose of writing some pseudocode, I'm assuming a QUIC API that pr= ovides an AcceptStream() method, but the conclusions will be the same for a= callback-based API. * If QUIC has implicit stream opening, AcceptStream() would return the = streams in order (and if a frame opening stream N+4 is received before stre= am n is opened, AcceptStream() will first return stream N and then stream N= +4). * Without implicit stream opening, AcceptStream() just returns whatever= stream is received first. Streams might be returned in arbitrary order, if= the peer doesn't open streams consecutively or if packets are reordered. Now imagine an application protocol where the first unidirectional stream o= pened by the client is a control stream, and all higher unidirectional stre= ams are data streams. The application on the server side needs to find out = which stream is the control stream, because it needs to be handled separate= ly. With implicit stream opening, the server code would be: control_stream =3D AcceptStream() // is guaranteed to open the first st= ream // handle the control stream while true: stream =3D AcceptStream() // handle the data stream and without implicit stream opening: while true: stream =3D AcceptStream() if stream.ID() =3D=3D kControlStreamID: // handle the control stream else: // handle the data stream In this case, after accepting a stream, we first have to check the stream I= D, since there's no guarantee if the control stream will actually be receiv= ed first. For this stream mapping, it seems like the removal of implicitly opened str= eams implies that QUIC has to expose stream IDs to the application layer. I= 'm not sure if this was intended when making the change, especially since w= e're considering to change HQ such that it doesn't rely on QUIC stream IDs = any more. We only manage to avoid the problem described here in our HTTP mapping, bec= ause the HTTP control streams are unidirectional and the request streams ar= e bidirectional, and can therefore be told apart by their directionality. H= owever, as a general transport protocol, other applications built on top of= QUIC will have to find some way to deal with it. --_000_42531619e25b4a4cbd16e77fb1859fdeusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is not a QUIC transport draft concern. This is a ques= tion of QUIC library API design. Your API may choose to have Accept return = streams in order. My API may choose to have Accept return streams as they come in (and expose steam IDs). As l= ong as the transport draft requires that streams are CREATED in order (as i= t does now), both API designs are valid.

It would be a matter of a very different draft to standardize QUIC APIs (li= ke we have for POSIX) so an application can be easily ported to use a diffe= rent vendor's QUIC libraries.

- Igor


-----Original Message-----
From: Marten Seemann [martenseemann@gmail.com]
Received: Monday, 02 Apr 2018, 7:43AM
To: QUIC WG [quic@ietf.org]
Subject: Implicitly opened streams and exposing stream IDs
Recently, the implicit opening of streams (i.e. that when a receiver r= eceives a frame for stream N+4, it can assume that stream N was already= opened, but the packet might have been reordered) was removed from the dra= ft. I think this change has some consequences that we haven't discussed so far.

For the purpose of writing some pseudocode, I'm assuming a QUIC API th= at provides an AcceptStream() method, but the conclusions will be the same for a ca= llback-based API.
  • If QUIC has implicit stream opening, AcceptStream() would return= the streams in order (and if a frame opening stream N+4 is received be= fore stream n is opened, AcceptStream() will first return stream N and then stream N+4).&= nbsp;
  • Without implicit stream opening, AcceptStream() just r= eturns whatever stream is received first. Streams might be returned in arbi= trary order, if the peer doesn't open streams consecutively or if packets a= re reordered.

Now imagine an application protocol where the first unidirectional str= eam opened by the client is a control stream, and all higher unidirectional= streams are data streams. The application on the server side needs to find= out which stream is the control stream, because it needs to be handled separately.

With implicit stream opening, the server code would be:

    control_stream =3D AcceptStream() // is guaranteed to open th= e first stream
    // handle the control stream
     while true:
         stream =3D AcceptStream()
         // handle the data stream

and without implicit stream opening:

    while true:
        stream =3D AcceptStream()
        if stream.ID() =3D=3D kControlStreamID:
            // handle the control stream=
        else:
            // handle the data stream

In this case, after accepting a stream, we first have to check the str= eam ID, since there's no guarantee if the control stream will actually be r= eceived first.

For this stream mapping, it seems like the removal of implicitly opene= d streams implies that QUIC has to expose stream IDs to the application lay= er. I'm not sure if this was intended when making the change, especially si= nce we're considering to change HQ such that it doesn't rely on QUIC stream IDs any more.
We only manage to avoid the problem described here in our HTTP mapping= , because the HTTP control streams are unidirectional and the request strea= ms are bidirectional, and can therefore be told apart by their directionali= ty. However, as a general transport protocol, other applications built on top of QUIC will have to find some w= ay to deal with it.
--_000_42531619e25b4a4cbd16e77fb1859fdeusma1exdag1mb5msgcorpak_-- From nobody Thu Apr 5 05:51:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB91A12778E for ; Thu, 5 Apr 2018 05:51:46 -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 yufm04mZuX0n for ; Thu, 5 Apr 2018 05:51:44 -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 3C35D127201 for ; Thu, 5 Apr 2018 05:51:44 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id e79so30478779ioi.7 for ; Thu, 05 Apr 2018 05:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=azQWq3yA4/cFRT2Hhm0FSHuvObdAYqmnRI5/ptyO8Eo=; b=QBfkr6TVFb5To3aMtizle5nS0OkR7dTS/z3H/qsH66tow6XdQ8kci80BQRDwN8IpZo xFzOpNE3DbgNJdrLMzglcqUl5eHxw426csgQULxIX/AQD9Hv/9g5204WEtDi/KtoVBPb b9NEtDfm0ALyDRNA7ReYMGG+6hzeFUY8KvI6FqfHFknzLIuDrdoFC7OpWcUWHoJoD8Zy PnY3pbpb0dJ3gKwUwJLvdNlMvSvg+XV76K+OkKnw8z04AT/vYBG5NWz2ML6/JFmZcdPW 6RqiVGuEHALhcQ7wnw73m1e5RlAPdXh2Rao7zOK8RkSNxLGxkfeD5JQtXZk/pmRqrJyw u6bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=azQWq3yA4/cFRT2Hhm0FSHuvObdAYqmnRI5/ptyO8Eo=; b=QUFProEm9BCi5sxzvgYGn1EwreYxZm/GNpXPZeNU/ucsJIC9TiwKUs24mY6NgOQjNb 6W4FBJM89rBS0mHHSWXs4XHNUD25kr32SkkJl1/WLlHUE86jPzFY6xmqwn4By8uEwg/m MzLc9ctR/FwhN8SBxS9le6O1f4rkNaCOIImBcQW27sqqkbd9lIW6qF04qABT6aMH5ZYo yBXWNh9Rx6FN2tF/DDTq5a+SD3KK7VvLXs0Bp/kCeRDVSvCh8ZYFDWnroxMdy2pUUutQ GD8MUaD9h5kqn7jyl67IWvUv6Hojk3ctWQv2s2O1HETAEww8UTnt0sSV+armRzphJ6ar Tb+A== X-Gm-Message-State: AElRT7GB72ipeFhdpyFXlMJAHncArGWqoVJccu0MpqsWrw19Bz0xHDpg lQe6mxNwGlHgaYpEXPdZ39eXa8oB3IBTstoZbDTK4A== X-Google-Smtp-Source: AIpwx49/57Uvu//6ylmLBJIGasNpLPe8qvpo2XUhnIHN4SfCdaKs76PI7I/vQmD28GpjOje57+2ikXdqKzl/IQKQewY= X-Received: by 10.107.6.32 with SMTP id 32mr20919474iog.24.1522932703250; Thu, 05 Apr 2018 05:51:43 -0700 (PDT) MIME-Version: 1.0 References: <42531619e25b4a4cbd16e77fb1859fde@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <42531619e25b4a4cbd16e77fb1859fde@usma1ex-dag1mb5.msg.corp.akamai.com> From: Marten Seemann Date: Thu, 05 Apr 2018 12:51:32 +0000 Message-ID: Subject: Re: Implicitly opened streams and exposing stream IDs To: "Lubashev, Igor" Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a113fbf5ccb52be05691966b4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 12:51:47 -0000 --001a113fbf5ccb52be05691966b4 Content-Type: text/plain; charset="UTF-8" Hi Igor, This is exactly the change I'm proposing. Currently, the draft says that you SHOULD create streams in order (section 9.2). I'd like to change that SHOULD to a MUST. Only if in order stream creation is a requirement, this question becomes an API design question. Regards, Marten On Thu, Apr 5, 2018 at 7:14 PM Lubashev, Igor wrote: > This is not a QUIC transport draft concern. This is a question of QUIC > library API design. Your API may choose to have Accept return streams in > order. My API may choose to have Accept return streams as they come in (and > expose steam IDs). As long as the transport draft requires that streams are > CREATED in order (as it does now), both API designs are valid. > > It would be a matter of a very different draft to standardize QUIC APIs > (like we have for POSIX) so an application can be easily ported to use a > different vendor's QUIC libraries. > > > - Igor > > > > -----Original Message----- > *From:* Marten Seemann [martenseemann@gmail.com] > *Received:* Monday, 02 Apr 2018, 7:43AM > *To:* QUIC WG [quic@ietf.org] > *Subject:* Implicitly opened streams and exposing stream IDs > > Recently, the implicit opening of streams (i.e. that when a receiver > receives a frame for stream N+4, it can assume that stream N was already > opened, but the packet might have been reordered) was removed from the > draft. I think this change has some consequences that we haven't discussed > so far. > > For the purpose of writing some pseudocode, I'm assuming a QUIC API that > provides an *AcceptStream()* method, but the conclusions will be the same > for a callback-based API. > > - If QUIC has implicit stream opening, *AcceptStream()* would return > the streams in order (and if a frame opening stream N+4 is received before > stream n is opened, *AcceptStream()* will first return stream N and > then stream N+4). > - Without implicit stream opening, *AcceptStream()* just returns > whatever stream is received first. Streams might be returned in arbitrary > order, if the peer doesn't open streams consecutively or if packets are > reordered. > > > Now imagine an application protocol where the first unidirectional stream > opened by the client is a control stream, and all higher unidirectional > streams are data streams. The application on the server side needs to find > out which stream is the control stream, because it needs to be handled > separately. > > With implicit stream opening, the server code would be: > > control_stream = AcceptStream() // is guaranteed to open the first > stream > // handle the control stream > while true: > stream = AcceptStream() > // handle the data stream > > and without implicit stream opening: > > while true: > stream = AcceptStream() > if stream.ID() == kControlStreamID: > // handle the control stream > else: > // handle the data stream > > In this case, after accepting a stream, we first have to check the stream > ID, since there's no guarantee if the control stream will actually be > received first. > > For this stream mapping, it seems like the removal of implicitly opened > streams implies that QUIC has to expose stream IDs to the application > layer. I'm not sure if this was intended when making the change, especially > since we're considering to change HQ such that it doesn't rely on QUIC > stream IDs any more. > We only manage to avoid the problem described here in our HTTP mapping, > because the HTTP control streams are unidirectional and the request streams > are bidirectional, and can therefore be told apart by their directionality. > However, as a general transport protocol, other applications built on top > of QUIC will have to find some way to deal with it. > --001a113fbf5ccb52be05691966b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Igor,

This is exactly the change I&#= 39;m proposing. Currently, the draft says that you SHOULD create streams in= order (section 9.2). I'd like to change that SHOULD to a MUST.
Only if in order stream creation is a requirement, this question becomes= an API design question.

Regards,
Marten=



On Thu, Apr 5, 2018 at 7:14 PM Lubashev, Igor <ilubashe@akamai.com> wrote:
This is not a QUIC transport draft concern. This is a questi= on of QUIC library API design. Your API may choose to have Accept return st= reams in order. My API may choose to have Accept return streams as they come in (and expose steam IDs). As l= ong as the transport draft requires that streams are CREATED in order (as i= t does now), both API designs are valid.

It would be a matter of a very different draft to standardize QUIC APIs (li= ke we have for POSIX) so an application can be easily ported to use a diffe= rent vendor's QUIC libraries.


- Igor



-----Original Message-----
From: Marten Seemann [martenseemann@gmail.com]
Received: Monday, 02 Apr 2018, 7:43AM
To: QUIC WG [quic= @ietf.org]
Subject: Implicitly opened streams and exposing stream IDs

Recently, the implicit opening of streams (i.e. that when a receiver r= eceives a frame for stream N+4, it can assume that stream N was already ope= ned, but the packet might have been reordered) was removed from the draft. = I think this change has some consequences that we haven't discussed so far.

For the purpose of writing some pseudocode, I'm assuming a QUIC AP= I that provides an AcceptStream() method, but the conclusions will be the same for a ca= llback-based API.
  • If QUIC has implicit stream opening, AcceptStream() would return= the streams in order (and if a frame opening stream N+4 is received before= stream n is opened, AcceptStream() will first return stream N and then stream N+4).=C2= =A0
  • Without implicit stream opening, AcceptStream() just ret= urns whatever stream is received first. Streams might be returned in arbitr= ary order, if the peer doesn't open streams consecutively or if packets= are reordered.

Now imagine an application protocol where the first unidirectional str= eam opened by the client is a control stream, and all higher unidirectional= streams are data streams. The application on the server side needs to find= out which stream is the control stream, because it needs to be handled separately.

With implicit stream opening, the server code would be:

=C2=A0 =C2=A0 control_stream =3D AcceptStream() // is guaranteed to open th= e first stream
=C2=A0 =C2=A0 // handle the control stream
=C2=A0 =C2=A0 =C2=A0while true:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0stream =3D AcceptStream()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// handle the data stream

and without implicit stream opening:

=C2=A0 =C2=A0 while true:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 stream =3D AcceptStream()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if stream.ID() =3D=3D kControlStreamID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // handle the control stream=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // handle the data stream

In this case, after accepting a stream, we first have to check the str= eam ID, since there's no guarantee if the control stream will actually = be received first.

For this stream mapping, it seems like the removal of implicitly opene= d streams implies that QUIC has to expose stream IDs to the application lay= er. I'm not sure if this was intended when making the change, especiall= y since we're considering to change HQ such that it doesn't rely on QUIC stream IDs any more.
We only manage to avoid the problem described here in our HTTP mapping= , because the HTTP control streams are unidirectional and the request strea= ms are bidirectional, and can therefore be told apart by their directionali= ty. However, as a general transport protocol, other applications built on top of QUIC will have to find some w= ay to deal with it.
--001a113fbf5ccb52be05691966b4-- From nobody Thu Apr 5 07:06:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432391289B0 for ; Thu, 5 Apr 2018 07:06:21 -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=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 Q-raPelHoB3O for ; Thu, 5 Apr 2018 07:06:19 -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 0C09D129C6B for ; Thu, 5 Apr 2018 07:06:18 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w35DwmBN028646; Thu, 5 Apr 2018 15:06:16 +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=NqnUgb5qiro/psuU9dBEooFHr5fc0SSwRTchYatjmaw=; b=LW1gkUkuS7UtYz4MIeEdKjFYJIuvL1rZ4ArvDMoIqWfhefdTzVebx4o0KCFuu2Y5EjM6 TwSkQbGowNsSxYo+nC9U+CW9+Zu1O4j0sbav9L/m+LVnqLRA3vb8oAgu3qYEhNph448b FpQXYp+2AHOn5TDkEmLKxxExG7Ky/qnu25R7Ao9iXq+CnmkqJ6ccnG80Al9374MmVlk2 GGZmb5GxCX41bhYULLduYsgewvisDzwtms2qZIEwbu5H/g+5SFFZ1Bh8bxxewGSNNNUk Kf3ERz1Zw58PfINNPtqS2gKs3AiZaCwWxNaE+vIn2PKNoef8B6gqCGCCK6nASisXvWA0 0A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2h4n5g4an5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 15:06:16 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w35E2NQg025990; Thu, 5 Apr 2018 10:06:15 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2h25nvtnxj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 10:06:14 -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.1365.1; Thu, 5 Apr 2018 10:06:13 -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.1365.000; Thu, 5 Apr 2018 10:06:13 -0400 From: "Lubashev, Igor" To: "martenseemann@gmail.com" CC: "quic@ietf.org" Subject: RE: Implicitly opened streams and exposing stream IDs Thread-Topic: Implicitly opened streams and exposing stream IDs Thread-Index: AQHTynfbGUCX+ewXh0mMrL6WkO0VQ6PyGkT0gABNfwD//9HPwg== Date: Thu, 5 Apr 2018 14:06:12 +0000 Message-ID: References: <42531619e25b4a4cbd16e77fb1859fde@usma1ex-dag1mb5.msg.corp.akamai.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_d77eac913ac44ce8a2f96ae38782d3bcusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050148 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=943 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050147 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 14:06:21 -0000 --_000_d77eac913ac44ce8a2f96ae38782d3bcusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. I would like to see MUST there as well. -----Original Message----- From: Marten Seemann [martenseemann@gmail.com] Received: Thursday, 05 Apr 2018, 8:51AM To: Lubashev, Igor [ilubashe@akamai.com] CC: quic@ietf.org [quic@ietf.org] Subject: Re: Implicitly opened streams and exposing stream IDs Hi Igor, This is exactly the change I'm proposing. Currently, the draft says that yo= u SHOULD create streams in order (section 9.2). I'd like to change that SHO= ULD to a MUST. Only if in order stream creation is a requirement, this question becomes an= API design question. Regards, Marten On Thu, Apr 5, 2018 at 7:14 PM Lubashev, Igor > wrote: This is not a QUIC transport draft concern. This is a question of QUIC libr= ary API design. Your API may choose to have Accept return streams in order.= My API may choose to have Accept return streams as they come in (and expos= e steam IDs). As long as the transport draft requires that streams are CREA= TED in order (as it does now), both API designs are valid. It would be a matter of a very different draft to standardize QUIC APIs (li= ke we have for POSIX) so an application can be easily ported to use a diffe= rent vendor's QUIC libraries. - Igor -----Original Message----- From: Marten Seemann [martenseemann@gmail.com] Received: Monday, 02 Apr 2018, 7:43AM To: QUIC WG [quic@ietf.org] Subject: Implicitly opened streams and exposing stream IDs Recently, the implicit opening of streams (i.e. that when a receiver receiv= es a frame for stream N+4, it can assume that stream N was already opened, = but the packet might have been reordered) was removed from the draft. I thi= nk this change has some consequences that we haven't discussed so far. For the purpose of writing some pseudocode, I'm assuming a QUIC API that pr= ovides an AcceptStream() method, but the conclusions will be the same for a= callback-based API. * If QUIC has implicit stream opening, AcceptStream() would return the = streams in order (and if a frame opening stream N+4 is received before stre= am n is opened, AcceptStream() will first return stream N and then stream N= +4). * Without implicit stream opening, AcceptStream() just returns whatever= stream is received first. Streams might be returned in arbitrary order, if= the peer doesn't open streams consecutively or if packets are reordered. Now imagine an application protocol where the first unidirectional stream o= pened by the client is a control stream, and all higher unidirectional stre= ams are data streams. The application on the server side needs to find out = which stream is the control stream, because it needs to be handled separate= ly. With implicit stream opening, the server code would be: control_stream =3D AcceptStream() // is guaranteed to open the first st= ream // handle the control stream while true: stream =3D AcceptStream() // handle the data stream and without implicit stream opening: while true: stream =3D AcceptStream() if stream.ID() =3D=3D kControlStreamID: // handle the control stream else: // handle the data stream In this case, after accepting a stream, we first have to check the stream I= D, since there's no guarantee if the control stream will actually be receiv= ed first. For this stream mapping, it seems like the removal of implicitly opened str= eams implies that QUIC has to expose stream IDs to the application layer. I= 'm not sure if this was intended when making the change, especially since w= e're considering to change HQ such that it doesn't rely on QUIC stream IDs = any more. We only manage to avoid the problem described here in our HTTP mapping, bec= ause the HTTP control streams are unidirectional and the request streams ar= e bidirectional, and can therefore be told apart by their directionality. H= owever, as a general transport protocol, other applications built on top of= QUIC will have to find some way to deal with it. --_000_d77eac913ac44ce8a2f96ae38782d3bcusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. I would like to see MUST there as well.

-----Original Message-----
From: Marten Seemann [martenseemann@gmail.com]
Received: Thursday, 05 Apr 2018, 8:51AM
To: Lubashev, Igor [ilubashe@akamai.com]
CC: quic@ietf.org [quic@ietf.org]
Subject: Re: Implicitly opened streams and exposing stream IDs
Hi Igor,

This is exactly the change I'm proposing. Currently, the draft says th= at you SHOULD create streams in order (section 9.2). I'd like to change tha= t SHOULD to a MUST.
Only if in order stream creation is a requirement, this question becom= es an API design question.

Regards,
Marten



On Thu, Apr 5, 2018 at 7:14 PM Lubashev, Igor <ilubashe@akamai.com> wrote:
This is not a QUIC transport draft concern. This is a= question of QUIC library API design. Your API may choose to have Accept re= turn streams in order. My API may choose to have Accept return streams as they come in (and expose steam IDs= ). As long as the transport draft requires that streams are CREATED in orde= r (as it does now), both API designs are valid.

It would be a matter of a very different draft to standardize QUIC APIs (li= ke we have for POSIX) so an application can be easily ported to use a diffe= rent vendor's QUIC libraries.


- Igor



-----Original Message-----
From: Marten Seemann [martenseemann@gmail.com]
Received: Monday, 02 Apr 2018, 7:43AM
To: QUIC WG [quic= @ietf.org]
Subject: Implicitly opened streams and exposing stream IDs

Recently, the implicit opening of streams (i.e. that when a receiver r= eceives a frame for stream N+4, it can assume that stream N was already= opened, but the packet might have been reordered) was removed from the dra= ft. I think this change has some consequences that we haven't discussed so far.

For the purpose of writing some pseudocode, I'm assuming a QUIC API th= at provides an AcceptStream() method, but the conclusions will be the same for a ca= llback-based API.
  • If QUIC has implicit stream opening, AcceptStream() would return= the streams in order (and if a frame opening stream N+4 is received be= fore stream n is opened, AcceptStream() will first return stream N and then stream N+4).&= nbsp;
  • Without implicit stream opening, AcceptStream() just r= eturns whatever stream is received first. Streams might be returned in arbi= trary order, if the peer doesn't open streams consecutively or if packets a= re reordered.

Now imagine an application protocol where the first unidirectional str= eam opened by the client is a control stream, and all higher unidirectional= streams are data streams. The application on the server side needs to find= out which stream is the control stream, because it needs to be handled separately.

With implicit stream opening, the server code would be:

    control_stream =3D AcceptStream() // is guaranteed to open th= e first stream
    // handle the control stream
     while true:
         stream =3D AcceptStream()
         // handle the data stream

and without implicit stream opening:

    while true:
        stream =3D AcceptStream()
        if stream.ID() =3D=3D kControlStreamID:
            // handle the control stream=
        else:
            // handle the data stream

In this case, after accepting a stream, we first have to check the str= eam ID, since there's no guarantee if the control stream will actually be r= eceived first.

For this stream mapping, it seems like the removal of implicitly opene= d streams implies that QUIC has to expose stream IDs to the application lay= er. I'm not sure if this was intended when making the change, especially si= nce we're considering to change HQ such that it doesn't rely on QUIC stream IDs any more.
We only manage to avoid the problem described here in our HTTP mapping= , because the HTTP control streams are unidirectional and the request strea= ms are bidirectional, and can therefore be told apart by their directionali= ty. However, as a general transport protocol, other applications built on top of QUIC will have to find some w= ay to deal with it.
--_000_d77eac913ac44ce8a2f96ae38782d3bcusma1exdag1mb5msgcorpak_-- From nobody Thu Apr 5 07:12:05 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2188129C6B for ; Thu, 5 Apr 2018 07:12: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, 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 k9BH8LezxRDB for ; Thu, 5 Apr 2018 07:11:56 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5B2127599 for ; Thu, 5 Apr 2018 07:11:56 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w35E7N8f000344; Thu, 5 Apr 2018 15:11:52 +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=PNKELAGXd1lcFoVVTbqcKSPZQUlGYxOzOqAeIlaWQbA=; b=dtnkvygxorPkfG4HX7uM7KFvOs1y6PSZAESlc/7nBEnVvEavx2mwCfya9AETedu9DlcE HxgRewjStEvsW1UvY/PK5/cKcXDptlOvEMR/J/rRPhOl0FS0BlkMxz7VaoFyt8LfjOWU mFUngL7YEZpB4NiQW/F/Eb1/8Ojvq0sfRyV+SjQvxrpW7JIpkszrrnb/tCsYPYTZKONx 1PIisd5/WHI524nsZ8JtOuh5og/gwzyEEE/0xLYJNEhRs4zR9HhE4/fs8JRLVLwJajxN ZtdGj6IO8JHuN7+oLr//0NE0Vq57VD5gX7X//kZUXY4DuWSEQpUGBEHAd/hKFxq3Mfu2 7w== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2h5awk1d8h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 15:11:51 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w35E6cfw004807; Thu, 5 Apr 2018 10:11:49 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2h25nvb0jq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 10:11:49 -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.1365.1; Thu, 5 Apr 2018 10:11:48 -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.1365.000; Thu, 5 Apr 2018 10:11:48 -0400 From: "Lubashev, Igor" To: Martin Thomson , Marten Seemann CC: Lucas Pardue , QUIC WG Subject: RE: Implicitly opened streams and exposing stream IDs Thread-Topic: Implicitly opened streams and exposing stream IDs Thread-Index: AQHTynfbGUCX+ewXh0mMrL6WkO0VQ6PttMSAgAEvEICAAAT5gIAAFESAgAAL9oCAAzFIoA== Date: Thu, 5 Apr 2018 14:11:47 +0000 Message-ID: <52f75966fb254e9abcc58ddc5f25ff53@usma1ex-dag1mb5.msg.corp.akamai.com> References: <7CF7F94CB496BF4FAB1676F375F9666A3BB0D858@bgb01xud1012> 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.36.160] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050149 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050148 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 14:12:04 -0000 PiBDcmVhdGlvbiBpc24ndCBhbiBvYnNlcnZhYmxlIGFjdGlvbiwgc28gd2UgbmVlZCB0byB1c2Ug b2JzZXJ2YWJsZSBhY3Rpb25zIHRvIGRyaXZlIHdoYXQgdGhlIHNwZWMgc2F5cy4NCg0KQ3JlYXRp b24gaXMgYSB3aXJlLW9ic2VydmFibGUgYWN0aW9uLCBpZiBhbiBlbmRwb2ludCBjcmVhdGVzIGp1 c3QgYSBzaW5nbGUgc3RyZWFtLCB3aGVuIE1BWF9TVFJFQU1TIGFsbG93cyBjcmVhdGlvbiBvZiBz dHJlYW1zIG4gdGhyb3VnaCBuK20uICBJZiBhIHNpbmdsZSBzdHJlYW0gaXMgY3JlYXRlZCwgdGhl cmUgd2lsbCBvbmx5IGJlIGEgc2luZ2xlIFNUUkVBTShpZD14LCBvZmY9MCkgb24gdGhlIHdpcmUg KHBvc3NpYmx5IHJldHJhbnNtaXR0ZWQpLiAgSXQgd2lsbCBiZSB2ZXJ5IG9ic2VydmFibGUgaWYg eCAhPSBuLg0KDQotIElnb3INCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDog VHVlc2RheSwgQXByaWwgMDMsIDIwMTggNToyNCBBTQ0KVG86IE1hcnRlbiBTZWVtYW5uIDxtYXJ0 ZW5zZWVtYW5uQGdtYWlsLmNvbT4NCkNjOiBMdWNhcyBQYXJkdWUgPEx1Y2FzLlBhcmR1ZUBiYmMu Y28udWs+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IEltcGxpY2l0bHkg b3BlbmVkIHN0cmVhbXMgYW5kIGV4cG9zaW5nIHN0cmVhbSBJRHMNCg0KQ3JlYXRpb24gaXNuJ3Qg YW4gb2JzZXJ2YWJsZSBhY3Rpb24sIHNvIHdlIG5lZWQgdG8gdXNlIG9ic2VydmFibGUgYWN0aW9u cyB0byBkcml2ZSB3aGF0IHRoZSBzcGVjIHNheXMuICBTbyB0aGF0IHdvdWxkIHNlZW0gdG8gYmUg ZXF1aXZhbGVudCB0byByZXN0b3JpbmcgaW1wbGljaXQgb3BlbiBpbiBteSBtaW5kLiAgV2hpY2gg LSBmb3IgdGhlIHJlY29yZCAtIEkgd2FzIGEgcHJvcG9uZW50IG9mLiAgQnV0IHlvdSBkb24ndCBu ZWVkIHRvIGNvbnZpbmNlIG1lIDopDQoNCkFzIHlvdSBzYXksIHRoZSBvYnNlcnZhYmxlIGRpZmZl cmVuY2UgaXMgaW4gd2hldGhlciBzZW5kaW5nIE1BWF9TVFJFQU1fREFUQSBvbiBzdHJlYW0gTiBp cyBwZXJtaXR0ZWQgb25jZSBzdHJlYW0gTis0IGhhcyBiZWVuIG9wZW5lZC4gIChBbmQgc2ltaWxh ciBzdWNoIHRoaW5ncy4pDQoNCkkgZm91bmQgdGhlIHJhdGhlciBzdHJpZGVudCBhcmd1bWVudHMg aW4gZmF2b3VyIG9mIGRyb3BwaW5nIGltcGxpY2l0IG9wZW4gY29udmluY2luZywgaW4gdGhlIHNl bnNlIHRoYXQgYSBzdHJpY3QgcmVxdWlyZW1lbnQgZm9yIGluIG9yZGVyIGNyZWF0aW9uIHdhcyBv bmVyb3VzIGZvciB0aG9zZSB3aG8gd2FudCB0byBwYXJhbGxlbGl6ZSBzdHJlYW0gY29uc3VtcHRp b24uICBCdXQgaXQncyBlbnRpcmVseSBwb3NzaWJsZSB0aGF0IHRoYXQgY291bGQgYmUgZGVhbHQg d2l0aCBieSBzYXlpbmcgdGhhdCB0aGUgc3RyZWFtcyBhcmUgc3RpbGwgY3JlYXRlZCBpbiBvcmRl ciwgYnV0IHVzZWQgb3V0IG9mIG9yZGVyLiAgSSBkb24ndCBrbm93LiAgVGhvc2Ugd2hvIGFyZ3Vl ZCBmb3IgYSBsaWZ0aW5nIG9mIHRoZSByZXF1aXJlbWVudCBzaG91bGQgd2VpZ2ggaW4uDQoNCk9u IFR1ZSwgQXByIDMsIDIwMTggYXQgNjo0MCBQTSwgTWFydGVuIFNlZW1hbm4gPG1hcnRlbnNlZW1h bm5AZ21haWwuY29tPiB3cm90ZToNCj4gSGkgTWFydGluLA0KPg0KPiBJIGRvbid0IHRoaW5rIGRl bGF5ZWQgc3RyZWFtIHVzYWdlIGlzIGEgcHJvYmxlbSBoZXJlLiBUbyBiZSBwcmVjaXNlLCANCj4g d2hhdCBJIG1lYW4gaXMgbm90IG9wZW5pbmcgdGhlIHN0cmVhbSAoYXMgaW4gYWN0dWFsbHkgc2Vu ZGluZyBhIGZyYW1lIA0KPiBvbiB0aGlzIHN0cmVhbSksIGJ1dCBjcmVhdGlvbiBvZiB0aGUgc3Ry ZWFtLiBTbyBhbGwgSSB3YW50IGlzIHRvIA0KPiBSRVFVSVJFIGhlcmUgaXMgdGhhdCBwZWVycyBj cmVhdGUgc3RyZWFtcyBpbiBvcmRlci4NCj4NCj4gVGhlcmUncyBhbiBpbXBvcnRhbnQgZGlmZmVy ZW5jZSBpbiBob3cgdGhlIHJlY2VpdmluZyBwZWVyIGlzIGFsbG93ZWQgdG8gYWN0Lg0KPiBBc3N1 bWUgZm9yIGV4YW1wbGUgdGhlIHJlY2VpdmVyIHdhbnRzIHRvIGdyYW50IGEgaGlnaGVyIGZsb3cg Y29udHJvbCANCj4gbGltaXQgdGhhbiBpdCBhZHZlcnRpc2VkIGR1cmluZyB0aGUgaGFuZHNoYWtl Og0KPg0KPiBJZiBzdHJlYW1zIE1VU1QgYmUgY3JlYXRlZCBpbiBvcmRlciwgdGhlIHJlY2VpdmVy IGNhbiBzZW5kIGEgDQo+IE1BWF9TVFJFQU1fREFUQSBmb3Igc3RyZWFtcyBOIGFuZCBOKzQgYXMg c29vbiBhcyBpdCByZWNlaXZlcyBhIGZyYW1lIGZvciBOKzQuDQo+IElmIHN0cmVhbXMgb25seSBT SE9VTEQgYmUgY3JlYXRlZCBpbiBvcmRlciwgc2VuZGluZyBhIE1BWF9TVFJFQU1fREFUQSANCj4g Zm9yIHN0cmVhbSBOIChhZnRlciByZWNlaXZpbmcgYSBmcmFtZSBmb3IgTis0KSB3aWxsIGNhdXNl IGEgY29ubmVjdGlvbiANCj4gZXJyb3IsIGlmIHRoZSBzZW5kZXIgZGVjaWRlZCB0byBza2lwIHN0 cmVhbSBOLg0KPg0KPiBJJ20gbm90IHNheWluZyB0aGF0IHRoaXMgaXMgYW4gaW1wb3J0YW50IHVz ZSBjYXNlLCBidXQgdGhpcyBleGFtcGxlIA0KPiBzaG93cyB0aGF0IGltcGxlbWVudGF0aW9ucyAq b25seSogaGF2ZSB0aGUgdHdvIG9wdGlvbnMgZm9yIGhhbmRsaW5nIA0KPiBvdXQgb2Ygb3JkZXIg c3RyZWFtcyBkZXNjcmliZWQgaW4gbXkgbGFzdCBlbWFpbCAqaWYqIHdlIHJlcXVpcmUgaW4gb3Jk ZXIgc3RyZWFtIGNyZWF0aW9uLg0KPg0KPiBJJ2QgdGhlcmVmb3JlIHN1Z2dlc3QgdG8gY2hhbmdl IHRoZSB0ZXh0IGluIHRoZSBzcGVjIHRvIHNvbWV0aGluZyBsaWtlIHRoaXM6DQo+ICJFbmRwb2lu dHMgTVVTVCBjcmVhdGUgdGhlIHNlbmQgc2lkZSBvZiBzdHJlYW1zIGZvciBlYWNoIHR5cGUgaW4g b3JkZXIiLg0KPg0KPiBCZXN0LA0KPiBNYXJ0ZW4NCj4NCj4gT24gVHVlLCBBcHIgMywgMjAxOCBh dCAyOjI4IFBNIE1hcnRpbiBUaG9tc29uIA0KPiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0K PiB3cm90ZToNCj4+DQo+PiBSZXF1aXJpbmcgaW4tb3JkZXIgb3BlbmluZyBpcyBoYXJkZXIgdGhh biBpdCBzb3VuZHMuICBTYXkgeW91IGhhdmUgYSANCj4+IG11bHRpdGhyZWFkZWQgYXBwbGljYXRp b24gdGhhdCBpcyBpbml0aWF0aW5nIHJlcXVlc3RzLiAgVGhlIHVzdWFsIA0KPj4gcHJvY2VzcyBp cyBzb21ldGhpbmcgbGlrZToNCj4+DQo+PiBzID0gY29ubmVjdGlvbi5PcGVuU3RyZWFtKCkNCj4+ IHMuV3JpdGUocmVxdWVzdC5IZWFkZXJzLkVuY29kZSgpKQ0KPj4NCj4+IFRoYXQgaXMsIHRoZXJl IGlzIHRpbWUgYmV0d2VlbiBhY3F1aXNpdGlvbiBvZiB0aGUgc3RyZWFtIGFuZCBpdHMgdXNlLg0K Pj4gRG8gdGhhdCB3aXRoIGVub3VnaCBjb25jdXJyZW5jeSBhbmQgeW91IGVuZCB1cCBoYXZpbmcg dG8gYWRkIGxhdGUgDQo+PiBiaW5kaW5nIG9mIHN0cmVhbSBpZGVudGlmaWVycyB0byBzdHJlYW1z LCB3aGljaCBjb21wbGljYXRlcyB0aGUgDQo+PiBkZXNpZ24gb2YgdGhlIHN0YWNrIGNvbnNpZGVy YWJseS4gIEl0IGFsc28gY29tcGxpY2F0ZXMgdXNhZ2UgYmVjYXVzZSANCj4+IG5vdyB0aGVyZSBp cyBhIHBlcmlvZCB3aGVyZSBzLklkKCkgcmV0dXJucyBhbiB1bmRlZmluZWQgcmVzdWx0Lg0KPj4N Cj4+IEFsdGVybmF0aXZlbHksIHlvdSBjb3VsZCB0cmFjayB0aGUgaGlnaGVzdCBzdHJlYW0gSUQg b24gd2hpY2ggZGF0YSANCj4+IGhhcyBiZWVuIHNlbnQgYW5kIHNlbmQgYW4gZW1wdHksIG9mZnNl dCAwIFNUUkVBTSBmcmFtZSByYXRoZXIgdGhhbiANCj4+IGNyZWF0ZSBhIGdhcC4NCj4+DQo+PiBP ciwgeW91IGNvdWxkIGRlY2lkZSB0aGF0IGEgTVVTVCBoZXJlIGlzIHVuZW5mb3JjZWFibGUgKGV2 ZW4gbW9yZSBzbyANCj4+IHRoYW4gdGhlIGZsb3cgY29udHJvbCBsaW1pdHMgb25lKSBhbmQganVz dCB3YW50b25seSBpZ25vcmUgdGhhdCANCj4+IHJlcXVpcmVtZW50IGlmIHRoaXMgcmFjZSBjb25k aXRpb24gaGFwcGVucy4gIFdoaWxlIGl0IGlzIGluIHRoZW9yeSANCj4+IHBvc3NpYmxlIHRvIGNh dGNoIHNvbWVvbmUgaW4gYSB2aW9sYXRpb24sIGl0IHJlcXVpcmVzIHNvbWUgDQo+PiBpbnRlcmVz dGluZyBjb25kaXRpb25zIChsaWtlIHplcm8gcGFja2V0IGxvc3MpLg0KPj4NCj4+IEJUVywgSSBh bHNvIHdpc2ggdG8gbWFrZSBpdCBwb3NzaWJsZSB0byBhdm9pZCByZWx5aW5nIG9uIHNwZWNpZmlj IA0KPj4gc3RyZWFtIElEcyBmb3Igc3BlY2lhbCBmdW5jdGlvbnMuICBJIGhhZG4ndCBjb25zaWRl cmVkIG9wZW5pbmcgb3JkZXIgDQo+PiBhcyBhIHdheSB0byBkbyB0aGF0IHRob3VnaCBhbmQgaGFk IGFzc3VtZWQgdGhhdCB3ZSdkIHVzZSBhbiBpbi1zdHJlYW0gDQo+PiBoZWFkZXIgZm9yIHRoYXQu ICBJIGRvbid0IHRoaW5rIHRoYXQgbWFrZXMgdGhlIGNvbXBsZXhpdHkgd29yc2UsIG9yIA0KPj4g YXQgbGVhc3Qgbm8gd29yc2UgdGhhbiBoYXZpbmcgdG8gZGVhbCB3aXRoIGRpZmZlcmVudCBmcmFt ZSB0eXBlcyBmb3IgDQo+PiBkaWZmZXJlbnQgZnVuY3Rpb25zLg0KPj4NCj4+DQo+PiBPbiBUdWUs IEFwciAzLCAyMDE4IGF0IDU6MTAgUE0sIE1hcnRlbiBTZWVtYW5uIA0KPj4gPG1hcnRlbnNlZW1h bm5AZ21haWwuY29tPg0KPj4gd3JvdGU6DQo+PiA+IEhlbGxvLA0KPj4gPg0KPj4gPiBTdXJlLCB0 aGUgYXBwbGljYXRpb24gY291bGQgZGVhbCB3aXRoIGl0IGJ5IHN0YXJ0aW5nIGV2ZXJ5IHN0cmVh bSANCj4+ID4gd2l0aCBzb21lIGtpbmQgb2YgaGVhZGVyLCB0byBzaWduYWwgd2hhdCBraW5kIG9m IHN0cmVhbSB0eXBlIHRoaXMgDQo+PiA+IGlzLiBJJ20gbm90IHN1cmUgaWYgSSBsaWtlIHRoaXMg c29sdXRpb24sIHNpbmNlIGl0IGNyZWF0ZXMgDQo+PiA+IGFkZGl0aW9uYWwgY29tcGxleGl0eSwg YW5kIGl0IGlzIG9ubHkgbmVjZXNzYXJ5IGJlY2F1c2Ugd2UgcmVtb3ZlZCANCj4+ID4gYSB1c2Vm dWwgZmVhdHVyZSBmcm9tIHRoZSBzcGVjLg0KPj4gPiBXaGF0IGRpZCB3ZSBhY3R1YWxseSBnYWlu IGZyb20gcmVtb3ZpbmcgaW1wbGljaXQgc3RyZWFtIG9wZW5pbmcgDQo+PiA+IGZyb20gdGhlIHBy b3RvY29sPyBBcyBmYXIgYXMgSSBjYW4gc2VlLCB3ZSB3ZXJlIGFibGUgdG8gcmVsYXggdGhlIA0K Pj4gPiByZXF1aXJlbWVudCAiZW5kcG9pbnRzIE1VU1Qgb3BlbiB0aGUgc2VuZCBzaWRlIG9mIHN0 cmVhbXMgZm9yIGVhY2ggDQo+PiA+IHR5cGUgaW4gb3JkZXIiIHRvICJlbmRwb2ludHMgU0hPVUxE IG9wZW4gdGhlIHNlbmQgc2lkZSBvZiBzdHJlYW1zIGZvciBlYWNoIHR5cGUgaW4gb3JkZXIiLg0K Pj4gPiBUaGlzIG1pZ2h0IHNlZW0gbmljZSBmcm9tIGEgY29uY2VwdHVhbCB2aWV3cG9pbnQsIGJ1 dCBob25lc3RseSwgSSANCj4+ID4gZG9uJ3QgcmVhbGx5IHNlZSB3aHkgYW55b25lIHdvdWxkIGFj dHVhbGx5IHdhbnQgdG8gZG8gdGhpcy4gSSB0aGluayANCj4+ID4gdGhlIG1haW4gYXJndW1lbnQg YWdhaW5zdCB0aGUgTVVTVCB3YXMgdGhhdCBpdCdzIG5vdCBlbmZvcmNlYWJsZSANCj4+ID4gYW55 d2F5LCBidXQgdGhpcyBhcHBsaWVzIHRvIGEgbG90IG9mIG90aGVyIE1VU1RzIGluIHRoZSBzcGVj IGFzIA0KPj4gPiB3ZWxsIChlLmcuIHRoYXQgZmxvdyBjb250cm9sIGxpbWl0cyBjYW4ndCBiZSBk ZWNyZWFzZWQpLg0KPj4gPg0KPj4gPiBUaGUgZml4IGZvciB0aGlzIGlzIHN0cmFpZ2h0Zm9yd2Fy ZDogV2Ugc2hvdWxkIFJFUVVJUkUgYSBwZWVyIHRvIA0KPj4gPiBvcGVuIHN0cmVhbXMgaW4gb3Jk ZXIuIEhvdyB0aGUgcmVjZWl2ZXIgaGFuZGxlcyBvdXQgb2Ygb3JkZXIgDQo+PiA+IHN0cmVhbXMg dGhlbiBpcyBhbiBpbXBsZW1lbnRhdGlvbiBhbmQgQVBJIGRlY2lzaW9uLiBJIHNlZSB0d28gd2F5 cyANCj4+ID4gdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCByZWFzb25hYmx5IGRlYWwgd2l0 aCB0aGlzOg0KPj4gPg0KPj4gPiBSZXR1cm4gc3RyZWFtcyBpbiB0aGUgb3JkZXIgdGhleSBhcmUg cmVjZWl2ZWQsIGUuZy4gcmV0dXJuIE4rNCANCj4+ID4gYmVmb3JlIE4sIGlmIHBhY2tldHMgYXJl IHJlb3JkZXJlZC4NCj4+ID4gUmV0dXJuIHN0cmVhbXMgb3JkZXJlZCBieSBzdHJlYW0gSUQsIGku ZS4gcmV0dXJuIGZpcnN0IE4gYW5kIHRoZW4gDQo+PiA+IE4rNCBpZiBhIGZyYW1lIGZvciBOKzQg aXMgcmVjZWl2ZWQuDQo+PiA+DQo+PiA+IFRoaXMgd2F5LCB3ZSB3b3VsZG4ndCBuZWVkIHRvIHJl aW50cm9kdWNlIGltcGxpY2l0bHkgb3BlbmVkIA0KPj4gPiBzdHJlYW1zLCBidXQgbGVhdmUgdGhp cyB1cCB0byBpbXBsZW1lbnRhdGlvbnMuIEkgc2hvdWxkIGhhdmUgbmFtZWQgDQo+PiA+IHRoaXMg dGhyZWFkIGRpZmZlcmVudGx5LCBpZiBvbmx5IEkgaGFkIHJlYWxpemVkIHRoaXMgZWFybGllciA7 KQ0KPj4gPg0KPj4gPiBSZWdhcmRzLA0KPj4gPiBNYXJ0ZW4NCj4+ID4NCj4+ID4gT24gTW9uLCBB cHIgMiwgMjAxOCBhdCA3OjA1IFBNIEx1Y2FzIFBhcmR1ZSANCj4+ID4gPEx1Y2FzLlBhcmR1ZUBi YmMuY28udWs+DQo+PiA+IHdyb3RlOg0KPj4gPj4NCj4+ID4+IEhpIE1hcnRlbiwNCj4+ID4+DQo+ PiA+PiBXb3VsZCBTdHJlYW0gaGVhZGVycyBmaXggdGhpcyBwcm9ibGVtPyBJLmUuIGFueXRoaW5n IHRoYXQgcmVxdWlyZXMgDQo+PiA+PiBzcGVjaWFsIGJlaGF2aW91ciBvdGhlciB0aGFuICJidWxr IGRhdGEiIGhhcyBzb21lIGJ5dGVzIG9mIG9mIA0KPj4gPj4gbWFnaWMgYXQgdGhlIHN0YXJ0IG9m IHRoZSBzdHJlYW0uDQo+PiA+Pg0KPj4gPj4gUmVnYXJkcw0KPj4gPj4gTHVjYXMNCj4+ID4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IEZyb206IFFVSUMg W3F1aWMtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIE1hcnRlbiBTZWVtYW5uIA0KPj4g Pj4gW21hcnRlbnNlZW1hbm5AZ21haWwuY29tXQ0KPj4gPj4gU2VudDogMDIgQXByaWwgMjAxOCAx Mjo0Mw0KPj4gPj4gVG86IFFVSUMgV0cNCj4+ID4+IFN1YmplY3Q6IEltcGxpY2l0bHkgb3BlbmVk IHN0cmVhbXMgYW5kIGV4cG9zaW5nIHN0cmVhbSBJRHMNCj4+ID4+DQo+PiA+PiBSZWNlbnRseSwg dGhlIGltcGxpY2l0IG9wZW5pbmcgb2Ygc3RyZWFtcyAoaS5lLiB0aGF0IHdoZW4gYSANCj4+ID4+ IHJlY2VpdmVyIHJlY2VpdmVzIGEgZnJhbWUgZm9yIHN0cmVhbSBOKzQsIGl0IGNhbiBhc3N1bWUg dGhhdCANCj4+ID4+IHN0cmVhbSBOIHdhcyBhbHJlYWR5IG9wZW5lZCwgYnV0IHRoZSBwYWNrZXQg bWlnaHQgaGF2ZSBiZWVuIA0KPj4gPj4gcmVvcmRlcmVkKSB3YXMgcmVtb3ZlZCBmcm9tIHRoZSBk cmFmdC4gSSB0aGluayB0aGlzIGNoYW5nZSBoYXMgDQo+PiA+PiBzb21lIGNvbnNlcXVlbmNlcyB0 aGF0IHdlIGhhdmVuJ3QgZGlzY3Vzc2VkIHNvIGZhci4NCj4+ID4+DQo+PiA+PiBGb3IgdGhlIHB1 cnBvc2Ugb2Ygd3JpdGluZyBzb21lIHBzZXVkb2NvZGUsIEknbSBhc3N1bWluZyBhIFFVSUMgDQo+ PiA+PiBBUEkgdGhhdCBwcm92aWRlcyBhbiBBY2NlcHRTdHJlYW0oKSBtZXRob2QsIGJ1dCB0aGUg Y29uY2x1c2lvbnMgDQo+PiA+PiB3aWxsIGJlIHRoZSBzYW1lIGZvciBhIGNhbGxiYWNrLWJhc2Vk IEFQSS4NCj4+ID4+DQo+PiA+PiAgICogICBJZiBRVUlDIGhhcyBpbXBsaWNpdCBzdHJlYW0gb3Bl bmluZywgQWNjZXB0U3RyZWFtKCkgd291bGQgcmV0dXJuDQo+PiA+PiB0aGUNCj4+ID4+IHN0cmVh bXMgaW4gb3JkZXIgKGFuZCBpZiBhIGZyYW1lIG9wZW5pbmcgc3RyZWFtIE4rNCBpcyByZWNlaXZl ZCANCj4+ID4+IGJlZm9yZSBzdHJlYW0gbiBpcyBvcGVuZWQsIEFjY2VwdFN0cmVhbSgpIHdpbGwg Zmlyc3QgcmV0dXJuIHN0cmVhbSANCj4+ID4+IE4gYW5kIHRoZW4gc3RyZWFtIE4rNCkuDQo+PiA+ PiAgICogICBXaXRob3V0IGltcGxpY2l0IHN0cmVhbSBvcGVuaW5nLCBBY2NlcHRTdHJlYW0oKSBq dXN0IHJldHVybnMNCj4+ID4+IHdoYXRldmVyIHN0cmVhbSBpcyByZWNlaXZlZCBmaXJzdC4gU3Ry ZWFtcyBtaWdodCBiZSByZXR1cm5lZCBpbiANCj4+ID4+IGFyYml0cmFyeSBvcmRlciwgaWYgdGhl IHBlZXIgZG9lc24ndCBvcGVuIHN0cmVhbXMgY29uc2VjdXRpdmVseSBvciANCj4+ID4+IGlmIHBh Y2tldHMgYXJlIHJlb3JkZXJlZC4NCj4+ID4+DQo+PiA+PiBOb3cgaW1hZ2luZSBhbiBhcHBsaWNh dGlvbiBwcm90b2NvbCB3aGVyZSB0aGUgZmlyc3QgdW5pZGlyZWN0aW9uYWwgDQo+PiA+PiBzdHJl YW0gb3BlbmVkIGJ5IHRoZSBjbGllbnQgaXMgYSBjb250cm9sIHN0cmVhbSwgYW5kIGFsbCBoaWdo ZXIgDQo+PiA+PiB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGFyZSBkYXRhIHN0cmVhbXMuIFRoZSBh cHBsaWNhdGlvbiBvbiB0aGUgDQo+PiA+PiBzZXJ2ZXIgc2lkZSBuZWVkcyB0byBmaW5kIG91dCB3 aGljaCBzdHJlYW0gaXMgdGhlIGNvbnRyb2wgc3RyZWFtLCANCj4+ID4+IGJlY2F1c2UgaXQgbmVl ZHMgdG8gYmUgaGFuZGxlZCBzZXBhcmF0ZWx5Lg0KPj4gPj4NCj4+ID4+IFdpdGggaW1wbGljaXQg c3RyZWFtIG9wZW5pbmcsIHRoZSBzZXJ2ZXIgY29kZSB3b3VsZCBiZToNCj4+ID4+DQo+PiA+PiAg ICAgY29udHJvbF9zdHJlYW0gPSBBY2NlcHRTdHJlYW0oKSAvLyBpcyBndWFyYW50ZWVkIHRvIG9w ZW4gdGhlIA0KPj4gPj4gZmlyc3Qgc3RyZWFtDQo+PiA+PiAgICAgLy8gaGFuZGxlIHRoZSBjb250 cm9sIHN0cmVhbQ0KPj4gPj4gICAgICB3aGlsZSB0cnVlOg0KPj4gPj4gICAgICAgICAgc3RyZWFt ID0gQWNjZXB0U3RyZWFtKCkNCj4+ID4+ICAgICAgICAgIC8vIGhhbmRsZSB0aGUgZGF0YSBzdHJl YW0NCj4+ID4+DQo+PiA+PiBhbmQgd2l0aG91dCBpbXBsaWNpdCBzdHJlYW0gb3BlbmluZzoNCj4+ ID4+DQo+PiA+PiAgICAgd2hpbGUgdHJ1ZToNCj4+ID4+ICAgICAgICAgc3RyZWFtID0gQWNjZXB0 U3RyZWFtKCkNCj4+ID4+ICAgICAgICAgaWYgc3RyZWFtLklEKCkgPT0ga0NvbnRyb2xTdHJlYW1J RDoNCj4+ID4+ICAgICAgICAgICAgIC8vIGhhbmRsZSB0aGUgY29udHJvbCBzdHJlYW0NCj4+ID4+ ICAgICAgICAgZWxzZToNCj4+ID4+ICAgICAgICAgICAgIC8vIGhhbmRsZSB0aGUgZGF0YSBzdHJl YW0NCj4+ID4+DQo+PiA+PiBJbiB0aGlzIGNhc2UsIGFmdGVyIGFjY2VwdGluZyBhIHN0cmVhbSwg d2UgZmlyc3QgaGF2ZSB0byBjaGVjayB0aGUgDQo+PiA+PiBzdHJlYW0gSUQsIHNpbmNlIHRoZXJl J3Mgbm8gZ3VhcmFudGVlIGlmIHRoZSBjb250cm9sIHN0cmVhbSB3aWxsIA0KPj4gPj4gYWN0dWFs bHkgYmUgcmVjZWl2ZWQgZmlyc3QuDQo+PiA+Pg0KPj4gPj4gRm9yIHRoaXMgc3RyZWFtIG1hcHBp bmcsIGl0IHNlZW1zIGxpa2UgdGhlIHJlbW92YWwgb2YgaW1wbGljaXRseSANCj4+ID4+IG9wZW5l ZCBzdHJlYW1zIGltcGxpZXMgdGhhdCBRVUlDIGhhcyB0byBleHBvc2Ugc3RyZWFtIElEcyB0byB0 aGUgDQo+PiA+PiBhcHBsaWNhdGlvbiBsYXllci4NCj4+ID4+IEknbSBub3Qgc3VyZSBpZiB0aGlz IHdhcyBpbnRlbmRlZCB3aGVuIG1ha2luZyB0aGUgY2hhbmdlLCANCj4+ID4+IGVzcGVjaWFsbHkg c2luY2Ugd2UncmUgY29uc2lkZXJpbmcgdG8gY2hhbmdlIEhRIHN1Y2ggdGhhdCBpdCANCj4+ID4+ IGRvZXNuJ3QgcmVseSBvbiBRVUlDIHN0cmVhbSBJRHMgYW55IG1vcmUuDQo+PiA+PiBXZSBvbmx5 IG1hbmFnZSB0byBhdm9pZCB0aGUgcHJvYmxlbSBkZXNjcmliZWQgaGVyZSBpbiBvdXIgSFRUUCAN Cj4+ID4+IG1hcHBpbmcsIGJlY2F1c2UgdGhlIEhUVFAgY29udHJvbCBzdHJlYW1zIGFyZSB1bmlk aXJlY3Rpb25hbCBhbmQgDQo+PiA+PiB0aGUgcmVxdWVzdCBzdHJlYW1zIGFyZSBiaWRpcmVjdGlv bmFsLCBhbmQgY2FuIHRoZXJlZm9yZSBiZSB0b2xkIA0KPj4gPj4gYXBhcnQgYnkgdGhlaXIgZGly ZWN0aW9uYWxpdHkuDQo+PiA+PiBIb3dldmVyLCBhcyBhIGdlbmVyYWwgdHJhbnNwb3J0IHByb3Rv Y29sLCBvdGhlciBhcHBsaWNhdGlvbnMgYnVpbHQgDQo+PiA+PiBvbiB0b3Agb2YgUVVJQyB3aWxs IGhhdmUgdG8gZmluZCBzb21lIHdheSB0byBkZWFsIHdpdGggaXQuDQo+PiA+Pg0KPj4gPj4NCj4+ ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiA+PiBodHRwOi8vd3d3LmJiYy5j by51aw0KPj4gPj4gVGhpcyBlLW1haWwgKGFuZCBhbnkgYXR0YWNobWVudHMpIGlzIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGNvbnRhaW4gDQo+PiA+PiBwZXJzb25hbCB2aWV3cyB3aGljaCBhcmUgbm90 IHRoZSB2aWV3cyBvZiB0aGUgQkJDIHVubGVzcyANCj4+ID4+IHNwZWNpZmljYWxseSBzdGF0ZWQu DQo+PiA+PiBJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbg0KPj4gPj4gZXJyb3IsIHBsZWFzZSBk ZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4NCj4+ID4+IERvIG5vdCB1c2UsIGNvcHkgb3IgZGlz Y2xvc2UgdGhlDQo+PiA+PiBpbmZvcm1hdGlvbiBpbiBhbnkgd2F5IG5vciBhY3QgaW4gcmVsaWFu Y2Ugb24gaXQgYW5kIG5vdGlmeSB0aGUgDQo+PiA+PiBzZW5kZXIgaW1tZWRpYXRlbHkuDQo+PiA+ PiBQbGVhc2Ugbm90ZSB0aGF0IHRoZSBCQkMgbW9uaXRvcnMgZS1tYWlscyBzZW50IG9yIHJlY2Vp dmVkLg0KPj4gPj4gRnVydGhlciBjb21tdW5pY2F0aW9uIHdpbGwgc2lnbmlmeSB5b3VyIGNvbnNl bnQgdG8gdGhpcy4NCj4+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Thu Apr 5 07:34:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8197B12D94A for ; Thu, 5 Apr 2018 07:34: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISXADeqXgtpr for ; Thu, 5 Apr 2018 07:34:44 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 CCEE112D7F9 for ; Thu, 5 Apr 2018 07:34:43 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id l18so27138944qtj.1 for ; Thu, 05 Apr 2018 07:34:43 -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:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=vZsQAoISp2RfYF0xYySwZmO8RkJ3pPJaAxE6FCQvR8c=; b=TlZ7nSEDZvMMFQRai2IeK0S0VkwoLbFP6X2R0dLWp6JtVkC//SNGqHP9GHWZW76iBd W83/jnoGqZcmCBKL+h3KbntrpKiRy/2GKoJwTa86k+/9h8FgcQ9ndMqiJGKv0ptS/ZI2 WMy5DxLhaqURTMEq5x8gfV1nvbErXdoobi9TuQGQ85/NWhaQBEzE/9wmjvoUIr+AeVO6 jYjiU8MwlYbjH0trn8FUgy3t/YQTk35whEGvA2q6MQJ+/E7kyfEQtHBuGm4rj/jLtLTR kSbrKHs18zGGkhJCxOPVlaSxlbvVRNntWZ8js5AsPVRKYV2a4oekFVfWxd8Bq0tLlhsa zJXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=vZsQAoISp2RfYF0xYySwZmO8RkJ3pPJaAxE6FCQvR8c=; b=fi6rpwZ5JWNQ5tyAGz1nDzAU+jWXVI/umWUCLC1r4uVr8djqquAJTRxPFobTY+CHqY wgZ125kiCqWXh4gsWedRu/l+JA1k1OvnCS+hp0IU8oT+3jgQuAOFt9HYtttguQtXHGOM RS/iorPozEkCwmQZTBb/zrJlU1vGWJaeUr7mkX7H589wzOOJ2vu+pbTd3LMHaj8ERaaz vJY5Ml+PFE0tiC+5X0i469bdNfm1tRdHZzSqzLYz6wZZuKovUN6MUgNeig2qZ1saA+Ue iyl4We1vqQuAchUa1KQ3W0fcZfVrf+gi7N+4aE6xRHiZ29JcTpvQ2w6XtUzlmDuBypZ/ RPAw== X-Gm-Message-State: ALQs6tAS2q2gWZF3iU7DpKDSHDRmpTY5W7cwKVd0yPqUhwguN4BJiJxM Ih/OZqY7mI1T232Qgr7c1IFPxg== X-Google-Smtp-Source: AIpwx4+ssIlHiswmMlzuYd5YPRuTzyIZYbzxBemE61pK7lO98mI9v1W7ngjDwVPVqxva8/imxVz9Zw== X-Received: by 10.237.47.227 with SMTP id m90mr33779677qtd.33.1522938882796; Thu, 05 Apr 2018 07:34:42 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id n30sm6364296qtb.93.2018.04.05.07.34.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 07:34:42 -0700 (PDT) Date: Thu, 5 Apr 2018 10:34:37 -0400 From: Dmitri Tikhonov To: "Lubashev, Igor" Cc: "martenseemann@gmail.com" , "quic@ietf.org" Subject: Re: Implicitly opened streams and exposing stream IDs Message-ID: <20180405143436.GA19079@ubuntu-dmitri> Mail-Followup-To: "Lubashev, Igor" , "martenseemann@gmail.com" , "quic@ietf.org" References: <42531619e25b4a4cbd16e77fb1859fde@usma1ex-dag1mb5.msg.corp.akamai.com> 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, 05 Apr 2018 14:34:46 -0000 The switch to MUST would cater to a single use case: a control stream opened at the beginning of the connection. Presumably, the following streams would not be useable without the control stream (as is the case with HQ), so waiting for the control stream frames is OK. The downside is that the stream creator no longer has the flexibility to use its legit set of Stream IDs as it sees fit, precluding some use cases (see issue #634 [1]) -- perhaps even the very use of QUIC for some protocols! The API problem Marten describes seems like a non-issue: There are two sets of APIs: - User code / HQ; and - HQ / QUIC. Stream IDs do not have to be exposed in the former: The user does not care about them, as these things are just your regular HTTP messages. In the HQ / QUIC API, on the other hand, expose away! Streams have IDs, the QUIC transport draft talks about them, the IDs have meanings -- it only makes sense that the layer that uses the QUIC objects directly can use Stream IDs. Why not?! - Dmitri. 1. https://github.com/quicwg/base-drafts/issues/634 On Thu, Apr 05, 2018 at 02:06:12PM +0000, Lubashev, Igor wrote: > I agree. I would like to see MUST there as well. > > -----Original Message----- > From: Marten Seemann [martenseemann@gmail.com] > Received: Thursday, 05 Apr 2018, 8:51AM > To: Lubashev, Igor [ilubashe@akamai.com] > CC: quic@ietf.org [quic@ietf.org] > Subject: Re: Implicitly opened streams and exposing stream IDs > > Hi Igor, > > This is exactly the change I'm proposing. Currently, the draft says that you SHOULD create streams in order (section 9.2). I'd like to change that SHOULD to a MUST. > Only if in order stream creation is a requirement, this question becomes an API design question. > > Regards, > Marten > > > > On Thu, Apr 5, 2018 at 7:14 PM Lubashev, Igor > wrote: > This is not a QUIC transport draft concern. This is a question of QUIC library API design. Your API may choose to have Accept return streams in order. My API may choose to have Accept return streams as they come in (and expose steam IDs). As long as the transport draft requires that streams are CREATED in order (as it does now), both API designs are valid. > > It would be a matter of a very different draft to standardize QUIC APIs (like we have for POSIX) so an application can be easily ported to use a different vendor's QUIC libraries. > > > - Igor > > > > -----Original Message----- > From: Marten Seemann [martenseemann@gmail.com] > Received: Monday, 02 Apr 2018, 7:43AM > To: QUIC WG [quic@ietf.org] > Subject: Implicitly opened streams and exposing stream IDs > > Recently, the implicit opening of streams (i.e. that when a receiver receives a frame for stream N+4, it can assume that stream N was already opened, but the packet might have been reordered) was removed from the draft. I think this change has some consequences that we haven't discussed so far. > > For the purpose of writing some pseudocode, I'm assuming a QUIC API that provides an AcceptStream() method, but the conclusions will be the same for a callback-based API. > > * If QUIC has implicit stream opening, AcceptStream() would return the streams in order (and if a frame opening stream N+4 is received before stream n is opened, AcceptStream() will first return stream N and then stream N+4). > * Without implicit stream opening, AcceptStream() just returns whatever stream is received first. Streams might be returned in arbitrary order, if the peer doesn't open streams consecutively or if packets are reordered. > > Now imagine an application protocol where the first unidirectional stream opened by the client is a control stream, and all higher unidirectional streams are data streams. The application on the server side needs to find out which stream is the control stream, because it needs to be handled separately. > > With implicit stream opening, the server code would be: > > control_stream = AcceptStream() // is guaranteed to open the first stream > // handle the control stream > while true: > stream = AcceptStream() > // handle the data stream > > and without implicit stream opening: > > while true: > stream = AcceptStream() > if stream.ID() == kControlStreamID: > // handle the control stream > else: > // handle the data stream > > In this case, after accepting a stream, we first have to check the stream ID, since there's no guarantee if the control stream will actually be received first. > > For this stream mapping, it seems like the removal of implicitly opened streams implies that QUIC has to expose stream IDs to the application layer. I'm not sure if this was intended when making the change, especially since we're considering to change HQ such that it doesn't rely on QUIC stream IDs any more. > We only manage to avoid the problem described here in our HTTP mapping, because the HTTP control streams are unidirectional and the request streams are bidirectional, and can therefore be told apart by their directionality. However, as a general transport protocol, other applications built on top of QUIC will have to find some way to deal with it. From nobody Thu Apr 5 07:34:54 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3FD12D94A for ; Thu, 5 Apr 2018 07:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522938888; bh=EH3wnnxurWhS/Fq/AM7aUMS+8Y97keLFYCU1bLZ6x44=; h=Date:From:Cc:Subject:References:In-Reply-To:To; b=bO5WXdrqQU0eYM39UfBuZZ+uUHQI34tqSDq/e2f8pvdySG4b9Cf837KB8tcoNzsXD B4V8d+eN5Nl7HNARs2LUmvKmYgj/mW+qS3/YzQ890TvTUBnv49ntVguAfkqIkdxOHQ itR5WIfchnZbcNT6imH+JPMSZAgj6o0qdLQsPV0Q= X-Mailbox-Line: From dtikhonov@litespeedtech.com Thu Apr 5 07:34:48 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8A912D947; Thu, 5 Apr 2018 07:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522938888; bh=EH3wnnxurWhS/Fq/AM7aUMS+8Y97keLFYCU1bLZ6x44=; h=Date:From:Cc:Subject:References:In-Reply-To:To; b=bO5WXdrqQU0eYM39UfBuZZ+uUHQI34tqSDq/e2f8pvdySG4b9Cf837KB8tcoNzsXD B4V8d+eN5Nl7HNARs2LUmvKmYgj/mW+qS3/YzQ890TvTUBnv49ntVguAfkqIkdxOHQ itR5WIfchnZbcNT6imH+JPMSZAgj6o0qdLQsPV0Q= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73B412D7F9 for ; Thu, 5 Apr 2018 07:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 Q9uhBddIb9Gu for ; Thu, 5 Apr 2018 07:34:44 -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 252A412D947 for ; Thu, 5 Apr 2018 07:34:44 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id f8so27099968qtg.12 for ; Thu, 05 Apr 2018 07:34:44 -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:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=vZsQAoISp2RfYF0xYySwZmO8RkJ3pPJaAxE6FCQvR8c=; b=TlZ7nSEDZvMMFQRai2IeK0S0VkwoLbFP6X2R0dLWp6JtVkC//SNGqHP9GHWZW76iBd W83/jnoGqZcmCBKL+h3KbntrpKiRy/2GKoJwTa86k+/9h8FgcQ9ndMqiJGKv0ptS/ZI2 WMy5DxLhaqURTMEq5x8gfV1nvbErXdoobi9TuQGQ85/NWhaQBEzE/9wmjvoUIr+AeVO6 jYjiU8MwlYbjH0trn8FUgy3t/YQTk35whEGvA2q6MQJ+/E7kyfEQtHBuGm4rj/jLtLTR kSbrKHs18zGGkhJCxOPVlaSxlbvVRNntWZ8js5AsPVRKYV2a4oekFVfWxd8Bq0tLlhsa zJXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=vZsQAoISp2RfYF0xYySwZmO8RkJ3pPJaAxE6FCQvR8c=; b=AmfSFu5CTjH8+lKdPfE+NF0FtQa8e30iOue0DHdT/HSKWqriHIctaRQV6kCyC8i9OT lW2IqLffvBvCBzPaCO38x0r8vcHbHmKwHEouCBbyEEuKVf4ZzgqIcBYO+kP5+AI/IfU/ 4WVwSm+jtttDs6fEgXTHxQCjWH1+hll/KjOCbeDtjO2Qm7sM/gGcC7ET2G2z4lCvHRMF /gfmqNdhG4jlbZh8DRPxFaokHvta6A3cIvPuPfAw10XhzbQTKdSW8CF3GjPIGFqUDulw GTBWQpYhQ1UoDgzHiwp0ltD+AAaTPx1h6rzFHWAfc5sRqvsgYy1OqKC4mKHb3i/ud+px O3iQ== X-Gm-Message-State: ALQs6tAk3MIan1NFJ241gQu6sd2Lmm62nAwxxD9EfB9SqvQ8AXpCIrT9 zK1oeYulDqFFcnP1y1Ps8GM+QqpU X-Google-Smtp-Source: AIpwx4+ssIlHiswmMlzuYd5YPRuTzyIZYbzxBemE61pK7lO98mI9v1W7ngjDwVPVqxva8/imxVz9Zw== X-Received: by 10.237.47.227 with SMTP id m90mr33779677qtd.33.1522938882796; Thu, 05 Apr 2018 07:34:42 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id n30sm6364296qtb.93.2018.04.05.07.34.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 07:34:42 -0700 (PDT) Date: Thu, 5 Apr 2018 10:34:37 -0400 From: Dmitri Tikhonov Cc: "martenseemann@gmail.com" , "quic@ietf.org" Subject: Re: Implicitly opened streams and exposing stream IDs Message-ID: <20180405143436.GA19079@ubuntu-dmitri> Mail-Followup-To: "Lubashev, Igor" , "martenseemann@gmail.com" , "quic@ietf.org" References: <42531619e25b4a4cbd16e77fb1859fde@usma1ex-dag1mb5.msg.corp.akamai.com> 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) To: "Lubashev, Igor" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 14:34:48 -0000 The switch to MUST would cater to a single use case: a control stream opened at the beginning of the connection. Presumably, the following streams would not be useable without the control stream (as is the case with HQ), so waiting for the control stream frames is OK. The downside is that the stream creator no longer has the flexibility to use its legit set of Stream IDs as it sees fit, precluding some use cases (see issue #634 [1]) -- perhaps even the very use of QUIC for some protocols! The API problem Marten describes seems like a non-issue: There are two sets of APIs: - User code / HQ; and - HQ / QUIC. Stream IDs do not have to be exposed in the former: The user does not care about them, as these things are just your regular HTTP messages. In the HQ / QUIC API, on the other hand, expose away! Streams have IDs, the QUIC transport draft talks about them, the IDs have meanings -- it only makes sense that the layer that uses the QUIC objects directly can use Stream IDs. Why not?! - Dmitri. 1. https://github.com/quicwg/base-drafts/issues/634 On Thu, Apr 05, 2018 at 02:06:12PM +0000, Lubashev, Igor wrote: > I agree. I would like to see MUST there as well. > > -----Original Message----- > From: Marten Seemann [martenseemann@gmail.com] > Received: Thursday, 05 Apr 2018, 8:51AM > To: Lubashev, Igor [ilubashe@akamai.com] > CC: quic@ietf.org [quic@ietf.org] > Subject: Re: Implicitly opened streams and exposing stream IDs > > Hi Igor, > > This is exactly the change I'm proposing. Currently, the draft says that you SHOULD create streams in order (section 9.2). I'd like to change that SHOULD to a MUST. > Only if in order stream creation is a requirement, this question becomes an API design question. > > Regards, > Marten > > > > On Thu, Apr 5, 2018 at 7:14 PM Lubashev, Igor > wrote: > This is not a QUIC transport draft concern. This is a question of QUIC library API design. Your API may choose to have Accept return streams in order. My API may choose to have Accept return streams as they come in (and expose steam IDs). As long as the transport draft requires that streams are CREATED in order (as it does now), both API designs are valid. > > It would be a matter of a very different draft to standardize QUIC APIs (like we have for POSIX) so an application can be easily ported to use a different vendor's QUIC libraries. > > > - Igor > > > > -----Original Message----- > From: Marten Seemann [martenseemann@gmail.com] > Received: Monday, 02 Apr 2018, 7:43AM > To: QUIC WG [quic@ietf.org] > Subject: Implicitly opened streams and exposing stream IDs > > Recently, the implicit opening of streams (i.e. that when a receiver receives a frame for stream N+4, it can assume that stream N was already opened, but the packet might have been reordered) was removed from the draft. I think this change has some consequences that we haven't discussed so far. > > For the purpose of writing some pseudocode, I'm assuming a QUIC API that provides an AcceptStream() method, but the conclusions will be the same for a callback-based API. > > * If QUIC has implicit stream opening, AcceptStream() would return the streams in order (and if a frame opening stream N+4 is received before stream n is opened, AcceptStream() will first return stream N and then stream N+4). > * Without implicit stream opening, AcceptStream() just returns whatever stream is received first. Streams might be returned in arbitrary order, if the peer doesn't open streams consecutively or if packets are reordered. > > Now imagine an application protocol where the first unidirectional stream opened by the client is a control stream, and all higher unidirectional streams are data streams. The application on the server side needs to find out which stream is the control stream, because it needs to be handled separately. > > With implicit stream opening, the server code would be: > > control_stream = AcceptStream() // is guaranteed to open the first stream > // handle the control stream > while true: > stream = AcceptStream() > // handle the data stream > > and without implicit stream opening: > > while true: > stream = AcceptStream() > if stream.ID() == kControlStreamID: > // handle the control stream > else: > // handle the data stream > > In this case, after accepting a stream, we first have to check the stream ID, since there's no guarantee if the control stream will actually be received first. > > For this stream mapping, it seems like the removal of implicitly opened streams implies that QUIC has to expose stream IDs to the application layer. I'm not sure if this was intended when making the change, especially since we're considering to change HQ such that it doesn't rely on QUIC stream IDs any more. > We only manage to avoid the problem described here in our HTTP mapping, because the HTTP control streams are unidirectional and the request streams are bidirectional, and can therefore be told apart by their directionality. However, as a general transport protocol, other applications built on top of QUIC will have to find some way to deal with it. From nobody Thu Apr 5 08:34:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242141277BB for ; Thu, 5 Apr 2018 08:34:34 -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 3kINTe_P8KRn for ; Thu, 5 Apr 2018 08:34: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 2C7CD127601 for ; Thu, 5 Apr 2018 08:34:32 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1f46uC-0001TY-B9 for quic@ietf.org; Thu, 05 Apr 2018 17:34:29 +0200 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1f46uA-0001Xa-QF for quic@ietf.org; Thu, 05 Apr 2018 11:34:27 -0400 Received: (qmail 3398 invoked from network); 5 Apr 2018 15:34:20 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.61]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Apr 2018 15:34:20 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Thu, 5 Apr 2018 08:34:14 -0700 Cc: quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <047d2ff0-ff8b-64c9-898 3-0ecabeb9fea5@huitema.net> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= Subject: Privacy holes (was: Re: Getting to consensus on packet number encryption) X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5rg7rcCduaE0Xwo/tNK9mrl602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVimHTpGI7nmuXHz2ru7+xXR87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBpxvnk7PJGygctl3LC86inx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpWYO2/mqpOb7Q80SeXyngcEQspW6PWtFljIeoG6OsM9IZZbga7DcbM5 TlUJnsdZhmZgiNplmw3yp4FFFCuS+k6jh5d4Swn5E67RV+LaU4GmVjH8gYlRWMzXMtJksqe+xLeX oHkzkRzbKyRDRP8j7fY6NV+QBQRtMmDe05Nd2KjhCWh+wlfAS2SbL4bvnSO/22WzpThgw5ICD+Lb xZm/MI4dOaYyGwgMwf9FTYaJWiXFxpRins15oKFWvUk5C9olBXB1qSIEae5DZ9cZ02JHi6IQw6nI oDr0sXUZ7YZoZ/GZ+gNl/9zCFdWYNKOuzgS95TNz5NQBt6vrTjaii/MA7FoCAhy1/eljfSN5aXns qLZLef9qwM7RXpJS8RjTdyh2j5AWyDZ7BRCxIW6XiPgk5wgNeRXbC69qDBnTAPdQSCnD1TRj9D8H LKHAKpPGP8EPnuDHTXhIrVzYteKGVryF5qVZ X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 15:34:34 -0000 =20 > On Apr 5, 2018, at 2:26 AM, Mirja K=C3=BChlewind wrote: > ... > Timing doesn=E2=80=99t help here either because you still have the same de= stination IP, both port numbers and the fact that a migrated connection does= not have a handshake. If we want to address the linkability problem, we wou= ld need to do much more, probably baring more hits on performance.=20 Mirja, You rightly point out that the connection ID and the Packet Number are not t= he only elements that provide linkability. There is also of course the UDP s= ource port. That one is not much of an issue for servers, but it is an issue= for clients. We are not spelling that out in the draft. We should, because c= lients can trivially close that hole when doing migration. I am not sure that the absence of negotiation divulges much data. It marks t= he path as originating from a migration, but it does not tell from where. Bu= t there might be an ossification issue. We will get that ossification if we t= rain middleboxes to believe that connection always start with an observable n= egotiation. So maybe we should explore ways to grease that. Any other privacy hole that we should fix? -- Christian Huitema=20= From nobody Thu Apr 5 08:59:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24A112DB72 for ; Thu, 5 Apr 2018 08:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=alumni-cmu-edu.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 yzQRc0oEzM_p for ; Thu, 5 Apr 2018 08:59:11 -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 ACF1712DA46 for ; Thu, 5 Apr 2018 08:59:09 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id v13so31194933iob.6 for ; Thu, 05 Apr 2018 08:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cmu-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9qFI4ZBBMTe3dzXYttpGn5zXOvDVnElGyQJRV64Nu2A=; b=uLImI6R8UfgBUUd2RZxRFd0cxYCEoOGpaSXyzRzmqbMJhb+GfYmOS1d2/IC4NEU54D cZaT7sa+rPSH9rRzDdLs8UmWefaNLT7CusCG65Odd9JsxVR5xjZFOIwd2dTY3Zr8Qtjh 5cL0xYAG8r48Vf6VWv0fg1thPWbr3yEhug9v/CLbcqUcw3IzfrYLFZz/MeHIrJM9RkTN XdilsUXKfGAUwglGRmxyc71hRoqXdAFNqB2iavNljYYE/nbCTELfkAr4qetRT7DdifwG KNnyJeEMtP7qcyp+17P+8wFKCFPkPKymsPmzDIajTslXu13uWAXSl805BcbrwPWQWzld sOKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9qFI4ZBBMTe3dzXYttpGn5zXOvDVnElGyQJRV64Nu2A=; b=IWqBM3gBZAOqNPSvuidc+7/6i+Sj2Yx7/inP+VZ/w45yyoc21+mTjF/Ph6Qo1WGgH9 NNxId4uxRX3oLkVmCXrkdsz/U/fnbA8KQRlSHs29iQD+tSzhbWOBwMtR7sPY61/nawQe oQcQjqny2L/erM2NYux/DQP42/jXHdZIEW/kWV8GiDiXKLLEw1dCnbGaUOBHSB7g5UhY +5gbIZ8Dmn3CMrLgU0BDiPAIRRc23RZUU0l+I0VTr23x75XyGywjoOIVIvGz6Np42ZPA 30UbBKyvybjpI5YU8Eon8rBc1tgul8VmNC4Nbg2JAxsxj5RA1wIE4PKrk1keN2zQlGEM JQxg== X-Gm-Message-State: ALQs6tA0EUBJAacLYikn8e8euH6i21XM3cTgnpbhMkh1Pbai69azc7Qt kv0aQVcDA27D8zspP1ZWcyqbZSj6FKxp1NnjGK5WSg== X-Google-Smtp-Source: AIpwx49dOM0ki421+HUIWgkPf0+GSK45GXN+PJTWpvePRH54YcT7qNzoo199/e7tr8SmI8ASpJnZ4jcRrc3fyhwkS9s= X-Received: by 10.107.132.97 with SMTP id g94mr21283579iod.46.1522943949058; Thu, 05 Apr 2018 08:59:09 -0700 (PDT) MIME-Version: 1.0 References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> In-Reply-To: <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Frederick Kautz Date: Thu, 05 Apr 2018 15:58:58 +0000 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: Christian Huitema Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , quic@ietf.org Content-Type: multipart/alternative; boundary="001a1149136a18e34105691c05f4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 15:59:14 -0000 --001a1149136a18e34105691c05f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are you concerned that middleware boxes may be trained to reject migrations, thereby forcing a new connection with a visible negotiation? On Thu, Apr 5, 2018, 8:34 AM Christian Huitema wrote: > > > > On Apr 5, 2018, at 2:26 AM, Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> wrote: > > ... > > Timing doesn=E2=80=99t help here either because you still have the same > destination IP, both port numbers and the fact that a migrated connection > does not have a handshake. If we want to address the linkability problem, > we would need to do much more, probably baring more hits on performance. > > Mirja, > > You rightly point out that the connection ID and the Packet Number are no= t > the only elements that provide linkability. There is also of course the U= DP > source port. That one is not much of an issue for servers, but it is an > issue for clients. We are not spelling that out in the draft. We should, > because clients can trivially close that hole when doing migration. > > I am not sure that the absence of negotiation divulges much data. It mark= s > the path as originating from a migration, but it does not tell from where= . > But there might be an ossification issue. We will get that ossification i= f > we train middleboxes to believe that connection always start with an > observable negotiation. So maybe we should explore ways to grease that. > > Any other privacy hole that we should fix? > > -- Christian Huitema > --001a1149136a18e34105691c05f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are you concerned that middleware boxes may be trained to reject migrations= , thereby forcing a new connection with a visible negotiation?

On Thu, Apr 5, 2018, 8:34 AM Christi= an Huitema <huitema@huitema.net> wrote:


> On Apr 5, 2018, at 2:26 AM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee= .ethz.ch> wrote:
> ...
> Timing doesn=E2=80=99t help here either because you still have the sam= e destination IP, both port numbers and the fact that a migrated connection= does not have a handshake. If we want to address the linkability problem, = we would need to do much more, probably baring more hits on performance.
Mirja,

You rightly point out that the connection ID and the Packet Number are not = the only elements that provide linkability. There is also of course the UDP= source port. That one is not much of an issue for servers, but it is an is= sue for clients. We are not spelling that out in the draft. We should, beca= use clients can trivially close that hole when doing migration.

I am not sure that the absence of negotiation divulges much data. It marks = the path as originating from a migration, but it does not tell from where. = But there might be an ossification issue. We will get that ossification if = we train middleboxes to believe that connection always start with an observ= able negotiation. So maybe we should explore ways to grease that.

Any other privacy hole that we should fix?

-- Christian Huitema
--001a1149136a18e34105691c05f4-- From nobody Thu Apr 5 09:09:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7E112DA18 for ; Thu, 5 Apr 2018 09:09:05 -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 fDBZS1JNlDnC for ; Thu, 5 Apr 2018 09:09:03 -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 2A56C12DA02 for ; Thu, 5 Apr 2018 09:09:02 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx61.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1f47RU-0008lX-5r for quic@ietf.org; Thu, 05 Apr 2018 18:08:52 +0200 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1f47RR-0002gQ-K8 for quic@ietf.org; Thu, 05 Apr 2018 12:08:50 -0400 Received: (qmail 4822 invoked from network); 5 Apr 2018 16:08:38 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.61]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Apr 2018 16:08:38 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Thu, 5 Apr 2018 09:08:36 -0700 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> To: Frederick Kautz Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) X-Originating-IP: 168.144.250.230 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.17) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5qAn9SXkBH2RRLzz+acGlgV602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViVbWQVN6pHoa+2j48sCa3Y87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBo86SAdJ6bLtg5NStMc8F1x/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpUMghVcCxYGhncxAP/ZLBkEYa+a8mnXc/MAfIKlnj6Nto/b1mMgAaU1 oReX0/iYlRmU2yw6z85L3UyCdO+oQ3S7VPd90DA1c/ZLOZZo7XGPVfWv8HL1YL3Zn8TE/e4IMjT6 4dZYZAAUgQSn0n4YsmwRbLz+Z/8OylBaLzk09eGtkuggKW28pboyZCmKkHUYXakxTSMSrOpNzFLV stGjF1YaJ8EfSTp0lDMTZZgIXVj8PXtB4/4Pbrz2QtFuyl+Sh6ctJJaoNQlm9OuZnd22I17dfqb5 R4VemuUI6bcEARsm0L3ImxSUHqpGB7nC++w7dpmNZy58uobCIkCdwVDO83SGTnM2K/9iKCD9v589 nVS3hWSdEOMftBjsWb6BDQzjSsHUIomTnJwT4ky6b7E7Hukt2Ge4B8NG0VKlrY+34Zmj+F/tjlrZ UvGhhjiSam0tWhQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 16:09:05 -0000 > On Apr 5, 2018, at 8:58 AM, Frederick Kautz wrote:= >=20 > Are you concerned that middleware boxes may be trained to reject migration= s, thereby forcing a new connection with a visible negotiation? Yes. Hence the need to grease. For example, have clients do some gratuitous m= igration to a new source port number rather frequently. -- Christian Huitema=20= From nobody Thu Apr 5 09:42:00 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677FD12DA17 for ; Thu, 5 Apr 2018 09:41:59 -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, 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 (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 Jnm9JJssBWF0 for ; Thu, 5 Apr 2018 09:41:57 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on072d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09231271DF for ; Thu, 5 Apr 2018 09:41:56 -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=8i2PqmldZEM1hqnZio6HOJJmpcCt/eIctOVIwLVlS3k=; b=cdXqxEL4HXLMsMNM0bn8dqSMMul3D17eB7PHbzzNWVzYjC7eVqE80udLliGISeWYIS141FvzWzfAUTHJaD8W0XOuqkhqq50vpE1jlelIixIrd0DoCWPpBFgS8DYUjrj009XmPVcshkhCfDoZBeN323p3vShWmwE+zsRu5Eww7uM= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0168.namprd21.prod.outlook.com (10.173.192.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Thu, 5 Apr 2018 16:41:54 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Thu, 5 Apr 2018 16:41:54 +0000 From: Praveen Balasubramanian To: Martin Thomson , Kazuho Oku CC: Lars Eggert , Mark Nottingham , IETF QUIC WG , Patrick McManus Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwkIMAgADKCACAADzkAIAAwwog Date: Thu, 5 Apr 2018 16:41:54 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0168; 7:EUklKonhmZPfOcbhm5BOvBisFQljhlbHLz5SZ9hOGaWaaYA9DyOaIOYHxiXCfq1wj0leE4Ueu5HtMkspjtfz+ZLm70atEDDie2ZWK5YSw3f+yhXeQC8Q7GJXYaoQpU6GieS8JXPob59xQov4gtTLAmpKNCn3aZNrxgEnP6DswyEC5TqhKPJc9ANO+fh0IQCTx7SldqM4WZa/dR0UVldxPJIsxf+JS67T27EFyiL0OQotet5FZNXV7vUG8OdVbW1y; 20:lOlJ82TEoQ3LG6+iMPaytezC5FJCWioBILD5O7WJX1/t4FPCQUHCjpYYEjAd3N2YeX9e/oQ7ikIMrXW4QkW8b9EMPhNCrgmJ2YI71SnXlmdO6jJM5rf3lJQUGgzBqgpD8hIMLljAzxPRbHdi7MSl1jsVTkQxfj1Wx29jnWM8lJA= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: cc01c7d6-4e20-4954-0644-08d59b142401 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0168; x-ms-traffictypediagnostic: CY4PR21MB0168: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0168; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0168; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(376002)(346002)(396003)(366004)(51444003)(13464003)(189003)(199004)(7736002)(25786009)(6436002)(74316002)(59450400001)(6246003)(305945005)(9686003)(478600001)(99286004)(486006)(55016002)(102836004)(68736007)(2900100001)(93886005)(5660300001)(316002)(110136005)(54906003)(229853002)(106356001)(22452003)(53936002)(53546011)(6506007)(76176011)(8990500004)(86362001)(105586002)(97736004)(39060400002)(7696005)(46003)(8936002)(81166006)(8676002)(476003)(14454004)(186003)(86612001)(446003)(2906002)(3660700001)(5250100002)(10290500003)(4326008)(81156014)(10090500001)(6116002)(11346002)(3280700002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0168; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9kaRZ2OBM/gt4408swmInTI0ySQYtTVpwXNggY886M76vkcxV2Ij5/Ymr3srlUFbpzl+7dAjf1NFwQOAsnjiK7MceAQ7iWArDnH36rXtgAEEimvNd0Y19I+NPyuRbMRuGh0Neh30t8UWzQU9S2/xYFKK3c7ebZDDB1sMcogubROZSVsWwzkj5x4WE7FaahucFtM/q0Srd3yMFuYS3hdpJVAbJi9y5giNMSLLKOvdBMAMZH53KnthrfOlX7u+yzjXwFt5zPWQGV1+4qIToAc24Nizs5htcNTfV5jy+XGNvmet7ENq9wMkFptIeNYUDwMw0LWv55WrVCVRW11GYisd6W8un2mvO+q2f6J3yv2bmSfmtSO8YTap5vIjBig1LTeQKhXIp+3XXOKH4nRmdsG5CYhGOUpHYIripESykteGIgA= 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-Network-Message-Id: cc01c7d6-4e20-4954-0644-08d59b142401 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 16:41:54.7430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0168 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 16:41:59 -0000 TG92ZSB0aGlzIGlkZWEuIEV4cGFuZGluZyBpdCBhIGJpdCBmdXJ0aGVyIEkgZG9u4oCZdCB0aGlu ayB3ZSBuZWVkIHRvIG1ha2UgUE4gdHJhbnNmb3JtIGEgdHJhbnNwb3J0IHBhcmFtZXRlciBidXQg cmF0aGVyIGNvbm5lY3Rpb24gbWlncmF0aW9uIGl0c2VsZi4gV2UgY291bGQgYWxzbyBzaW1wbHkg dXNlIFFVSUMgdmVyc2lvbmluZyBmb3IgdGhpcy4gDQoNCjEuIFNoaXAgUVVJQyB2MSB3aXRoIG5v IHN1cHBvcnQgZm9yIGNvbm5lY3Rpb24gbWlncmF0aW9uLiBTZXJ2ZXJzIGJlaGluZCBsb2FkIGJh bGFuY2VycyB0aGF0IGFyZSBub3QgUVVJQyBhd2FyZSB3aWxsIG9ubHkgYWR2ZXJ0aXNlIHRoaXMg dmVyc2lvbi4gSSBleHBlY3QgdGhpcyB0byBiZSBhIGxhcmdlIGZyYWN0aW9uIG9mIHNlcnZlcnMg ZXNwZWNpYWxseSB0aG9zZSBob3N0ZWQgaW4gQVdTLCBBenVyZSwgR0NQLiAqVGhpcyBpcyBpbXBv cnRhbnQgLSBJIHdhbnQgdGhlIGdyb3VwIHRvIGFja25vd2xlZGdlIHRoYXQgc2VydmVycyBuZWVk cyB0byBiZSBhYmxlIHRvIGFkdmVydGlzZSBzdXBwb3J0IGZvciBjb25uZWN0aW9uIG1pZ3JhdGlv biouDQoyLiBTaGlwIFFVSUMgdjIgd2l0aCBzdXBwb3J0IGZvciBjb25uZWN0aW9uIG1pZ3JhdGlv bi4gSWYgYSBjbGllbnQgYW5kIHNlcnZlciB1c2UgdGhpcyB2ZXJzaW9uIHRoZXkgTVVTVCBkbyBQ TkUgYXMgcGVyICMxMDc5LiBJZiB3ZSBmaW5kIGEgbW9yZSBlZmZpY2llbnQgc2NoZW1lIGJlZm9y ZSBOb3ZlbWJlciB0aGVuIHdlIHVzZSB0aGF0IGluc3RlYWQuIA0KDQpFdmVudHVhbGx5IHdlIHdp bGwgc2hpcCBRVUlWIHZOIHdoaWNoIGhhcyBzdXBwb3J0IGZvciBtdWx0aS1wYXRoIGFuZCB3ZSBj YW4gcmV2aXNpdCBpZiBQTkUgaXMgbmVlZGVkIG9yIG11bHRpcGxlIFBOIHNwYWNlcyB3aWxsIHdv cmsuIFVudGlsIHRoZW4gSSBjYW4gbGl2ZSB3aXRoIGhpZ2hlciBDUFUgY29zdCBmb3IgdGhlIGZy YWN0aW9uIG9mIGNvbm5lY3Rpb25zIHRoYXQgd2lsbCBtaWdyYXRlLiANCg0KTm93IHRoZXJlIGlz IHRoZSBvc3NpZmljYXRpb24gcHJvYmxlbSBpbiBRVUlDIHYxIGFzIHJlZmVycmVkIHRvIGFib3Zl LiBXZSBhbHJlYWR5IHJlcXVpcmUgYSByYW5kb20gc3RhcnRpbmcgUE4uIFRoZSBuZXh0IHByb2Js ZW0gaXMgb25lIHRoYXQgS2F6dWhvIGJyb3VnaHQgdXAgd2hlcmUgbWlkZGxlYm94ZXMgd2lsbCBz dGFydCBzZWVpbmcgc3RyaWN0IGluY3JlYXNpbmcgUE4gYW5kIHRyeSB0byByZW9yZGVyLiBJIHdh cyB0aGlua2luZyBhYm91dCBzaG9ydCByYW5kb20ganVtcHMgdG8gZml4IHRoaXMgcHJvYmxlbSBi dXQgdGhlIG1vbm90b25pYyBpbmNyZWFzZSB3aWxsIHJlbWFpbi4gV2hpbGUgSSB0aGluayBzYW5l IG1pZGRsZWJveGVzIHdpbGwgbm90IGRvIGFueSByZW9yZGVyaW5nLCB0aGVyZSBtaWdodCBiZSBh IGZldyBjcmF6eSBvdXRsaWVycyBsaWtlIHdpdGggVENQLiBJIHRoaW5rIHdlIGNhbiBzb2x2ZSB0 aGlzIGJ5IG1ha2luZyB0aGUgaW4gY2xlYXIgUE4ganVtcCBib3RoIGZvcndhcmQgYW5kIGJhY2sg d2l0aGluIGEgInJlb3JkZXJpbmcgZGVncmVlIi4gSSBhbSB0aGlua2luZyBhYm91dCBzb21lIGlk ZWFzIGhlcmUgYW5kIHdpbGwgcmVwbHkgYmFjayBpZiBJIGZpbmQgYSBzaW1wbGUgc2NoZW1lLg0K DQo+PiBGV0lXLCB3aGF0IEkgZ290IGZyb20gdGhlIGluZm8gdGhhdCBQcmF2ZWVuIGFuZCBJYW4g aGF2ZSBzaGFyZWQgaXMgdGhhdCB0aGVyZSBhcmUgZW5vdWdoIHByb2JsZW1zIHRvIHNvbHZlIHdp dGggVURQIHRoYXQgd29ycnlpbmcgYWJvdXQgdGhlIHBlcmZvcm1hbmNlIGhpdCBmcm9tIGVuY3J5 cHRpb24gaXMgcHJlbWF0dXJlDQpNYXJ0aW4sIHdlIGhhdmUgcGxhbnMgdG8gbWFrZSBVRFAgc2Ny ZWFtaW5nIGZhc3QgaW4gc29mdHdhcmUuIEJ1dCB0aGUgcmVhbCBhZHZhbnRhZ2UgZm9yIFRDUCBj b21lcyBmcm9tIHRoZSBiYXRjaCBvZmZsb2FkcyAoc2VlIGVtYWlsIHdpdGggc3ViamVjdCAiIElt cGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlIiku IEJhdGNoIG9mZmxvYWRzIGZvciBRVUlDIGFyZSBpbXBvc3NpYmxlIHRvIGRvIHdpdGhvdXQgY3J5 cHRvIG9mZmxvYWQuIEkgd291bGQgYmUgaGFwcHkgdG8gZXhwbGFpbiBtb3JlIG9uIHRoaXMgZnJv bnQuIEkgdGhpbmsgd2Ugd2lsbCBleGhhdXN0IHNvZnR3YXJlIG9wdGltaXphdGlvbnMgc29vbiBh bmQgdGhlbiBnZXQgYmxvY2tlZCBvbiBjcnlwdG8gb2ZmbG9hZC4NCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1hcnRpbiBUaG9tc29uDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDQsIDIw MTggOTozNiBQTQ0KVG86IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpDYzogTGFy cyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz47IE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5l dD47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IFBhdHJpY2sgTWNNYW51cyA8cG1jbWFu dXNAbW96aWxsYS5jb20+DQpTdWJqZWN0OiBSZTogR2V0dGluZyB0byBjb25zZW5zdXMgb24gcGFj a2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCk9uIFRodSwgQXByIDUsIDIwMTggYXQgMTA6NTcgQU0s IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+IHdyb3RlOg0KPiBJdCBpcyB0cnVlIHRo YXQgIzEwNzkgaGFzIGlzc3VlcyB3aXRoIGhhcmR3YXJlIGNyeXB0byBvZmZsb2FkLiBJIGFtIA0K PiBoYXBweSB0byBzdXBwb3J0IHN3aXRjaGluZyB0byBhIGJldHRlciBlbmNyeXB0aW9uIHNjaGVt ZSAoaWYgd2UgZmluZA0KPiBvbmUpIGF0IGFueSBtb21lbnQ7IGUuZy4sIGR1cmluZyB0aGUgc3Rh bmRhcmRpemF0aW9uIG9mIFFVSUN2MSwgb3IgYXMgDQo+IGFuIGV4dGVuc2lvbiB0byB2MSwgb3Ig cGFydCBvZiB2WC4NCg0KVW50aWwgdGhpcyBjYW1lIHVwLCBJIGhhZG4ndCBjb25zaWRlcmVkIHRo ZSB1c2Ugb2YgYW4gZXh0ZW5zaW9uL3RyYW5zcG9ydCBwYXJhbWV0ZXIgdG8gbmVnb3RpYXRlIGEg bmV3IHNjaGVtZSwgYnV0IGl0J3Mgb2J2aW91cy4gIFRoaXMgZml0cyBiZXN0IHdpdGggbXkgdmll dyBvZiB0aGluZ3MuDQoNCklmIHRoYXQgbWVhbnMgdGhhdCB3ZSBnZXQgdGhlIERDLVFVSUMgb3B0 aW9uIHRoYXQgdHVybnMgdGhlIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbiBmdW5jdGlvbiBpbnRv IGlkZW50aXR5IG9yIHNvbWUgY2hlYXBlciBmdW5jdGlvbiwgdGhlbiBJIHRoaW5rIHRoYXQncyBh biBPSyBvdXRjb21lLiAgV2Ugc2hvdWxkIHN0b3AgcHJldGVuZGluZyB0aGF0IG9uZSBzaXplIGZp dHMgYWxsIGlzIGFjaGlldmFibGU7IGl0J3Mgbm90IGJlZW4gdGhlIGNhc2UgZm9yIHllYXJzIGFs cmVhZHkuDQoNCkZXSVcsIHdoYXQgSSBnb3QgZnJvbSB0aGUgaW5mbyB0aGF0IFByYXZlZW4gYW5k IElhbiBoYXZlIHNoYXJlZCBpcyB0aGF0IHRoZXJlIGFyZSBlbm91Z2ggcHJvYmxlbXMgdG8gc29s dmUgd2l0aCBVRFAgdGhhdCB3b3JyeWluZyBhYm91dCB0aGUgcGVyZm9ybWFuY2UgaGl0IGZyb20g ZW5jcnlwdGlvbiBpcyBwcmVtYXR1cmUuDQoNCg== From nobody Thu Apr 5 09:57:25 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0CC12DA28 for ; Thu, 5 Apr 2018 09:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_NPNqO0nesN for ; Thu, 5 Apr 2018 09:57:21 -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 AFCDD1271DF for ; Thu, 5 Apr 2018 09:57:21 -0700 (PDT) Received: from dhcp-207-156.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:b4be:8e72:cc28:8630]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id F0B061B003A8; Thu, 5 Apr 2018 17:57:20 +0100 (BST) Reply-To: gorry@erg.abdn.ac.uk Subject: Re: Privacy holes To: Christian Huitema , Frederick Kautz Cc: quic@ietf.org, =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <0133ba5a-466f-b037-0ba7-47d24a9eaa75@erg.abdn.ac.uk> Date: Thu, 5 Apr 2018 17:57:20 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.6.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: Thu, 05 Apr 2018 16:57:24 -0000 On 05/04/2018 17:08, Christian Huitema wrote: > > >> On Apr 5, 2018, at 8:58 AM, Frederick Kautz wrote: >> >> Are you concerned that middleware boxes may be trained to reject migrations, thereby forcing a new connection with a visible negotiation? > > Yes. Hence the need to grease. For example, have clients do some gratuitous migration to a new source port number rather frequently. > > -- Christian Huitema > This concern about "migration", seems an odd concern to me - and that probably stems from a very different perspective. My desire to see numbers here is to allow for toolchains to plot, analyse, connection progress and a variety of other traffic characteristics - complimenting the SPIN bit(s); I see it can also provide opportunities to leverage what we know about using hardware offload fro transport processing (and I expect potentially crypto), etc. Yes potentially such numbers could be used to help build connection state in CGNs or whatever middlebox that wants to see connections continue to progress (but then they can also count packets right now t do that). To me such use is totally independent of how QUIC chooses to use these numbers internally in future, and in no way stops the QUIC protocol evolving. My point is that I keep hearing issues: e.g. the potential opportunities for discovering linkability - yet the uses I had in mind do not need to be per-path, for these topics there could just as well be one sequence space per "path" being used. Gorry From nobody Thu Apr 5 10:19:00 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F2212DA28 for ; Thu, 5 Apr 2018 10:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lfvr9TYcpnVF for ; Thu, 5 Apr 2018 10:18:55 -0700 (PDT) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::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 CA0D11271DF for ; Thu, 5 Apr 2018 10:18:55 -0700 (PDT) Received: by mail-pl0-x234.google.com with SMTP id a39-v6so748953pla.10 for ; Thu, 05 Apr 2018 10:18:55 -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=t3Ivv2paA3FtJoxmsHqRGxz+T4wYg+UjZhvsBIth0Wo=; b=ODX3K/CbLMD7r4Uhubvr5t4kNqiCvNyP2xp3/c8pEtcmufFLWrQAwzILCMrIiIkJuz hVQZWDvKAuX8BEQj41monOEpbR8+DIPQ4icbwIGbrbr05DTIEVfoOt1sqCTIkWcWQJeh L+64NyVow+cw2bKUrwKXPCkb8Eu4NFiWKp+BOkcfR8rlakYI/gIG8BXMEfOIREP+U0v1 +VpGTjF8wZHtB7IGFIUOAcgESpJdQGa7ZSpSHQGri96aevtnb3jv3b2Q+/8K8Pi1OyTt bygeTfJB6nUhMoNuOEK/RKs49Wufqe/1vhlWlPPI2Zla/mKsQRzC2psE4QH30Jytxo4n I8Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=t3Ivv2paA3FtJoxmsHqRGxz+T4wYg+UjZhvsBIth0Wo=; b=rUuEuqpR9/2orHEcHv229mbq+0o9I/PaP+ZarEr5DlLDivBDlpXw176WuBy156ixrt CHJ+FzDcMno5CbtrlXMpjoGqwzG53bneu+TKNnQOUehfxJYWzBtpYe/PmuNJmERimK3d 7p9FwgjbMt+F+EGA175XLLUDtGUf6GUdJEJlYwova3pDFauDtMLISXVvzkLbmhOXcAnI dN7VevjPS1RL/FCpk72mRSJCVf32v45AStd/0AntPi/ZZUt0AVThDH9g+iL51ndcjdMm 7XqX4FtHoi3hzupM4QpS0M4tnPWir9MZC6leXOuI3NVkn21zrCEGMfUnnmdXBxw5Bn0k rsVg== X-Gm-Message-State: AElRT7GXod8+3UfKKAtJ3PpOfU+IlCMZdHRquFOADsP6MnrR/9A61O6W kxeKEJBynBrBwI25ImJV3POicvAFbX76UhATLL6C8Q== X-Google-Smtp-Source: AIpwx48n+JDZz2nU4b/z55dVhXYYlpCyJFQmn0uB/yMH8kuxSGvLyUgDQz8Y2bdUPhsc/S6xIf6i1lZUuHQwaI/TpnM= X-Received: by 2002:a17:902:8ec8:: with SMTP id x8-v6mr24262722plo.179.1522948735353; Thu, 05 Apr 2018 10:18:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Thu, 5 Apr 2018 10:18:54 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Kazuho Oku Date: Fri, 6 Apr 2018 02:18:54 +0900 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: Christian Huitema Cc: Frederick Kautz , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= 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, 05 Apr 2018 17:18:57 -0000 2018-04-06 1:08 GMT+09:00 Christian Huitema : > > >> On Apr 5, 2018, at 8:58 AM, Frederick Kautz wrote: >> >> Are you concerned that middleware boxes may be trained to reject migrations, thereby forcing a new connection with a visible negotiation? > > Yes. Hence the need to grease. For example, have clients do some gratuitous migration to a new source port number rather frequently. I agree that it might be a good idea to grease. OTOH I do not think that gratuitous migration would be a good solution due to performance issues. We would be required to start from INITCWND every time the client switches to a new address. The fact that we cannot run two paths simultaneously in QUIC v1 makes the performance drawback big. Rather, I'd prefer making handshake packets indistinguishable from short header packets. In essence, you move the flags of the long header inside the AEAD-protected area. An endpoint that receives a packet carrying a CID that does not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connection initiation, or sends a stateful reset if the trial-decryption fails. > -- Christian Huitema -- Kazuho Oku From nobody Thu Apr 5 10:19:35 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279A512DA46 for ; Thu, 5 Apr 2018 10:19:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_H5I-fZNGfZ for ; Thu, 5 Apr 2018 10:19:30 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0095.outbound.protection.outlook.com [104.47.38.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F441271DF for ; Thu, 5 Apr 2018 10:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ai/d4EjCdEIqKh0FQ7HB4N7FnZLn3a017tsDYKkBUGQ=; b=IF7aJ0FGeVc6i5M53kbBGjrSenMc8DhpusnNHEJdvSL3kEzfRvu/DE2ueA/OhysgOpHpF/9quPDfwMB7vk0B5WBE5MH6tds0krJmYRIQW6tQNFM5/njGlvc1Ds335pHZJcVRMVlaPKiQ4m0QnF4yfbH8EZjKSbfcZfFe3cx3XD0= Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1373.namprd08.prod.outlook.com (10.162.1.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.631.10; Thu, 5 Apr 2018 17:19:27 +0000 Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0653.013; Thu, 5 Apr 2018 17:19:27 +0000 From: Mike Bishop To: IETF QUIC WG Subject: Server's Preferred Address Thread-Topic: Server's Preferred Address Thread-Index: AdPM/yWWCvy2v59cR66uoZGAhfklJA== Date: Thu, 5 Apr 2018 17:19:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR08MB1373; 7:6BipCPhaKx+c2Pykm0ZH4CAP30rl0hpmSImkVto0qNryiLpIocO1oRaMSC/t/NGxjKovLGjQuS3vDeSS2I5Zcxl+9PwuY38ztoZGuW004SXSZUOIDXl9WSXIPrO/aWfM80pZcBHGkXFf+aJySSXXdJOj7QN0br6LgDpXJqNcS+euNsJpXFxfksqDt4O5nsk1pwMG/kMGpvfADqS1+y39jLh/5YXDGJAC08m0pPC32FeAA1DfG86Kd7bClfOj8nMZ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b0af59e8-d1a4-4314-be12-08d59b19626c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1373; x-ms-traffictypediagnostic: SN1PR08MB1373: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231221)(944501327)(52105095)(6041310)(20161123560045)(20161123564045)(20161123558120)(2016111802025)(20161123562045)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1373; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1373; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(396003)(39830400003)(39380400002)(199004)(189003)(53936002)(3846002)(6916009)(54896002)(5660300001)(9686003)(68736007)(790700001)(74316002)(6306002)(97736004)(7736002)(6116002)(105586002)(33656002)(14454004)(6436002)(55016002)(478600001)(8936002)(106356001)(102836004)(6506007)(8676002)(81166006)(99286004)(86362001)(25786009)(66066001)(81156014)(59450400001)(186003)(316002)(7696005)(3660700001)(74482002)(3480700004)(2900100001)(26005)(476003)(2906002)(3280700002)(486006)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1373; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: ByaBTo29RGjxGKnqQ0YcXgudO3QH16acnq7BHi4WYHBPZtAaAoYdrFrRAS7g7k28XLN6FaJf0KDvCiCVVl1Tg20LfMrAjyehLody5GrlaVME/l0Xznu0HNaBYlUtoaurO19EEvKVxHeMB/KupgxC6qmkQXmISGgysxF05SWG3lQXb4LW7SBbeUSK9uw8xty6yJMUnpaXqEnh7SrNERGf31T72SLO07ASUQQm6A6kJb5M/mcn8f/pbYhJlc5jugZfX2mLpian4aJZJSAwJREw+eZMWP7ncZD0OKR4EMklvLCPTcDROps5MKm89/bzNO6ztipSd9o+v21kqivCKb/9CLgZnJGPYNQUc1McULoRFlHX7rxjKh4VdOH4DqmyPt1x7j8m8hgs+NW8w8BDSSytzbPeKccWLHHgnvzYwdCabxs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR08MB185489DC70881C810110B987DABB0SN1PR08MB1854namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: b0af59e8-d1a4-4314-be12-08d59b19626c X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 17:19:26.8386 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1373 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 17:19:33 -0000 --_000_SN1PR08MB185489DC70881C810110B987DABB0SN1PR08MB1854namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As we walk along the spectrum from fixed 4-tuple for the life of a connecti= on to full multipath, #560 requested a solution to the problem of Anycast I= P addresses. There are some large server deployments where the front-end a= ddresses are Anycast-based. However, for a connection-oriented protocol, y= ou want to be "sticky" to the server endpoint that you did the handshake wi= th. Currently, that's addressed with some amount of re-forwarding internal= ly and some amount of tolerated connection breakage. This gets more painfu= l if we support connection migration, as the same Anycast address likely hi= ts a different server from your new IP address. PR#1251 builds on the path verification approach to enable servers to hand = off to a unicast IP address if desired. It adds a transport parameter in w= hich the server supplies: * IP version * IP address * UDP port * Connection ID (possibly empty) * Stateless Reset Token At the end of the handshake, the client SHOULD perform path validation on t= he supplied address; if it succeeds, it transitions to the new address. If= it fails, it just stays on the original (presumably Anycast) address and t= akes the risk that the connection will fail when routing changes. (The SHO= ULD is a matter of some contention - servers want to be able to rely on thi= s, but can't actually tell whether the client's path validation failed or w= as never attempted.) It's important to note that this isn't full server migration - it's a step = in that direction, but this is scoped strictly to the server making one cha= nge attempt to an address it provides at a specified time. However, this i= sn't something that has seen broad discussion, so I wanted to raise it for = the WG's consideration. (If we want to tackle server migration, I think the next piece would be a f= rame that carries essentially the same information, requesting the client t= o make a probe attempt. This helps deal with NATs by making clients speak = first, but it assumes that the server always maintains control of both addr= esses during a transition. To support full P2P, where both sides could be = make-after-break, you basically need something like ICE.) --_000_SN1PR08MB185489DC70881C810110B987DABB0SN1PR08MB1854namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As we walk along the spectrum from fixed 4-tuple for= the life of a connection to full multipath, #560 requested a solution to t= he problem of Anycast IP addresses.  There are some large server deplo= yments where the front-end addresses are Anycast-based.  However, for a connection-oriented protocol, you want= to be “sticky” to the server endpoint that you did the handsha= ke with.  Currently, that’s addressed with some amount of re-for= warding internally and some amount of tolerated connection breakage.  This gets more painful if we support connection migration, as the same Any= cast address likely hits a different server from your new IP address.<= /o:p>

 

PR#1251 builds on the path verification approach to = enable servers to hand off to a unicast IP address if desired.  It add= s a transport parameter in which the server supplies:

  • IP version
  • IP address
  • UDP= port
  • Connection ID (possibly empty)
    • Stateless Reset Token

 

At the end of the handshake, the client SHOULD perfo= rm path validation on the supplied address; if it succeeds, it transitions = to the new address.  If it fails, it just stays on the original (presu= mably Anycast) address and takes the risk that the connection will fail when routing changes.  (The SHOULD is a= matter of some contention – servers want to be able to rely on this,= but can’t actually tell whether the client’s path validation f= ailed or was never attempted.)

 

It’s important to note that this isn’t f= ull server migration – it’s a step in that direction, but this = is scoped strictly to the server making one change attempt to an address it= provides at a specified time.  However, this isn’t something that has seen broad discussion, so I wanted to raise it for the WG’s= consideration.

 

(If we want to tackle server migration, I think the = next piece would be a frame that carries essentially the same information, = requesting the client to make a probe attempt.  This helps deal with N= ATs by making clients speak first, but it assumes that the server always maintains control of both addresses duri= ng a transition.  To support full P2P, where both sides could be make-= after-break, you basically need something like ICE.)

--_000_SN1PR08MB185489DC70881C810110B987DABB0SN1PR08MB1854namp_-- From nobody Thu Apr 5 10:27:18 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0360A126D3F for ; Thu, 5 Apr 2018 10:27:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSATDvd7MhMT for ; Thu, 5 Apr 2018 10:27:13 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::724]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7A41271DF for ; Thu, 5 Apr 2018 10:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NbWz/TLQfOrw7af6jkv74d2tlCFlNwag0eL8EslkR+w=; b=UzrrPctsa1L1ZICESIXoKD/I3D7teYDBtKya5spgVjNRXHdrzizxFX/T6R2ftWQlWIoKxhv/n20GYzQZgxG5Xjep4Piixp19upW4/7pBElvOitjYmzJQ/IKfjZ5dZyQ41/ygkc+luoGFuAa+4+TKhWIVcbpd3l4QqYYnrCkxPKg= Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1391.namprd08.prod.outlook.com (10.162.1.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Thu, 5 Apr 2018 17:27:10 +0000 Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0653.013; Thu, 5 Apr 2018 17:27:10 +0000 From: Mike Bishop To: Kazuho Oku , Christian Huitema CC: IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Frederick Kautz Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Index: AQHTzPOeIdtMxyMgr0ikidMd5Tq1W6PyVBwAgAACsQCAABOkAIAAAGeQ Date: Thu, 5 Apr 2018 17:27:10 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR08MB1391; 7:JT58Me2LbrHlV5ysbvjQuBaMbO5dNCleitzrYX6IXoTGyHzi4t9Cz5rTnNq0QUxxdMsWeV8Lksl5S5nABO4FiPIhpSctbk9dB0eh9remIZ7aDK3r0EpXROEmYt4t/w/Osex2LV0F2PmNN4qjyt8tHMOU7a4ROxxIZiZsyguSLP2Zv4t7jE5a4aQYU1m1+2PqbT183BgK03zXKGkZHUg3wEa++g0EFk7v8LJjYdHlvYSi7of3j4sW792GPkWoQDYm x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 095c9d97-39ba-4968-79d5-08d59b1a7679 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1391; x-ms-traffictypediagnostic: SN1PR08MB1391: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(6041310)(2016111802025)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1391; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1391; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(39830400003)(396003)(376002)(366004)(199004)(13464003)(189003)(377424004)(8676002)(2900100001)(7696005)(106356001)(76176011)(39060400002)(316002)(25786009)(5660300001)(81166006)(33656002)(486006)(3660700001)(81156014)(93886005)(99286004)(4326008)(229853002)(97736004)(6246003)(478600001)(790700001)(6116002)(3846002)(3280700002)(14454004)(186003)(55016002)(66066001)(6436002)(476003)(11346002)(446003)(5250100002)(2906002)(54906003)(8936002)(6506007)(53546011)(110136005)(7736002)(26005)(74316002)(53936002)(86362001)(74482002)(236005)(9686003)(6306002)(54896002)(68736007)(102836004)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1391; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: r5C4fX+SJFtqr6VOTuT25PvJfRx9gzw1Jd5rw3vlVN+tCvvOu4J2agaiOtqsocW17tUn5+st+CdnXDq9/aXLxWT9U11SQn5bM7xq9DJOWpwUop2CZLF18lOcsnHOMSgtO+dHSyXUgiCoN4e9y6AHy+T5M+0k9WA/a6UJI6jaMHrYLyP4zrE1wkuNFdtIHnovQHex1DSFmIYfq57UXHc1WCOSA+nvvzbXqkVHTQvAQRXfNLj+ndpFgIAaM19/c2xSaS41fyjiv9u8M9Njlx/GtcEry2HDyLXRNcXql5zl8rgMCRbq5zJv0zV9NBeSRnjjU/iydbkH6dz+lW9PmfijEdfLI97Kzr3m2/UgycAcjkhi6piNOqd5ZXsqxqTNTbATPuoY/gj37J7dtP5Zri5iqyhLq2A1SVmLeLBf/9qYZJs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR08MB1854010FD61AC17D19E497FDDABB0SN1PR08MB1854namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 095c9d97-39ba-4968-79d5-08d59b1a7679 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 17:27:10.0670 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1391 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 17:27:17 -0000 --_000_SN1PR08MB1854010FD61AC17D19E497FDDABB0SN1PR08MB1854namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3BlYyBzYXlzOg0KDQpBbiBlbmRwb2ludCBNVVNUIE5PVCByZXR1cm4gdG8gdGhlIHNlbmQgcmF0 ZSB1c2VkIGZvciB0aGUgcHJldmlvdXMgcGF0aCB1bmxlc3MgaXQgaXMgcmVhc29uYWJseSBzdXJl IHRoYXQgdGhlIHByZXZpb3VzIHNlbmQgcmF0ZSBpcyB2YWxpZCBmb3IgdGhlIG5ldyBwYXRoLiBG b3IgaW5zdGFuY2UsIGEgY2hhbmdlIGluIHRoZSBjbGllbnTigJlzIHBvcnQgbnVtYmVyIGlzIGxp a2VseSBpbmRpY2F0aXZlIG9mIGEgcmViaW5kaW5nIGluIGEgbWlkZGxlYm94IGFuZCBub3QgYSBj b21wbGV0ZSBjaGFuZ2UgaW4gcGF0aC4gVGhpcyBkZXRlcm1pbmF0aW9uIGxpa2VseSBkZXBlbmRz IG9uIGhldXJpc3RpY3MsIHdoaWNoIGNvdWxkIGJlIGltcGVyZmVjdDsgaWYgdGhlIG5ldyBwYXRo IGNhcGFjaXR5IGlzIHNpZ25pZmljYW50bHkgcmVkdWNlZCwgdWx0aW1hdGVseSB0aGlzIHJlbGll cyBvbiB0aGUgY29uZ2VzdGlvbiBjb250cm9sbGVyIHJlc3BvbmRpbmcgdG8gY29uZ2VzdGlvbiBz aWduYWxzIGFuZCByZWR1Y2luZyBzZW5kIHJhdGVzIGFwcHJvcHJpYXRlbHkuDQoNCg0KDQpZb3Un cmUgbm90IHJlcXVpcmVkIHRvIHJlc2V0IHRoZSBDV05EIGlmIHlvdSBoYXZlIHJlYXNvbiB0byBi ZWxpZXZlIHRoZSB1bmRlcmx5aW5nIHBhdGggaXMgdGhlIHNhbWUsIHNvIGRvaW5nIHRoaXMgc2hv dWxkbuKAmXQgY2F1c2UgYW55IHRyYW5zcG9ydCBpbmZvcm1hdGlvbiB0byBnZXQgcmVzZXQuDQoN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEthenVobyBPa3UNClNlbnQ6IFRodXJzZGF5 LCBBcHJpbCA1LCAyMDE4IDEwOjE5IEFNDQpUbzogQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFA aHVpdGVtYS5uZXQ+DQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgTWlyamEgS8O8 aGxld2luZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD47IEZyZWRlcmljayBLYXV0 eiA8ZmthdXR6QGFsdW1uaS5jbXUuZWR1Pg0KU3ViamVjdDogUmU6IFByaXZhY3kgaG9sZXMgKHdh czogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbikN Cg0KDQoNCjIwMTgtMDQtMDYgMTowOCBHTVQrMDk6MDAgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRl bWFAaHVpdGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+PjoNCg0KPg0KDQo+DQoN Cj4+IE9uIEFwciA1LCAyMDE4LCBhdCA4OjU4IEFNLCBGcmVkZXJpY2sgS2F1dHogPGZrYXV0ekBh bHVtbmkuY211LmVkdTxtYWlsdG86ZmthdXR6QGFsdW1uaS5jbXUuZWR1Pj4gd3JvdGU6DQoNCj4+ DQoNCj4+IEFyZSB5b3UgY29uY2VybmVkIHRoYXQgbWlkZGxld2FyZSBib3hlcyBtYXkgYmUgdHJh aW5lZCB0byByZWplY3QgbWlncmF0aW9ucywgdGhlcmVieSBmb3JjaW5nIGEgbmV3IGNvbm5lY3Rp b24gd2l0aCBhIHZpc2libGUgbmVnb3RpYXRpb24/DQoNCj4NCg0KPiBZZXMuIEhlbmNlIHRoZSBu ZWVkIHRvIGdyZWFzZS4gRm9yIGV4YW1wbGUsIGhhdmUgY2xpZW50cyBkbyBzb21lIGdyYXR1aXRv dXMgbWlncmF0aW9uIHRvIGEgbmV3IHNvdXJjZSBwb3J0IG51bWJlciByYXRoZXIgZnJlcXVlbnRs eS4NCg0KDQoNCkkgYWdyZWUgdGhhdCBpdCBtaWdodCBiZSBhIGdvb2QgaWRlYSB0byBncmVhc2Uu DQoNCg0KDQpPVE9IIEkgZG8gbm90IHRoaW5rIHRoYXQgZ3JhdHVpdG91cyBtaWdyYXRpb24gd291 bGQgYmUgYSBnb29kIHNvbHV0aW9uIGR1ZSB0byBwZXJmb3JtYW5jZSBpc3N1ZXMuIFdlIHdvdWxk IGJlIHJlcXVpcmVkIHRvIHN0YXJ0IGZyb20gSU5JVENXTkQgZXZlcnkgdGltZSB0aGUgY2xpZW50 IHN3aXRjaGVzIHRvIGEgbmV3IGFkZHJlc3MuIFRoZSBmYWN0IHRoYXQgd2UgY2Fubm90IHJ1biB0 d28gcGF0aHMgc2ltdWx0YW5lb3VzbHkgaW4gUVVJQyB2MSBtYWtlcyB0aGUgcGVyZm9ybWFuY2Ug ZHJhd2JhY2sgYmlnLg0KDQoNCg0KUmF0aGVyLCBJJ2QgcHJlZmVyIG1ha2luZyBoYW5kc2hha2Ug cGFja2V0cyBpbmRpc3Rpbmd1aXNoYWJsZSBmcm9tIHNob3J0IGhlYWRlciBwYWNrZXRzLiBJbiBl c3NlbmNlLCB5b3UgbW92ZSB0aGUgZmxhZ3Mgb2YgdGhlIGxvbmcgaGVhZGVyIGluc2lkZSB0aGUg QUVBRC1wcm90ZWN0ZWQgYXJlYS4gQW4gZW5kcG9pbnQgdGhhdCByZWNlaXZlcyBhIHBhY2tldCBj YXJyeWluZyBhIENJRCB0aGF0IGRvZXMgbm90IGJlbG9uZyB0byBhbnkga25vd24gY29ubmVjdGlv biB0cmlhbC1kZWNyeXB0cyB0aGUgcGFja2V0IGFzIGEgaW5pdGlhbCBwYWNrZXQgYW5kIGhhbmRs ZXMgaXQgYXMgYSBjb25uZWN0aW9uIGluaXRpYXRpb24sIG9yIHNlbmRzIGEgc3RhdGVmdWwgcmVz ZXQgaWYgdGhlIHRyaWFsLWRlY3J5cHRpb24gZmFpbHMuDQoNCg0KDQo+IC0tIENocmlzdGlhbiBI dWl0ZW1hDQoNCg0KDQoNCg0KDQoNCi0tDQoNCkthenVobyBPa3UNCg0KDQo= --_000_SN1PR08MB1854010FD61AC17D19E497FDDABB0SN1PR08MB1854namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TcGVjIHNheXM6PG86cD48L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgIzQ0NzJDNCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21h cmdpbi1sZWZ0Oi41aW47bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzowaW4iPkFuIGVuZHBvaW50IE1VU1QgTk9UIHJl dHVybiB0byB0aGUgc2VuZCByYXRlIHVzZWQgZm9yIHRoZSBwcmV2aW91cyBwYXRoDQo8Yj51bmxl c3MgaXQgaXMgcmVhc29uYWJseSBzdXJlIHRoYXQgdGhlIHByZXZpb3VzIHNlbmQgcmF0ZSBpcyB2 YWxpZCBmb3IgdGhlIG5ldyBwYXRoLiBGb3IgaW5zdGFuY2UsIGEgY2hhbmdlIGluIHRoZSBjbGll bnTigJlzIHBvcnQgbnVtYmVyPC9iPiBpcyBsaWtlbHkgaW5kaWNhdGl2ZSBvZiBhIHJlYmluZGlu ZyBpbiBhIG1pZGRsZWJveCBhbmQgbm90IGEgY29tcGxldGUgY2hhbmdlIGluIHBhdGguIFRoaXMg ZGV0ZXJtaW5hdGlvbiBsaWtlbHkgZGVwZW5kcw0KIG9uIGhldXJpc3RpY3MsIHdoaWNoIGNvdWxk IGJlIGltcGVyZmVjdDsgaWYgdGhlIG5ldyBwYXRoIGNhcGFjaXR5IGlzIHNpZ25pZmljYW50bHkg cmVkdWNlZCwgdWx0aW1hdGVseSB0aGlzIHJlbGllcyBvbiB0aGUgY29uZ2VzdGlvbiBjb250cm9s bGVyIHJlc3BvbmRpbmcgdG8gY29uZ2VzdGlvbiBzaWduYWxzIGFuZCByZWR1Y2luZyBzZW5kIHJh dGVzIGFwcHJvcHJpYXRlbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ WW91J3JlIG5vdCByZXF1aXJlZCB0byByZXNldCB0aGUgQ1dORCBpZiB5b3UgaGF2ZSByZWFzb24g dG8gYmVsaWV2ZSB0aGUgdW5kZXJseWluZyBwYXRoIGlzIHRoZSBzYW1lLCBzbyBkb2luZyB0aGlz IHNob3VsZG7igJl0IGNhdXNlIGFueSB0cmFuc3BvcnQgaW5mb3JtYXRpb24gdG8gZ2V0IHJlc2V0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBLYXp1aG8gT2t1PGJyPg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDUsIDIwMTggMTA6MTkg QU08YnI+DQpUbzogQ2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7 PGJyPg0KQ2M6IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1pcmphIEvDvGhs ZXdpbmQgJmx0O21pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gmZ3Q7OyBGcmVkZXJpY2sg S2F1dHogJmx0O2ZrYXV0ekBhbHVtbmkuY211LmVkdSZndDs8YnI+DQpTdWJqZWN0OiBSZTogUHJp dmFjeSBob2xlcyAod2FzOiBSZTogR2V0dGluZyB0byBjb25zZW5zdXMgb24gcGFja2V0IG51bWJl ciBlbmNyeXB0aW9uKTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MjAxOC0wNC0wNiAxOjA4IEdNVCYjNDM7 MDk6MDAgQ2hyaXN0aWFuIEh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRl bWEubmV0Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9u ZSI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvc3Bhbj48L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7IE9uIEFwciA1LCAyMDE4LCBhdCA4OjU4IEFNLCBGcmVkZXJpY2sg S2F1dHogJmx0OzxhIGhyZWY9Im1haWx0bzpma2F1dHpAYWx1bW5pLmNtdS5lZHUiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5ma2F1dHpAYWx1bW5p LmNtdS5lZHU8L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyZndDsgQXJlIHlvdSBjb25jZXJuZWQgdGhhdCBtaWRkbGV3YXJlIGJv eGVzIG1heSBiZSB0cmFpbmVkIHRvIHJlamVjdCBtaWdyYXRpb25zLCB0aGVyZWJ5IGZvcmNpbmcg YSBuZXcgY29ubmVjdGlvbiB3aXRoIGEgdmlzaWJsZSBuZWdvdGlhdGlvbj88bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgWWVzLiBIZW5jZSB0aGUgbmVlZCB0byBncmVhc2Uu IEZvciBleGFtcGxlLCBoYXZlIGNsaWVudHMgZG8gc29tZSBncmF0dWl0b3VzIG1pZ3JhdGlvbiB0 byBhIG5ldyBzb3VyY2UgcG9ydCBudW1iZXIgcmF0aGVyIGZyZXF1ZW50bHkuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkkgYWdyZWUgdGhhdCBpdCBtaWdodCBiZSBhIGdvb2QgaWRlYSB0 byBncmVhc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk9UT0ggSSBkbyBub3QgdGhp bmsgdGhhdCBncmF0dWl0b3VzIG1pZ3JhdGlvbiB3b3VsZCBiZSBhIGdvb2Qgc29sdXRpb24gZHVl IHRvIHBlcmZvcm1hbmNlIGlzc3Vlcy4gV2Ugd291bGQgYmUgcmVxdWlyZWQgdG8gc3RhcnQgZnJv bSBJTklUQ1dORCBldmVyeSB0aW1lIHRoZSBjbGllbnQgc3dpdGNoZXMgdG8gYSBuZXcgYWRkcmVz cy4gVGhlIGZhY3QgdGhhdCB3ZSBjYW5ub3QgcnVuIHR3byBwYXRocyBzaW11bHRhbmVvdXNseQ0K IGluIFFVSUMgdjEgbWFrZXMgdGhlIHBlcmZvcm1hbmNlIGRyYXdiYWNrIGJpZy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+UmF0aGVyLCBJJ2QgcHJlZmVyIG1ha2luZyBoYW5kc2hha2Ug cGFja2V0cyBpbmRpc3Rpbmd1aXNoYWJsZSBmcm9tIHNob3J0IGhlYWRlciBwYWNrZXRzLiBJbiBl c3NlbmNlLCB5b3UgbW92ZSB0aGUgZmxhZ3Mgb2YgdGhlIGxvbmcgaGVhZGVyIGluc2lkZSB0aGUg QUVBRC1wcm90ZWN0ZWQgYXJlYS4gQW4gZW5kcG9pbnQgdGhhdCByZWNlaXZlcyBhIHBhY2tldCBj YXJyeWluZyBhIENJRCB0aGF0IGRvZXMgbm90DQogYmVsb25nIHRvIGFueSBrbm93biBjb25uZWN0 aW9uIHRyaWFsLWRlY3J5cHRzIHRoZSBwYWNrZXQgYXMgYSBpbml0aWFsIHBhY2tldCBhbmQgaGFu ZGxlcyBpdCBhcyBhIGNvbm5lY3Rpb24gaW5pdGlhdGlvbiwgb3Igc2VuZHMgYSBzdGF0ZWZ1bCBy ZXNldCBpZiB0aGUgdHJpYWwtZGVjcnlwdGlvbiBmYWlscy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAtLSBDaHJpc3RpYW4gSHVpdGVtYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkthenVobyBPa3U8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN1PR08MB1854010FD61AC17D19E497FDDABB0SN1PR08MB1854namp_-- From nobody Thu Apr 5 10:27:46 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AC112DA4E for ; Thu, 5 Apr 2018 10:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deCr_iAEDzEI for ; Thu, 5 Apr 2018 10:27:43 -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 EB923126D3F for ; Thu, 5 Apr 2018 10:27:42 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id q80so31493231ioi.13 for ; Thu, 05 Apr 2018 10:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dLgxs+7kSM9btmfAVoSsTqUpcvsXcItpVds7UjHitPk=; b=vRdSVkCbC+FVNVRdlU6ptxKvCRnGtkZuhMNML9HqYN1DszxG2IPt4SZtp+0iBTEjbR s9QliqZE33mTuZzXEHJ9zAk9u3R/P2VFHQSlh7cJJr1+yS8hAsVBwXMNulsV6ong1T0f ob64ujYo8cZJ7e/q8OKJD2oYor7ylhC2N0Wxa0W67kLjHE9+h4nvayhn1pIlcYFrs3lV dE7//LMxCAkVysBcXiHCfo9yg5lWXU6n4aPOrPceJ2CC981btnVZGZ5vHhKMNsWr8fh8 Uk8xj+seYMVe+vNyCmkSD/IC8C+WexgXvwJ7381E6WL8ztsKPzhxUGdC8uVdiHO/QvYy ZXpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dLgxs+7kSM9btmfAVoSsTqUpcvsXcItpVds7UjHitPk=; b=e9Ci4/5v1VoG20BpwzkJ/Dria87kSxzMh2w7eehk/nZFWHG2iQBLUNfCtK1Qr3cq5m yZi5zCt/0yP8jY/XAQMGUl5Av+ZuSAaEzKm+iwHBqIyPvvmBMEbwx0427TNctboTgxYu EEBI102JJmk8o5btbF+H9LS6oHYVOQeuG4o9OsAMjchJw4RsAJYpHKNv92T0IQgttCOG ScVNKf2LJXgziYyG5qq2Yyw/0zRxSYkfXAblJxIL81Q3jeMJRtCuhEK8GyFUPACMT7R+ oc1WNY0La94SQOVSbh/jcgE2gYXDo+rvlZYQqLSoh/ZC2+ipvGLy/R6lREqNSX9TB0K1 wBbA== X-Gm-Message-State: ALQs6tBeXezPYlrH7fWTIy0kDICarIgWStkMRLlWZ2MdD7eJP3nc4ktV RwIrVW5gypfSkJAipOH2qqCDCGttI5mg0J2K/ED6tg== X-Google-Smtp-Source: AIpwx492TalzpvA2ObWuVsrKtivu/mZiORkDMpQUGa6DLvNHhiab1eXaq/qD3gnz17FOjZMoME3/nj1JUbt8QHSuACs= X-Received: by 10.107.131.83 with SMTP id f80mr20929841iod.102.1522949257823; Thu, 05 Apr 2018 10:27:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Thu, 05 Apr 2018 17:27:24 +0000 Message-ID: Subject: Re: Server's Preferred Address To: Mike Bishop Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113f998a8b383805691d419c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 17:27:45 -0000 --001a113f998a8b383805691d419c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I and the traffic engineers I work with would REALLY like to have this feature. Also, in practice it's required to make connection migration work with anycast. At Google, we've started experimenting with this already in gQUIC, and it works as expected, though you do need to probe before jumping to the new server IP(as described in Mike's PR), or you risk a small but visible number of connection failures post-handshake. On Thu, Apr 5, 2018 at 1:19 PM Mike Bishop wrote: > As we walk along the spectrum from fixed 4-tuple for the life of a > connection to full multipath, #560 requested a solution to the problem of > Anycast IP addresses. There are some large server deployments where the > front-end addresses are Anycast-based. However, for a connection-oriente= d > protocol, you want to be =E2=80=9Csticky=E2=80=9D to the server endpoint = that you did the > handshake with. Currently, that=E2=80=99s addressed with some amount of > re-forwarding internally and some amount of tolerated connection breakage= . > This gets more painful if we support connection migration, as the same > Anycast address likely hits a different server from your new IP address. > > > > PR#1251 builds on the path verification approach to enable servers to han= d > off to a unicast IP address if desired. It adds a transport parameter in > which the server supplies: > > - IP version > - IP address > - UDP port > - Connection ID (possibly empty) > - Stateless Reset Token > > > > At the end of the handshake, the client SHOULD perform path validation on > the supplied address; if it succeeds, it transitions to the new address. > If it fails, it just stays on the original (presumably Anycast) address a= nd > takes the risk that the connection will fail when routing changes. (The > SHOULD is a matter of some contention =E2=80=93 servers want to be able t= o rely on > this, but can=E2=80=99t actually tell whether the client=E2=80=99s path v= alidation failed > or was never attempted.) > > > > It=E2=80=99s important to note that this isn=E2=80=99t full server migrat= ion =E2=80=93 it=E2=80=99s a step > in that direction, but this is scoped strictly to the server making one > change attempt to an address it provides at a specified time. However, > this isn=E2=80=99t something that has seen broad discussion, so I wanted = to raise > it for the WG=E2=80=99s consideration. > > > > (If we want to tackle server migration, I think the next piece would be a > frame that carries essentially the same information, requesting the clien= t > to make a probe attempt. This helps deal with NATs by making clients spe= ak > first, but it assumes that the server always maintains control of both > addresses during a transition. To support full P2P, where both sides cou= ld > be make-after-break, you basically need something like ICE.) > --001a113f998a8b383805691d419c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I and the traffic engineers I work with would REALLY = like to have this feature.=C2=A0 Also, in practice it's required to mak= e connection migration work with anycast.

At Google, we= 've started experimenting with this already in gQUIC, and it works as e= xpected, though you do need to probe before jumping to the new server IP(as= described in Mike's PR), or you risk a small but visible number of con= nection failures post-handshake.=C2=A0

=
On Thu, Apr 5, 2018 at 1:19 PM Mike Bishop <mbishop@evequefou.be> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

As we walk along the spectrum from fixed 4-tuple for= the life of a connection to full multipath, #560 requested a solution to t= he problem of Anycast IP addresses.=C2=A0 There are some large server deplo= yments where the front-end addresses are Anycast-based.=C2=A0 However, for a connection-oriented protocol, you want= to be =E2=80=9Csticky=E2=80=9D to the server endpoint that you did the han= dshake with.=C2=A0 Currently, that=E2=80=99s addressed with some amount of = re-forwarding internally and some amount of tolerated connection breakage.= =C2=A0 This gets more painful if we support connection migration, as the same Any= cast address likely hits a different server from your new IP address.

=C2=A0

PR#1251 builds on the path verification approach to = enable servers to hand off to a unicast IP address if desired.=C2=A0 It add= s a transport parameter in which the server supplies:

  • IP version
  • IP address
  • UDP p= ort
  • Connection ID (possibly empty)
    • =
  • Stateless Reset Token

=C2=A0

At the end of the handshake, the client SHOULD perfo= rm path validation on the supplied address; if it succeeds, it transitions = to the new address.=C2=A0 If it fails, it just stays on the original (presu= mably Anycast) address and takes the risk that the connection will fail when routing changes.=C2=A0 (The SHOULD is a= matter of some contention =E2=80=93 servers want to be able to rely on thi= s, but can=E2=80=99t actually tell whether the client=E2=80=99s path valida= tion failed or was never attempted.)

=C2=A0

It=E2=80=99s important to note that this isn=E2=80= =99t full server migration =E2=80=93 it=E2=80=99s a step in that direction,= but this is scoped strictly to the server making one change attempt to an = address it provides at a specified time.=C2=A0 However, this isn=E2=80=99t = something that has seen broad discussion, so I wanted to raise it for the WG=E2=80= =99s consideration.

=C2=A0

(If we want to tackle server migration, I think the = next piece would be a frame that carries essentially the same information, = requesting the client to make a probe attempt.=C2=A0 This helps deal with N= ATs by making clients speak first, but it assumes that the server always maintains control of both addresses duri= ng a transition.=C2=A0 To support full P2P, where both sides could be make-= after-break, you basically need something like ICE.)

--001a113f998a8b383805691d419c-- From nobody Thu Apr 5 10:31:00 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B73124D6C for ; Thu, 5 Apr 2018 10:30:58 -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 d8gt_ApTWZZ4 for ; Thu, 5 Apr 2018 10:30:57 -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 E52E012DA48 for ; Thu, 5 Apr 2018 10:30:56 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id b20so31545030iof.5 for ; Thu, 05 Apr 2018 10:30:56 -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=yqfGSto27bmIoTv0mkmgEn1T1fV2oDtgmzD4t6Yyu9w=; b=J1YxUno5kVrrr+1cqYru9NPcnXL/0GdBKnyaouaaumScKzPjrR1v+8muf8Dy5H2SZ+ AI1vfMVVqOxO2gLdlwSDfyykMP1H54Pt3+e8i+iT42hjeV+qKEcHuUnJYprF/1Y1HZCA y+En1dygil55DWTApS97eQ7/qDvmv7rZcZS7Bm49polSjhoYgoUBKpHvqRVq027+WfrN zTMo/1MBHemyJF28lvENjqi5TsILbd0ZD9uUTCAP8+NVbHxvDOFqKH9xVyENKH/A6AL6 ycy85BLySSIjuWfX8/GER/R5SpALFOnJ8awrbVn8NHKmQHAlUeSMlJyOUCo8ai8Sqonq nIvg== 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=yqfGSto27bmIoTv0mkmgEn1T1fV2oDtgmzD4t6Yyu9w=; b=tqfxsPrGMJSxdC/FMpRo4QbUkUtaYZwtBzwONmJtln0oXMXT8pnbxd2qfYPr9/vsy6 jniQokKAxWptH+I88ddJvycCielrn0wyCPmbVVeuTJjt7sB7owiRDevtmw3ZzgtdTutN lE2nghLBOEH0WaERi08pj/vfPhl1KrCKHWhiuP8U05AYsnxg6aW1mtnsFtta6MCOgQHO oxLypbAXCa5g7ZrvhktfojIIYIc5jVzB7x2AsGbcSwAPkxYrHX6XNMTdhXeX7da4pJyp p2bxOjcauv+y3zHoQ1GQCJbN+DL3jm0gtVO+er0zE4Bvzui9YvhX3tc89qYuUnKxjIhF dMpQ== X-Gm-Message-State: ALQs6tCS/JUmJwsGXo8R0jzHEWrO7K3DgDUSAhEzTqxPeW02I2Moi6xC tmYh8KtP+NcLpookTn7KX3METyt6+qqO2u4+wzBjerCx X-Google-Smtp-Source: AIpwx4+TCq8EiVMwB9MCTstzK9kNKnZJZeDr2kcuUTkQsfiwFeASeTw64dGPPrujeZMvMAYoXVTEHvoYIPRYLzv46rc= X-Received: by 10.107.14.12 with SMTP id 12mr20527663ioo.209.1522949456145; Thu, 05 Apr 2018 10:30:56 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 5 Apr 2018 10:30:55 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 5 Apr 2018 10:30:55 -0700 Message-ID: Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: Mike Bishop , Christian Huitema , Kazuho Oku Cc: Frederick Kautz , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113fa9b058313805691d4dde" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 17:30:59 -0000 --001a113fa9b058313805691d4dde Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi On 5 April 2018 at 19.27.24, Mike Bishop (mbishop@evequefou.be) wrote: An endpoint that receives a packet carrying a CID that does not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connection initiation, or sends a stateful reset if the trial-decryption fails. I can see hiding things may be a good thing, but having to trial decrypt all unknown packets as potentially creating a huge load, unless you combine it with my proposal to add a checksum to the encrypted packet number so you only need one crypto block on average to reject random packet content. It won=E2=80=99t solve all DDoS, but it will help. Forcing trial decryption= fo the full packet makes me a bit anxious. Mikkel --001a113fa9b058313805691d4dde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Hi

On 5 April 2018 at 19.27.24, Mike Bishop (mbishop@evequefou.be) wrote:

=C2=A0An endpoint that receives a packet carrying a CID that = does not belong to any known connection trial-decrypts the packet as a init= ial packet and handles it as a connection initiation, or sends a stateful r= eset if the trial-decryption fails.

I can s= ee hiding things may be a good thing, but having to trial decrypt all unkno= wn packets as potentially creating a huge load, unless you combine it with = my proposal to add a checksum to the encrypted packet number so you only ne= ed one crypto block on average to reject random packet content.

It wo= n=E2=80=99t solve all DDoS, but it will help. Forcing trial decryption fo t= he full packet makes me a bit anxious.


Mikkel


--001a113fa9b058313805691d4dde-- From nobody Thu Apr 5 10:43:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68314124D6C for ; Thu, 5 Apr 2018 10:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oPfpKzCNmY9 for ; Thu, 5 Apr 2018 10:43:24 -0700 (PDT) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419DF12DA73 for ; Thu, 5 Apr 2018 10:43:24 -0700 (PDT) Received: by mail-pl0-x22c.google.com with SMTP id s10-v6so18203287plp.0 for ; Thu, 05 Apr 2018 10:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=o/4U6BsZ/FZfeeOovvKjFKcrrjqIfCjhbQ7WlmXZua8=; b=YqIIpgE8p3y6vg+SdyWISWi5ZnU9pdhuuGCzWF0ZDvePhbbL1VjdFP+JW27y4rXRl3 zA4C1ox5NSA3901vZivrZr1Zj31Tb/V0TIA6Uf/zSCME3zX/aZrT0IXEujCazAhpwTN3 7k5WCqyVy6YiPnMsj0CZQq8x3unwRJocp3XkccoKCqFJaP7sz57n8V74ScNxw6c05Q6g JAmYZ0frNozn6s/YhgPZffelJSVO1OJrGim9CgdrgBx28gtbfPPpa1O3rA2LDmqySPFt rLhCeRzhn8/NWu64KLsqO8fT3cTbt9cGMges9U+WsMooLLhXXq1X2BJE6YYkERXJaEit befw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=o/4U6BsZ/FZfeeOovvKjFKcrrjqIfCjhbQ7WlmXZua8=; b=cGcPPpe30UPTpUJBMT7efmBYWEP3BXbyKdP/RNioDygNPFDkT38MCbtTyPxjt9p15f JHC4HZ7MBl8a5tadEZTRdHdSBam+RcD4t9gSSCHfrAsrFdOKtXpWpyWn1uMGGHPdVbXl oItg8hgpGgU3ahgEeRFGMKbpIlOVPNVdZRMgAchvKiVT6s1R4vz1j29AVANnGPgcwZzD HDik9BbbDITpzmviJu2i588eNsnsRfiBzSEb7ClDlWWej/qGywrD6Y8V0tVCyeax3UuX sor/QMhezwapZW4VNEkzQOcwqlZXWuliCPXT6nvr/kZa0/d+T6k4BRmu09rfWS/GWS6o 5ylw== X-Gm-Message-State: AElRT7HYTGugd7u7CA4BD39hOtViyOwJC+gECCFNX0fGGu3llF4TXyLx tsxcq72rNcCz/dA320u90wMbRqzOguYmbJXEphQ2iw== X-Google-Smtp-Source: AIpwx48Fg6gH5KTR4T1+j48WgyXh33tiWIcVxKdQ38+x9XTazCinr6zricts28bSE8jgKuOFoLwMRa9ixcML/2qwJus= X-Received: by 10.167.129.136 with SMTP id g8mr17797968pfi.19.1522950203812; Thu, 05 Apr 2018 10:43:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Thu, 5 Apr 2018 10:43:23 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Kazuho Oku Date: Fri, 6 Apr 2018 02:43:23 +0900 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: Mike Bishop Cc: Christian Huitema , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Frederick Kautz 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, 05 Apr 2018 17:43:26 -0000 2018-04-06 2:27 GMT+09:00 Mike Bishop : > Spec says: > > An endpoint MUST NOT return to the send rate used for the previous path > unless it is reasonably sure that the previous send rate is valid for the > new path. For instance, a change in the client=E2=80=99s port number is l= ikely > indicative of a rebinding in a middlebox and not a complete change in pat= h. > This determination likely depends on heuristics, which could be imperfect= ; > if the new path capacity is significantly reduced, ultimately this relies= on > the congestion controller responding to congestion signals and reducing s= end > rates appropriately. > > > > You're not required to reset the CWND if you have reason to believe the > underlying path is the same, so doing this shouldn=E2=80=99t cause any tr= ansport > information to get reset. Thank you for pointing that out. I missed that. OTOH, I still wonder if frequent gratuitous migration is a good solution. I'd assume that in case of users behind a large-scale NAT connecting to a CDN, there would be many connections sharing the same client-IP, server-IP, server-port. The only difference in the 5-tuple is the clients' port. If we require frequent gratuitous migration, wouldn't either the NAT will run out of port addresses belonging to the same client-IP or required to switch to a different IP address? > > > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Kazuho Oku > Sent: Thursday, April 5, 2018 10:19 AM > To: Christian Huitema > Cc: IETF QUIC WG ; Mirja K=C3=BChlewind > ; Frederick Kautz > Subject: Re: Privacy holes (was: Re: Getting to consensus on packet numbe= r > encryption) > > > > 2018-04-06 1:08 GMT+09:00 Christian Huitema : > >> > >> > >>> On Apr 5, 2018, at 8:58 AM, Frederick Kautz >>> wrote: > >>> > >>> Are you concerned that middleware boxes may be trained to reject >>> migrations, thereby forcing a new connection with a visible negotiation= ? > >> > >> Yes. Hence the need to grease. For example, have clients do some >> gratuitous migration to a new source port number rather frequently. > > > > I agree that it might be a good idea to grease. > > > > OTOH I do not think that gratuitous migration would be a good solution du= e > to performance issues. We would be required to start from INITCWND every > time the client switches to a new address. The fact that we cannot run tw= o > paths simultaneously in QUIC v1 makes the performance drawback big. > > > > Rather, I'd prefer making handshake packets indistinguishable from short > header packets. In essence, you move the flags of the long header inside = the > AEAD-protected area. An endpoint that receives a packet carrying a CID th= at > does not belong to any known connection trial-decrypts the packet as a > initial packet and handles it as a connection initiation, or sends a > stateful reset if the trial-decryption fails. > > > >> -- Christian Huitema > > > > > > > > -- > > Kazuho Oku > > --=20 Kazuho Oku From nobody Thu Apr 5 10:51:02 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A4E12DB72 for ; Thu, 5 Apr 2018 10:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_GrrgF2G-0N for ; Thu, 5 Apr 2018 10:50:59 -0700 (PDT) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::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 B74BE129C5D for ; Thu, 5 Apr 2018 10:50:59 -0700 (PDT) Received: by mail-pl0-x22f.google.com with SMTP id a39-v6so876657pla.10 for ; Thu, 05 Apr 2018 10:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xeNY2EPq/RjolpOo+5vTzRAsRPMJsMvrGY0CkXgzzdY=; b=r1UxliHcjdQYM/yL3roRFIcnJqHiavTLWqnuwSIOeAppomq0QlkSPEb4CpzxdbUsHY 2oYeyeuJ4zXBdmN4Z37EXHVWoaepqO43qbNUeKynpJpDYFF5heLr46jglF+5B+06PZRu grHExk1YpvkPxoc5kRpfGF/Ka7Nu0Q04LuFQ+7V5fWrtd9+/Ej7k1+FsRHQk0abTa2Ca owjBm328LVr45u0LhxpvvA69OPQe8fTs7b7ovQJWBqecxl73aG41CyBuAPPOGIizxbdm mDLuzDd4HI8hMCMJkFjPpG9s95gLN4IdrF7uxSDkBCRP7ezUIBK8s4QuLnkwSiByc2VQ lLew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=xeNY2EPq/RjolpOo+5vTzRAsRPMJsMvrGY0CkXgzzdY=; b=UMyxbbIHShWZjvoveiGGsUKlmkhF8mZjGF2L4NcvDFyJMaKI+Jkooa45zqKtse+/ag rusFdHxFePgSDEOq6KIEkv6gXRrx+mExSJEX4UP76ME6irF12sHGsGoa/ZfnStuKDWCX qg8hJG8BCy1ZBxuajbkbzsLvSvplvMDykVAHBzDdbyz7gjwZEgFiabdwg0wM22OSS4Ke FuYsZiMJdGkiD7kucVBVu6Ym8XHjan5VZ9G00OV6yHYq96aC+SlLUuJZuIrspdqrti9O Vwu6Qmle4B9ZDx1M3Cir9neZRWlhDUXZo6YcuF+2crs995LoTYadP6X8dwoQC45jwGNI oevg== X-Gm-Message-State: AElRT7HxxWJibhpagBg69bZMhybVVaG6BvHfe6/tToCvCZIl5fHeFJW9 puTKjQ7ed5+BRVNPaKiNMgUP9KWpt2IqPr4l+a4= X-Google-Smtp-Source: AIpwx48jKIonipaj2FPR+3UFuiTdIoZ7nOn9z3D7BUXty9jRE2kPFyeO3A5VkLWLyuKtCLgtDuHQisaurrYB2bTGHxs= X-Received: by 10.101.86.198 with SMTP id w6mr15453669pgs.294.1522950659336; Thu, 05 Apr 2018 10:50:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Thu, 5 Apr 2018 10:50:58 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Kazuho Oku Date: Fri, 6 Apr 2018 02:50:58 +0900 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Mike Bishop , Christian Huitema , Frederick Kautz , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , 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: Thu, 05 Apr 2018 17:51:01 -0000 2018-04-06 2:30 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen : > Hi > > On 5 April 2018 at 19.27.24, Mike Bishop (mbishop@evequefou.be) wrote: > > An endpoint that receives a packet carrying a CID that does not belong t= o > any known connection trial-decrypts the packet as a initial packet and > handles it as a connection initiation, or sends a stateful reset if the > trial-decryption fails. > > I can see hiding things may be a good thing, but having to trial decrypt = all > unknown packets as potentially creating a huge load, unless you combine i= t > with my proposal to add a checksum to the encrypted packet number so you > only need one crypto block on average to reject random packet content. While you might be correct in pointing out that requiring trial-decryption is not a good thing in general, I think it is an orthogonal issue to whether if we can move the packet type bits into AEAD-encrypted area. In the current form of QUIC, a server is required to AES-decrypt the Initial packet. So it is possible to mount a brute-force attack targeting the symmetric crypto by sending some junk together with a packet header that looks like a Initial packet. The approach I proposed merely moves when the packet type is being checked, from prior-to-decryption to post-decryption. Maybe I should have explained it this way. Sorry if that has caused the confusion. > > It won=E2=80=99t solve all DDoS, but it will help. Forcing trial decrypti= on fo the > full packet makes me a bit anxious. > > > Mikkel > > --=20 Kazuho Oku From nobody Thu Apr 5 10:59:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B297129C5D for ; Thu, 5 Apr 2018 10:59:19 -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=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 p3jRmIRZYMcr for ; Thu, 5 Apr 2018 10:59:16 -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 966BE126BF6 for ; Thu, 5 Apr 2018 10:59:16 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w35HriKg007188; Thu, 5 Apr 2018 18:59:07 +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=D5rIDnC6KZ/V2keppBC5sY6uESTMq+81x8wCAGIFD6Q=; b=pNY2EGimy18aAau9wlW7x9ssa178zxLeEEKN6P/n4ST2jQD9VXBrMQ/xdctYIU7G1+fJ HZRMKHtC6CwmGlFjZddZDJwtZFe6km2muF82ESTp8celuUIYNtWmstBlhCLW6FmBQ9hW CkKcnUYWkdJsTfI/zOawoxjeiuNR9kCuNOUp60+SzrSe9Ti4bIattFFfSUlRYPey2gar 09wqXwxs41E6k1NFRidz2pTHdmNEBMhjKmesF0i+iO1PnZLS4X0fKyQBt6YRk5Iqguxq CBlXOdDOgYRzvIvdrCgere4r0y8czZQbC/AMWgXQh+BJGa2JtZWDgwgViIAQs5VMT1L4 HA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2h4vfv3v83-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 18:59:07 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w35HqaxP008847; Thu, 5 Apr 2018 13:59:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2h25nvugc4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 13:59:06 -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.1365.1; Thu, 5 Apr 2018 13:59:05 -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.1365.000; Thu, 5 Apr 2018 13:59:05 -0400 From: "Lubashev, Igor" To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Mike Bishop , Christian Huitema , Kazuho Oku CC: IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Frederick Kautz Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Index: AQHTzPOeCspMmk/31UumuO1CInS8X6PylyoAgAACsQCAABOkAIAAAk8AgAABDID//8BxoA== Date: Thu, 5 Apr 2018 17:59:04 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.87] Content-Type: multipart/alternative; boundary="_000_a02101a18f16419f81233058a1a6de15usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=942 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050184 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=879 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050184 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 17:59:19 -0000 --_000_a02101a18f16419f81233058a1a6de15usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSdkIHByZWZlciBtYWtpbmcgaGFuZHNoYWtlIHBhY2tldHMgaW5kaXN0aW5ndWlzaGFi bGUgZnJvbSBzaG9ydCBoZWFkZXIgcGFja2V0cy4gSW4gZXNzZW5jZSwgeW91IG1vdmUgdGhlIGZs YWdzIG9mIHRoZSBsb25nIGhlYWRlciBpbnNpZGUgdGhlIEFFQUQtcHJvdGVjdGVkIGFyZWEuIEFu IGVuZHBvaW50IHRoYXQgcmVjZWl2ZXMgYSBwYWNrZXQgY2FycnlpbmcgYSBDSUQgdGhhdCBkb2Vz IG5vdCBiZWxvbmcgdG8gYW55IGtub3duIGNvbm5lY3Rpb24gdHJpYWwtZGVjcnlwdHMgdGhlIHBh Y2tldCBhcyBhIGluaXRpYWwgcGFja2V0IGFuZCBoYW5kbGVzIGl0IGFzIGEgY29ubmVjdGlvbiBp bml0aWF0aW9uLCBvciBzZW5kcyBhIHN0YXRlZnVsIHJlc2V0IGlmIHRoZSB0cmlhbC1kZWNyeXB0 aW9uIGZhaWxzLg0KVGhpcyBjaGFuZ2Ugd291bGQgd3JlY2sgc3RhdGVsZXNzIGxvYWQgYmFsYW5j ZXJzIHRoYXQgcmVseSBvbiBiZWluZyBhYmxlIHRvIGRpc3Rpbmd1aXNoIENJIHBhY2tldHMgKGFu ZCByb3V0ZSB0aGVtIGJhc2VkIG9uIElQcykgZnJvbSBvdGhlciBwYWNrZXRzIChhbmQgcm91dGUg dGhlbSBiYXNlZCBvbiBDSUQpLg0KDQotIElnb3INCg0KRnJvbTogTWlra2VsIEZhaG7DuGUgSsO4 cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBcHJp bCAwNSwgMjAxOCAxOjMxIFBNDQpUbzogTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJl PjsgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+OyBLYXp1aG8gT2t1IDxr YXp1aG9va3VAZ21haWwuY29tPg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1p cmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+OyBGcmVkZXJp Y2sgS2F1dHogPGZrYXV0ekBhbHVtbmkuY211LmVkdT4NClN1YmplY3Q6IFJFOiBQcml2YWN5IGhv bGVzICh3YXM6IFJlOiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5 cHRpb24pDQoNCkhpDQoNCg0KT24gNSBBcHJpbCAyMDE4IGF0IDE5LjI3LjI0LCBNaWtlIEJpc2hv cCAobWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPikgd3Jv dGU6DQoNCiBBbiBlbmRwb2ludCB0aGF0IHJlY2VpdmVzIGEgcGFja2V0IGNhcnJ5aW5nIGEgQ0lE IHRoYXQgZG9lcyBub3QgYmVsb25nIHRvIGFueSBrbm93biBjb25uZWN0aW9uIHRyaWFsLWRlY3J5 cHRzIHRoZSBwYWNrZXQgYXMgYSBpbml0aWFsIHBhY2tldCBhbmQgaGFuZGxlcyBpdCBhcyBhIGNv bm5lY3Rpb24gaW5pdGlhdGlvbiwgb3Igc2VuZHMgYSBzdGF0ZWZ1bCByZXNldCBpZiB0aGUgdHJp YWwtZGVjcnlwdGlvbiBmYWlscy4NCg0KSSBjYW4gc2VlIGhpZGluZyB0aGluZ3MgbWF5IGJlIGEg Z29vZCB0aGluZywgYnV0IGhhdmluZyB0byB0cmlhbCBkZWNyeXB0IGFsbCB1bmtub3duIHBhY2tl dHMgYXMgcG90ZW50aWFsbHkgY3JlYXRpbmcgYSBodWdlIGxvYWQsIHVubGVzcyB5b3UgY29tYmlu ZSBpdCB3aXRoIG15IHByb3Bvc2FsIHRvIGFkZCBhIGNoZWNrc3VtIHRvIHRoZSBlbmNyeXB0ZWQg cGFja2V0IG51bWJlciBzbyB5b3Ugb25seSBuZWVkIG9uZSBjcnlwdG8gYmxvY2sgb24gYXZlcmFn ZSB0byByZWplY3QgcmFuZG9tIHBhY2tldCBjb250ZW50Lg0KDQpJdCB3b27igJl0IHNvbHZlIGFs bCBERG9TLCBidXQgaXQgd2lsbCBoZWxwLiBGb3JjaW5nIHRyaWFsIGRlY3J5cHRpb24gZm8gdGhl IGZ1bGwgcGFja2V0IG1ha2VzIG1lIGEgYml0IGFueGlvdXMuDQoNCg0KDQpNaWtrZWwNCg0KDQo= --_000_a02101a18f16419f81233058a1a6de15usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2 Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLmFpcm1haWxv biwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1lOmFpcm1haWxf b247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLWNv bnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0K c3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NzAxMTI1 ODI1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMjQyMjMyMTY0O30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6MTg4MDE2NTcyODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk0NDA3MDIxMCAtNTYyMDA2NjQ2IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NjE3Ow0KCW1zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0 IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omwx IGxldmVsMSBsZm8zIj4NCkknZCBwcmVmZXIgbWFraW5nIGhhbmRzaGFrZSBwYWNrZXRzIGluZGlz dGluZ3Vpc2hhYmxlIGZyb20gc2hvcnQgaGVhZGVyIHBhY2tldHMuIEluIGVzc2VuY2UsIHlvdSBt b3ZlIHRoZSBmbGFncyBvZiB0aGUgbG9uZyBoZWFkZXIgaW5zaWRlIHRoZSBBRUFELXByb3RlY3Rl ZCBhcmVhLiBBbiBlbmRwb2ludCB0aGF0IHJlY2VpdmVzIGEgcGFja2V0IGNhcnJ5aW5nIGEgQ0lE IHRoYXQgZG9lcyBub3QgYmVsb25nIHRvIGFueSBrbm93biBjb25uZWN0aW9uDQogdHJpYWwtZGVj cnlwdHMgdGhlIHBhY2tldCBhcyBhIGluaXRpYWwgcGFja2V0IGFuZCBoYW5kbGVzIGl0IGFzIGEg Y29ubmVjdGlvbiBpbml0aWF0aW9uLCBvciBzZW5kcyBhIHN0YXRlZnVsIHJlc2V0IGlmIHRoZSB0 cmlhbC1kZWNyeXB0aW9uIGZhaWxzLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyBjaGFuZ2Ugd291bGQgd3JlY2sgc3RhdGVsZXNzIGxvYWQgYmFsYW5jZXJz IHRoYXQgcmVseSBvbiBiZWluZyBhYmxlIHRvIGRpc3Rpbmd1aXNoIENJIHBhY2tldHMgKGFuZCBy b3V0ZSB0aGVtIGJhc2VkIG9uIElQcykgZnJvbSBvdGhlciBwYWNrZXRzIChhbmQgcm91dGUgdGhl bSBiYXNlZCBvbiBDSUQpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIElnb3I8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86bWlra2VsZmpAZ21haWwuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAwNSwgMjAxOCAxOjMxIFBNPGJy Pg0KPGI+VG86PC9iPiBNaWtlIEJpc2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUmZ3Q7OyBD aHJpc3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs7IEthenVobyBPa3Ug Jmx0O2thenVob29rdUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0cg Jmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBNaXJqYSBLw7xobGV3aW5kICZsdDttaXJqYS5rdWVobGV3 aW5kQHRpay5lZS5ldGh6LmNoJmd0OzsgRnJlZGVyaWNrIEthdXR6ICZsdDtma2F1dHpAYWx1bW5p LmNtdS5lZHUmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBQcml2YWN5IGhvbGVzICh3YXM6 IFJlOiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24pPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5IaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJhaXJtYWlsb24iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5PbiA1IEFwcmlsIDIwMTggYXQgMTkuMjcuMjQsIE1pa2UgQmlzaG9wICg8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWJpc2hv cEBldmVxdWVmb3UuYmU8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4pDQogd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2ZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QW4gZW5kcG9pbnQg dGhhdCByZWNlaXZlcyBhIHBhY2tldCBjYXJyeWluZyBhIENJRCB0aGF0IGRvZXMgbm90IGJlbG9u ZyB0byBhbnkga25vd24gY29ubmVjdGlvbiB0cmlhbC1kZWNyeXB0cyB0aGUgcGFja2V0IGFzIGEg aW5pdGlhbCBwYWNrZXQgYW5kIGhhbmRsZXMgaXQNCiBhcyBhIGNvbm5lY3Rpb24gaW5pdGlhdGlv biwgb3Igc2VuZHMgYSBzdGF0ZWZ1bCByZXNldCBpZiB0aGUgdHJpYWwtZGVjcnlwdGlvbiBmYWls cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5JIGNhbiBzZWUgaGlkaW5nIHRoaW5ncyBtYXkgYmUgYSBnb29kIHRoaW5n LCBidXQgaGF2aW5nIHRvIHRyaWFsIGRlY3J5cHQgYWxsIHVua25vd24gcGFja2V0cyBhcyBwb3Rl bnRpYWxseSBjcmVhdGluZyBhIGh1Z2UgbG9hZCwgdW5sZXNzIHlvdSBjb21iaW5lIGl0IHdpdGgg bXkgcHJvcG9zYWwgdG8gYWRkIGEgY2hlY2tzdW0gdG8NCiB0aGUgZW5jcnlwdGVkIHBhY2tldCBu dW1iZXIgc28geW91IG9ubHkgbmVlZCBvbmUgY3J5cHRvIGJsb2NrIG9uIGF2ZXJhZ2UgdG8gcmVq ZWN0IHJhbmRvbSBwYWNrZXQgY29udGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+SXQgd29u4oCZdCBzb2x2ZSBhbGwgRERvUywgYnV0IGl0IHdpbGwgaGVs cC4gRm9yY2luZyB0cmlhbCBkZWNyeXB0aW9uIGZvIHRoZSBmdWxsIHBhY2tldCBtYWtlcyBtZSBh IGJpdCBhbnhpb3VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TWlr a2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_a02101a18f16419f81233058a1a6de15usma1exdag1mb5msgcorpak_-- From nobody Thu Apr 5 11:09:19 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE79126C22 for ; Thu, 5 Apr 2018 11:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5TLzzX9JPrP for ; Thu, 5 Apr 2018 11:09:14 -0700 (PDT) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501A6126BF6 for ; Thu, 5 Apr 2018 11:09:14 -0700 (PDT) Received: by mail-pl0-x22c.google.com with SMTP id s24-v6so20267162plq.6 for ; Thu, 05 Apr 2018 11: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=Ac8fH6k6vle/u5E5stQMJb9xPHDsiKvxXXjD0IL5Jd4=; b=LQKjfxavHOyuQnL/AmSMg4WWgv4dHU/9ZEXov26/fmUfIGyGxiF2tTKXE6XChtJVFp 8al6i2FTPhU5ici7bn1xc5BDn7VNr3OQQiQxN6ieSE5zExg1rK46GeSbdhvx18+ES/jO 9UzKoM0wops+TaB1KvRZd5hpWrsPhwniHIAJmx4iiEISgcqmp/+sgBhTnajFX4rZvOZe KMYneb0C7ui3oGdw3yvSQB62QoGkGoA84GvhzAgI2fcbAvB6LhmToOO3cWyifq3yVVj9 4ek+PAfNupZW4yVs39e+h/9zPyorm4SCu9IcPfUV6itnYhYYr7wS5VveRO4Cp7F43VQi SEOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=Ac8fH6k6vle/u5E5stQMJb9xPHDsiKvxXXjD0IL5Jd4=; b=QJUdqnlMZRKiYEYTi7Ol2WAg4BYkI4tfkTw9T7cy+G62YVq3xGlEEedCHAXFz1Y0jd nOQVFky/us8AAwsJOjl3Rf6nTjqyr8OXMXzzlrSf38nXw0zaXAo2S2h4PCu55dnv8AQP WI/AlM8A3fufTRaHmDU6BV0GgmMh5NQD/N/v/awUJAE4Q3NJV/pLfPZcIuMB1abFX9pd l4Gb/qfN3zBjVJ5J7I9i1Qbq6sSAk8BggWZpFrTpyfhmiFbV+m6euFOAqCXP1pEQ+6qg JxpZIcCjx45bTT9L5BngaBxxNk4Yec2epmAymodSAQcCytoYRjGs3MCsO+Pkut9/kFz7 bk6w== X-Gm-Message-State: AElRT7GTOdvYm8zdRhwSepWrN/N2w8l/08MTX/sOiRhgVprg+l+s5HQK UupjxcyUA38A/k1vHymLL3QRTEoM8e6olctGEa8= X-Google-Smtp-Source: AIpwx49MfG8W0dQgomEgBdK3/yNVuy/UzLlxBAWikL2vuayW1nqsg/6bCwfPvQGAEUP6vZ8Nh27S434VMXm4S6SwvGA= X-Received: by 2002:a17:902:bd91:: with SMTP id q17-v6mr22055641pls.330.1522951753957; Thu, 05 Apr 2018 11:09:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Thu, 5 Apr 2018 11:09:13 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Kazuho Oku Date: Fri, 6 Apr 2018 03:09:13 +0900 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: "Lubashev, Igor" Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Mike Bishop , Christian Huitema , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Frederick Kautz Content-Type: multipart/alternative; boundary="0000000000004e045a05691dd634" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 18:09:16 -0000 --0000000000004e045a05691dd634 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-04-06 2:59 GMT+09:00 Lubashev, Igor : > > - I'd prefer making handshake packets indistinguishable from short > header packets. In essence, you move the flags of the long header insi= de > the AEAD-protected area. An endpoint that receives a packet carrying a= CID > that does not belong to any known connection trial-decrypts the packet= as a > initial packet and handles it as a connection initiation, or sends a > stateful reset if the trial-decryption fails. > > This change would wreck stateless load balancers that rely on being able > to distinguish CI packets (and route them based on IPs) from other packet= s > (and route them based on CID). > It would not, *if* the stateless load balancer can AES-decrypt the packet (using the key derived from the packet header) to see if the packet is in fact a initial packet. Or another way of solving the issue will be to always route the packet based on CID, then forward the packet between the endpoints behind the load balancer. I agree that it would be a no-deal for stateless load balancers that are incapable of doing such things. > > > - Igor > > > > *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] > *Sent:* Thursday, April 05, 2018 1:31 PM > *To:* Mike Bishop ; Christian Huitema < > huitema@huitema.net>; Kazuho Oku > *Cc:* IETF QUIC WG ; Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch>; Frederick Kautz > *Subject:* RE: Privacy holes (was: Re: Getting to consensus on packet > number encryption) > > > > Hi > > > > On 5 April 2018 at 19.27.24, Mike Bishop (mbishop@evequefou.be) wrote: > > An endpoint that receives a packet carrying a CID that does not belong > to any known connection trial-decrypts the packet as a initial packet and > handles it as a connection initiation, or sends a stateful reset if the > trial-decryption fails. > > I can see hiding things may be a good thing, but having to trial decrypt > all unknown packets as potentially creating a huge load, unless you combi= ne > it with my proposal to add a checksum to the encrypted packet number so y= ou > only need one crypto block on average to reject random packet content. > > It won=E2=80=99t solve all DDoS, but it will help. Forcing trial decrypti= on fo the > full packet makes me a bit anxious. > > > > Mikkel > > > --=20 Kazuho Oku --0000000000004e045a05691dd634 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-04-06 2:59 GMT+09:00 Lubashev, Igor <ilubashe@akamai.com&g= t;:
  • I'd prefer making handshake packets indistinguishable from short header= packets. In essence, you move the flags of the long header inside the AEAD= -protected area. An endpoint that receives a packet carrying a CID that doe= s not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connecti= on initiation, or sends a stateful reset if the trial-decryption fails.<= /u>

This change would wreck stateless load balancers tha= t rely on being able to distinguish CI packets (and route them based on IPs= ) from other packets (and route them based on CID).


It would not, *if* the stateless load balancer can= AES-decrypt the packet (using the key derived from the packet header) to s= ee if the packet is in fact a initial packet. Or another way of solving the= issue will be to always route the packet based on CID, then forward the pa= cket between the endpoints behind the load balancer.

I agree that it would be a no-deal for stateless load balancers that are= incapable of doing such things.
=C2=A0

<= /p>

=C2=A0

- Igor

=C2=A0

From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mail= to:mikkelfj@gmail.c= om]
Sent: Thursday, April 05, 2018 1:31 PM
To: Mike Bishop <mbishop@evequefou.be>; Christian Huitema <huitema@huitema.net>; = Kazuho Oku <kaz= uhooku@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>; Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.= ch>; Frederick Kautz <fkautz@alumni.cmu.edu>
Subject: RE: Privacy holes (was: Re: Getting to consensus on = packet number encryption)

=C2=A0

Hi

=C2=A0

On 5 April 2018 at 19.27.24= , Mike Bishop (mbishop@evequefou.be) wrote:

=C2=A0An endpoint th= at receives a packet carrying a CID that does not belong to any known conne= ction trial-decrypts the packet as a initial packet and handles it as a connection initiation, or sends a stateful reset if the trial-decrypt= ion fails.

I can see hiding things may be a good thing, but having to trial decr= ypt all unknown packets as potentially creating a huge load, unless you com= bine it with my proposal to add a checksum to the encrypted packet number so you only need one crypto block on average t= o reject random packet content.

It won=E2=80=99t solve all DDoS, but it will help. Forcing trial decr= yption fo the full packet makes me a bit anxious.

=C2=A0

Mikkel

=C2=A0




--
Kazuho Oku
--0000000000004e045a05691dd634-- From nobody Thu Apr 5 11:14:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5094912AAB6 for ; Thu, 5 Apr 2018 11:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKOzELSga-KV for ; Thu, 5 Apr 2018 11:14:01 -0700 (PDT) Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::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 8B18D126BF6 for ; Thu, 5 Apr 2018 11:14:01 -0700 (PDT) Received: by mail-pl0-x22d.google.com with SMTP id 61-v6so18318743plb.2 for ; Thu, 05 Apr 2018 11:14: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=Td3lCZVz1fu93p1nlGIvbZaTNGDRitEsqtWRKfJf5dk=; b=WM9ylGi3LmHzg4cgITlTMT0/Ksm07aBOnTDabhcqD8ZdyaxPnpAeaJ5I8VgrYjOLJi 5Ib4eFU5kl+G8oJBRusdDLBI/+o1hqBkoRCCcC3WOhP3dii4fT8I/x70QR+tFKxe3ngw 1F9Yz6FUWtuli0zO1Re/bQzf5vwl+F/g7hGBhcEcOisolGVYTOkKQ693wrwfwVy1pW49 9wgxBGX6GBRlYVnsSOmbcAH01cD7EBP3XE7H/CBo8N6opRzROF49rr50yvt0+5TyVfLx q4oiyMVIEoxBFULLeZx+4ZllGb3u3Q6sx5f3nPjNVkKnaVvWLdG5SPkeqEIOCAR7phuO pLkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=Td3lCZVz1fu93p1nlGIvbZaTNGDRitEsqtWRKfJf5dk=; b=ohPv4g/54AKfJwkW/7sTelRb/iLm++4a1YdYae/H1Fw0Ln9MsxS98j2vtaz0q1hWBu vP1f8lLlov7w+D6bVLiyDIYftigfay1c5yQnH5W5dOoYNGZSgm8oEIXyKgb/eOAqR1Tq z2gjQWXZckG0UMIWtXK4nyMz8+eN2Yvqlg0fhM8/q5MYgwSvkZ/tIbNrvn3HLM0OFTgh adDeh2fGMxW24lfYYmEAoZM7oOB3ZD1qKVLEN7bxujeqz5tRY7nn7U+wl5d1zMol3AJK d6O120iheDkzMVZ3AJ5eboV7foMazcHXru87EwEws7dJtsPUkJriNEGiqbHlWCUIhvh1 zY9Q== X-Gm-Message-State: AElRT7FomwC5jyh/pZ6xg4elwPNAgucCvTg1ReEYPcgmustjRX53IwDb IlokPUiGsYLLfm5g5REtgFZs/HRLzftbZtAih5A= X-Google-Smtp-Source: AIpwx4/YikEJc6NglTcxrEQWzQOBYspNLqsZxiecQsapvPKn/aIJ/QfnzUPL3tC6LM5KmBSwU5YB+QOE2/lAgLbbayw= X-Received: by 2002:a17:902:52a4:: with SMTP id a33-v6mr16895306pli.371.1522952041211; Thu, 05 Apr 2018 11:14:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Thu, 5 Apr 2018 11:14:00 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Kazuho Oku Date: Fri, 6 Apr 2018 03:14:00 +0900 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: "Lubashev, Igor" Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Mike Bishop , Christian Huitema , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Frederick Kautz Content-Type: multipart/alternative; boundary="0000000000006d2fe105691de7f7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 18:14:03 -0000 --0000000000006d2fe105691de7f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-04-06 3:09 GMT+09:00 Kazuho Oku : > > > 2018-04-06 2:59 GMT+09:00 Lubashev, Igor : > >> >> - I'd prefer making handshake packets indistinguishable from short >> header packets. In essence, you move the flags of the long header ins= ide >> the AEAD-protected area. An endpoint that receives a packet carrying = a CID >> that does not belong to any known connection trial-decrypts the packe= t as a >> initial packet and handles it as a connection initiation, or sends a >> stateful reset if the trial-decryption fails. >> >> This change would wreck stateless load balancers that rely on being able >> to distinguish CI packets (and route them based on IPs) from other packe= ts >> (and route them based on CID). >> > > It would not, *if* the stateless load balancer can AES-decrypt the packet > (using the key derived from the packet header) to see if the packet is in > fact a initial packet. Or another way of solving the issue will be to > always route the packet based on CID, then forward the packet between the > endpoints behind the load balancer. > > I agree that it would be a no-deal for stateless load balancers that are > incapable of doing such things. > > PS. Note that the purpose of AES-encrypting the handshake packets is purely for obfuscation. It might be worth considering changing it to some snake-oil scrambling scheme if it helps stateless load balancer adopt the proposed scheme. > >> >> - Igor >> >> >> >> *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] >> *Sent:* Thursday, April 05, 2018 1:31 PM >> *To:* Mike Bishop ; Christian Huitema < >> huitema@huitema.net>; Kazuho Oku >> *Cc:* IETF QUIC WG ; Mirja K=C3=BChlewind < >> mirja.kuehlewind@tik.ee.ethz.ch>; Frederick Kautz >> *Subject:* RE: Privacy holes (was: Re: Getting to consensus on packet >> number encryption) >> >> >> >> Hi >> >> >> >> On 5 April 2018 at 19.27.24, Mike Bishop (mbishop@evequefou.be) wrote: >> >> An endpoint that receives a packet carrying a CID that does not belong >> to any known connection trial-decrypts the packet as a initial packet an= d >> handles it as a connection initiation, or sends a stateful reset if the >> trial-decryption fails. >> >> I can see hiding things may be a good thing, but having to trial decrypt >> all unknown packets as potentially creating a huge load, unless you comb= ine >> it with my proposal to add a checksum to the encrypted packet number so = you >> only need one crypto block on average to reject random packet content. >> >> It won=E2=80=99t solve all DDoS, but it will help. Forcing trial decrypt= ion fo >> the full packet makes me a bit anxious. >> >> >> >> Mikkel >> >> >> > > > > -- > Kazuho Oku > --=20 Kazuho Oku --0000000000006d2fe105691de7f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-04-06 3:09 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com>:


2018-04-06 2:5= 9 GMT+09:00 Lubashev, Igor <ilubashe@akamai.com>:
  • I'd prefer making handshake packets indistinguishable from short header= packets. In essence, you move the flags of the long header inside the AEAD= -protected area. An endpoint that receives a packet carrying a CID that doe= s not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connecti= on initiation, or sends a stateful reset if the trial-decryption fails.<= /u>

This change would wreck stateless load balancers tha= t rely on being able to distinguish CI packets (and route them based on IPs= ) from other packets (and route them based on CID).


It would not, *if* the stateless load balan= cer can AES-decrypt the packet (using the key derived from the packet heade= r) to see if the packet is in fact a initial packet. Or another way of solv= ing the issue will be to always route the packet based on CID, then forward= the packet between the endpoints behind the load balancer.

<= /div>
I agree that it would be a no-deal for stateless load balancers t= hat are incapable of doing such things.
=C2=A0

PS. Note that= the purpose of AES-encrypting the handshake packets is purely for obfuscat= ion. It might be worth considering changing it to some snake-oil scrambling= scheme if it helps stateless load balancer adopt the proposed scheme.
=C2=A0

=C2=A0

- Igor

=C2=A0

From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mail= to:mikkelfj@gmail.c= om]
Sent: Thursday, April 05, 2018 1:31 PM
To: Mike Bishop <mbishop@evequefou.be>; Christian Huitema <huitema@huitema.net>; = Kazuho Oku <kaz= uhooku@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>; Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.= ch>; Frederick Kautz <fkautz@alumni.cmu.edu>
Subject: RE: Privacy holes (was: Re: Getting to consensus on = packet number encryption)

=C2=A0

Hi

=C2=A0

On 5 = April 2018 at 19.27.24, Mike Bishop (mbishop@evequefou.be) wrote:

=C2=A0An endpoint that receives a packet carrying a CID that does not bel= ong to any known connection trial-decrypts the packet as a initial packet a= nd handles it as a connection initiation, or sends a stateful reset if the trial-decrypt= ion fails.

I can see hiding things may be a good thing, but having to trial decr= ypt all unknown packets as potentially creating a huge load, unless you com= bine it with my proposal to add a checksum to the encrypted packet number so you only need one crypto block on average t= o reject random packet content.

It won=E2=80=99t solve all DDoS, but it will help. Forcing trial decr= yption fo the full packet makes me a bit anxious.

=C2=A0

Mikkel

=C2=A0



--
Kazuho Oku



--
Kazuho Oku
--0000000000006d2fe105691de7f7-- From nobody Thu Apr 5 11:19:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691E312AF84 for ; Thu, 5 Apr 2018 11:19:29 -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 (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 9PSWIh1PozBt for ; Thu, 5 Apr 2018 11:19:26 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0120.outbound.protection.outlook.com [104.47.32.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47203129C6D for ; Thu, 5 Apr 2018 11:19:26 -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=1W8g4r2tTiZki7j+KI6RWstYibwM6cMo8YYtEzC28HM=; b=Tnb0TW7skqAri7JjM6+YhNmtuGqCIAw+9csXReu4pesKym1Xr334E4Yl8e2yGCh9+tR3mur8rO/DP4mxoTtsJdA85KdCxTRimqrzsX/sCu3UGJWbCtpe4GgSvh1vfWbQXUINMyQtugOXPSD+ktNOovK0297P1wne3nRC5ErwTwE= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0856.namprd21.prod.outlook.com (10.173.192.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Thu, 5 Apr 2018 18:19:23 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Thu, 5 Apr 2018 18:19:23 +0000 From: Praveen Balasubramanian To: Kazuho Oku , "Lubashev, Igor" CC: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , huitema , Mike Bishop , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , IETF QUIC WG , Frederick Kautz Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Index: AQHTzPOfhJMCgvyw60+hsX7hCsq0T6PyVBsAgAACsgCAABOkAIAAAk8AgAABDICAAAfeAIAAAtaAgAACq3A= Date: Thu, 5 Apr 2018 18:19:22 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0856; 7:O4CDZHK1AprjHOvFt+JcBYR0LoiErigUIjm+aTZKbGkNk0m3ycDphPcv74uItMPmAfLJxJriF/w47S+UtJBryEAYKNYZcj/QiKkOu7drkLsO1Jtm1oq+xm6toB/ngS7rZq+sK5KhHCPQwkMX1n+r+vLSWEMwEl7F7ueGTCwzGo+symxP+SeybLQoyQFDCYSfMmFMEoEhv1k1qC01ubu7vam4fXTTWFc2mmCphDAnTsMW58gVL08BoRteJg6chAtG; 20:/7SEgdmdm+jHctUtqvWkKTpNS/sJMfgjTpGUrgAikXCLaRzDNX5meseS87JBTR3PLebaF+ORXItW/DCt/I/JVoHLq8D4t+kUPzPqxYwTwYw4MDKHQ2jrlKfiAwXNyN8+Lw4zix1jEKTPWpS5X5Jlg3btsY66TtD8Bz53bRdgXRM= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7cd69645-838d-4fe2-e221-08d59b21c1d8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0856; x-ms-traffictypediagnostic: CY4PR21MB0856: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(100405760836317)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(10201501046)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0856; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0856; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(39380400002)(376002)(396003)(346002)(199004)(189003)(377424004)(8990500004)(6506007)(2900100001)(110136005)(54906003)(46003)(476003)(93886005)(5660300001)(14454004)(11346002)(2906002)(5250100002)(105586002)(7736002)(86362001)(478600001)(74316002)(102836004)(53546011)(486006)(19609705001)(186003)(86612001)(68736007)(8676002)(97736004)(81156014)(22452003)(76176011)(39060400002)(3280700002)(8936002)(446003)(25786009)(81166006)(10090500001)(6246003)(561944003)(106356001)(55016002)(54896002)(790700001)(3660700001)(6306002)(6116002)(53936002)(6436002)(316002)(9686003)(236005)(10290500003)(229853002)(99286004)(33656002)(7696005)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0856; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: X3aJN7jQtL9jZkaXb+iwsMtMVhE2NJ1jPIi27GTEUJ4gqPstcGpbZ4zk/fABxVf8Z+wtaviFyDhYql33uwcZd8lfIvXR/8C9etDFE569y0yiYB+V3FqZ38Rc7RSZtbXHrAJRW/xGIoSLXK+4EmM3o8uhvZ8NO6/tQa5F05L6HQaQfBKfT60jPlzREm9Qblhhs+8I2k/ArdBdAA6TwehguIgBjCN6b14k3NYzDskG6sG41iOmL/axCiRMR14+EYhEz7mDUflkF8/DYzZ2/B+CI1I3+YB9C/0ewqqppV1vLJutvRKPwkndCLcYGqexCbkQzAb9UYtwHEFJzLPX3bmSXp9czrA0Uqwd1XmwIG2LpjWd2NChOf49fr/ckc1Zp5TjLT6DotOLEB6d9k0/qS0Q2K+Y3TPrN3ptf0febdEyGdk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630BF7EC130BD8987C8CE11B6BB0CY4PR21MB0630namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7cd69645-838d-4fe2-e221-08d59b21c1d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 18:19:22.9334 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0856 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 18:19:29 -0000 --_000_CY4PR21MB0630BF7EC130BD8987C8CE11B6BB0CY4PR21MB0630namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SU1PIHdlIHNob3VsZCBub3QgaGF2ZSBhIGRlc2lnbiB0aGF0IGZvcmNlcyBsb2FkIGJhbGFuY2Vy cyB0byBkZWNyeXB0Lg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgS2F6dWhvIE9rdQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDUsIDIwMTgg MTE6MDkgQU0NClRvOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT4NCkNjOiBN aXJqYSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPjsgaHVpdGVt YSA8aHVpdGVtYUBodWl0ZW1hLm5ldD47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5i ZT47IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT47IElFVEYg UVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IEZyZWRlcmljayBLYXV0eiA8ZmthdXR6QGFsdW1uaS5j bXUuZWR1Pg0KU3ViamVjdDogUmU6IFByaXZhY3kgaG9sZXMgKHdhczogUmU6IEdldHRpbmcgdG8g Y29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbikNCg0KDQoNCjIwMTgtMDQtMDYg Mjo1OSBHTVQrMDk6MDAgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRv OmlsdWJhc2hlQGFrYW1haS5jb20+PjoNCg0KICAqICAgSSdkIHByZWZlciBtYWtpbmcgaGFuZHNo YWtlIHBhY2tldHMgaW5kaXN0aW5ndWlzaGFibGUgZnJvbSBzaG9ydCBoZWFkZXIgcGFja2V0cy4g SW4gZXNzZW5jZSwgeW91IG1vdmUgdGhlIGZsYWdzIG9mIHRoZSBsb25nIGhlYWRlciBpbnNpZGUg dGhlIEFFQUQtcHJvdGVjdGVkIGFyZWEuIEFuIGVuZHBvaW50IHRoYXQgcmVjZWl2ZXMgYSBwYWNr ZXQgY2FycnlpbmcgYSBDSUQgdGhhdCBkb2VzIG5vdCBiZWxvbmcgdG8gYW55IGtub3duIGNvbm5l Y3Rpb24gdHJpYWwtZGVjcnlwdHMgdGhlIHBhY2tldCBhcyBhIGluaXRpYWwgcGFja2V0IGFuZCBo YW5kbGVzIGl0IGFzIGEgY29ubmVjdGlvbiBpbml0aWF0aW9uLCBvciBzZW5kcyBhIHN0YXRlZnVs IHJlc2V0IGlmIHRoZSB0cmlhbC1kZWNyeXB0aW9uIGZhaWxzLg0KVGhpcyBjaGFuZ2Ugd291bGQg d3JlY2sgc3RhdGVsZXNzIGxvYWQgYmFsYW5jZXJzIHRoYXQgcmVseSBvbiBiZWluZyBhYmxlIHRv IGRpc3Rpbmd1aXNoIENJIHBhY2tldHMgKGFuZCByb3V0ZSB0aGVtIGJhc2VkIG9uIElQcykgZnJv bSBvdGhlciBwYWNrZXRzIChhbmQgcm91dGUgdGhlbSBiYXNlZCBvbiBDSUQpLg0KDQpJdCB3b3Vs ZCBub3QsICppZiogdGhlIHN0YXRlbGVzcyBsb2FkIGJhbGFuY2VyIGNhbiBBRVMtZGVjcnlwdCB0 aGUgcGFja2V0ICh1c2luZyB0aGUga2V5IGRlcml2ZWQgZnJvbSB0aGUgcGFja2V0IGhlYWRlcikg dG8gc2VlIGlmIHRoZSBwYWNrZXQgaXMgaW4gZmFjdCBhIGluaXRpYWwgcGFja2V0LiBPciBhbm90 aGVyIHdheSBvZiBzb2x2aW5nIHRoZSBpc3N1ZSB3aWxsIGJlIHRvIGFsd2F5cyByb3V0ZSB0aGUg cGFja2V0IGJhc2VkIG9uIENJRCwgdGhlbiBmb3J3YXJkIHRoZSBwYWNrZXQgYmV0d2VlbiB0aGUg ZW5kcG9pbnRzIGJlaGluZCB0aGUgbG9hZCBiYWxhbmNlci4NCg0KSSBhZ3JlZSB0aGF0IGl0IHdv dWxkIGJlIGEgbm8tZGVhbCBmb3Igc3RhdGVsZXNzIGxvYWQgYmFsYW5jZXJzIHRoYXQgYXJlIGlu Y2FwYWJsZSBvZiBkb2luZyBzdWNoIHRoaW5ncy4NCg0KDQotIElnb3INCg0KRnJvbTogTWlra2Vs IEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlr a2VsZmpAZ21haWwuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNSwgMjAxOCAxOjMxIFBN DQpUbzogTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzptYmlzaG9wQGV2 ZXF1ZWZvdS5iZT4+OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWls dG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+OyBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29t PG1haWx0bzprYXp1aG9va3VAZ21haWwuY29tPj4NCkNjOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0 Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PjsgTWlyamEgS8O8aGxld2luZCA8bWlyamEua3Vl aGxld2luZEB0aWsuZWUuZXRoei5jaDxtYWlsdG86bWlyamEuLmt1ZWhsZXdpbmRAdGlrLmVlLmV0 aHouY2g+PjsgRnJlZGVyaWNrIEthdXR6IDxma2F1dHpAYWx1bW5pLmNtdS5lZHU8bWFpbHRvOmZr YXV0ekBhbHVtbmkuY211LmVkdT4+DQpTdWJqZWN0OiBSRTogUHJpdmFjeSBob2xlcyAod2FzOiBS ZTogR2V0dGluZyB0byBjb25zZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uKQ0KDQpI aQ0KDQoNCk9uIDUgQXByaWwgMjAxOCBhdCAxOS4yNy4yNCwgTWlrZSBCaXNob3AgKG1iaXNob3BA ZXZlcXVlZm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4pIHdyb3RlOg0KDQogQW4g ZW5kcG9pbnQgdGhhdCByZWNlaXZlcyBhIHBhY2tldCBjYXJyeWluZyBhIENJRCB0aGF0IGRvZXMg bm90IGJlbG9uZyB0byBhbnkga25vd24gY29ubmVjdGlvbiB0cmlhbC1kZWNyeXB0cyB0aGUgcGFj a2V0IGFzIGEgaW5pdGlhbCBwYWNrZXQgYW5kIGhhbmRsZXMgaXQgYXMgYSBjb25uZWN0aW9uIGlu aXRpYXRpb24sIG9yIHNlbmRzIGEgc3RhdGVmdWwgcmVzZXQgaWYgdGhlIHRyaWFsLWRlY3J5cHRp b24gZmFpbHMuDQoNCkkgY2FuIHNlZSBoaWRpbmcgdGhpbmdzIG1heSBiZSBhIGdvb2QgdGhpbmcs IGJ1dCBoYXZpbmcgdG8gdHJpYWwgZGVjcnlwdCBhbGwgdW5rbm93biBwYWNrZXRzIGFzIHBvdGVu dGlhbGx5IGNyZWF0aW5nIGEgaHVnZSBsb2FkLCB1bmxlc3MgeW91IGNvbWJpbmUgaXQgd2l0aCBt eSBwcm9wb3NhbCB0byBhZGQgYSBjaGVja3N1bSB0byB0aGUgZW5jcnlwdGVkIHBhY2tldCBudW1i ZXIgc28geW91IG9ubHkgbmVlZCBvbmUgY3J5cHRvIGJsb2NrIG9uIGF2ZXJhZ2UgdG8gcmVqZWN0 IHJhbmRvbSBwYWNrZXQgY29udGVudC4NCg0KSXQgd29u4oCZdCBzb2x2ZSBhbGwgRERvUywgYnV0 IGl0IHdpbGwgaGVscC4gRm9yY2luZyB0cmlhbCBkZWNyeXB0aW9uIGZvIHRoZSBmdWxsIHBhY2tl dCBtYWtlcyBtZSBhIGJpdCBhbnhpb3VzLg0KDQoNCg0KTWlra2VsDQoNCg0KDQoNCg0KLS0NCkth enVobyBPa3UNCg== --_000_CY4PR21MB0630BF7EC130BD8987C8CE11B6BB0CY4PR21MB0630namp_ 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 emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubS02MzUx MTQwNDUxNzE2MzYzNzc1YWlybWFpbG9uLCBsaS5tLTYzNTExNDA0NTE3MTYzNjM3NzVhaXJtYWls b24sIGRpdi5tLTYzNTExNDA0NTE3MTYzNjM3NzVhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6 bV8tNjM1MTE0MDQ1MTcxNjM2Mzc3NWFpcm1haWxvbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubS02MzUxMTQwNDUxNzE2MzYzNzc1bXNvcGxhaW50ZXh0LCBsaS5t LTYzNTExNDA0NTE3MTYzNjM3NzVtc29wbGFpbnRleHQsIGRpdi5tLTYzNTExNDA0NTE3MTYzNjM3 NzVtc29wbGFpbnRleHQNCgl7bXNvLXN0eWxlLW5hbWU6bV8tNjM1MTE0MDQ1MTcxNjM2Mzc3NW1z b3BsYWludGV4dDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u bS02MzUxMTQwNDUxNzE2MzYzNzc1YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1u YW1lOm1fLTYzNTExNDA0NTE3MTYzNjM3NzVhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6MTQzODcxNTA4OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTYyODQ2MzEy NDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JTU8gd2Ugc2hvdWxkIG5vdCBoYXZlIGEgZGVzaWduIHRoYXQgZm9yY2VzIGxvYWQgYmFs YW5jZXJzIHRvIGRlY3J5cHQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+ IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9i PkthenVobyBPa3U8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDUsIDIwMTggMTE6 MDkgQU08YnI+DQo8Yj5Ubzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDtpbHViYXNoZUBha2FtYWku Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWlyamEgS8O8aGxld2luZCAmbHQ7bWlyamEua3VlaGxl d2luZEB0aWsuZWUuZXRoei5jaCZndDs7IGh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQm Z3Q7OyBNaWtlIEJpc2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUmZ3Q7OyBNaWtrZWwgRmFo bsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cg Jmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBGcmVkZXJpY2sgS2F1dHogJmx0O2ZrYXV0ekBhbHVtbmku Y211LmVkdSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFByaXZhY3kgaG9sZXMgKHdhczog UmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbik8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjIwMTgtMDQtMDYgMjo1OSBHTVQmIzQzOzA5OjAwIEx1YmFzaGV2LCBJ Z29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSSdkIHByZWZlciBtYWtpbmcgaGFuZHNoYWtl IHBhY2tldHMgaW5kaXN0aW5ndWlzaGFibGUgZnJvbSBzaG9ydCBoZWFkZXIgcGFja2V0cy4gSW4g ZXNzZW5jZSwgeW91IG1vdmUgdGhlIGZsYWdzIG9mIHRoZSBsb25nIGhlYWRlciBpbnNpZGUgdGhl IEFFQUQtcHJvdGVjdGVkIGFyZWEuIEFuIGVuZHBvaW50IHRoYXQgcmVjZWl2ZXMgYSBwYWNrZXQg Y2FycnlpbmcgYSBDSUQgdGhhdCBkb2VzIG5vdCBiZWxvbmcgdG8gYW55IGtub3duIGNvbm5lY3Rp b24NCiB0cmlhbC1kZWNyeXB0cyB0aGUgcGFja2V0IGFzIGEgaW5pdGlhbCBwYWNrZXQgYW5kIGhh bmRsZXMgaXQgYXMgYSBjb25uZWN0aW9uIGluaXRpYXRpb24sIG9yIHNlbmRzIGEgc3RhdGVmdWwg cmVzZXQgaWYgdGhlIHRyaWFsLWRlY3J5cHRpb24gZmFpbHMuPG86cD48L286cD48L2xpPjwvdWw+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgY2hhbmdlIHdvdWxkIHdyZWNrIHN0YXRlbGVz cyBsb2FkIGJhbGFuY2VycyB0aGF0IHJlbHkgb24gYmVpbmcgYWJsZSB0byBkaXN0aW5ndWlzaCBD SSBwYWNrZXRzIChhbmQgcm91dGUgdGhlbSBiYXNlZCBvbiBJUHMpIGZyb20gb3RoZXIgcGFja2V0 cyAoYW5kIHJvdXRlIHRoZW0gYmFzZWQgb24gQ0lEKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3 b3VsZCBub3QsICppZiogdGhlIHN0YXRlbGVzcyBsb2FkIGJhbGFuY2VyIGNhbiBBRVMtZGVjcnlw dCB0aGUgcGFja2V0ICh1c2luZyB0aGUga2V5IGRlcml2ZWQgZnJvbSB0aGUgcGFja2V0IGhlYWRl cikgdG8gc2VlIGlmIHRoZSBwYWNrZXQgaXMgaW4gZmFjdCBhIGluaXRpYWwgcGFja2V0LiBPciBh bm90aGVyIHdheSBvZiBzb2x2aW5nIHRoZSBpc3N1ZSB3aWxsIGJlIHRvIGFsd2F5cyByb3V0ZSB0 aGUgcGFja2V0DQogYmFzZWQgb24gQ0lELCB0aGVuIGZvcndhcmQgdGhlIHBhY2tldCBiZXR3ZWVu IHRoZSBlbmRwb2ludHMgYmVoaW5kIHRoZSBsb2FkIGJhbGFuY2VyLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoYXQgaXQgd291 bGQgYmUgYSBuby1kZWFsIGZvciBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlcnMgdGhhdCBhcmUgaW5j YXBhYmxlIG9mIGRvaW5nIHN1Y2ggdGhpbmdzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gSWdvcjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206 PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1p a2tlbGZqQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT5d DQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDA1LCAyMDE4IDE6MzEgUE08YnI+ DQo8Yj5Ubzo8L2I+IE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVx dWVmb3UuYmUiIHRhcmdldD0iX2JsYW5rIj5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7OyBD aHJpc3RpYW4gSHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQi IHRhcmdldD0iX2JsYW5rIj5odWl0ZW1hQGh1aXRlbWEubmV0PC9hPiZndDs7IEthenVobyBPa3Ug Jmx0OzxhIGhyZWY9Im1haWx0bzprYXp1aG9va3VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ a2F6dWhvb2t1QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0cg Jmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0Bp ZXRmLm9yZzwvYT4mZ3Q7OyBNaXJqYSBLw7xobGV3aW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWly amEuLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2giIHRhcmdldD0iX2JsYW5rIj5taXJqYS5rdWVo bGV3aW5kQHRpay5lZS5ldGh6LmNoPC9hPiZndDs7IEZyZWRlcmljayBLYXV0eiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmZrYXV0ekBhbHVtbmkuY211LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmZrYXV0ekBh bHVtbmkuY211LmVkdTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBQcml2YWN5IGhv bGVzICh3YXM6IFJlOiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5 cHRpb24pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0ibV8tNjM1 MTE0MDQ1MTcxNjM2Mzc3NWJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+SGk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTYzNTExNDA0NTE3MTYzNjM3NzVhaXJtYWlsb24iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5PbiA1IEFwcmlsIDIwMTggYXQgMTkuMjcuMjQsIE1pa2UgQmlzaG9w ICg8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+KQ0KIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxwIGNsYXNzPSJtLTYzNTExNDA0NTE3MTYzNjM3NzVtc29wbGFpbnRleHQi IHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDtmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGNsYXNz PSJtLTYzNTExNDA0NTE3MTYzNjM3NzVhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkFuIGVuZHBvaW50IHRoYXQgcmVjZWl2ZXMgYSBwYWNrZXQgY2FycnlpbmcgYSBDSUQgdGhh dCBkb2VzIG5vdCBiZWxvbmcgdG8gYW55IGtub3duIGNvbm5lY3Rpb24gdHJpYWwtZGVjcnlwdHMg dGhlIHBhY2tldCBhcyBhIGluaXRpYWwNCiBwYWNrZXQgYW5kIGhhbmRsZXMgaXQgYXMgYSBjb25u ZWN0aW9uIGluaXRpYXRpb24sIG9yIHNlbmRzIGEgc3RhdGVmdWwgcmVzZXQgaWYgdGhlIHRyaWFs LWRlY3J5cHRpb24gZmFpbHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBjYW4gc2VlIGhpZGluZyB0aGluZ3MgbWF5 IGJlIGEgZ29vZCB0aGluZywgYnV0IGhhdmluZyB0byB0cmlhbCBkZWNyeXB0IGFsbCB1bmtub3du IHBhY2tldHMgYXMgcG90ZW50aWFsbHkgY3JlYXRpbmcgYSBodWdlIGxvYWQsIHVubGVzcyB5b3Ug Y29tYmluZSBpdCB3aXRoIG15IHByb3Bvc2FsIHRvIGFkZCBhIGNoZWNrc3VtIHRvDQogdGhlIGVu Y3J5cHRlZCBwYWNrZXQgbnVtYmVyIHNvIHlvdSBvbmx5IG5lZWQgb25lIGNyeXB0byBibG9jayBv biBhdmVyYWdlIHRvIHJlamVjdCByYW5kb20gcGFja2V0IGNvbnRlbnQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkl0IHdvbuKAmXQgc29sdmUgYWxsIEREb1Ms IGJ1dCBpdCB3aWxsIGhlbHAuIEZvcmNpbmcgdHJpYWwgZGVjcnlwdGlvbiBmbyB0aGUgZnVsbCBw YWNrZXQgbWFrZXMgbWUgYSBiaXQgYW54aW91cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPk1pa2tlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+S2F6dWhvIE9rdTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB0630BF7EC130BD8987C8CE11B6BB0CY4PR21MB0630namp_-- From nobody Thu Apr 5 11:21:18 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F61912AF84 for ; Thu, 5 Apr 2018 11:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 hyI8wIvPf6IC for ; Thu, 5 Apr 2018 11:21:14 -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 356E012AAB6 for ; Thu, 5 Apr 2018 11:21:14 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w35I9Kcb019068; Thu, 5 Apr 2018 19:21:03 +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=VKp05008MnFcrUDthEBurXanuCGzx9Bks4eNQj2XAUI=; b=mEcvwrPsoeljwpizvL2SHuph/c6yInKq18d92fdFMZfN+GAbj7QEXPGnS43F9i/aGuM6 TMBB5WUPBCer+uPb0cVdhyf02BWZm7VHkvOaO0vti5kqD3Lv4W3gG1F8p4B0qMoe5qYO +Y5smgQNYHhJ/oGxw+DAKf7ni2eirIeCYOzDUurrfPYzsP68o35lG3vTs/HVYQVQSl/L YUf+xEXfCnGOCftdRnQ6FlCGT9DvBqkKYJcq7S5rKXkT56btI/ZBqThessxcOt0nnLsi woBXFIkmcottsyQ+rtR1HuFni+D5OT+51NChkqxdovhvPjmimvaVV34qFnDB/q7+GxBl ZA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2h4vfv3wp1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 19:21:03 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w35I6wpe006418; Thu, 5 Apr 2018 14:21:02 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2h25nwcjff-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 14:21:02 -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.1365.1; Thu, 5 Apr 2018 14:21:01 -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.1365.000; Thu, 5 Apr 2018 14:21:01 -0400 From: "Lubashev, Igor" To: Kazuho Oku CC: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Mike Bishop , Christian Huitema , IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Frederick Kautz Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Index: AQHTzPOeCspMmk/31UumuO1CInS8X6PylyoAgAACsQCAABOkAIAAAk8AgAABDID//8BxoIAASkOA//+9aUA= Date: Thu, 5 Apr 2018 18:21:00 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.87] Content-Type: multipart/alternative; boundary="_000_d9efb98a11304b049694cb89dcc04629usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050185 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050185 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 18:21:17 -0000 --_000_d9efb98a11304b049694cb89dcc04629usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSXQgd291bGQgbm90LCAqaWYqIHRoZSBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlciBjYW4g QUVTLWRlY3J5cHQgdGhlIHBhY2tldCAodXNpbmcgdGhlIGtleSBkZXJpdmVkIGZyb20gdGhlIHBh Y2tldCBoZWFkZXIpIHRvIHNlZSBpZiB0aGUgcGFja2V0IGlzIGluIGZhY3QgYSBpbml0aWFsIHBh Y2tldC4NCg0KV291bGQgbm90IGl0IG5lZWQgdG8gZmlyc3QgZGVjaWRlIHRoYXQgdGhlIENJRCBp biB0aGUgcGFja2V0IGlzIHVua25vd24gKHdoaWNoIG1lYW5zIHN0YXRlZnVsKT8gIEl0IHdvdWxk IG5lZWQgdG8gZG8gc29tZSBpbnRlZ3JpdHkgY2hlY2sgb24gQ0lELCB3aGljaCB3b3VsZCByZXF1 aXJlIGEgbGFyZ2Ugbm9uY2UgdG8gYXZvaWQgYWNjaWRlbnRhbGx5IGNsYXNzaWZ5aW5nIGEgcmFu ZG9tIENJRCBhcyB2YWxpZCwgYmVjYXVzZSB0aGUgY29zdCBvZiB0aGlzIG1pc3Rha2UgY2FuIGJl IHZlcnkgbGFyZ2UgZm9yIHRoZSBjbGllbnQgKHNlZSBiZWxvdykuDQoNCg0KICAqICAgT3IgYW5v dGhlciB3YXkgb2Ygc29sdmluZyB0aGUgaXNzdWUgd2lsbCBiZSB0byBhbHdheXMgcm91dGUgdGhl IHBhY2tldCBiYXNlZCBvbiBDSUQsIHRoZW4gZm9yd2FyZCB0aGUgcGFja2V0IGJldHdlZW4gdGhl IGVuZHBvaW50cyBiZWhpbmQgdGhlIGxvYWQgYmFsYW5jZXIuDQoNClRoaXMgd291bGQgbm90IHJl YWxseSB3b3JrIGZvciBhIGdsb2JhbCBsb2FkIGJhbGFuY2VyIOKAkyB0aGUgb25lIGNhcGFibGUg b2YgZm9yd2FyZGluZyBhY3Jvc3MgYSBjb250aW5lbnQgdG8gYSBkaWZmZXJlbnQgYW55Y2FzdCBw b3AgKGR1ZSB0byBjbGllbnTigJlzIGNoYW5nZSBpbiBhdHRhY2htZW50IHBvaW50IG9yIEJHUCBy ZWNvbnZlcmdlbmNlKS4NCg0KDQoNCkZyb206IEthenVobyBPa3UgW21haWx0bzprYXp1aG9va3VA Z21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDA1LCAyMDE4IDI6MDkgUE0NClRvOiBM dWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT4NCkNjOiBNaWtrZWwgRmFobsO4ZSBK w7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb20+OyBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVx dWVmb3UuYmU+OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD47IElFVEYg UVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdp bmRAdGlrLmVlLmV0aHouY2g+OyBGcmVkZXJpY2sgS2F1dHogPGZrYXV0ekBhbHVtbmkuY211LmVk dT4NClN1YmplY3Q6IFJlOiBQcml2YWN5IGhvbGVzICh3YXM6IFJlOiBHZXR0aW5nIHRvIGNvbnNl bnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24pDQoNCg0KDQoyMDE4LTA0LTA2IDI6NTkg R01UKzA5OjAwIEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHVi YXNoZUBha2FtYWkuY29tPj46DQoNCiAgKiAgIEknZCBwcmVmZXIgbWFraW5nIGhhbmRzaGFrZSBw YWNrZXRzIGluZGlzdGluZ3Vpc2hhYmxlIGZyb20gc2hvcnQgaGVhZGVyIHBhY2tldHMuIEluIGVz c2VuY2UsIHlvdSBtb3ZlIHRoZSBmbGFncyBvZiB0aGUgbG9uZyBoZWFkZXIgaW5zaWRlIHRoZSBB RUFELXByb3RlY3RlZCBhcmVhLiBBbiBlbmRwb2ludCB0aGF0IHJlY2VpdmVzIGEgcGFja2V0IGNh cnJ5aW5nIGEgQ0lEIHRoYXQgZG9lcyBub3QgYmVsb25nIHRvIGFueSBrbm93biBjb25uZWN0aW9u IHRyaWFsLWRlY3J5cHRzIHRoZSBwYWNrZXQgYXMgYSBpbml0aWFsIHBhY2tldCBhbmQgaGFuZGxl cyBpdCBhcyBhIGNvbm5lY3Rpb24gaW5pdGlhdGlvbiwgb3Igc2VuZHMgYSBzdGF0ZWZ1bCByZXNl dCBpZiB0aGUgdHJpYWwtZGVjcnlwdGlvbiBmYWlscy4NClRoaXMgY2hhbmdlIHdvdWxkIHdyZWNr IHN0YXRlbGVzcyBsb2FkIGJhbGFuY2VycyB0aGF0IHJlbHkgb24gYmVpbmcgYWJsZSB0byBkaXN0 aW5ndWlzaCBDSSBwYWNrZXRzIChhbmQgcm91dGUgdGhlbSBiYXNlZCBvbiBJUHMpIGZyb20gb3Ro ZXIgcGFja2V0cyAoYW5kIHJvdXRlIHRoZW0gYmFzZWQgb24gQ0lEKS4NCg0KSXQgd291bGQgbm90 LCAqaWYqIHRoZSBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlciBjYW4gQUVTLWRlY3J5cHQgdGhlIHBh Y2tldCAodXNpbmcgdGhlIGtleSBkZXJpdmVkIGZyb20gdGhlIHBhY2tldCBoZWFkZXIpIHRvIHNl ZSBpZiB0aGUgcGFja2V0IGlzIGluIGZhY3QgYSBpbml0aWFsIHBhY2tldC4gT3IgYW5vdGhlciB3 YXkgb2Ygc29sdmluZyB0aGUgaXNzdWUgd2lsbCBiZSB0byBhbHdheXMgcm91dGUgdGhlIHBhY2tl dCBiYXNlZCBvbiBDSUQsIHRoZW4gZm9yd2FyZCB0aGUgcGFja2V0IGJldHdlZW4gdGhlIGVuZHBv aW50cyBiZWhpbmQgdGhlIGxvYWQgYmFsYW5jZXIuDQoNCkkgYWdyZWUgdGhhdCBpdCB3b3VsZCBi ZSBhIG5vLWRlYWwgZm9yIHN0YXRlbGVzcyBsb2FkIGJhbGFuY2VycyB0aGF0IGFyZSBpbmNhcGFi bGUgb2YgZG9pbmcgc3VjaCB0aGluZ3MuDQoNCg0KLSBJZ29yDQoNCkZyb206IE1pa2tlbCBGYWhu w7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tlbGZq QGdtYWlsLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDUsIDIwMTggMTozMSBQTQ0KVG86 IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVm b3UuYmU+PjsgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ8bWFpbHRvOmh1 aXRlbWFAaHVpdGVtYS5uZXQ+PjsgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxtYWls dG86a2F6dWhvb2t1QGdtYWlsLmNvbT4+DQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3Jn PG1haWx0bzpxdWljQGlldGYub3JnPj47IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdp bmRAdGlrLmVlLmV0aHouY2g8bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+ PjsgRnJlZGVyaWNrIEthdXR6IDxma2F1dHpAYWx1bW5pLmNtdS5lZHU8bWFpbHRvOmZrYXV0ekBh bHVtbmkuY211LmVkdT4+DQpTdWJqZWN0OiBSRTogUHJpdmFjeSBob2xlcyAod2FzOiBSZTogR2V0 dGluZyB0byBjb25zZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uKQ0KDQpIaQ0KDQoN Ck9uIDUgQXByaWwgMjAxOCBhdCAxOS4yNy4yNCwgTWlrZSBCaXNob3AgKG1iaXNob3BAZXZlcXVl Zm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4pIHdyb3RlOg0KDQogQW4gZW5kcG9p bnQgdGhhdCByZWNlaXZlcyBhIHBhY2tldCBjYXJyeWluZyBhIENJRCB0aGF0IGRvZXMgbm90IGJl bG9uZyB0byBhbnkga25vd24gY29ubmVjdGlvbiB0cmlhbC1kZWNyeXB0cyB0aGUgcGFja2V0IGFz IGEgaW5pdGlhbCBwYWNrZXQgYW5kIGhhbmRsZXMgaXQgYXMgYSBjb25uZWN0aW9uIGluaXRpYXRp b24sIG9yIHNlbmRzIGEgc3RhdGVmdWwgcmVzZXQgaWYgdGhlIHRyaWFsLWRlY3J5cHRpb24gZmFp bHMuDQoNCkkgY2FuIHNlZSBoaWRpbmcgdGhpbmdzIG1heSBiZSBhIGdvb2QgdGhpbmcsIGJ1dCBo YXZpbmcgdG8gdHJpYWwgZGVjcnlwdCBhbGwgdW5rbm93biBwYWNrZXRzIGFzIHBvdGVudGlhbGx5 IGNyZWF0aW5nIGEgaHVnZSBsb2FkLCB1bmxlc3MgeW91IGNvbWJpbmUgaXQgd2l0aCBteSBwcm9w b3NhbCB0byBhZGQgYSBjaGVja3N1bSB0byB0aGUgZW5jcnlwdGVkIHBhY2tldCBudW1iZXIgc28g eW91IG9ubHkgbmVlZCBvbmUgY3J5cHRvIGJsb2NrIG9uIGF2ZXJhZ2UgdG8gcmVqZWN0IHJhbmRv bSBwYWNrZXQgY29udGVudC4NCg0KSXQgd29u4oCZdCBzb2x2ZSBhbGwgRERvUywgYnV0IGl0IHdp bGwgaGVscC4gRm9yY2luZyB0cmlhbCBkZWNyeXB0aW9uIGZvIHRoZSBmdWxsIHBhY2tldCBtYWtl cyBtZSBhIGJpdCBhbnhpb3VzLg0KDQoNCg0KTWlra2VsDQoNCg0KDQoNCg0KLS0NCkthenVobyBP a3UNCg== --_000_d9efb98a11304b049694cb89dcc04629usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubS02MzUxMTQwNDUxNzE2MzYzNzc1YWlybWFp bG9uLCBsaS5tLTYzNTExNDA0NTE3MTYzNjM3NzVhaXJtYWlsb24sIGRpdi5tLTYzNTExNDA0NTE3 MTYzNjM3NzVhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6bV8tNjM1MTE0MDQ1MTcxNjM2Mzc3 NWFpcm1haWxvbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubS02 MzUxMTQwNDUxNzE2MzYzNzc1bXNvcGxhaW50ZXh0LCBsaS5tLTYzNTExNDA0NTE3MTYzNjM3NzVt c29wbGFpbnRleHQsIGRpdi5tLTYzNTExNDA0NTE3MTYzNjM3NzVtc29wbGFpbnRleHQNCgl7bXNv LXN0eWxlLW5hbWU6bV8tNjM1MTE0MDQ1MTcxNjM2Mzc3NW1zb3BsYWludGV4dDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4ubS02MzUxMTQwNDUxNzE2MzYzNzc1 YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOm1fLTYzNTExNDA0NTE3MTYz NjM3NzVhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjg5MTMwNjUzNDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTExOTE5NjI4MzY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28t bGlzdC1pZDoyMDIwODE1NTczOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotMTkwNzgyNTg2NCAxOTIwOTA0MTY4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NjE3Ow0KCW1zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlz dCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2 ZWwxIGxmbzIiPkl0IHdvdWxkIG5vdCwgKmlmKiB0aGUgc3RhdGVsZXNzIGxvYWQgYmFsYW5jZXIg Y2FuIEFFUy1kZWNyeXB0IHRoZSBwYWNrZXQgKHVzaW5nIHRoZSBrZXkgZGVyaXZlZCBmcm9tIHRo ZSBwYWNrZXQgaGVhZGVyKSB0byBzZWUgaWYgdGhlIHBhY2tldCBpcyBpbiBmYWN0IGEgaW5pdGlh bCBwYWNrZXQuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIG5vdCBpdCBuZWVk IHRvIGZpcnN0IGRlY2lkZSB0aGF0IHRoZSBDSUQgaW4gdGhlIHBhY2tldCBpcyB1bmtub3duICh3 aGljaCBtZWFucyBzdGF0ZWZ1bCk/Jm5ic3A7IEl0IHdvdWxkIG5lZWQgdG8gZG8gc29tZSBpbnRl Z3JpdHkgY2hlY2sgb24gQ0lELCB3aGljaCB3b3VsZCByZXF1aXJlIGEgbGFyZ2Ugbm9uY2UgdG8g YXZvaWQgYWNjaWRlbnRhbGx5IGNsYXNzaWZ5aW5nIGEgcmFuZG9tIENJRCBhcyB2YWxpZCwNCiBi ZWNhdXNlIHRoZSBjb3N0IG9mIHRoaXMgbWlzdGFrZSBjYW4gYmUgdmVyeSBsYXJnZSBmb3IgdGhl IGNsaWVudCAoc2VlIGJlbG93KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPk9yIGFub3RoZXIgd2F5IG9mIHNvbHZpbmcgdGhl IGlzc3VlIHdpbGwgYmUgdG8gYWx3YXlzIHJvdXRlIHRoZSBwYWNrZXQgYmFzZWQgb24gQ0lELCB0 aGVuIGZvcndhcmQgdGhlIHBhY2tldCBiZXR3ZWVuIHRoZSBlbmRwb2ludHMgYmVoaW5kIHRoZSBs b2FkIGJhbGFuY2VyLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHdvdWxkIG5v dCByZWFsbHkgd29yayBmb3IgYSBnbG9iYWwgbG9hZCBiYWxhbmNlciDigJMgdGhlIG9uZSBjYXBh YmxlIG9mIGZvcndhcmRpbmcgYWNyb3NzIGEgY29udGluZW50IHRvIGEgZGlmZmVyZW50IGFueWNh c3QgcG9wIChkdWUgdG8gY2xpZW504oCZcyBjaGFuZ2UgaW4gYXR0YWNobWVudCBwb2ludCBvciBC R1AgcmVjb252ZXJnZW5jZSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gS2F6dWhvIE9rdSBbbWFpbHRvOmthenVob29r dUBnbWFpbC5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMDUsIDIwMTgg MjowOSBQTTxicj4NCjxiPlRvOjwvYj4gTHViYXNoZXYsIElnb3IgJmx0O2lsdWJhc2hlQGFrYW1h aS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDtt aWtrZWxmakBnbWFpbC5jb20mZ3Q7OyBNaWtlIEJpc2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3Uu YmUmZ3Q7OyBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs7IElF VEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1pcmphIEvDvGhsZXdpbmQgJmx0O21p cmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gmZ3Q7OyBGcmVkZXJpY2sgS2F1dHogJmx0O2Zr YXV0ekBhbHVtbmkuY211LmVkdSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFByaXZhY3kg aG9sZXMgKHdhczogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5j cnlwdGlvbik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTgtMDQtMDYgMjo1OSBHTVQmIzQzOzA5OjAw IEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSSdkIHByZWZlciBtYWtp bmcgaGFuZHNoYWtlIHBhY2tldHMgaW5kaXN0aW5ndWlzaGFibGUgZnJvbSBzaG9ydCBoZWFkZXIg cGFja2V0cy4gSW4gZXNzZW5jZSwgeW91IG1vdmUgdGhlIGZsYWdzIG9mIHRoZSBsb25nIGhlYWRl ciBpbnNpZGUgdGhlIEFFQUQtcHJvdGVjdGVkIGFyZWEuIEFuIGVuZHBvaW50IHRoYXQgcmVjZWl2 ZXMgYSBwYWNrZXQgY2FycnlpbmcgYSBDSUQgdGhhdCBkb2VzIG5vdCBiZWxvbmcgdG8gYW55IGtu b3duIGNvbm5lY3Rpb24NCiB0cmlhbC1kZWNyeXB0cyB0aGUgcGFja2V0IGFzIGEgaW5pdGlhbCBw YWNrZXQgYW5kIGhhbmRsZXMgaXQgYXMgYSBjb25uZWN0aW9uIGluaXRpYXRpb24sIG9yIHNlbmRz IGEgc3RhdGVmdWwgcmVzZXQgaWYgdGhlIHRyaWFsLWRlY3J5cHRpb24gZmFpbHMuPG86cD48L286 cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgY2hhbmdlIHdvdWxkIHdy ZWNrIHN0YXRlbGVzcyBsb2FkIGJhbGFuY2VycyB0aGF0IHJlbHkgb24gYmVpbmcgYWJsZSB0byBk aXN0aW5ndWlzaCBDSSBwYWNrZXRzIChhbmQgcm91dGUgdGhlbSBiYXNlZCBvbiBJUHMpIGZyb20g b3RoZXIgcGFja2V0cyAoYW5kIHJvdXRlIHRoZW0gYmFzZWQgb24gQ0lEKS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JdCB3b3VsZCBub3QsICppZiogdGhlIHN0YXRlbGVzcyBsb2FkIGJhbGFuY2VyIGNh biBBRVMtZGVjcnlwdCB0aGUgcGFja2V0ICh1c2luZyB0aGUga2V5IGRlcml2ZWQgZnJvbSB0aGUg cGFja2V0IGhlYWRlcikgdG8gc2VlIGlmIHRoZSBwYWNrZXQgaXMgaW4gZmFjdCBhIGluaXRpYWwg cGFja2V0LiBPciBhbm90aGVyIHdheSBvZiBzb2x2aW5nIHRoZSBpc3N1ZSB3aWxsIGJlIHRvIGFs d2F5cyByb3V0ZSB0aGUgcGFja2V0DQogYmFzZWQgb24gQ0lELCB0aGVuIGZvcndhcmQgdGhlIHBh Y2tldCBiZXR3ZWVuIHRoZSBlbmRwb2ludHMgYmVoaW5kIHRoZSBsb2FkIGJhbGFuY2VyLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVl IHRoYXQgaXQgd291bGQgYmUgYSBuby1kZWFsIGZvciBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlcnMg dGhhdCBhcmUgaW5jYXBhYmxlIG9mIGRvaW5nIHN1Y2ggdGhpbmdzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gSWdvcjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPkZyb206PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1pa2tlbGZqQGdt YWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDA1LCAyMDE4 IDE6MzEgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86 bWJpc2hvcEBldmVxdWVmb3UuYmUiIHRhcmdldD0iX2JsYW5rIj5tYmlzaG9wQGV2ZXF1ZWZvdS5i ZTwvYT4mZ3Q7OyBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFA aHVpdGVtYS5uZXQiIHRhcmdldD0iX2JsYW5rIj5odWl0ZW1hQGh1aXRlbWEubmV0PC9hPiZndDs7 IEthenVobyBPa3UgJmx0OzxhIGhyZWY9Im1haWx0bzprYXp1aG9va3VAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+a2F6dWhvb2t1QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJ RVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7OyBNaXJqYSBLw7xobGV3aW5kICZsdDs8YSBocmVm PSJtYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCIgdGFyZ2V0PSJfYmxhbmsi Pm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8L2E+Jmd0OzsgRnJlZGVyaWNrIEthdXR6 ICZsdDs8YSBocmVmPSJtYWlsdG86ZmthdXR6QGFsdW1uaS5jbXUuZWR1IiB0YXJnZXQ9Il9ibGFu ayI+ZmthdXR6QGFsdW1uaS5jbXUuZWR1PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IFByaXZhY3kgaG9sZXMgKHdhczogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBu dW1iZXIgZW5jcnlwdGlvbik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 IGlkPSJtXy02MzUxMTQwNDUxNzE2MzYzNzc1Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5IaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tNjM1MTE0MDQ1MTcxNjM2Mzc3NWFp cm1haWxvbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDUgQXByaWwgMjAxOCBhdCAxOS4yNy4yNCwg TWlrZSBCaXNob3AgKDwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWJpc2hvcEBldmVxdWVmb3UuYmU8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4pDQogd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHAgY2xhc3M9Im0tNjM1MTE0MDQ1MTcxNjM2Mzc3NW1z b3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2ZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gY2xhc3M9Im0tNjM1MTE0MDQ1MTcxNjM2Mzc3NWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+QW4gZW5kcG9pbnQgdGhhdCByZWNlaXZlcyBhIHBhY2tldCBjYXJyeWlu ZyBhIENJRCB0aGF0IGRvZXMgbm90IGJlbG9uZyB0byBhbnkga25vd24gY29ubmVjdGlvbiB0cmlh bC1kZWNyeXB0cyB0aGUgcGFja2V0IGFzIGEgaW5pdGlhbA0KIHBhY2tldCBhbmQgaGFuZGxlcyBp dCBhcyBhIGNvbm5lY3Rpb24gaW5pdGlhdGlvbiwgb3Igc2VuZHMgYSBzdGF0ZWZ1bCByZXNldCBp ZiB0aGUgdHJpYWwtZGVjcnlwdGlvbiBmYWlscy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGNhbiBzZWUgaGlkaW5n IHRoaW5ncyBtYXkgYmUgYSBnb29kIHRoaW5nLCBidXQgaGF2aW5nIHRvIHRyaWFsIGRlY3J5cHQg YWxsIHVua25vd24gcGFja2V0cyBhcyBwb3RlbnRpYWxseSBjcmVhdGluZyBhIGh1Z2UgbG9hZCwg dW5sZXNzIHlvdSBjb21iaW5lIGl0IHdpdGggbXkgcHJvcG9zYWwgdG8gYWRkIGEgY2hlY2tzdW0g dG8NCiB0aGUgZW5jcnlwdGVkIHBhY2tldCBudW1iZXIgc28geW91IG9ubHkgbmVlZCBvbmUgY3J5 cHRvIGJsb2NrIG9uIGF2ZXJhZ2UgdG8gcmVqZWN0IHJhbmRvbSBwYWNrZXQgY29udGVudC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SXQgd29u4oCZdCBzb2x2 ZSBhbGwgRERvUywgYnV0IGl0IHdpbGwgaGVscC4gRm9yY2luZyB0cmlhbCBkZWNyeXB0aW9uIGZv IHRoZSBmdWxsIHBhY2tldCBtYWtlcyBtZSBhIGJpdCBhbnhpb3VzLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TWlra2VsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5LYXp1aG8gT2t1PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_d9efb98a11304b049694cb89dcc04629usma1exdag1mb5msgcorpak_-- From nobody Thu Apr 5 11:27:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6856412DFDB for ; Thu, 5 Apr 2018 11:27:13 -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, 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 (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 1N4f03QcgxjW for ; Thu, 5 Apr 2018 11:27:11 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0097.outbound.protection.outlook.com [104.47.34.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2107D12DA6F for ; Thu, 5 Apr 2018 11:27:11 -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=Op9tmHS691BKgCg3m7+AJy/dycD9cN3BLAygCxcRXgM=; b=Kg2pPOgqt4gdxHYouJiTR7Ew346UdN+UINnJkpFTwU6Ns76Ge0dExx7qjgyJO1BEA97NorxCt54f64xyxy81vS+nWDtGYcnB4ejrsmJ+k6IuH1r8zz/OIVttXq/f9q7kbnVVi6jUdyTXDAu9AHuhOT+q2aCXFPbgJ6UKyWzQefQ= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0839.namprd21.prod.outlook.com (10.173.192.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Thu, 5 Apr 2018 18:27:09 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Thu, 5 Apr 2018 18:27:09 +0000 From: Praveen Balasubramanian To: Praveen Balasubramanian , Martin Thomson , Kazuho Oku CC: Lars Eggert , Mark Nottingham , IETF QUIC WG , Patrick McManus Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwkIMAgADKCACAADzkAIAAwwoggAAk8AA= Date: Thu, 5 Apr 2018 18:27:08 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0839; 7:oFAW8Vkk1KiVBOKAko0Ho3j+nAWhbVeyjSYN/m9puHKDYZS8JAW602wtp6+ln4Jbw5S5Fs8qzRU3a73L0XWIVAxo9sIuQVjJgao2ieMAJJddHCHvtKgACZOkky90nLUdvAoD04h+k7rsoJfr+9UvQA0HoBePih9527vXmuQ2JHZyMzxANc34t0LkP509SElkXoFDDeeKVNUiwuJaQVbcYN30GFiICpxDuXZpwgiv0bIzNZoynlQ2xYwbfQWpq4A9; 20:20BXc8+DhuvljP5VkXxVY+BesQLkxUjaKd7SBdtEbtFEIeBmuuF06uYP8irzdeqBRklLDs+wOG7X0MB0qu6rLYHSac2YDygycFHz555gfCzkBZOAdx6tigLTFZNNus8yecIEFX/AU7oAJvxpiDavlsn1NTKfJpp00V6H2WQ7jdA= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: af63a43d-3cb7-48d7-3646-08d59b22d79f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0839; x-ms-traffictypediagnostic: CY4PR21MB0839: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231221)(944501327)(52105095)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0839; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0839; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(366004)(396003)(39380400002)(346002)(199004)(13464003)(51444003)(189003)(86612001)(59450400001)(3280700002)(229853002)(2940100002)(11346002)(102836004)(99286004)(446003)(3660700001)(486006)(39060400002)(478600001)(46003)(8676002)(305945005)(476003)(25786009)(74316002)(2906002)(316002)(10290500003)(5660300001)(8936002)(2900100001)(8990500004)(10090500001)(22452003)(14454004)(4326008)(7736002)(81166006)(81156014)(6246003)(86362001)(53936002)(186003)(7696005)(55016002)(6436002)(76176011)(68736007)(93886005)(9686003)(54906003)(5250100002)(6506007)(53546011)(97736004)(33656002)(110136005)(106356001)(6116002)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0839; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: r/v0hz7ijPV3eFCeF8m+CxCK7CTTCmCaeCOwzRuAZBsqPM57eBoz6ECZMc2gZz7Wq4xpX4lSi2h3vzEQgY7yamYxVW6/eAe3GwOMdOXhWWRrRAsPWBy1y1hdAO+zsDPsH+JaTB2ITAG38IfoOIyAh23WrigfURqfTUQeF9fb8Qex+Z7AuYMejYueSARxxva96Mkh4WcDdZ/GUM+hz3F2G2G6e2wRDvrhB3vLXyYDoWkJ6SMf/NymYZrqY1hF8ahXowW6V6fiaCODGgKoFe0D8y2GAMgabscnx9eh03WaGHidi13GDbhlCHpIQYSdDt/ZFN7M0Ti92oOw22AJfnSYzqBKTAOWWrSPhZqI3RxHnPu9GNKYFs0zDAvXElXgXkBwuo0TWhn6pWqIvIMrBNY25YeQkwwU+RJ1iTLIvXQfT4g= 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-Network-Message-Id: af63a43d-3cb7-48d7-3646-08d59b22d79f X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 18:27:09.0130 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0839 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 18:27:13 -0000 SeKAmWQgbGlrZSB0byBjbGFyaWZ5IHRoYXQgd2hlbiBJIHNhaWQgdjEgYW5kIHYyIHRoYXQgd2Ug d2lsbCBzaW0gc2hpcCB0aGVtIGluIHRoZSBzYW1lIFJGQy4gSSBkaWQgbm90IGludGVuZCB0byBz dWdnZXN0IG1vdmluZyBtaWdyYXRpb24gb3V0IG9mIHNjb3BlLiBBbmQgdGhlbiBjbGllbnRzIHRo YXQgd2FudCB0byBtaWdyYXRlIGFuZCBzZXJ2ZXJzIHRoYXQgc3VwcG9ydCBtaWdyYXRpb24gd2ls bCBuZWdvdGlhdGUgdjIgYW5kIHJlc3Qgb2YgdGhlIGNhc2VzIHdpbGwgIGJlIHYxLg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQpTZW50OiBUaHVy c2RheSwgQXByaWwgNSwgMjAxOCA5OjQyIEFNDQpUbzogTWFydGluIFRob21zb24gPG1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT47IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpDYzog TGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz47IE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90 Lm5ldD47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IFBhdHJpY2sgTWNNYW51cyA8cG1j bWFudXNAbW96aWxsYS5jb20+DQpTdWJqZWN0OiBSRTogR2V0dGluZyB0byBjb25zZW5zdXMgb24g cGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCkxvdmUgdGhpcyBpZGVhLiBFeHBhbmRpbmcgaXQg YSBiaXQgZnVydGhlciBJIGRvbuKAmXQgdGhpbmsgd2UgbmVlZCB0byBtYWtlIFBOIHRyYW5zZm9y bSBhIHRyYW5zcG9ydCBwYXJhbWV0ZXIgYnV0IHJhdGhlciBjb25uZWN0aW9uIG1pZ3JhdGlvbiBp dHNlbGYuIFdlIGNvdWxkIGFsc28gc2ltcGx5IHVzZSBRVUlDIHZlcnNpb25pbmcgZm9yIHRoaXMu IA0KDQoxLiBTaGlwIFFVSUMgdjEgd2l0aCBubyBzdXBwb3J0IGZvciBjb25uZWN0aW9uIG1pZ3Jh dGlvbi4gU2VydmVycyBiZWhpbmQgbG9hZCBiYWxhbmNlcnMgdGhhdCBhcmUgbm90IFFVSUMgYXdh cmUgd2lsbCBvbmx5IGFkdmVydGlzZSB0aGlzIHZlcnNpb24uIEkgZXhwZWN0IHRoaXMgdG8gYmUg YSBsYXJnZSBmcmFjdGlvbiBvZiBzZXJ2ZXJzIGVzcGVjaWFsbHkgdGhvc2UgaG9zdGVkIGluIEFX UywgQXp1cmUsIEdDUC4gKlRoaXMgaXMgaW1wb3J0YW50IC0gSSB3YW50IHRoZSBncm91cCB0byBh Y2tub3dsZWRnZSB0aGF0IHNlcnZlcnMgbmVlZHMgdG8gYmUgYWJsZSB0byBhZHZlcnRpc2Ugc3Vw cG9ydCBmb3IgY29ubmVjdGlvbiBtaWdyYXRpb24qLg0KMi4gU2hpcCBRVUlDIHYyIHdpdGggc3Vw cG9ydCBmb3IgY29ubmVjdGlvbiBtaWdyYXRpb24uIElmIGEgY2xpZW50IGFuZCBzZXJ2ZXIgdXNl IHRoaXMgdmVyc2lvbiB0aGV5IE1VU1QgZG8gUE5FIGFzIHBlciAjMTA3OS4gSWYgd2UgZmluZCBh IG1vcmUgZWZmaWNpZW50IHNjaGVtZSBiZWZvcmUgTm92ZW1iZXIgdGhlbiB3ZSB1c2UgdGhhdCBp bnN0ZWFkLiANCg0KRXZlbnR1YWxseSB3ZSB3aWxsIHNoaXAgUVVJViB2TiB3aGljaCBoYXMgc3Vw cG9ydCBmb3IgbXVsdGktcGF0aCBhbmQgd2UgY2FuIHJldmlzaXQgaWYgUE5FIGlzIG5lZWRlZCBv ciBtdWx0aXBsZSBQTiBzcGFjZXMgd2lsbCB3b3JrLiBVbnRpbCB0aGVuIEkgY2FuIGxpdmUgd2l0 aCBoaWdoZXIgQ1BVIGNvc3QgZm9yIHRoZSBmcmFjdGlvbiBvZiBjb25uZWN0aW9ucyB0aGF0IHdp bGwgbWlncmF0ZS4gDQoNCk5vdyB0aGVyZSBpcyB0aGUgb3NzaWZpY2F0aW9uIHByb2JsZW0gaW4g UVVJQyB2MSBhcyByZWZlcnJlZCB0byBhYm92ZS4gV2UgYWxyZWFkeSByZXF1aXJlIGEgcmFuZG9t IHN0YXJ0aW5nIFBOLiBUaGUgbmV4dCBwcm9ibGVtIGlzIG9uZSB0aGF0IEthenVobyBicm91Z2h0 IHVwIHdoZXJlIG1pZGRsZWJveGVzIHdpbGwgc3RhcnQgc2VlaW5nIHN0cmljdCBpbmNyZWFzaW5n IFBOIGFuZCB0cnkgdG8gcmVvcmRlci4gSSB3YXMgdGhpbmtpbmcgYWJvdXQgc2hvcnQgcmFuZG9t IGp1bXBzIHRvIGZpeCB0aGlzIHByb2JsZW0gYnV0IHRoZSBtb25vdG9uaWMgaW5jcmVhc2Ugd2ls bCByZW1haW4uIFdoaWxlIEkgdGhpbmsgc2FuZSBtaWRkbGVib3hlcyB3aWxsIG5vdCBkbyBhbnkg cmVvcmRlcmluZywgdGhlcmUgbWlnaHQgYmUgYSBmZXcgY3Jhenkgb3V0bGllcnMgbGlrZSB3aXRo IFRDUC4gSSB0aGluayB3ZSBjYW4gc29sdmUgdGhpcyBieSBtYWtpbmcgdGhlIGluIGNsZWFyIFBO IGp1bXAgYm90aCBmb3J3YXJkIGFuZCBiYWNrIHdpdGhpbiBhICJyZW9yZGVyaW5nIGRlZ3JlZSIu IEkgYW0gdGhpbmtpbmcgYWJvdXQgc29tZSBpZGVhcyBoZXJlIGFuZCB3aWxsIHJlcGx5IGJhY2sg aWYgSSBmaW5kIGEgc2ltcGxlIHNjaGVtZS4NCg0KPj4gRldJVywgd2hhdCBJIGdvdCBmcm9tIHRo ZSBpbmZvIHRoYXQgUHJhdmVlbiBhbmQgSWFuIGhhdmUgc2hhcmVkIGlzIA0KPj4gdGhhdCB0aGVy ZSBhcmUgZW5vdWdoIHByb2JsZW1zIHRvIHNvbHZlIHdpdGggVURQIHRoYXQgd29ycnlpbmcgYWJv dXQgDQo+PiB0aGUgcGVyZm9ybWFuY2UgaGl0IGZyb20gZW5jcnlwdGlvbiBpcyBwcmVtYXR1cmUN Ck1hcnRpbiwgd2UgaGF2ZSBwbGFucyB0byBtYWtlIFVEUCBzY3JlYW1pbmcgZmFzdCBpbiBzb2Z0 d2FyZS4gQnV0IHRoZSByZWFsIGFkdmFudGFnZSBmb3IgVENQIGNvbWVzIGZyb20gdGhlIGJhdGNo IG9mZmxvYWRzIChzZWUgZW1haWwgd2l0aCBzdWJqZWN0ICIgSW1wYWN0IG9mIGhhcmR3YXJlIG9m ZmxvYWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVyZm9ybWFuY2UiKS4gQmF0Y2ggb2ZmbG9hZHMgZm9y IFFVSUMgYXJlIGltcG9zc2libGUgdG8gZG8gd2l0aG91dCBjcnlwdG8gb2ZmbG9hZC4gSSB3b3Vs ZCBiZSBoYXBweSB0byBleHBsYWluIG1vcmUgb24gdGhpcyBmcm9udC4gSSB0aGluayB3ZSB3aWxs IGV4aGF1c3Qgc29mdHdhcmUgb3B0aW1pemF0aW9ucyBzb29uIGFuZCB0aGVuIGdldCBibG9ja2Vk IG9uIGNyeXB0byBvZmZsb2FkLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGlu IFRob21zb24NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxOCA5OjM2IFBNDQpUbzogS2F6 dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbT4NCkNjOiBMYXJzIEVnZ2VydCA8bGFyc0BlZ2dl cnQub3JnPjsgTWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0PjsgSUVURiBRVUlDIFdHIDxx dWljQGlldGYub3JnPjsgUGF0cmljayBNY01hbnVzIDxwbWNtYW51c0Btb3ppbGxhLmNvbT4NClN1 YmplY3Q6IFJlOiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5cHRp b24NCg0KT24gVGh1LCBBcHIgNSwgMjAxOCBhdCAxMDo1NyBBTSwgS2F6dWhvIE9rdSA8a2F6dWhv b2t1QGdtYWlsLmNvbT4gd3JvdGU6DQo+IEl0IGlzIHRydWUgdGhhdCAjMTA3OSBoYXMgaXNzdWVz IHdpdGggaGFyZHdhcmUgY3J5cHRvIG9mZmxvYWQuIEkgYW0gDQo+IGhhcHB5IHRvIHN1cHBvcnQg c3dpdGNoaW5nIHRvIGEgYmV0dGVyIGVuY3J5cHRpb24gc2NoZW1lIChpZiB3ZSBmaW5kDQo+IG9u ZSkgYXQgYW55IG1vbWVudDsgZS5nLiwgZHVyaW5nIHRoZSBzdGFuZGFyZGl6YXRpb24gb2YgUVVJ Q3YxLCBvciBhcyANCj4gYW4gZXh0ZW5zaW9uIHRvIHYxLCBvciBwYXJ0IG9mIHZYLg0KDQpVbnRp bCB0aGlzIGNhbWUgdXAsIEkgaGFkbid0IGNvbnNpZGVyZWQgdGhlIHVzZSBvZiBhbiBleHRlbnNp b24vdHJhbnNwb3J0IHBhcmFtZXRlciB0byBuZWdvdGlhdGUgYSBuZXcgc2NoZW1lLCBidXQgaXQn cyBvYnZpb3VzLiAgVGhpcyBmaXRzIGJlc3Qgd2l0aCBteSB2aWV3IG9mIHRoaW5ncy4NCg0KSWYg dGhhdCBtZWFucyB0aGF0IHdlIGdldCB0aGUgREMtUVVJQyBvcHRpb24gdGhhdCB0dXJucyB0aGUg cGFja2V0IG51bWJlciBlbmNyeXB0aW9uIGZ1bmN0aW9uIGludG8gaWRlbnRpdHkgb3Igc29tZSBj aGVhcGVyIGZ1bmN0aW9uLCB0aGVuIEkgdGhpbmsgdGhhdCdzIGFuIE9LIG91dGNvbWUuICBXZSBz aG91bGQgc3RvcCBwcmV0ZW5kaW5nIHRoYXQgb25lIHNpemUgZml0cyBhbGwgaXMgYWNoaWV2YWJs ZTsgaXQncyBub3QgYmVlbiB0aGUgY2FzZSBmb3IgeWVhcnMgYWxyZWFkeS4NCg0KRldJVywgd2hh dCBJIGdvdCBmcm9tIHRoZSBpbmZvIHRoYXQgUHJhdmVlbiBhbmQgSWFuIGhhdmUgc2hhcmVkIGlz IHRoYXQgdGhlcmUgYXJlIGVub3VnaCBwcm9ibGVtcyB0byBzb2x2ZSB3aXRoIFVEUCB0aGF0IHdv cnJ5aW5nIGFib3V0IHRoZSBwZXJmb3JtYW5jZSBoaXQgZnJvbSBlbmNyeXB0aW9uIGlzIHByZW1h dHVyZS4NCg0K From nobody Thu Apr 5 11:27:32 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB48112DA6F for ; Thu, 5 Apr 2018 11:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522952834; bh=Op9tmHS691BKgCg3m7+AJy/dycD9cN3BLAygCxcRXgM=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To; b=a9K1UVIl4NAJrUAEOuJnCCDFFjncQLtwVuMRPZxUAPlLFHknc9T2uVbxilXKbsSdJ OfprscsQujx2rstXPW5GkICBUx7uJyMsoKq9bo6LUhkgQdHsAk0CBKyI1BtaJKozwF dCP/SCkglGk4ug5iQ9RKtOaYvj/baV8SXPNpHYRA= X-Mailbox-Line: From pravb@microsoft.com Thu Apr 5 11:27:14 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3EA12D94D; Thu, 5 Apr 2018 11:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522952834; bh=Op9tmHS691BKgCg3m7+AJy/dycD9cN3BLAygCxcRXgM=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To; b=a9K1UVIl4NAJrUAEOuJnCCDFFjncQLtwVuMRPZxUAPlLFHknc9T2uVbxilXKbsSdJ OfprscsQujx2rstXPW5GkICBUx7uJyMsoKq9bo6LUhkgQdHsAk0CBKyI1BtaJKozwF dCP/SCkglGk4ug5iQ9RKtOaYvj/baV8SXPNpHYRA= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A85A12D777 for ; Thu, 5 Apr 2018 11:27: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Gsrsy1P1dDB3 for ; Thu, 5 Apr 2018 11:27:11 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on071a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe42::71a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B9A12D94D for ; Thu, 5 Apr 2018 11:27:10 -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=Op9tmHS691BKgCg3m7+AJy/dycD9cN3BLAygCxcRXgM=; b=Kg2pPOgqt4gdxHYouJiTR7Ew346UdN+UINnJkpFTwU6Ns76Ge0dExx7qjgyJO1BEA97NorxCt54f64xyxy81vS+nWDtGYcnB4ejrsmJ+k6IuH1r8zz/OIVttXq/f9q7kbnVVi6jUdyTXDAu9AHuhOT+q2aCXFPbgJ6UKyWzQefQ= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0839.namprd21.prod.outlook.com (10.173.192.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Thu, 5 Apr 2018 18:27:09 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Thu, 5 Apr 2018 18:27:09 +0000 From: Praveen Balasubramanian CC: Lars Eggert , Mark Nottingham , IETF QUIC WG , Patrick McManus Subject: RE: Getting to consensus on packet number encryption Thread-Topic: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwkIMAgADKCACAADzkAIAAwwoggAAk8AA= Date: Thu, 5 Apr 2018 18:27:08 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0839; 7:oFAW8Vkk1KiVBOKAko0Ho3j+nAWhbVeyjSYN/m9puHKDYZS8JAW602wtp6+ln4Jbw5S5Fs8qzRU3a73L0XWIVAxo9sIuQVjJgao2ieMAJJddHCHvtKgACZOkky90nLUdvAoD04h+k7rsoJfr+9UvQA0HoBePih9527vXmuQ2JHZyMzxANc34t0LkP509SElkXoFDDeeKVNUiwuJaQVbcYN30GFiICpxDuXZpwgiv0bIzNZoynlQ2xYwbfQWpq4A9; 20:20BXc8+DhuvljP5VkXxVY+BesQLkxUjaKd7SBdtEbtFEIeBmuuF06uYP8irzdeqBRklLDs+wOG7X0MB0qu6rLYHSac2YDygycFHz555gfCzkBZOAdx6tigLTFZNNus8yecIEFX/AU7oAJvxpiDavlsn1NTKfJpp00V6H2WQ7jdA= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: af63a43d-3cb7-48d7-3646-08d59b22d79f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0839; x-ms-traffictypediagnostic: CY4PR21MB0839: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231221)(944501327)(52105095)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0839; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0839; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(366004)(396003)(39380400002)(346002)(199004)(13464003)(51444003)(189003)(86612001)(59450400001)(3280700002)(229853002)(2940100002)(11346002)(102836004)(99286004)(446003)(3660700001)(486006)(39060400002)(478600001)(46003)(8676002)(305945005)(476003)(25786009)(74316002)(2906002)(316002)(10290500003)(5660300001)(8936002)(2900100001)(8990500004)(10090500001)(22452003)(14454004)(4326008)(7736002)(81166006)(81156014)(6246003)(86362001)(53936002)(186003)(7696005)(55016002)(6436002)(76176011)(68736007)(93886005)(9686003)(54906003)(5250100002)(6506007)(53546011)(97736004)(33656002)(110136005)(106356001)(6116002)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0839; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: r/v0hz7ijPV3eFCeF8m+CxCK7CTTCmCaeCOwzRuAZBsqPM57eBoz6ECZMc2gZz7Wq4xpX4lSi2h3vzEQgY7yamYxVW6/eAe3GwOMdOXhWWRrRAsPWBy1y1hdAO+zsDPsH+JaTB2ITAG38IfoOIyAh23WrigfURqfTUQeF9fb8Qex+Z7AuYMejYueSARxxva96Mkh4WcDdZ/GUM+hz3F2G2G6e2wRDvrhB3vLXyYDoWkJ6SMf/NymYZrqY1hF8ahXowW6V6fiaCODGgKoFe0D8y2GAMgabscnx9eh03WaGHidi13GDbhlCHpIQYSdDt/ZFN7M0Ti92oOw22AJfnSYzqBKTAOWWrSPhZqI3RxHnPu9GNKYFs0zDAvXElXgXkBwuo0TWhn6pWqIvIMrBNY25YeQkwwU+RJ1iTLIvXQfT4g= 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-Network-Message-Id: af63a43d-3cb7-48d7-3646-08d59b22d79f X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 18:27:09.0130 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0839 To: Praveen Balasubramanian To: Martin Thomson To: Kazuho Oku Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 18:27:15 -0000 SeKAmWQgbGlrZSB0byBjbGFyaWZ5IHRoYXQgd2hlbiBJIHNhaWQgdjEgYW5kIHYyIHRoYXQgd2Ug d2lsbCBzaW0gc2hpcCB0aGVtIGluIHRoZSBzYW1lIFJGQy4gSSBkaWQgbm90IGludGVuZCB0byBz dWdnZXN0IG1vdmluZyBtaWdyYXRpb24gb3V0IG9mIHNjb3BlLiBBbmQgdGhlbiBjbGllbnRzIHRo YXQgd2FudCB0byBtaWdyYXRlIGFuZCBzZXJ2ZXJzIHRoYXQgc3VwcG9ydCBtaWdyYXRpb24gd2ls bCBuZWdvdGlhdGUgdjIgYW5kIHJlc3Qgb2YgdGhlIGNhc2VzIHdpbGwgIGJlIHYxLg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQpTZW50OiBUaHVy c2RheSwgQXByaWwgNSwgMjAxOCA5OjQyIEFNDQpUbzogTWFydGluIFRob21zb24gPG1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT47IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpDYzog TGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz47IE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90 Lm5ldD47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IFBhdHJpY2sgTWNNYW51cyA8cG1j bWFudXNAbW96aWxsYS5jb20+DQpTdWJqZWN0OiBSRTogR2V0dGluZyB0byBjb25zZW5zdXMgb24g cGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCkxvdmUgdGhpcyBpZGVhLiBFeHBhbmRpbmcgaXQg YSBiaXQgZnVydGhlciBJIGRvbuKAmXQgdGhpbmsgd2UgbmVlZCB0byBtYWtlIFBOIHRyYW5zZm9y bSBhIHRyYW5zcG9ydCBwYXJhbWV0ZXIgYnV0IHJhdGhlciBjb25uZWN0aW9uIG1pZ3JhdGlvbiBp dHNlbGYuIFdlIGNvdWxkIGFsc28gc2ltcGx5IHVzZSBRVUlDIHZlcnNpb25pbmcgZm9yIHRoaXMu IA0KDQoxLiBTaGlwIFFVSUMgdjEgd2l0aCBubyBzdXBwb3J0IGZvciBjb25uZWN0aW9uIG1pZ3Jh dGlvbi4gU2VydmVycyBiZWhpbmQgbG9hZCBiYWxhbmNlcnMgdGhhdCBhcmUgbm90IFFVSUMgYXdh cmUgd2lsbCBvbmx5IGFkdmVydGlzZSB0aGlzIHZlcnNpb24uIEkgZXhwZWN0IHRoaXMgdG8gYmUg YSBsYXJnZSBmcmFjdGlvbiBvZiBzZXJ2ZXJzIGVzcGVjaWFsbHkgdGhvc2UgaG9zdGVkIGluIEFX UywgQXp1cmUsIEdDUC4gKlRoaXMgaXMgaW1wb3J0YW50IC0gSSB3YW50IHRoZSBncm91cCB0byBh Y2tub3dsZWRnZSB0aGF0IHNlcnZlcnMgbmVlZHMgdG8gYmUgYWJsZSB0byBhZHZlcnRpc2Ugc3Vw cG9ydCBmb3IgY29ubmVjdGlvbiBtaWdyYXRpb24qLg0KMi4gU2hpcCBRVUlDIHYyIHdpdGggc3Vw cG9ydCBmb3IgY29ubmVjdGlvbiBtaWdyYXRpb24uIElmIGEgY2xpZW50IGFuZCBzZXJ2ZXIgdXNl IHRoaXMgdmVyc2lvbiB0aGV5IE1VU1QgZG8gUE5FIGFzIHBlciAjMTA3OS4gSWYgd2UgZmluZCBh IG1vcmUgZWZmaWNpZW50IHNjaGVtZSBiZWZvcmUgTm92ZW1iZXIgdGhlbiB3ZSB1c2UgdGhhdCBp bnN0ZWFkLiANCg0KRXZlbnR1YWxseSB3ZSB3aWxsIHNoaXAgUVVJViB2TiB3aGljaCBoYXMgc3Vw cG9ydCBmb3IgbXVsdGktcGF0aCBhbmQgd2UgY2FuIHJldmlzaXQgaWYgUE5FIGlzIG5lZWRlZCBv ciBtdWx0aXBsZSBQTiBzcGFjZXMgd2lsbCB3b3JrLiBVbnRpbCB0aGVuIEkgY2FuIGxpdmUgd2l0 aCBoaWdoZXIgQ1BVIGNvc3QgZm9yIHRoZSBmcmFjdGlvbiBvZiBjb25uZWN0aW9ucyB0aGF0IHdp bGwgbWlncmF0ZS4gDQoNCk5vdyB0aGVyZSBpcyB0aGUgb3NzaWZpY2F0aW9uIHByb2JsZW0gaW4g UVVJQyB2MSBhcyByZWZlcnJlZCB0byBhYm92ZS4gV2UgYWxyZWFkeSByZXF1aXJlIGEgcmFuZG9t IHN0YXJ0aW5nIFBOLiBUaGUgbmV4dCBwcm9ibGVtIGlzIG9uZSB0aGF0IEthenVobyBicm91Z2h0 IHVwIHdoZXJlIG1pZGRsZWJveGVzIHdpbGwgc3RhcnQgc2VlaW5nIHN0cmljdCBpbmNyZWFzaW5n IFBOIGFuZCB0cnkgdG8gcmVvcmRlci4gSSB3YXMgdGhpbmtpbmcgYWJvdXQgc2hvcnQgcmFuZG9t IGp1bXBzIHRvIGZpeCB0aGlzIHByb2JsZW0gYnV0IHRoZSBtb25vdG9uaWMgaW5jcmVhc2Ugd2ls bCByZW1haW4uIFdoaWxlIEkgdGhpbmsgc2FuZSBtaWRkbGVib3hlcyB3aWxsIG5vdCBkbyBhbnkg cmVvcmRlcmluZywgdGhlcmUgbWlnaHQgYmUgYSBmZXcgY3Jhenkgb3V0bGllcnMgbGlrZSB3aXRo IFRDUC4gSSB0aGluayB3ZSBjYW4gc29sdmUgdGhpcyBieSBtYWtpbmcgdGhlIGluIGNsZWFyIFBO IGp1bXAgYm90aCBmb3J3YXJkIGFuZCBiYWNrIHdpdGhpbiBhICJyZW9yZGVyaW5nIGRlZ3JlZSIu IEkgYW0gdGhpbmtpbmcgYWJvdXQgc29tZSBpZGVhcyBoZXJlIGFuZCB3aWxsIHJlcGx5IGJhY2sg aWYgSSBmaW5kIGEgc2ltcGxlIHNjaGVtZS4NCg0KPj4gRldJVywgd2hhdCBJIGdvdCBmcm9tIHRo ZSBpbmZvIHRoYXQgUHJhdmVlbiBhbmQgSWFuIGhhdmUgc2hhcmVkIGlzIA0KPj4gdGhhdCB0aGVy ZSBhcmUgZW5vdWdoIHByb2JsZW1zIHRvIHNvbHZlIHdpdGggVURQIHRoYXQgd29ycnlpbmcgYWJv dXQgDQo+PiB0aGUgcGVyZm9ybWFuY2UgaGl0IGZyb20gZW5jcnlwdGlvbiBpcyBwcmVtYXR1cmUN Ck1hcnRpbiwgd2UgaGF2ZSBwbGFucyB0byBtYWtlIFVEUCBzY3JlYW1pbmcgZmFzdCBpbiBzb2Z0 d2FyZS4gQnV0IHRoZSByZWFsIGFkdmFudGFnZSBmb3IgVENQIGNvbWVzIGZyb20gdGhlIGJhdGNo IG9mZmxvYWRzIChzZWUgZW1haWwgd2l0aCBzdWJqZWN0ICIgSW1wYWN0IG9mIGhhcmR3YXJlIG9m ZmxvYWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVyZm9ybWFuY2UiKS4gQmF0Y2ggb2ZmbG9hZHMgZm9y IFFVSUMgYXJlIGltcG9zc2libGUgdG8gZG8gd2l0aG91dCBjcnlwdG8gb2ZmbG9hZC4gSSB3b3Vs ZCBiZSBoYXBweSB0byBleHBsYWluIG1vcmUgb24gdGhpcyBmcm9udC4gSSB0aGluayB3ZSB3aWxs IGV4aGF1c3Qgc29mdHdhcmUgb3B0aW1pemF0aW9ucyBzb29uIGFuZCB0aGVuIGdldCBibG9ja2Vk IG9uIGNyeXB0byBvZmZsb2FkLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGlu IFRob21zb24NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxOCA5OjM2IFBNDQpUbzogS2F6 dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbT4NCkNjOiBMYXJzIEVnZ2VydCA8bGFyc0BlZ2dl cnQub3JnPjsgTWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0PjsgSUVURiBRVUlDIFdHIDxx dWljQGlldGYub3JnPjsgUGF0cmljayBNY01hbnVzIDxwbWNtYW51c0Btb3ppbGxhLmNvbT4NClN1 YmplY3Q6IFJlOiBHZXR0aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5cHRp b24NCg0KT24gVGh1LCBBcHIgNSwgMjAxOCBhdCAxMDo1NyBBTSwgS2F6dWhvIE9rdSA8a2F6dWhv b2t1QGdtYWlsLmNvbT4gd3JvdGU6DQo+IEl0IGlzIHRydWUgdGhhdCAjMTA3OSBoYXMgaXNzdWVz IHdpdGggaGFyZHdhcmUgY3J5cHRvIG9mZmxvYWQuIEkgYW0gDQo+IGhhcHB5IHRvIHN1cHBvcnQg c3dpdGNoaW5nIHRvIGEgYmV0dGVyIGVuY3J5cHRpb24gc2NoZW1lIChpZiB3ZSBmaW5kDQo+IG9u ZSkgYXQgYW55IG1vbWVudDsgZS5nLiwgZHVyaW5nIHRoZSBzdGFuZGFyZGl6YXRpb24gb2YgUVVJ Q3YxLCBvciBhcyANCj4gYW4gZXh0ZW5zaW9uIHRvIHYxLCBvciBwYXJ0IG9mIHZYLg0KDQpVbnRp bCB0aGlzIGNhbWUgdXAsIEkgaGFkbid0IGNvbnNpZGVyZWQgdGhlIHVzZSBvZiBhbiBleHRlbnNp b24vdHJhbnNwb3J0IHBhcmFtZXRlciB0byBuZWdvdGlhdGUgYSBuZXcgc2NoZW1lLCBidXQgaXQn cyBvYnZpb3VzLiAgVGhpcyBmaXRzIGJlc3Qgd2l0aCBteSB2aWV3IG9mIHRoaW5ncy4NCg0KSWYg dGhhdCBtZWFucyB0aGF0IHdlIGdldCB0aGUgREMtUVVJQyBvcHRpb24gdGhhdCB0dXJucyB0aGUg cGFja2V0IG51bWJlciBlbmNyeXB0aW9uIGZ1bmN0aW9uIGludG8gaWRlbnRpdHkgb3Igc29tZSBj aGVhcGVyIGZ1bmN0aW9uLCB0aGVuIEkgdGhpbmsgdGhhdCdzIGFuIE9LIG91dGNvbWUuICBXZSBz aG91bGQgc3RvcCBwcmV0ZW5kaW5nIHRoYXQgb25lIHNpemUgZml0cyBhbGwgaXMgYWNoaWV2YWJs ZTsgaXQncyBub3QgYmVlbiB0aGUgY2FzZSBmb3IgeWVhcnMgYWxyZWFkeS4NCg0KRldJVywgd2hh dCBJIGdvdCBmcm9tIHRoZSBpbmZvIHRoYXQgUHJhdmVlbiBhbmQgSWFuIGhhdmUgc2hhcmVkIGlz IHRoYXQgdGhlcmUgYXJlIGVub3VnaCBwcm9ibGVtcyB0byBzb2x2ZSB3aXRoIFVEUCB0aGF0IHdv cnJ5aW5nIGFib3V0IHRoZSBwZXJmb3JtYW5jZSBoaXQgZnJvbSBlbmNyeXB0aW9uIGlzIHByZW1h dHVyZS4NCg0K From nobody Thu Apr 5 11:28:00 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1330412E040 for ; Thu, 5 Apr 2018 11:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522952879; bh=DCd5RwCmO26qeIHHbSG6YjyjVXDnjDMm9G7ltF1nhfQ=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=sDqnMPVXCzqAUEhznkGUN8F8TlEo12AW6JlDps7pB0XqPURVKzYatnCU4RFlCVHHu BdrLGZjyytU8EmdniP+3L+pdgtmIGo4lwDRBIAOIA8l2zYtDrPc1IbIDCVZZ4xlLmo +Vb+qMP9JZk3IHETEI/sg8HUvTwQTYDpZLdiQ4bs= X-Mailbox-Line: From ilubashe@akamai.com Thu Apr 5 11:27:58 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC31B12D94D; Thu, 5 Apr 2018 11:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522952878; bh=DCd5RwCmO26qeIHHbSG6YjyjVXDnjDMm9G7ltF1nhfQ=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=vHnMurUgFdT0xKmmrjBPzoEGpuJaSEEUX6KYDyy2aczLbpSKUtLFzI4mvwYteiiJH gnCWLlQ4RFludqzRzjDvywErmhrVA8V3GEbHGhLbExpX8Im1M/qcCxcyGI7nGalV8u aWl5XogtK5PV7N7EZa/hxYfA3eop89pP0PUXrFNM= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B05712DA6F for ; Thu, 5 Apr 2018 11:27:58 -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=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 42tzITTY8MHU for ; Thu, 5 Apr 2018 11:27:55 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8951812D94D for ; Thu, 5 Apr 2018 11:27:55 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w35IMwVC011150; Thu, 5 Apr 2018 19:27:52 +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=DCd5RwCmO26qeIHHbSG6YjyjVXDnjDMm9G7ltF1nhfQ=; b=a8tsmB1jN11IPZPND8rw92HJqAhuv0gjK3z4acKZd0Ep4dYudtsbIIWalFlAk/kRS8Yz PLB+dcx9njnGqpxf0WKcAP6yOIpDY0Rr5xj8fn/flZFxOnDfaDttrhRbbzlAqa31qXHq mnQUFKnu+FTNOGTJvAUz9OQy4pyJq2F4f3DehD6/T3UhXTLArqSPeGYQMBV1X1w5lmbI FS8Yjid5eZvaGhYPlEsmD/LWZ0ZMWwtzvjJ7ZR6aXJBZ5IT/+kl8/Pm+xeXpmR90I9oa QjES6ucMlD0C4qMoakdXu0aKye1F1Aet+oQ5oo+JlkkxlJMb2clWi/iOUEPehPQ8rcZy aw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2h4hphwp85-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 19:27:51 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w35IRovr013999; Thu, 5 Apr 2018 14:27:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2h25nxcasa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 14:27:41 -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.1365.1; Thu, 5 Apr 2018 14:27:24 -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.1365.000; Thu, 5 Apr 2018 14:27:24 -0400 From: "Lubashev, Igor" CC: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Christian Huitema , Mike Bishop , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "IETF QUIC WG" , Frederick Kautz Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Index: AQHTzPOeCspMmk/31UumuO1CInS8X6PylyoAgAACsQCAABOkAIAAAk8AgAABDID//8BxoIAASkOA//+9aUCAAAPCYA== Date: Thu, 5 Apr 2018 18:27:23 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.87] Content-Type: multipart/alternative; boundary="_000_bb0a35e62e6d426baf7a36d3f2958da3usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050187 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050186 To: "Lubashev, Igor" To: Kazuho Oku Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 18:27:59 -0000 --_000_bb0a35e62e6d426baf7a36d3f2958da3usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIE9yIGFub3RoZXIgd2F5IG9mIHNvbHZpbmcgdGhlIGlzc3VlIHdpbGwgYmUgdG8gYWx3YXlz IHJvdXRlIHRoZSBwYWNrZXQgYmFzZWQgb24gQ0lELCB0aGVuIGZvcndhcmQgdGhlIHBhY2tldCBi ZXR3ZWVuIHRoZSBlbmRwb2ludHMgYmVoaW5kIHRoZSBsb2FkIGJhbGFuY2VyLg0KDQpUaGlzIHdv dWxkIG5vdCByZWFsbHkgd29yayBmb3IgYSBnbG9iYWwgbG9hZCBiYWxhbmNlciDigJMgdGhlIG9u ZSBjYXBhYmxlIG9mIGZvcndhcmRpbmcgYWNyb3NzIGEgY29udGluZW50IHRvIGEgZGlmZmVyZW50 IGFueWNhc3QgcG9wIChkdWUgdG8gY2xpZW504oCZcyBjaGFuZ2UgaW4gYXR0YWNobWVudCBwb2lu dCBvciBCR1AgcmVjb252ZXJnZW5jZSkuDQoNCk1vcmVvdmVyLCB0aGUgcm91dGluZyBpbmZvIGlu IGEgcmFuZG9tIENJRCBtYXkgbG9vayDigJxzeW50YWN0aWNhbGx5IHZhbGlk4oCdIGJ1dCBiZSDi gJxzZW1hbnRpY2FsbHkgaW52YWxpZOKAnSAocG9pbnRpbmcgYXQgYSBkZWFkIHBhdGggb3IgYSBz ZXQgb2Ygc2VydmVycyBub3QgY2FwYWJsZSBvZiBzZXJ2aW5nIFFVSUMgdHJhZmZpYykuDQoNCg0K RnJvbTogTHViYXNoZXYsIElnb3IgW21haWx0bzppbHViYXNoZT00MGFrYW1haS5jb21AZG1hcmMu aWV0Zi5vcmddDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDUsIDIwMTggMjoyMSBQTQ0KVG86IEth enVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpDYzogTWlyamEgS8O8aGxld2luZCA8bWly amEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1h QGh1aXRlbWEubmV0PjsgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPjsgTWlra2Vs IEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPjsgSUVURiBRVUlDIFdHIDxx dWljQGlldGYub3JnPjsgRnJlZGVyaWNrIEthdXR6IDxma2F1dHpAYWx1bW5pLmNtdS5lZHU+DQpT dWJqZWN0OiBSRTogUHJpdmFjeSBob2xlcyAod2FzOiBSZTogR2V0dGluZyB0byBjb25zZW5zdXMg b24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uKQ0KDQoNCiAgKiAgIEl0IHdvdWxkIG5vdCwgKmlm KiB0aGUgc3RhdGVsZXNzIGxvYWQgYmFsYW5jZXIgY2FuIEFFUy1kZWNyeXB0IHRoZSBwYWNrZXQg KHVzaW5nIHRoZSBrZXkgZGVyaXZlZCBmcm9tIHRoZSBwYWNrZXQgaGVhZGVyKSB0byBzZWUgaWYg dGhlIHBhY2tldCBpcyBpbiBmYWN0IGEgaW5pdGlhbCBwYWNrZXQuDQoNCldvdWxkIG5vdCBpdCBu ZWVkIHRvIGZpcnN0IGRlY2lkZSB0aGF0IHRoZSBDSUQgaW4gdGhlIHBhY2tldCBpcyB1bmtub3du ICh3aGljaCBtZWFucyBzdGF0ZWZ1bCk/ICBJdCB3b3VsZCBuZWVkIHRvIGRvIHNvbWUgaW50ZWdy aXR5IGNoZWNrIG9uIENJRCwgd2hpY2ggd291bGQgcmVxdWlyZSBhIGxhcmdlIG5vbmNlIHRvIGF2 b2lkIGFjY2lkZW50YWxseSBjbGFzc2lmeWluZyBhIHJhbmRvbSBDSUQgYXMgdmFsaWQsIGJlY2F1 c2UgdGhlIGNvc3Qgb2YgdGhpcyBtaXN0YWtlIGNhbiBiZSB2ZXJ5IGxhcmdlIGZvciB0aGUgY2xp ZW50IChzZWUgYmVsb3cpLg0KDQoNCiAgKiAgIE9yIGFub3RoZXIgd2F5IG9mIHNvbHZpbmcgdGhl IGlzc3VlIHdpbGwgYmUgdG8gYWx3YXlzIHJvdXRlIHRoZSBwYWNrZXQgYmFzZWQgb24gQ0lELCB0 aGVuIGZvcndhcmQgdGhlIHBhY2tldCBiZXR3ZWVuIHRoZSBlbmRwb2ludHMgYmVoaW5kIHRoZSBs b2FkIGJhbGFuY2VyLg0KDQpUaGlzIHdvdWxkIG5vdCByZWFsbHkgd29yayBmb3IgYSBnbG9iYWwg bG9hZCBiYWxhbmNlciDigJMgdGhlIG9uZSBjYXBhYmxlIG9mIGZvcndhcmRpbmcgYWNyb3NzIGEg Y29udGluZW50IHRvIGEgZGlmZmVyZW50IGFueWNhc3QgcG9wIChkdWUgdG8gY2xpZW504oCZcyBj aGFuZ2UgaW4gYXR0YWNobWVudCBwb2ludCBvciBCR1AgcmVjb252ZXJnZW5jZSkuDQoNCg0KDQpG cm9tOiBLYXp1aG8gT2t1IFttYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbV0NClNlbnQ6IFRodXJz ZGF5LCBBcHJpbCAwNSwgMjAxOCAyOjA5IFBNDQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hl QGFrYW1haS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+Pg0KQ2M6IE1pa2tlbCBGYWhu w7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwu Y29tPj47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBl dmVxdWVmb3UuYmU+PjsgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ8bWFp bHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1h aWx0bzpxdWljQGlldGYub3JnPj47IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRA dGlrLmVlLmV0aHouY2g8bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+Pjsg RnJlZGVyaWNrIEthdXR6IDxma2F1dHpAYWx1bW5pLmNtdS5lZHU8bWFpbHRvOmZrYXV0ekBhbHVt bmkuY211LmVkdT4+DQpTdWJqZWN0OiBSZTogUHJpdmFjeSBob2xlcyAod2FzOiBSZTogR2V0dGlu ZyB0byBjb25zZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uKQ0KDQoNCg0KMjAxOC0w NC0wNiAyOjU5IEdNVCswOTowMCBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxt YWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+Og0KDQogICogICBJJ2QgcHJlZmVyIG1ha2luZyBo YW5kc2hha2UgcGFja2V0cyBpbmRpc3Rpbmd1aXNoYWJsZSBmcm9tIHNob3J0IGhlYWRlciBwYWNr ZXRzLiBJbiBlc3NlbmNlLCB5b3UgbW92ZSB0aGUgZmxhZ3Mgb2YgdGhlIGxvbmcgaGVhZGVyIGlu c2lkZSB0aGUgQUVBRC1wcm90ZWN0ZWQgYXJlYS4gQW4gZW5kcG9pbnQgdGhhdCByZWNlaXZlcyBh IHBhY2tldCBjYXJyeWluZyBhIENJRCB0aGF0IGRvZXMgbm90IGJlbG9uZyB0byBhbnkga25vd24g Y29ubmVjdGlvbiB0cmlhbC1kZWNyeXB0cyB0aGUgcGFja2V0IGFzIGEgaW5pdGlhbCBwYWNrZXQg YW5kIGhhbmRsZXMgaXQgYXMgYSBjb25uZWN0aW9uIGluaXRpYXRpb24sIG9yIHNlbmRzIGEgc3Rh dGVmdWwgcmVzZXQgaWYgdGhlIHRyaWFsLWRlY3J5cHRpb24gZmFpbHMuDQpUaGlzIGNoYW5nZSB3 b3VsZCB3cmVjayBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlcnMgdGhhdCByZWx5IG9uIGJlaW5nIGFi bGUgdG8gZGlzdGluZ3Vpc2ggQ0kgcGFja2V0cyAoYW5kIHJvdXRlIHRoZW0gYmFzZWQgb24gSVBz KSBmcm9tIG90aGVyIHBhY2tldHMgKGFuZCByb3V0ZSB0aGVtIGJhc2VkIG9uIENJRCkuDQoNCkl0 IHdvdWxkIG5vdCwgKmlmKiB0aGUgc3RhdGVsZXNzIGxvYWQgYmFsYW5jZXIgY2FuIEFFUy1kZWNy eXB0IHRoZSBwYWNrZXQgKHVzaW5nIHRoZSBrZXkgZGVyaXZlZCBmcm9tIHRoZSBwYWNrZXQgaGVh ZGVyKSB0byBzZWUgaWYgdGhlIHBhY2tldCBpcyBpbiBmYWN0IGEgaW5pdGlhbCBwYWNrZXQuIE9y IGFub3RoZXIgd2F5IG9mIHNvbHZpbmcgdGhlIGlzc3VlIHdpbGwgYmUgdG8gYWx3YXlzIHJvdXRl IHRoZSBwYWNrZXQgYmFzZWQgb24gQ0lELCB0aGVuIGZvcndhcmQgdGhlIHBhY2tldCBiZXR3ZWVu IHRoZSBlbmRwb2ludHMgYmVoaW5kIHRoZSBsb2FkIGJhbGFuY2VyLg0KDQpJIGFncmVlIHRoYXQg aXQgd291bGQgYmUgYSBuby1kZWFsIGZvciBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlcnMgdGhhdCBh cmUgaW5jYXBhYmxlIG9mIGRvaW5nIHN1Y2ggdGhpbmdzLg0KDQoNCi0gSWdvcg0KDQpGcm9tOiBN aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86bWlra2VsZmpAZ21haWwuY29tPG1haWx0 bzptaWtrZWxmakBnbWFpbC5jb20+XQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDA1LCAyMDE4IDE6 MzEgUE0NClRvOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNo b3BAZXZlcXVlZm91LmJlPj47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0 PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj47IEthenVobyBPa3UgPGthenVob29rdUBnbWFp bC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5jb20+Pg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVp Y0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBNaXJqYSBLw7xobGV3aW5kIDxtaXJq YS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPG1haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5l ZS5ldGh6LmNoPj47IEZyZWRlcmljayBLYXV0eiA8ZmthdXR6QGFsdW1uaS5jbXUuZWR1PG1haWx0 bzpma2F1dHpAYWx1bW5pLmNtdS5lZHU+Pg0KU3ViamVjdDogUkU6IFByaXZhY3kgaG9sZXMgKHdh czogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbikN Cg0KSGkNCg0KDQpPbiA1IEFwcmlsIDIwMTggYXQgMTkuMjcuMjQsIE1pa2UgQmlzaG9wIChtYmlz aG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+KSB3cm90ZToNCg0K IEFuIGVuZHBvaW50IHRoYXQgcmVjZWl2ZXMgYSBwYWNrZXQgY2FycnlpbmcgYSBDSUQgdGhhdCBk b2VzIG5vdCBiZWxvbmcgdG8gYW55IGtub3duIGNvbm5lY3Rpb24gdHJpYWwtZGVjcnlwdHMgdGhl IHBhY2tldCBhcyBhIGluaXRpYWwgcGFja2V0IGFuZCBoYW5kbGVzIGl0IGFzIGEgY29ubmVjdGlv biBpbml0aWF0aW9uLCBvciBzZW5kcyBhIHN0YXRlZnVsIHJlc2V0IGlmIHRoZSB0cmlhbC1kZWNy eXB0aW9uIGZhaWxzLg0KDQpJIGNhbiBzZWUgaGlkaW5nIHRoaW5ncyBtYXkgYmUgYSBnb29kIHRo aW5nLCBidXQgaGF2aW5nIHRvIHRyaWFsIGRlY3J5cHQgYWxsIHVua25vd24gcGFja2V0cyBhcyBw b3RlbnRpYWxseSBjcmVhdGluZyBhIGh1Z2UgbG9hZCwgdW5sZXNzIHlvdSBjb21iaW5lIGl0IHdp dGggbXkgcHJvcG9zYWwgdG8gYWRkIGEgY2hlY2tzdW0gdG8gdGhlIGVuY3J5cHRlZCBwYWNrZXQg bnVtYmVyIHNvIHlvdSBvbmx5IG5lZWQgb25lIGNyeXB0byBibG9jayBvbiBhdmVyYWdlIHRvIHJl amVjdCByYW5kb20gcGFja2V0IGNvbnRlbnQuDQoNCkl0IHdvbuKAmXQgc29sdmUgYWxsIEREb1Ms IGJ1dCBpdCB3aWxsIGhlbHAuIEZvcmNpbmcgdHJpYWwgZGVjcnlwdGlvbiBmbyB0aGUgZnVsbCBw YWNrZXQgbWFrZXMgbWUgYSBiaXQgYW54aW91cy4NCg0KDQoNCk1pa2tlbA0KDQoNCg0KDQoNCi0t DQpLYXp1aG8gT2t1DQo= --_000_bb0a35e62e6d426baf7a36d3f2958da3usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubS02MzUxMTQwNDUxNzE2MzYzNzc1YWlybWFp bG9uLCBsaS5tLTYzNTExNDA0NTE3MTYzNjM3NzVhaXJtYWlsb24sIGRpdi5tLTYzNTExNDA0NTE3 MTYzNjM3NzVhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6bV8tNjM1MTE0MDQ1MTcxNjM2Mzc3 NWFpcm1haWxvbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubS02 MzUxMTQwNDUxNzE2MzYzNzc1bXNvcGxhaW50ZXh0LCBsaS5tLTYzNTExNDA0NTE3MTYzNjM3NzVt c29wbGFpbnRleHQsIGRpdi5tLTYzNTExNDA0NTE3MTYzNjM3NzVtc29wbGFpbnRleHQNCgl7bXNv LXN0eWxlLW5hbWU6bV8tNjM1MTE0MDQ1MTcxNjM2Mzc3NW1zb3BsYWludGV4dDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4ubS02MzUxMTQwNDUxNzE2MzYzNzc1 YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOm1fLTYzNTExNDA0NTE3MTYz NjM3NzVhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6MzM0MTg0OTcyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo2MjgyMzA4ODI7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo0NjgzMjM4NTI7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjkyNzA4MzgzODt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlk Ojg5MTMwNjUzNDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExOTE5NjI4MzY7fQ0KQGxpc3Qg bDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxMTU3MTgzNDQ2Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTgzOTY3NzY5NiA2ODY0Mjk5MTAgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo2MTc7DQoJ bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGw0DQoJe21zby1saXN0LWlkOjE0ODM2MTkzNDM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x MTY5NzY4MzQ2O30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MjAyMDgxNTU3MzsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE5MDc4MjU4 NjQgMTkyMDkwNDE2OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsNTpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjYxNzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDU6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsNTps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1Omxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDU6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDUgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPk9yIGFub3RoZXIgd2F5IG9mIHNvbHZpbmcg dGhlIGlzc3VlIHdpbGwgYmUgdG8gYWx3YXlzIHJvdXRlIHRoZSBwYWNrZXQgYmFzZWQgb24gQ0lE LCB0aGVuIGZvcndhcmQgdGhlIHBhY2tldCBiZXR3ZWVuIHRoZSBlbmRwb2ludHMgYmVoaW5kIHRo ZSBsb2FkIGJhbGFuY2VyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbiI+VGhpcyB3b3VsZCBub3QgcmVhbGx5 IHdvcmsgZm9yIGEgZ2xvYmFsIGxvYWQgYmFsYW5jZXIg4oCTIHRoZSBvbmUgY2FwYWJsZSBvZiBm b3J3YXJkaW5nIGFjcm9zcyBhIGNvbnRpbmVudCB0byBhIGRpZmZlcmVudCBhbnljYXN0IHBvcCAo ZHVlIHRvIGNsaWVudOKAmXMgY2hhbmdlIGluIGF0dGFjaG1lbnQgcG9pbnQgb3IgQkdQIHJlY29u dmVyZ2VuY2UpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb3Jlb3ZlciwgdGhlIHJvdXRpbmcg aW5mbyBpbiBhIHJhbmRvbSBDSUQgbWF5IGxvb2sg4oCcc3ludGFjdGljYWxseSB2YWxpZOKAnSBi dXQgYmUg4oCcc2VtYW50aWNhbGx5IGludmFsaWTigJ0gKHBvaW50aW5nIGF0IGEgZGVhZCBwYXRo IG9yIGEgc2V0IG9mIHNlcnZlcnMgbm90IGNhcGFibGUgb2Ygc2VydmluZyBRVUlDIHRyYWZmaWMp LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwv Yj4gTHViYXNoZXYsIElnb3IgW21haWx0bzppbHViYXNoZT00MGFrYW1haS5jb21AZG1hcmMuaWV0 Zi5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDA1LCAyMDE4IDI6MjEg UE08YnI+DQo8Yj5Ubzo8L2I+IEthenVobyBPa3UgJmx0O2thenVob29rdUBnbWFpbC5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBNaXJqYSBLw7xobGV3aW5kICZsdDttaXJqYS5rdWVobGV3aW5kQHRp ay5lZS5ldGh6LmNoJmd0OzsgQ2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5u ZXQmZ3Q7OyBNaWtlIEJpc2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUmZ3Q7OyBNaWtrZWwg RmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7OyBJRVRGIFFVSUMg V0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBGcmVkZXJpY2sgS2F1dHogJmx0O2ZrYXV0ekBhbHVt bmkuY211LmVkdSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFByaXZhY3kgaG9sZXMgKHdh czogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbik8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsNSBsZXZlbDEgbGZvMyI+ SXQgd291bGQgbm90LCAqaWYqIHRoZSBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlciBjYW4gQUVTLWRl Y3J5cHQgdGhlIHBhY2tldCAodXNpbmcgdGhlIGtleSBkZXJpdmVkIGZyb20gdGhlIHBhY2tldCBo ZWFkZXIpIHRvIHNlZSBpZiB0aGUgcGFja2V0IGlzIGluIGZhY3QgYSBpbml0aWFsIHBhY2tldC48 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGQgbm90IGl0IG5lZWQgdG8gZmlyc3Qg ZGVjaWRlIHRoYXQgdGhlIENJRCBpbiB0aGUgcGFja2V0IGlzIHVua25vd24gKHdoaWNoIG1lYW5z IHN0YXRlZnVsKT8mbmJzcDsgSXQgd291bGQgbmVlZCB0byBkbyBzb21lIGludGVncml0eSBjaGVj ayBvbiBDSUQsIHdoaWNoIHdvdWxkIHJlcXVpcmUgYSBsYXJnZSBub25jZSB0byBhdm9pZCBhY2Np ZGVudGFsbHkgY2xhc3NpZnlpbmcgYSByYW5kb20gQ0lEIGFzIHZhbGlkLA0KIGJlY2F1c2UgdGhl IGNvc3Qgb2YgdGhpcyBtaXN0YWtlIGNhbiBiZSB2ZXJ5IGxhcmdlIGZvciB0aGUgY2xpZW50IChz ZWUgYmVsb3cpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDUgbGV2ZWwxIGxmbzMiPk9yIGFu b3RoZXIgd2F5IG9mIHNvbHZpbmcgdGhlIGlzc3VlIHdpbGwgYmUgdG8gYWx3YXlzIHJvdXRlIHRo ZSBwYWNrZXQgYmFzZWQgb24gQ0lELCB0aGVuIGZvcndhcmQgdGhlIHBhY2tldCBiZXR3ZWVuIHRo ZSBlbmRwb2ludHMgYmVoaW5kIHRoZSBsb2FkIGJhbGFuY2VyLjxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlzIHdvdWxkIG5vdCByZWFsbHkgd29yayBmb3IgYSBnbG9iYWwgbG9hZCBi YWxhbmNlciDigJMgdGhlIG9uZSBjYXBhYmxlIG9mIGZvcndhcmRpbmcgYWNyb3NzIGEgY29udGlu ZW50IHRvIGEgZGlmZmVyZW50IGFueWNhc3QgcG9wIChkdWUgdG8gY2xpZW504oCZcyBjaGFuZ2Ug aW4gYXR0YWNobWVudCBwb2ludCBvciBCR1AgcmVjb252ZXJnZW5jZSkuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gS2F6 dWhvIE9rdSBbPGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iPm1haWx0bzprYXp1 aG9va3VAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwg MDUsIDIwMTggMjowOSBQTTxicj4NCjxiPlRvOjwvYj4gTHViYXNoZXYsIElnb3IgJmx0OzxhIGhy ZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIj5pbHViYXNoZUBha2FtYWkuY29tPC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0OzxhIGhyZWY9 Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT4mZ3Q7OyBN aWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIj5tYmlz aG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7OyBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0OzsN CiBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGll dGYub3JnPC9hPiZndDs7IE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzptaXJq YS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoIj5taXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6 LmNoPC9hPiZndDs7IEZyZWRlcmljayBLYXV0eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZrYXV0ekBh bHVtbmkuY211LmVkdSI+ZmthdXR6QGFsdW1uaS5jbXUuZWR1PC9hPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFByaXZhY3kgaG9sZXMgKHdhczogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3Vz IG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTgtMDQt MDYgMjo1OSBHTVQmIzQzOzA5OjAwIEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86 aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208 L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm83Ij4NCkknZCBwcmVmZXIgbWFr aW5nIGhhbmRzaGFrZSBwYWNrZXRzIGluZGlzdGluZ3Vpc2hhYmxlIGZyb20gc2hvcnQgaGVhZGVy IHBhY2tldHMuIEluIGVzc2VuY2UsIHlvdSBtb3ZlIHRoZSBmbGFncyBvZiB0aGUgbG9uZyBoZWFk ZXIgaW5zaWRlIHRoZSBBRUFELXByb3RlY3RlZCBhcmVhLiBBbiBlbmRwb2ludCB0aGF0IHJlY2Vp dmVzIGEgcGFja2V0IGNhcnJ5aW5nIGEgQ0lEIHRoYXQgZG9lcyBub3QgYmVsb25nIHRvIGFueSBr bm93biBjb25uZWN0aW9uDQogdHJpYWwtZGVjcnlwdHMgdGhlIHBhY2tldCBhcyBhIGluaXRpYWwg cGFja2V0IGFuZCBoYW5kbGVzIGl0IGFzIGEgY29ubmVjdGlvbiBpbml0aWF0aW9uLCBvciBzZW5k cyBhIHN0YXRlZnVsIHJlc2V0IGlmIHRoZSB0cmlhbC1kZWNyeXB0aW9uIGZhaWxzLjxvOnA+PC9v OnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIGNoYW5nZSB3b3VsZCB3 cmVjayBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlcnMgdGhhdCByZWx5IG9uIGJlaW5nIGFibGUgdG8g ZGlzdGluZ3Vpc2ggQ0kgcGFja2V0cyAoYW5kIHJvdXRlIHRoZW0gYmFzZWQgb24gSVBzKSBmcm9t IG90aGVyIHBhY2tldHMgKGFuZCByb3V0ZSB0aGVtIGJhc2VkIG9uIENJRCkuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXQgd291bGQgbm90LCAqaWYqIHRoZSBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlciBj YW4gQUVTLWRlY3J5cHQgdGhlIHBhY2tldCAodXNpbmcgdGhlIGtleSBkZXJpdmVkIGZyb20gdGhl IHBhY2tldCBoZWFkZXIpIHRvIHNlZSBpZiB0aGUgcGFja2V0IGlzIGluIGZhY3QgYSBpbml0aWFs IHBhY2tldC4gT3IgYW5vdGhlciB3YXkgb2Ygc29sdmluZyB0aGUgaXNzdWUgd2lsbCBiZSB0byBh bHdheXMgcm91dGUgdGhlIHBhY2tldA0KIGJhc2VkIG9uIENJRCwgdGhlbiBmb3J3YXJkIHRoZSBw YWNrZXQgYmV0d2VlbiB0aGUgZW5kcG9pbnRzIGJlaGluZCB0aGUgbG9hZCBiYWxhbmNlci48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3Jl ZSB0aGF0IGl0IHdvdWxkIGJlIGEgbm8tZGVhbCBmb3Igc3RhdGVsZXNzIGxvYWQgYmFsYW5jZXJz IHRoYXQgYXJlIGluY2FwYWJsZSBvZiBkb2luZyBzdWNoIHRoaW5ncy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBJZ29yPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IE1p a2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86bWlra2VsZmpA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9hPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMDUsIDIwMTggMTozMSBQTTxicj4NCjxiPlRv OjwvYj4gTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5i ZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPiZndDs7IENocmlzdGlh biBIdWl0ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCIgdGFyZ2V0 PSJfYmxhbmsiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0OzsgS2F6dWhvIE9rdSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXp1aG9v a3VAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3Jn PC9hPiZndDs7IE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzptaXJqYS5rdWVo bGV3aW5kQHRpay5lZS5ldGh6LmNoIiB0YXJnZXQ9Il9ibGFuayI+bWlyamEua3VlaGxld2luZEB0 aWsuZWUuZXRoei5jaDwvYT4mZ3Q7OyBGcmVkZXJpY2sgS2F1dHogJmx0OzxhIGhyZWY9Im1haWx0 bzpma2F1dHpAYWx1bW5pLmNtdS5lZHUiIHRhcmdldD0iX2JsYW5rIj5ma2F1dHpAYWx1bW5pLmNt dS5lZHU8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogUHJpdmFjeSBob2xlcyAod2Fz OiBSZTogR2V0dGluZyB0byBjb25zZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uKTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9Im1fLTYzNTExNDA0NTE3 MTYzNjM3NzVibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPkhpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibS02MzUxMTQwNDUxNzE2MzYzNzc1YWlybWFpbG9uIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+T24gNSBBcHJpbCAyMDE4IGF0IDE5LjI3LjI0LCBNaWtlIEJpc2hvcCAoPC9zcGFu PjxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPikNCiB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBw eCI+DQo8cCBjbGFzcz0ibS02MzUxMTQwNDUxNzE2MzYzNzc1bXNvcGxhaW50ZXh0IiBzdHlsZT0i bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBjbGFzcz0ibS02MzUx MTQwNDUxNzE2MzYzNzc1YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BbiBl bmRwb2ludCB0aGF0IHJlY2VpdmVzIGEgcGFja2V0IGNhcnJ5aW5nIGEgQ0lEIHRoYXQgZG9lcyBu b3QgYmVsb25nIHRvIGFueSBrbm93biBjb25uZWN0aW9uIHRyaWFsLWRlY3J5cHRzIHRoZSBwYWNr ZXQgYXMgYSBpbml0aWFsDQogcGFja2V0IGFuZCBoYW5kbGVzIGl0IGFzIGEgY29ubmVjdGlvbiBp bml0aWF0aW9uLCBvciBzZW5kcyBhIHN0YXRlZnVsIHJlc2V0IGlmIHRoZSB0cmlhbC1kZWNyeXB0 aW9uIGZhaWxzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgY2FuIHNlZSBoaWRpbmcgdGhpbmdzIG1heSBiZSBhIGdv b2QgdGhpbmcsIGJ1dCBoYXZpbmcgdG8gdHJpYWwgZGVjcnlwdCBhbGwgdW5rbm93biBwYWNrZXRz IGFzIHBvdGVudGlhbGx5IGNyZWF0aW5nIGEgaHVnZSBsb2FkLCB1bmxlc3MgeW91IGNvbWJpbmUg aXQgd2l0aCBteSBwcm9wb3NhbCB0byBhZGQgYSBjaGVja3N1bSB0bw0KIHRoZSBlbmNyeXB0ZWQg cGFja2V0IG51bWJlciBzbyB5b3Ugb25seSBuZWVkIG9uZSBjcnlwdG8gYmxvY2sgb24gYXZlcmFn ZSB0byByZWplY3QgcmFuZG9tIHBhY2tldCBjb250ZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5JdCB3b27igJl0IHNvbHZlIGFsbCBERG9TLCBidXQgaXQg d2lsbCBoZWxwLiBGb3JjaW5nIHRyaWFsIGRlY3J5cHRpb24gZm8gdGhlIGZ1bGwgcGFja2V0IG1h a2VzIG1lIGEgYml0IGFueGlvdXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5NaWtrZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkth enVobyBPa3U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_bb0a35e62e6d426baf7a36d3f2958da3usma1exdag1mb5msgcorpak_-- From nobody Thu Apr 5 11:28:18 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94ED412EA90 for ; Thu, 5 Apr 2018 11:28:06 -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=unavailable 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 Q0fDGmU_l3GK for ; Thu, 5 Apr 2018 11:28:03 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77DD12E8D9 for ; Thu, 5 Apr 2018 11:28:03 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w35IMwVC011150; Thu, 5 Apr 2018 19:27:52 +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=DCd5RwCmO26qeIHHbSG6YjyjVXDnjDMm9G7ltF1nhfQ=; b=a8tsmB1jN11IPZPND8rw92HJqAhuv0gjK3z4acKZd0Ep4dYudtsbIIWalFlAk/kRS8Yz PLB+dcx9njnGqpxf0WKcAP6yOIpDY0Rr5xj8fn/flZFxOnDfaDttrhRbbzlAqa31qXHq mnQUFKnu+FTNOGTJvAUz9OQy4pyJq2F4f3DehD6/T3UhXTLArqSPeGYQMBV1X1w5lmbI FS8Yjid5eZvaGhYPlEsmD/LWZ0ZMWwtzvjJ7ZR6aXJBZ5IT/+kl8/Pm+xeXpmR90I9oa QjES6ucMlD0C4qMoakdXu0aKye1F1Aet+oQ5oo+JlkkxlJMb2clWi/iOUEPehPQ8rcZy aw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2h4hphwp85-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 19:27:51 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w35IRovr013999; Thu, 5 Apr 2018 14:27:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2h25nxcasa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 14:27:41 -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.1365.1; Thu, 5 Apr 2018 14:27:24 -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.1365.000; Thu, 5 Apr 2018 14:27:24 -0400 From: "Lubashev, Igor" To: "Lubashev, Igor" , Kazuho Oku CC: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Christian Huitema , Mike Bishop , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "IETF QUIC WG" , Frederick Kautz Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Index: AQHTzPOeCspMmk/31UumuO1CInS8X6PylyoAgAACsQCAABOkAIAAAk8AgAABDID//8BxoIAASkOA//+9aUCAAAPCYA== Date: Thu, 5 Apr 2018 18:27:23 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.87] Content-Type: multipart/alternative; boundary="_000_bb0a35e62e6d426baf7a36d3f2958da3usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050187 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050186 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 18:28:16 -0000 --_000_bb0a35e62e6d426baf7a36d3f2958da3usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIE9yIGFub3RoZXIgd2F5IG9mIHNvbHZpbmcgdGhlIGlzc3VlIHdpbGwgYmUgdG8gYWx3YXlz IHJvdXRlIHRoZSBwYWNrZXQgYmFzZWQgb24gQ0lELCB0aGVuIGZvcndhcmQgdGhlIHBhY2tldCBi ZXR3ZWVuIHRoZSBlbmRwb2ludHMgYmVoaW5kIHRoZSBsb2FkIGJhbGFuY2VyLg0KDQpUaGlzIHdv dWxkIG5vdCByZWFsbHkgd29yayBmb3IgYSBnbG9iYWwgbG9hZCBiYWxhbmNlciDigJMgdGhlIG9u ZSBjYXBhYmxlIG9mIGZvcndhcmRpbmcgYWNyb3NzIGEgY29udGluZW50IHRvIGEgZGlmZmVyZW50 IGFueWNhc3QgcG9wIChkdWUgdG8gY2xpZW504oCZcyBjaGFuZ2UgaW4gYXR0YWNobWVudCBwb2lu dCBvciBCR1AgcmVjb252ZXJnZW5jZSkuDQoNCk1vcmVvdmVyLCB0aGUgcm91dGluZyBpbmZvIGlu IGEgcmFuZG9tIENJRCBtYXkgbG9vayDigJxzeW50YWN0aWNhbGx5IHZhbGlk4oCdIGJ1dCBiZSDi gJxzZW1hbnRpY2FsbHkgaW52YWxpZOKAnSAocG9pbnRpbmcgYXQgYSBkZWFkIHBhdGggb3IgYSBz ZXQgb2Ygc2VydmVycyBub3QgY2FwYWJsZSBvZiBzZXJ2aW5nIFFVSUMgdHJhZmZpYykuDQoNCg0K RnJvbTogTHViYXNoZXYsIElnb3IgW21haWx0bzppbHViYXNoZT00MGFrYW1haS5jb21AZG1hcmMu aWV0Zi5vcmddDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDUsIDIwMTggMjoyMSBQTQ0KVG86IEth enVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpDYzogTWlyamEgS8O8aGxld2luZCA8bWly amEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1h QGh1aXRlbWEubmV0PjsgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPjsgTWlra2Vs IEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPjsgSUVURiBRVUlDIFdHIDxx dWljQGlldGYub3JnPjsgRnJlZGVyaWNrIEthdXR6IDxma2F1dHpAYWx1bW5pLmNtdS5lZHU+DQpT dWJqZWN0OiBSRTogUHJpdmFjeSBob2xlcyAod2FzOiBSZTogR2V0dGluZyB0byBjb25zZW5zdXMg b24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uKQ0KDQoNCiAgKiAgIEl0IHdvdWxkIG5vdCwgKmlm KiB0aGUgc3RhdGVsZXNzIGxvYWQgYmFsYW5jZXIgY2FuIEFFUy1kZWNyeXB0IHRoZSBwYWNrZXQg KHVzaW5nIHRoZSBrZXkgZGVyaXZlZCBmcm9tIHRoZSBwYWNrZXQgaGVhZGVyKSB0byBzZWUgaWYg dGhlIHBhY2tldCBpcyBpbiBmYWN0IGEgaW5pdGlhbCBwYWNrZXQuDQoNCldvdWxkIG5vdCBpdCBu ZWVkIHRvIGZpcnN0IGRlY2lkZSB0aGF0IHRoZSBDSUQgaW4gdGhlIHBhY2tldCBpcyB1bmtub3du ICh3aGljaCBtZWFucyBzdGF0ZWZ1bCk/ICBJdCB3b3VsZCBuZWVkIHRvIGRvIHNvbWUgaW50ZWdy aXR5IGNoZWNrIG9uIENJRCwgd2hpY2ggd291bGQgcmVxdWlyZSBhIGxhcmdlIG5vbmNlIHRvIGF2 b2lkIGFjY2lkZW50YWxseSBjbGFzc2lmeWluZyBhIHJhbmRvbSBDSUQgYXMgdmFsaWQsIGJlY2F1 c2UgdGhlIGNvc3Qgb2YgdGhpcyBtaXN0YWtlIGNhbiBiZSB2ZXJ5IGxhcmdlIGZvciB0aGUgY2xp ZW50IChzZWUgYmVsb3cpLg0KDQoNCiAgKiAgIE9yIGFub3RoZXIgd2F5IG9mIHNvbHZpbmcgdGhl IGlzc3VlIHdpbGwgYmUgdG8gYWx3YXlzIHJvdXRlIHRoZSBwYWNrZXQgYmFzZWQgb24gQ0lELCB0 aGVuIGZvcndhcmQgdGhlIHBhY2tldCBiZXR3ZWVuIHRoZSBlbmRwb2ludHMgYmVoaW5kIHRoZSBs b2FkIGJhbGFuY2VyLg0KDQpUaGlzIHdvdWxkIG5vdCByZWFsbHkgd29yayBmb3IgYSBnbG9iYWwg bG9hZCBiYWxhbmNlciDigJMgdGhlIG9uZSBjYXBhYmxlIG9mIGZvcndhcmRpbmcgYWNyb3NzIGEg Y29udGluZW50IHRvIGEgZGlmZmVyZW50IGFueWNhc3QgcG9wIChkdWUgdG8gY2xpZW504oCZcyBj aGFuZ2UgaW4gYXR0YWNobWVudCBwb2ludCBvciBCR1AgcmVjb252ZXJnZW5jZSkuDQoNCg0KDQpG cm9tOiBLYXp1aG8gT2t1IFttYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbV0NClNlbnQ6IFRodXJz ZGF5LCBBcHJpbCAwNSwgMjAxOCAyOjA5IFBNDQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hl QGFrYW1haS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+Pg0KQ2M6IE1pa2tlbCBGYWhu w7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwu Y29tPj47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBl dmVxdWVmb3UuYmU+PjsgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ8bWFp bHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1h aWx0bzpxdWljQGlldGYub3JnPj47IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRA dGlrLmVlLmV0aHouY2g8bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+Pjsg RnJlZGVyaWNrIEthdXR6IDxma2F1dHpAYWx1bW5pLmNtdS5lZHU8bWFpbHRvOmZrYXV0ekBhbHVt bmkuY211LmVkdT4+DQpTdWJqZWN0OiBSZTogUHJpdmFjeSBob2xlcyAod2FzOiBSZTogR2V0dGlu ZyB0byBjb25zZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uKQ0KDQoNCg0KMjAxOC0w NC0wNiAyOjU5IEdNVCswOTowMCBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxt YWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+Og0KDQogICogICBJJ2QgcHJlZmVyIG1ha2luZyBo YW5kc2hha2UgcGFja2V0cyBpbmRpc3Rpbmd1aXNoYWJsZSBmcm9tIHNob3J0IGhlYWRlciBwYWNr ZXRzLiBJbiBlc3NlbmNlLCB5b3UgbW92ZSB0aGUgZmxhZ3Mgb2YgdGhlIGxvbmcgaGVhZGVyIGlu c2lkZSB0aGUgQUVBRC1wcm90ZWN0ZWQgYXJlYS4gQW4gZW5kcG9pbnQgdGhhdCByZWNlaXZlcyBh IHBhY2tldCBjYXJyeWluZyBhIENJRCB0aGF0IGRvZXMgbm90IGJlbG9uZyB0byBhbnkga25vd24g Y29ubmVjdGlvbiB0cmlhbC1kZWNyeXB0cyB0aGUgcGFja2V0IGFzIGEgaW5pdGlhbCBwYWNrZXQg YW5kIGhhbmRsZXMgaXQgYXMgYSBjb25uZWN0aW9uIGluaXRpYXRpb24sIG9yIHNlbmRzIGEgc3Rh dGVmdWwgcmVzZXQgaWYgdGhlIHRyaWFsLWRlY3J5cHRpb24gZmFpbHMuDQpUaGlzIGNoYW5nZSB3 b3VsZCB3cmVjayBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlcnMgdGhhdCByZWx5IG9uIGJlaW5nIGFi bGUgdG8gZGlzdGluZ3Vpc2ggQ0kgcGFja2V0cyAoYW5kIHJvdXRlIHRoZW0gYmFzZWQgb24gSVBz KSBmcm9tIG90aGVyIHBhY2tldHMgKGFuZCByb3V0ZSB0aGVtIGJhc2VkIG9uIENJRCkuDQoNCkl0 IHdvdWxkIG5vdCwgKmlmKiB0aGUgc3RhdGVsZXNzIGxvYWQgYmFsYW5jZXIgY2FuIEFFUy1kZWNy eXB0IHRoZSBwYWNrZXQgKHVzaW5nIHRoZSBrZXkgZGVyaXZlZCBmcm9tIHRoZSBwYWNrZXQgaGVh ZGVyKSB0byBzZWUgaWYgdGhlIHBhY2tldCBpcyBpbiBmYWN0IGEgaW5pdGlhbCBwYWNrZXQuIE9y IGFub3RoZXIgd2F5IG9mIHNvbHZpbmcgdGhlIGlzc3VlIHdpbGwgYmUgdG8gYWx3YXlzIHJvdXRl IHRoZSBwYWNrZXQgYmFzZWQgb24gQ0lELCB0aGVuIGZvcndhcmQgdGhlIHBhY2tldCBiZXR3ZWVu IHRoZSBlbmRwb2ludHMgYmVoaW5kIHRoZSBsb2FkIGJhbGFuY2VyLg0KDQpJIGFncmVlIHRoYXQg aXQgd291bGQgYmUgYSBuby1kZWFsIGZvciBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlcnMgdGhhdCBh cmUgaW5jYXBhYmxlIG9mIGRvaW5nIHN1Y2ggdGhpbmdzLg0KDQoNCi0gSWdvcg0KDQpGcm9tOiBN aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86bWlra2VsZmpAZ21haWwuY29tPG1haWx0 bzptaWtrZWxmakBnbWFpbC5jb20+XQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDA1LCAyMDE4IDE6 MzEgUE0NClRvOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNo b3BAZXZlcXVlZm91LmJlPj47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0 PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj47IEthenVobyBPa3UgPGthenVob29rdUBnbWFp bC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5jb20+Pg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVp Y0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBNaXJqYSBLw7xobGV3aW5kIDxtaXJq YS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPG1haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5l ZS5ldGh6LmNoPj47IEZyZWRlcmljayBLYXV0eiA8ZmthdXR6QGFsdW1uaS5jbXUuZWR1PG1haWx0 bzpma2F1dHpAYWx1bW5pLmNtdS5lZHU+Pg0KU3ViamVjdDogUkU6IFByaXZhY3kgaG9sZXMgKHdh czogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbikN Cg0KSGkNCg0KDQpPbiA1IEFwcmlsIDIwMTggYXQgMTkuMjcuMjQsIE1pa2UgQmlzaG9wIChtYmlz aG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+KSB3cm90ZToNCg0K IEFuIGVuZHBvaW50IHRoYXQgcmVjZWl2ZXMgYSBwYWNrZXQgY2FycnlpbmcgYSBDSUQgdGhhdCBk b2VzIG5vdCBiZWxvbmcgdG8gYW55IGtub3duIGNvbm5lY3Rpb24gdHJpYWwtZGVjcnlwdHMgdGhl IHBhY2tldCBhcyBhIGluaXRpYWwgcGFja2V0IGFuZCBoYW5kbGVzIGl0IGFzIGEgY29ubmVjdGlv biBpbml0aWF0aW9uLCBvciBzZW5kcyBhIHN0YXRlZnVsIHJlc2V0IGlmIHRoZSB0cmlhbC1kZWNy eXB0aW9uIGZhaWxzLg0KDQpJIGNhbiBzZWUgaGlkaW5nIHRoaW5ncyBtYXkgYmUgYSBnb29kIHRo aW5nLCBidXQgaGF2aW5nIHRvIHRyaWFsIGRlY3J5cHQgYWxsIHVua25vd24gcGFja2V0cyBhcyBw b3RlbnRpYWxseSBjcmVhdGluZyBhIGh1Z2UgbG9hZCwgdW5sZXNzIHlvdSBjb21iaW5lIGl0IHdp dGggbXkgcHJvcG9zYWwgdG8gYWRkIGEgY2hlY2tzdW0gdG8gdGhlIGVuY3J5cHRlZCBwYWNrZXQg bnVtYmVyIHNvIHlvdSBvbmx5IG5lZWQgb25lIGNyeXB0byBibG9jayBvbiBhdmVyYWdlIHRvIHJl amVjdCByYW5kb20gcGFja2V0IGNvbnRlbnQuDQoNCkl0IHdvbuKAmXQgc29sdmUgYWxsIEREb1Ms IGJ1dCBpdCB3aWxsIGhlbHAuIEZvcmNpbmcgdHJpYWwgZGVjcnlwdGlvbiBmbyB0aGUgZnVsbCBw YWNrZXQgbWFrZXMgbWUgYSBiaXQgYW54aW91cy4NCg0KDQoNCk1pa2tlbA0KDQoNCg0KDQoNCi0t DQpLYXp1aG8gT2t1DQo= --_000_bb0a35e62e6d426baf7a36d3f2958da3usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubS02MzUxMTQwNDUxNzE2MzYzNzc1YWlybWFp bG9uLCBsaS5tLTYzNTExNDA0NTE3MTYzNjM3NzVhaXJtYWlsb24sIGRpdi5tLTYzNTExNDA0NTE3 MTYzNjM3NzVhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6bV8tNjM1MTE0MDQ1MTcxNjM2Mzc3 NWFpcm1haWxvbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubS02 MzUxMTQwNDUxNzE2MzYzNzc1bXNvcGxhaW50ZXh0LCBsaS5tLTYzNTExNDA0NTE3MTYzNjM3NzVt c29wbGFpbnRleHQsIGRpdi5tLTYzNTExNDA0NTE3MTYzNjM3NzVtc29wbGFpbnRleHQNCgl7bXNv LXN0eWxlLW5hbWU6bV8tNjM1MTE0MDQ1MTcxNjM2Mzc3NW1zb3BsYWludGV4dDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4ubS02MzUxMTQwNDUxNzE2MzYzNzc1 YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOm1fLTYzNTExNDA0NTE3MTYz NjM3NzVhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6MzM0MTg0OTcyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo2MjgyMzA4ODI7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo0NjgzMjM4NTI7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjkyNzA4MzgzODt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlk Ojg5MTMwNjUzNDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExOTE5NjI4MzY7fQ0KQGxpc3Qg bDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxMTU3MTgzNDQ2Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTgzOTY3NzY5NiA2ODY0Mjk5MTAgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo2MTc7DQoJ bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGw0DQoJe21zby1saXN0LWlkOjE0ODM2MTkzNDM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x MTY5NzY4MzQ2O30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MjAyMDgxNTU3MzsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE5MDc4MjU4 NjQgMTkyMDkwNDE2OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsNTpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjYxNzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDU6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsNTps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1Omxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDU6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDUgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPk9yIGFub3RoZXIgd2F5IG9mIHNvbHZpbmcg dGhlIGlzc3VlIHdpbGwgYmUgdG8gYWx3YXlzIHJvdXRlIHRoZSBwYWNrZXQgYmFzZWQgb24gQ0lE LCB0aGVuIGZvcndhcmQgdGhlIHBhY2tldCBiZXR3ZWVuIHRoZSBlbmRwb2ludHMgYmVoaW5kIHRo ZSBsb2FkIGJhbGFuY2VyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbiI+VGhpcyB3b3VsZCBub3QgcmVhbGx5 IHdvcmsgZm9yIGEgZ2xvYmFsIGxvYWQgYmFsYW5jZXIg4oCTIHRoZSBvbmUgY2FwYWJsZSBvZiBm b3J3YXJkaW5nIGFjcm9zcyBhIGNvbnRpbmVudCB0byBhIGRpZmZlcmVudCBhbnljYXN0IHBvcCAo ZHVlIHRvIGNsaWVudOKAmXMgY2hhbmdlIGluIGF0dGFjaG1lbnQgcG9pbnQgb3IgQkdQIHJlY29u dmVyZ2VuY2UpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb3Jlb3ZlciwgdGhlIHJvdXRpbmcg aW5mbyBpbiBhIHJhbmRvbSBDSUQgbWF5IGxvb2sg4oCcc3ludGFjdGljYWxseSB2YWxpZOKAnSBi dXQgYmUg4oCcc2VtYW50aWNhbGx5IGludmFsaWTigJ0gKHBvaW50aW5nIGF0IGEgZGVhZCBwYXRo IG9yIGEgc2V0IG9mIHNlcnZlcnMgbm90IGNhcGFibGUgb2Ygc2VydmluZyBRVUlDIHRyYWZmaWMp LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwv Yj4gTHViYXNoZXYsIElnb3IgW21haWx0bzppbHViYXNoZT00MGFrYW1haS5jb21AZG1hcmMuaWV0 Zi5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDA1LCAyMDE4IDI6MjEg UE08YnI+DQo8Yj5Ubzo8L2I+IEthenVobyBPa3UgJmx0O2thenVob29rdUBnbWFpbC5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBNaXJqYSBLw7xobGV3aW5kICZsdDttaXJqYS5rdWVobGV3aW5kQHRp ay5lZS5ldGh6LmNoJmd0OzsgQ2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5u ZXQmZ3Q7OyBNaWtlIEJpc2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUmZ3Q7OyBNaWtrZWwg RmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7OyBJRVRGIFFVSUMg V0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBGcmVkZXJpY2sgS2F1dHogJmx0O2ZrYXV0ekBhbHVt bmkuY211LmVkdSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFByaXZhY3kgaG9sZXMgKHdh czogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbik8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsNSBsZXZlbDEgbGZvMyI+ SXQgd291bGQgbm90LCAqaWYqIHRoZSBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlciBjYW4gQUVTLWRl Y3J5cHQgdGhlIHBhY2tldCAodXNpbmcgdGhlIGtleSBkZXJpdmVkIGZyb20gdGhlIHBhY2tldCBo ZWFkZXIpIHRvIHNlZSBpZiB0aGUgcGFja2V0IGlzIGluIGZhY3QgYSBpbml0aWFsIHBhY2tldC48 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGQgbm90IGl0IG5lZWQgdG8gZmlyc3Qg ZGVjaWRlIHRoYXQgdGhlIENJRCBpbiB0aGUgcGFja2V0IGlzIHVua25vd24gKHdoaWNoIG1lYW5z IHN0YXRlZnVsKT8mbmJzcDsgSXQgd291bGQgbmVlZCB0byBkbyBzb21lIGludGVncml0eSBjaGVj ayBvbiBDSUQsIHdoaWNoIHdvdWxkIHJlcXVpcmUgYSBsYXJnZSBub25jZSB0byBhdm9pZCBhY2Np ZGVudGFsbHkgY2xhc3NpZnlpbmcgYSByYW5kb20gQ0lEIGFzIHZhbGlkLA0KIGJlY2F1c2UgdGhl IGNvc3Qgb2YgdGhpcyBtaXN0YWtlIGNhbiBiZSB2ZXJ5IGxhcmdlIGZvciB0aGUgY2xpZW50IChz ZWUgYmVsb3cpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDUgbGV2ZWwxIGxmbzMiPk9yIGFu b3RoZXIgd2F5IG9mIHNvbHZpbmcgdGhlIGlzc3VlIHdpbGwgYmUgdG8gYWx3YXlzIHJvdXRlIHRo ZSBwYWNrZXQgYmFzZWQgb24gQ0lELCB0aGVuIGZvcndhcmQgdGhlIHBhY2tldCBiZXR3ZWVuIHRo ZSBlbmRwb2ludHMgYmVoaW5kIHRoZSBsb2FkIGJhbGFuY2VyLjxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlzIHdvdWxkIG5vdCByZWFsbHkgd29yayBmb3IgYSBnbG9iYWwgbG9hZCBi YWxhbmNlciDigJMgdGhlIG9uZSBjYXBhYmxlIG9mIGZvcndhcmRpbmcgYWNyb3NzIGEgY29udGlu ZW50IHRvIGEgZGlmZmVyZW50IGFueWNhc3QgcG9wIChkdWUgdG8gY2xpZW504oCZcyBjaGFuZ2Ug aW4gYXR0YWNobWVudCBwb2ludCBvciBCR1AgcmVjb252ZXJnZW5jZSkuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gS2F6 dWhvIE9rdSBbPGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iPm1haWx0bzprYXp1 aG9va3VAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwg MDUsIDIwMTggMjowOSBQTTxicj4NCjxiPlRvOjwvYj4gTHViYXNoZXYsIElnb3IgJmx0OzxhIGhy ZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIj5pbHViYXNoZUBha2FtYWkuY29tPC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0OzxhIGhyZWY9 Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT4mZ3Q7OyBN aWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIj5tYmlz aG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7OyBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0OzsN CiBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGll dGYub3JnPC9hPiZndDs7IE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzptaXJq YS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoIj5taXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6 LmNoPC9hPiZndDs7IEZyZWRlcmljayBLYXV0eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZrYXV0ekBh bHVtbmkuY211LmVkdSI+ZmthdXR6QGFsdW1uaS5jbXUuZWR1PC9hPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFByaXZhY3kgaG9sZXMgKHdhczogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3Vz IG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTgtMDQt MDYgMjo1OSBHTVQmIzQzOzA5OjAwIEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86 aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208 L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm83Ij4NCkknZCBwcmVmZXIgbWFr aW5nIGhhbmRzaGFrZSBwYWNrZXRzIGluZGlzdGluZ3Vpc2hhYmxlIGZyb20gc2hvcnQgaGVhZGVy IHBhY2tldHMuIEluIGVzc2VuY2UsIHlvdSBtb3ZlIHRoZSBmbGFncyBvZiB0aGUgbG9uZyBoZWFk ZXIgaW5zaWRlIHRoZSBBRUFELXByb3RlY3RlZCBhcmVhLiBBbiBlbmRwb2ludCB0aGF0IHJlY2Vp dmVzIGEgcGFja2V0IGNhcnJ5aW5nIGEgQ0lEIHRoYXQgZG9lcyBub3QgYmVsb25nIHRvIGFueSBr bm93biBjb25uZWN0aW9uDQogdHJpYWwtZGVjcnlwdHMgdGhlIHBhY2tldCBhcyBhIGluaXRpYWwg cGFja2V0IGFuZCBoYW5kbGVzIGl0IGFzIGEgY29ubmVjdGlvbiBpbml0aWF0aW9uLCBvciBzZW5k cyBhIHN0YXRlZnVsIHJlc2V0IGlmIHRoZSB0cmlhbC1kZWNyeXB0aW9uIGZhaWxzLjxvOnA+PC9v OnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIGNoYW5nZSB3b3VsZCB3 cmVjayBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlcnMgdGhhdCByZWx5IG9uIGJlaW5nIGFibGUgdG8g ZGlzdGluZ3Vpc2ggQ0kgcGFja2V0cyAoYW5kIHJvdXRlIHRoZW0gYmFzZWQgb24gSVBzKSBmcm9t IG90aGVyIHBhY2tldHMgKGFuZCByb3V0ZSB0aGVtIGJhc2VkIG9uIENJRCkuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXQgd291bGQgbm90LCAqaWYqIHRoZSBzdGF0ZWxlc3MgbG9hZCBiYWxhbmNlciBj YW4gQUVTLWRlY3J5cHQgdGhlIHBhY2tldCAodXNpbmcgdGhlIGtleSBkZXJpdmVkIGZyb20gdGhl IHBhY2tldCBoZWFkZXIpIHRvIHNlZSBpZiB0aGUgcGFja2V0IGlzIGluIGZhY3QgYSBpbml0aWFs IHBhY2tldC4gT3IgYW5vdGhlciB3YXkgb2Ygc29sdmluZyB0aGUgaXNzdWUgd2lsbCBiZSB0byBh bHdheXMgcm91dGUgdGhlIHBhY2tldA0KIGJhc2VkIG9uIENJRCwgdGhlbiBmb3J3YXJkIHRoZSBw YWNrZXQgYmV0d2VlbiB0aGUgZW5kcG9pbnRzIGJlaGluZCB0aGUgbG9hZCBiYWxhbmNlci48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3Jl ZSB0aGF0IGl0IHdvdWxkIGJlIGEgbm8tZGVhbCBmb3Igc3RhdGVsZXNzIGxvYWQgYmFsYW5jZXJz IHRoYXQgYXJlIGluY2FwYWJsZSBvZiBkb2luZyBzdWNoIHRoaW5ncy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBJZ29yPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IE1p a2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86bWlra2VsZmpA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9hPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMDUsIDIwMTggMTozMSBQTTxicj4NCjxiPlRv OjwvYj4gTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5i ZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPiZndDs7IENocmlzdGlh biBIdWl0ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCIgdGFyZ2V0 PSJfYmxhbmsiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0OzsgS2F6dWhvIE9rdSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXp1aG9v a3VAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3Jn PC9hPiZndDs7IE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzptaXJqYS5rdWVo bGV3aW5kQHRpay5lZS5ldGh6LmNoIiB0YXJnZXQ9Il9ibGFuayI+bWlyamEua3VlaGxld2luZEB0 aWsuZWUuZXRoei5jaDwvYT4mZ3Q7OyBGcmVkZXJpY2sgS2F1dHogJmx0OzxhIGhyZWY9Im1haWx0 bzpma2F1dHpAYWx1bW5pLmNtdS5lZHUiIHRhcmdldD0iX2JsYW5rIj5ma2F1dHpAYWx1bW5pLmNt dS5lZHU8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogUHJpdmFjeSBob2xlcyAod2Fz OiBSZTogR2V0dGluZyB0byBjb25zZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uKTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9Im1fLTYzNTExNDA0NTE3 MTYzNjM3NzVibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPkhpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibS02MzUxMTQwNDUxNzE2MzYzNzc1YWlybWFpbG9uIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+T24gNSBBcHJpbCAyMDE4IGF0IDE5LjI3LjI0LCBNaWtlIEJpc2hvcCAoPC9zcGFu PjxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPikNCiB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBw eCI+DQo8cCBjbGFzcz0ibS02MzUxMTQwNDUxNzE2MzYzNzc1bXNvcGxhaW50ZXh0IiBzdHlsZT0i bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBjbGFzcz0ibS02MzUx MTQwNDUxNzE2MzYzNzc1YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BbiBl bmRwb2ludCB0aGF0IHJlY2VpdmVzIGEgcGFja2V0IGNhcnJ5aW5nIGEgQ0lEIHRoYXQgZG9lcyBu b3QgYmVsb25nIHRvIGFueSBrbm93biBjb25uZWN0aW9uIHRyaWFsLWRlY3J5cHRzIHRoZSBwYWNr ZXQgYXMgYSBpbml0aWFsDQogcGFja2V0IGFuZCBoYW5kbGVzIGl0IGFzIGEgY29ubmVjdGlvbiBp bml0aWF0aW9uLCBvciBzZW5kcyBhIHN0YXRlZnVsIHJlc2V0IGlmIHRoZSB0cmlhbC1kZWNyeXB0 aW9uIGZhaWxzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgY2FuIHNlZSBoaWRpbmcgdGhpbmdzIG1heSBiZSBhIGdv b2QgdGhpbmcsIGJ1dCBoYXZpbmcgdG8gdHJpYWwgZGVjcnlwdCBhbGwgdW5rbm93biBwYWNrZXRz IGFzIHBvdGVudGlhbGx5IGNyZWF0aW5nIGEgaHVnZSBsb2FkLCB1bmxlc3MgeW91IGNvbWJpbmUg aXQgd2l0aCBteSBwcm9wb3NhbCB0byBhZGQgYSBjaGVja3N1bSB0bw0KIHRoZSBlbmNyeXB0ZWQg cGFja2V0IG51bWJlciBzbyB5b3Ugb25seSBuZWVkIG9uZSBjcnlwdG8gYmxvY2sgb24gYXZlcmFn ZSB0byByZWplY3QgcmFuZG9tIHBhY2tldCBjb250ZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5JdCB3b27igJl0IHNvbHZlIGFsbCBERG9TLCBidXQgaXQg d2lsbCBoZWxwLiBGb3JjaW5nIHRyaWFsIGRlY3J5cHRpb24gZm8gdGhlIGZ1bGwgcGFja2V0IG1h a2VzIG1lIGEgYml0IGFueGlvdXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5NaWtrZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkth enVobyBPa3U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_bb0a35e62e6d426baf7a36d3f2958da3usma1exdag1mb5msgcorpak_-- From nobody Thu Apr 5 11:33:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C342D12D94D for ; Thu, 5 Apr 2018 11:33:46 -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, 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 (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 LGTLXh_X-MKx for ; Thu, 5 Apr 2018 11:33:44 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0090.outbound.protection.outlook.com [104.47.36.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A0E124C27 for ; Thu, 5 Apr 2018 11:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JXB2zkh6OMf8OWKxd+81fyG3X0MkAIA7slMc0D0Niig=; b=mLJThOLCXHGFwph7T35aasClF8fLbZsmweSx0ZSqRmE7NaHcTtHE465KLkd8N89SJCPBranqXQyg9L8n4FNgwujkgSaEY3hhDmDGyqjXvUbL/WRhO9cyfgBZX7ysh4d0PoP184pkxa5SVkp20w3ZU7nbZbjzfxcRUKB+yI2cTy0= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0135.namprd21.prod.outlook.com (10.173.189.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Thu, 5 Apr 2018 18:33:41 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Thu, 5 Apr 2018 18:33:41 +0000 From: Praveen Balasubramanian To: "Brian Trammell (IETF)" , Lars Eggert CC: Mark Nottingham , IETF QUIC WG , Martin Thomson , Patrick McManus , Kazuho Oku Subject: RE: ECN signaling from userland Re: Getting to consensus on packet number encryption Thread-Topic: ECN signaling from userland Re: Getting to consensus on packet number encryption Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwkIMAgADKCACAADzkAIAAJouAgAACNYCAAABvAIAAwCzw Date: Thu, 5 Apr 2018 18:33:41 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <3E5BCB0F-DEDE-4EBA-80DF-31E49764C0FE@trammell.ch> <0F07FB8F-A8D0-4F2B-8ED8-7230DF99EE7C@eggert.org> <8F38C971-5E0C-4C6D-B67F-7186D88AF034@trammell.ch> In-Reply-To: <8F38C971-5E0C-4C6D-B67F-7186D88AF034@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0135; 7:wrdhRuUC4iks8o9bY8PYO3FlrKFKxeDioX/UItYDP1eHJcZsUXYa4bO4DS1c3QYKGFHw2bw6catJ52wtF8D5LogqTDv7wmBc919BurwXzXtDfoh2oMHr/jGiOx+LOMKrD3SBYmQ65zL4+1GjaFsimRAMZQKGDI8EqjYyhfFyh9xYsByzphWisRK8YMzYUVz+OtW2uNz+UVjvhKuNmQVunYfVhsfj2gzhQXPqysboszFkhiyDYJcFVwY4x6WqaTs1; 20:DioOIVe/GUWOazzVB3DpQ9aSKYLksIqXKwhifbc9OIRCnYb//O2aM61oQLoWyQ+baEH1lOkD0MKsQQko7zoyBYJ8YWvWYiHulwJxJ+rS9sKMu7ahvvsMmcEC2gauYrGs0ca1Pqgif5/e9t1ADx1dA1hlsykQGhZcNQOMeEgZNhA= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8f62f1eb-ca9f-405a-a9c2-08d59b23c162 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0135; x-ms-traffictypediagnostic: CY4PR21MB0135: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(85827821059158)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0135; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0135; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(39860400002)(346002)(376002)(366004)(377424004)(13464003)(189003)(199004)(86612001)(105586002)(99286004)(186003)(106356001)(7696005)(316002)(102836004)(33656002)(76176011)(53546011)(6506007)(68736007)(110136005)(54906003)(93886005)(14454004)(7736002)(966005)(305945005)(22452003)(11346002)(446003)(4326008)(39060400002)(97736004)(10290500003)(4001150100001)(478600001)(25786009)(3280700002)(3660700001)(2906002)(5660300001)(74316002)(486006)(8676002)(229853002)(10090500001)(8936002)(81156014)(81166006)(476003)(6116002)(8990500004)(6436002)(9686003)(86362001)(6306002)(53936002)(6246003)(2900100001)(55016002)(5250100002)(46003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0135; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: V/MpA5mGo8cOsuB6hg3GNSXovf8XqXrS/CJPMs8PVLn5193Jh3zoWDAh+4ZaZyw+rRcF9c7hVNpW+zXv9CI25HWrQOvRl88b9eyETjmEN6WpWBXoRQlSqiZ8neXKS1z4cv/vELWZKw0yuPgjAh7oRrNLIEitDNHZTInAsH7bCNBOk4dKeGxdna+Fwhih3oLpLiBN9kjHibaMwFT1z1fw1E7D8LvJJHKmJTLedxNe46Ye6I5HAdqXK8fgo9we2OYygITh7VIeiiiIQvpYBiDuhvgqBysytGGYa9+VgYefb5eTBjcMROJttiY3Nqwqc4gyKE5YuEvJeFarS7EeXXnyV2Km2/W6ADuKSQR2I15w1RpEqk+MF4RK9hzH7zgQZRRGD2uEqjDT3eRaPfBWMrar0Y2QSAPZF6xzeYkVTf7jsJ0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f62f1eb-ca9f-405a-a9c2-08d59b23c162 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 18:33:41.2271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0135 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 18:33:47 -0000 Windows supports querying of the ECN bits (recvmsg) on recent versions but = does not yet support setting them (sendmsg). Adding support for set is on o= ur TODO list. Please see https://github.com/quicwg/base-drafts/wiki/ECN-in-= QUIC which has per OS details. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell (IETF= ) Sent: Thursday, April 5, 2018 12:03 AM To: Lars Eggert Cc: Mark Nottingham ; IETF QUIC WG ; Martin T= homson ; Patrick McManus ; = Kazuho Oku Subject: Re: ECN signaling from userland Re: Getting to consensus on packet= number encryption > On 5 Apr 2018, at 09:01, Lars Eggert wrote: >=20 > Hi, >=20 > On 2018-4-5, at 8:53, Brian Trammell (IETF) wrote: >> However, fixing kernel interface issues (as are at the root of UDP perfo= rmance problems, as well as the lack of ECN signaling from userland) takes = time >=20 > FWIW, ECN signaling is mostly only an issue on Windows at the moment. Mos= t other stacks can do this via ancillary data on sendmsg/recvmsg. I have te= sted Linux, FreeBSD and Darwin and they work (modulo a bug in Darwin on TX = that Apple is looking into.) Ah, I thought this was a more widely spread problem. Okay, cool, we can foc= us more on making UDP not suck then. :) Thanks, cheers, Brian From nobody Thu Apr 5 11:35:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC1312D94D for ; Thu, 5 Apr 2018 11:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uw3H8jlRwEZp for ; Thu, 5 Apr 2018 11:35:39 -0700 (PDT) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::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 3C456124C27 for ; Thu, 5 Apr 2018 11:35:39 -0700 (PDT) Received: by mail-pl0-x234.google.com with SMTP id s24-v6so20372083plq.6 for ; Thu, 05 Apr 2018 11:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Er96ffdZIEfi2eyqITJOBL5pE0GcWrlArDhcoDphqJo=; b=MCfFGDrNO5SgZ9KBnxXWu/3QnBhovl01S3e96ntSGBZwj8oPNMWJfn2oxte+g+QBzm r0aTyR0yoM583hF9BPgNg6127Iy9ZNnJ1v1GSTKW/vnwEyhrGpts7szVRAzo6eaBQjQy 0oqK/m83nuT6lPjMXyJK0SfYDPZ7IwIozP9CL6P4fEuh/hG420TUQ2vpgX4PiT+2eLJa NAXb3sSenkRrkVQsBSsVc422IY5l+CDyxZBrPnbfOJlwLrWzBrKRlrm4Msjk+ug3G1pc j+NLE8kvKdCJMw6T8W2RQL+h0DwOS/dsZKy1YPg/QuauPVd7no+3lEqdiktzwHJRSgFv W0Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=Er96ffdZIEfi2eyqITJOBL5pE0GcWrlArDhcoDphqJo=; b=dw7iGXMKZUSOEILz3u3ajvY5rHlgJUjgz0RTxUiS4T1HZCv6CePcluSt4tgKiExUue M5zzbvd6aVHvauNpIWXrCljQN2PPtfu+gYB5uBFEsDEAAz4MxvjAZ9GnVTVGlv1mw6EP HEk6A9fqFvLwvWNqxEKJFBiAqynfA2pM09vC2tGUs3wzxl9RO8UR5LSR3aij6EYxqkmp /xZOBhUV1ThB5uIVexIlCfGFJMfakCE6NtFMmSlCnUKyLBYYkZ6d9khHjwS5J05PaaUb 58bH6zZDTJosgeKmdePj/zhVSXq4h/Bd7Y+bCVnRYtD900FDi9c+zxykuHNk+57YGq1O X8PA== X-Gm-Message-State: AElRT7FEpUkp7MgsuvU7fYzO6foWIEURqHKn+oo+DkhZMftuPP7K7oqa 0pR5DxZpWCNRh9sznbiR6a/vJ1xSO3fj1k0rdRE= X-Google-Smtp-Source: AIpwx4/tZyas1DXeEQXscnLGx23wNihvVOQbbUKMw++KAzk4ByzDvS5E+0zBbuRtsZC2MMr1BmRkK5WJya3pyPtRrK8= X-Received: by 2002:a17:902:209:: with SMTP id 9-v6mr23488887plc.403.1522953338558; Thu, 05 Apr 2018 11:35:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Thu, 5 Apr 2018 11:35:37 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Kazuho Oku Date: Fri, 6 Apr 2018 03:35:37 +0900 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: "Lubashev, Igor" Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Mike Bishop , Christian Huitema , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Frederick Kautz Content-Type: multipart/alternative; boundary="000000000000c11c4405691e3473" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 18:35:42 -0000 --000000000000c11c4405691e3473 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-04-06 3:21 GMT+09:00 Lubashev, Igor : > > - It would not, *if* the stateless load balancer can AES-decrypt the > packet (using the key derived from the packet header) to see if the pa= cket > is in fact a initial packet. > > > > Would not it need to first decide that the CID in the packet is unknown > (which means stateful)? It would need to do some integrity check on CID, > which would require a large nonce to avoid accidentally classifying a > random CID as valid, because the cost of this mistake can be very large f= or > the client (see below). > AEAD tag that is used for checking if a packet is legitimate as a initial packet is currently 16 octets. That would not change. I believe that it would be enough to avoid 1-RTT packets being misclassified as handshake packets. > > > - Or another way of solving the issue will be to always route the > packet based on CID, then forward the packet between the endpoints beh= ind > the load balancer. > > > > This would not really work for a global load balancer =E2=80=93 the one c= apable of > forwarding across a continent to a different anycast pop (due to client= =E2=80=99s > change in attachment point or BGP reconvergence). > Agreed. > > > > > > > *From:* Kazuho Oku [mailto:kazuhooku@gmail.com] > *Sent:* Thursday, April 05, 2018 2:09 PM > *To:* Lubashev, Igor > *Cc:* Mikkel Fahn=C3=B8e J=C3=B8rgensen ; Mike Bishop= < > mbishop@evequefou.be>; Christian Huitema ; IETF QUIC > WG ; Mirja K=C3=BChlewind ; > Frederick Kautz > *Subject:* Re: Privacy holes (was: Re: Getting to consensus on packet > number encryption) > > > > > > > > 2018-04-06 2:59 GMT+09:00 Lubashev, Igor : > > > - I'd prefer making handshake packets indistinguishable from short > header packets. In essence, you move the flags of the long header insi= de > the AEAD-protected area. An endpoint that receives a packet carrying a= CID > that does not belong to any known connection trial-decrypts the packet= as a > initial packet and handles it as a connection initiation, or sends a > stateful reset if the trial-decryption fails. > > This change would wreck stateless load balancers that rely on being able > to distinguish CI packets (and route them based on IPs) from other packet= s > (and route them based on CID). > > > > It would not, *if* the stateless load balancer can AES-decrypt the packet > (using the key derived from the packet header) to see if the packet is in > fact a initial packet. Or another way of solving the issue will be to > always route the packet based on CID, then forward the packet between the > endpoints behind the load balancer. > > > > I agree that it would be a no-deal for stateless load balancers that are > incapable of doing such things. > > > > > > - Igor > > > > *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] > *Sent:* Thursday, April 05, 2018 1:31 PM > *To:* Mike Bishop ; Christian Huitema < > huitema@huitema.net>; Kazuho Oku > *Cc:* IETF QUIC WG ; Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch>; Frederick Kautz > *Subject:* RE: Privacy holes (was: Re: Getting to consensus on packet > number encryption) > > > > Hi > > > > On 5 April 2018 at 19.27.24, Mike Bishop (mbishop@evequefou.be) wrote: > > An endpoint that receives a packet carrying a CID that does not belong > to any known connection trial-decrypts the packet as a initial packet and > handles it as a connection initiation, or sends a stateful reset if the > trial-decryption fails. > > I can see hiding things may be a good thing, but having to trial decrypt > all unknown packets as potentially creating a huge load, unless you combi= ne > it with my proposal to add a checksum to the encrypted packet number so y= ou > only need one crypto block on average to reject random packet content. > > It won=E2=80=99t solve all DDoS, but it will help. Forcing trial decrypti= on fo the > full packet makes me a bit anxious. > > > > Mikkel > > > > > > > > -- > > Kazuho Oku > --=20 Kazuho Oku --000000000000c11c4405691e3473 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-04-06 3:21 GMT+09:00 Lubashev, Igor <ilubashe@akamai.com&g= t;:
  • It would not, *if* the stateless load balancer can AES-decrypt the pack= et (using the key derived from the packet header) to see if the packet is i= n fact a initial packet.

=C2=A0

Would not it need to first decide that the CI= D in the packet is unknown (which means stateful)?=C2=A0 It would need to d= o some integrity check on CID, which would require a large nonce to avoid a= ccidentally classifying a random CID as valid, because the cost of this mistake can be very large for the client (see bel= ow).


AEAD tag that is used = for checking if a packet is legitimate as a initial packet is currently 16 = octets. That would not change. I believe that it would be enough to avoid 1= -RTT packets being misclassified as handshake packets.
=C2=A0

=C2=A0

  • Or another way of solving the issue will be to always route the packet = based on CID, then forward the packet between the endpoints behind the load= balancer.

=C2=A0

This would not really work for a global load = balancer =E2=80=93 the one capable of forwarding across a continent to a di= fferent anycast pop (due to client=E2=80=99s change in attachment point or = BGP reconvergence).


Agreed.=
=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Kazuho Oku [mailto:kazuhooku@gmail.com]
Sent: Thursday, April 05, 2018 2:09 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; Mike Bishop <<= a href=3D"mailto:mbishop@evequefou.be" target=3D"_blank">mbishop@evequefou.= be>; Christian Huitema <huitema@huitema.net>; IETF QUIC WG <quic@ietf.org>; Mirja K=C3=BCh= lewind <mirja.kuehlewind@tik.ee.ethz.ch>; Frederick Kautz <fkautz@alumni.cmu.ed= u>
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet = number encryption)

=C2=A0

=C2=A0

=C2=A0

2018-04-06 2:59 GMT+09:00 Lubashev, Igor <ilubashe@akamai.com&g= t;:

  • I'd prefer making handshake packets indistinguishable from short header= packets. In essence, you move the flags of the long header inside the AEAD= -protected area. An endpoint that receives a packet carrying a CID that doe= s not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connecti= on initiation, or sends a stateful reset if the trial-decryption fails.<= /u>

This change would wreck stateless load balancers tha= t rely on being able to distinguish CI packets (and route them based on IPs= ) from other packets (and route them based on CID).

=C2=A0

It would not, *if* the stateless load balancer can A= ES-decrypt the packet (using the key derived from the packet header) to see= if the packet is in fact a initial packet. Or another way of solving the i= ssue will be to always route the packet based on CID, then forward the packet between the endpoints behind the loa= d balancer.

=C2=A0

I agree that it would be a no-deal for stateless loa= d balancers that are incapable of doing such things.

=C2=A0

=C2=A0

- Igor

=C2=A0

From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mail= to:mikkelfj@gmail.c= om]
Sent: Thursday, April 05, 2018 1:31 PM
To: Mike Bishop <mbishop@evequefou.be>; Christian Huitema <huitema@huitema.net>; = Kazuho Oku <kaz= uhooku@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>; Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.= ch>; Frederick Kautz <fkautz@alumni.cmu.edu>
Subject: RE: Privacy holes (was: Re: Getting to consensus on packet = number encryption)

=C2=A0

Hi

=C2=A0

On 5 A= pril 2018 at 19.27.24, Mike Bishop (mbishop@evequefou.be) wrote:

=C2=A0An endpoint that receives a packet carrying a CID that does not belo= ng to any known connection trial-decrypts the packet as a initial packet and handles it as a connection initiation, or sends a stateful rese= t if the trial-decryption fails.

I can see hiding things may be a good thing, but having to trial decr= ypt all unknown packets as potentially creating a huge load, unless you com= bine it with my proposal to add a checksum to the encrypted packet number so you only need one crypto block on average t= o reject random packet content.

It won=E2=80=99t solve all DDoS, but it will help. Forcing trial decr= yption fo the full packet makes me a bit anxious.

=C2=A0

Mikkel

=C2=A0



=C2=A0

--

Kazuho Oku




--
Kazuho Oku
--000000000000c11c4405691e3473-- From nobody Thu Apr 5 12:23:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3A61243F6 for ; Thu, 5 Apr 2018 12:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=alumni-cmu-edu.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 Yb1I9dj8fgDo for ; Thu, 5 Apr 2018 12:23:16 -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 D5193124239 for ; Thu, 5 Apr 2018 12:23:15 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id m134-v6so4014436itb.3 for ; Thu, 05 Apr 2018 12:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cmu-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o9PDL865ZQjKFBXoVzKzUGwV0ScaPHAZtxhCGzKDivo=; b=2DOnFt7p5pFLNWdMVs0WRFq4lYBWhLf/ZlGoJH6eC15qRBNm9GvtxNj2eqpu3mdlnd adMltzilz+yDwDJocA3jNg1YcvZQPUu6oCvJtKqCO/POTg75znW8WDfHU9nnhyAyYWWC Emz04kLnYu98fX1vsQi/hm8Bpz5X/2YeRZi6emc5x8fjV6saJzUeCWV99OaMr0yUeVv0 FmJx9zq3oO3XTwHJUGx4jt4JLSTCW82SBmqiYrUaHg6SR8S234M1mNyVPtY2SAVcYVoY 3LMoL/UO4qhwqUMZC7ZHOrorz43kE9jLXFSeWWFxIvC4wZP13uGvbLDiELLpf2oxY28L akmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=o9PDL865ZQjKFBXoVzKzUGwV0ScaPHAZtxhCGzKDivo=; b=LeC1itdUVgXZpqakSwNiQEsoRxcZeo+ki4MjlkZzHaK4vOS0KKFp9U+4uMpAuFkeGi v3SpmRj6MSqziRItshZlqe/OwDa08fkazJUhQ3cma52EUcoEtuxqxEsTt7jv253lEkCa YuvAUP6dpRSyGQ5sE7JCLQEWjZQHGgG0YqrYDuX8pX2ckrYUuR3jIyeYTHAGXOFmNrlG KOasQKhqzrdT2eoeR4N+cla6LmzNjPYBjeXebRsLTqKAXn8B1gHpK/cU+t8/UwDlhkEu Od4SABBdqzZRzcC6yUMEFMxshSxjBaZri7lhnyc+HU/HQ10m1WvPwtCn/kTvfHduhLkM 63ug== X-Gm-Message-State: ALQs6tAkPWBxsibsbXhA9unbMXtGSjQ0++GPJ7vil1o0+iBKenSI/aQ7 gWiQqTkKGFR2XONgqBNsfoJVqaGx38ocpWMYpQI3Ug== X-Google-Smtp-Source: AIpwx480lNPfXyROdmWBvr60HXwGSrVxGj0a7TX7XSTGygsIpflH5v+OpqkhCrJevAUsBzPsOF7GANKn9S3O5QF20CQ= X-Received: by 2002:a24:4507:: with SMTP id y7-v6mr15062246ita.112.1522956195163; Thu, 05 Apr 2018 12:23:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.38.11 with HTTP; Thu, 5 Apr 2018 12:23:14 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Frederick Kautz Date: Thu, 5 Apr 2018 12:23:14 -0700 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: Kazuho Oku Cc: "Lubashev, Igor" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Mike Bishop , Christian Huitema , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary="0000000000000587e605691edfa7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 19:23:19 -0000 --0000000000000587e605691edfa7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Maybe there could be some form of unencrypted header which load balancers could use to land it to the correct location? This id could be set by the server after a successful negotiation, and would be shared across all connections to that same server. It can be used to ensure that the same server internally always handles the given connection while attempting to keep linkability low. On Thu, Apr 5, 2018 at 11:35 AM, Kazuho Oku wrote: > > > 2018-04-06 3:21 GMT+09:00 Lubashev, Igor : > >> >> - It would not, *if* the stateless load balancer can AES-decrypt the >> packet (using the key derived from the packet header) to see if the p= acket >> is in fact a initial packet. >> >> >> >> Would not it need to first decide that the CID in the packet is unknown >> (which means stateful)? It would need to do some integrity check on CID= , >> which would require a large nonce to avoid accidentally classifying a >> random CID as valid, because the cost of this mistake can be very large = for >> the client (see below). >> > > AEAD tag that is used for checking if a packet is legitimate as a initial > packet is currently 16 octets. That would not change. I believe that it > would be enough to avoid 1-RTT packets being misclassified as handshake > packets. > > >> >> >> - Or another way of solving the issue will be to always route the >> packet based on CID, then forward the packet between the endpoints be= hind >> the load balancer. >> >> >> >> This would not really work for a global load balancer =E2=80=93 the one = capable >> of forwarding across a continent to a different anycast pop (due to >> client=E2=80=99s change in attachment point or BGP reconvergence). >> > > Agreed. > > >> >> >> >> >> >> >> *From:* Kazuho Oku [mailto:kazuhooku@gmail.com] >> *Sent:* Thursday, April 05, 2018 2:09 PM >> *To:* Lubashev, Igor >> *Cc:* Mikkel Fahn=C3=B8e J=C3=B8rgensen ; Mike Bisho= p < >> mbishop@evequefou.be>; Christian Huitema ; IETF >> QUIC WG ; Mirja K=C3=BChlewind ; >> Frederick Kautz >> *Subject:* Re: Privacy holes (was: Re: Getting to consensus on packet >> number encryption) >> >> >> >> >> >> >> >> 2018-04-06 2:59 GMT+09:00 Lubashev, Igor : >> >> >> - I'd prefer making handshake packets indistinguishable from short >> header packets. In essence, you move the flags of the long header ins= ide >> the AEAD-protected area. An endpoint that receives a packet carrying = a CID >> that does not belong to any known connection trial-decrypts the packe= t as a >> initial packet and handles it as a connection initiation, or sends a >> stateful reset if the trial-decryption fails. >> >> This change would wreck stateless load balancers that rely on being able >> to distinguish CI packets (and route them based on IPs) from other packe= ts >> (and route them based on CID). >> >> >> >> It would not, *if* the stateless load balancer can AES-decrypt the packe= t >> (using the key derived from the packet header) to see if the packet is i= n >> fact a initial packet. Or another way of solving the issue will be to >> always route the packet based on CID, then forward the packet between th= e >> endpoints behind the load balancer. >> >> >> >> I agree that it would be a no-deal for stateless load balancers that are >> incapable of doing such things. >> >> >> >> >> >> - Igor >> >> >> >> *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] >> *Sent:* Thursday, April 05, 2018 1:31 PM >> *To:* Mike Bishop ; Christian Huitema < >> huitema@huitema.net>; Kazuho Oku >> *Cc:* IETF QUIC WG ; Mirja K=C3=BChlewind < >> mirja.kuehlewind@tik.ee.ethz.ch>; Frederick Kautz >> *Subject:* RE: Privacy holes (was: Re: Getting to consensus on packet >> number encryption) >> >> >> >> Hi >> >> >> >> On 5 April 2018 at 19.27.24, Mike Bishop (mbishop@evequefou.be) wrote: >> >> An endpoint that receives a packet carrying a CID that does not belong >> to any known connection trial-decrypts the packet as a initial packet an= d >> handles it as a connection initiation, or sends a stateful reset if the >> trial-decryption fails. >> >> I can see hiding things may be a good thing, but having to trial decrypt >> all unknown packets as potentially creating a huge load, unless you comb= ine >> it with my proposal to add a checksum to the encrypted packet number so = you >> only need one crypto block on average to reject random packet content. >> >> It won=E2=80=99t solve all DDoS, but it will help. Forcing trial decrypt= ion fo >> the full packet makes me a bit anxious. >> >> >> >> Mikkel >> >> >> >> >> >> >> >> -- >> >> Kazuho Oku >> > > > > -- > Kazuho Oku > --0000000000000587e605691edfa7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maybe there could be some form of unencrypted header which= load balancers could use to land it to the correct location? This id could= be set by the server after a successful negotiation, and would be shared a= cross all connections to that same server. It can be used to ensure that th= e same server internally always handles the given connection while attempti= ng to keep linkability low.

On Thu, Apr 5, 2018 at 11:35 AM, Kazuho Oku <= ;kazuhooku@gmail.c= om> wrote:


2018-0= 4-06 3:21 GMT+09:00 Lubashev, Igor <ilubashe@akamai.com>:<= br>
  • It would not, *if* the state= less load balancer can AES-decrypt the packet (using the key derived from t= he packet header) to see if the packet is in fact a initial packet.<= u>

=C2=A0

Would not it need to first decide that the CI= D in the packet is unknown (which means stateful)?=C2=A0 It would need to d= o some integrity check on CID, which would require a large nonce to avoid a= ccidentally classifying a random CID as valid, because the cost of this mistake can be very large for the client (see bel= ow).


AEAD tag that i= s used for checking if a packet is legitimate as a initial packet is curren= tly 16 octets. That would not change. I believe that it would be enough to = avoid 1-RTT packets being misclassified as handshake packets.
=C2=A0

=C2=A0

  • Or another way of solving th= e issue will be to always route the packet based on CID, then forward the p= acket between the endpoints behind the load balancer.

    • =C2=A0

    This would not really work for a global load = balancer =E2=80=93 the one capable of forwarding across a continent to a di= fferent anycast pop (due to client=E2=80=99s change in attachment point or = BGP reconvergence).


= Agreed.
=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Kazuho Oku [mailto:kazuhooku@gmail.com]
Sent: Thursday, April 05, 2018 2:09 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; Mike Bishop <<= a href=3D"mailto:mbishop@evequefou.be" target=3D"_blank">mbishop@evequefou.= be>; Christian Huitema <huitema@huitema.net>; IETF QUIC WG <quic@ietf.org>; Mirja K=C3=BCh= lewind <mirja.kuehlewind@tik.ee.ethz.ch>; Frederick Kautz <fkautz@alumni.cmu.ed= u>
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet = number encryption)

=C2=A0

=C2=A0

=C2=A0

2018-04-06 2:59 GMT+09:00 Lubashev, Igor <ilubashe@akamai.com&g= t;:

  • I'd prefer making handshake packets indistinguishable from short header= packets. In essence, you move the flags of the long header inside the AEAD= -protected area. An endpoint that receives a packet carrying a CID that doe= s not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connecti= on initiation, or sends a stateful reset if the trial-decryption fails.<= /u>

This change would wreck stateless load balancers tha= t rely on being able to distinguish CI packets (and route them based on IPs= ) from other packets (and route them based on CID).

=C2=A0

It would not, *if* the stateless load balancer can A= ES-decrypt the packet (using the key derived from the packet header) to see= if the packet is in fact a initial packet. Or another way of solving the i= ssue will be to always route the packet based on CID, then forward the packet between the endpoints behind the loa= d balancer.

=C2=A0

I agree that it would be a no-deal for stateless loa= d balancers that are incapable of doing such things.

=C2=A0

=C2=A0

- Igor

=C2=A0

From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mail= to:mikkelfj@gmail.c= om]
Sent: Thursday, April 05, 2018 1:31 PM
To: Mike Bishop <mbishop@evequefou.be>; Christian Huitema <huitema@huitema.net>; = Kazuho Oku <kaz= uhooku@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>; Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.= ch>; Frederick Kautz <fkautz@alumni.cmu.edu>
Subject: RE: Privacy holes (was: Re: Getting to consensus on packet = number encryption)

=C2=A0

Hi

=C2=A0

On 5 April 2018 at 19.27.24, Mike Bish= op (mbi= shop@evequefou.be) wrote:

=C2=A0An endpoint that receives= a packet carrying a CID that does not belong to any known connection trial= -decrypts the packet as a initial packet and handles it as a connection initiation, or sends a stateful rese= t if the trial-decryption fails.

I can see hiding things may be a good thing, but having to trial decr= ypt all unknown packets as potentially creating a huge load, unless you com= bine it with my proposal to add a checksum to the encrypted packet number so you only need one crypto block on average t= o reject random packet content.

It won=E2=80=99t solve all DDoS, but it will help. Forcing trial decr= yption fo the full packet makes me a bit anxious.

=C2=A0

Mikkel

=C2=A0



=C2=A0

--

Kazuho Oku




--
Kazuho Oku

--0000000000000587e605691edfa7-- From nobody Thu Apr 5 13:37:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC28F1200B9 for ; Thu, 5 Apr 2018 13:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdTk0wTAsYjQ for ; Thu, 5 Apr 2018 13:37:09 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id A9EB712D77B for ; Thu, 5 Apr 2018 13:37:07 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w35Kaphc027375; Thu, 5 Apr 2018 22:36:51 +0200 Date: Thu, 5 Apr 2018 22:36:51 +0200 From: Willy Tarreau To: Kazuho Oku Cc: Mike Bishop , Mirja =?iso-8859-1?Q?K=FChlewind?= , IETF QUIC WG , Christian Huitema , Frederick Kautz Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) Message-ID: <20180405203651.GA27338@1wt.eu> References: <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 20:37:11 -0000 On Fri, Apr 06, 2018 at 02:43:23AM +0900, Kazuho Oku wrote: > If we require frequent gratuitous migration, wouldn't either the NAT > will run out of port addresses belonging to the same client-IP or > required to switch to a different IP address? Or much more commonly simply drop the packets by lack of new source ports. I've witnessed this problem a lot already at places having to access HTTP services not using keep-alive. Willy From nobody Thu Apr 5 14:56:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D09AC12DA49 for ; Thu, 5 Apr 2018 14:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522965417; bh=b3vQpCa29vkbdRkoey4IwLaurTqAmlOkkFoVyYxw5YQ=; h=From:Subject:Date:References:In-Reply-To:To:To:To; b=iTjXepNLobPKGC/g2XdbXPsG1EnG8ozRfMuXKwk62clR5jLSVGA3lcYddzHrQtouU D0xHnM2PuLZVLCLlCXZoUkPO4i7DcdPDtR3gsTmzyaHrsMAGISMIX6IO7WdvA4YXf7 6J3CDOC3rn+lf6SmXP/1nJrbH4z85XP19iZ1Udqo= X-Mailbox-Line: From mbishop@evequefou.be Thu Apr 5 14:56:57 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 802A812D948; Thu, 5 Apr 2018 14:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522965417; bh=b3vQpCa29vkbdRkoey4IwLaurTqAmlOkkFoVyYxw5YQ=; h=From:Subject:Date:References:In-Reply-To:To:To:To; b=iTjXepNLobPKGC/g2XdbXPsG1EnG8ozRfMuXKwk62clR5jLSVGA3lcYddzHrQtouU D0xHnM2PuLZVLCLlCXZoUkPO4i7DcdPDtR3gsTmzyaHrsMAGISMIX6IO7WdvA4YXf7 6J3CDOC3rn+lf6SmXP/1nJrbH4z85XP19iZ1Udqo= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5528612D962 for ; Thu, 5 Apr 2018 14:56: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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKuFSUF-sYh0 for ; Thu, 5 Apr 2018 14:56:45 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on071f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe44::71f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4016212D948 for ; Thu, 5 Apr 2018 14:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b3vQpCa29vkbdRkoey4IwLaurTqAmlOkkFoVyYxw5YQ=; b=FY7Z167WjiJSAh8RLIioYFiF1JiQNexuGsgOTxTTSJUS1WXlt1L0HGicMX4uk0XFs7YM2S6Lp4E8Quu2gPyvhbgRKhsHKQZ+BAG5nkV3ZeTWN34tRCqw033LZyaoHud7OAf3TM5clrhilVKzJR/JiBi6vsx4suseuPqhh7t8a7M= Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1856.namprd08.prod.outlook.com (10.169.39.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Thu, 5 Apr 2018 21:56:41 +0000 Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0653.013; Thu, 5 Apr 2018 21:56:41 +0000 From: Mike Bishop Subject: RE: Impact of hardware offloads on network stack performance Thread-Topic: Impact of hardware offloads on network stack performance Thread-Index: AdPMUbL7T8nZAW2ySiO289IPTC0ttgAApm4AADSbFZA= Date: Thu, 5 Apr 2018 21:56:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR08MB1856; 7:oVUgXNLHuJU9rLcWpcZL/U6dBBuGnlXcxM8XLkW2ftcaqmbGEA9XzQgwkne0NwPIIO1DjuEBwCsSuvXCVX7lGR+ONgU1ZBKopdj65+eKVw80uV6n+YvDm48HkK/mqRuBr4pnq3EEAioetYHppmTzxZr2by+cLAYlqwN/XVP7sKxJOLlwqwVsto4QZ/OoSwqREbLoTnZ9NZJtU5wgefGdDxsgIWi2Vy5Xl1+jdUwhhX1gSgLfdqWq1iw2ToDYBUjj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 79a81afb-403d-4dd5-3fe2-08d59b401d30 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1856; x-ms-traffictypediagnostic: SN1PR08MB1856: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231221)(944501327)(52105095)(10201501046)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(2016111802025)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1856; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1856; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(376002)(366004)(39830400003)(396003)(189003)(199004)(486006)(5250100002)(186003)(106356001)(6506007)(74482002)(19609705001)(33656002)(8936002)(102836004)(86362001)(81166006)(8676002)(81156014)(26005)(97736004)(476003)(229853002)(66066001)(3280700002)(2906002)(11346002)(446003)(53546011)(5660300001)(105586002)(316002)(790700001)(55016002)(39060400002)(7736002)(68736007)(74316002)(110136005)(3660700001)(53936002)(54896002)(6306002)(7696005)(9686003)(236005)(6246003)(6116002)(2900100001)(99286004)(25786009)(3846002)(14454004)(478600001)(6436002)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1856; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: 3VUr96vjl0P6a8XmmQgmfI+kcxOdiMqYU5OHiEjLvyjYcX0t6KcmlOkdSbjBi6T3adZPvLuYwuHwy5xT7dnGwY5gJlBvSEVOlJ9Adnym246f99HD+YVW/NaqELx0ryYanBVeZAfDYlg/bayKAUYjMdbmrQ2Sk4EGIVr5fKQBGj36TvC/5J0vw/s46oLKfFTtf2xNTrnh0HI/em12/sOs9oS0/M5gJ6fJKT3dd1Poikq4wG1eqPHQrH32YM62W9xbKJ/rYcO5YNI/khwIznVNtuBl+zAkiGf4hmzQPo5D2GXmNB9wtx11MSobXiFtVrxvcaJw9lkxLGchkW2IQ6AG3ZVeEaekl3iWy4P49FhlJMUQmuiWe8g7IK0VNNqtkgzII9HhUpRWuLR0u+jNBeB99yfG8+ZvnxcZ4sa0i8xRv+U= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR08MB1854E64D7C370BF0A7456977DABB0SN1PR08MB1854namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 79a81afb-403d-4dd5-3fe2-08d59b401d30 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 21:56:40.9894 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1856 To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= To: Praveen Balasubramanian To: IETF QUIC WG Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 21:56:58 -0000 --_000_SN1PR08MB1854E64D7C370BF0A7456977DABB0SN1PR08MB1854namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgaW50ZXJlc3RpbmcgZGF0YSwgUHJhdmVlbiDigJMgdGhhbmtzLiAgVGhlcmUgaXMg b25lIGNhdmVhdCB0aGVyZSwgd2hpY2ggaXMgdGhhdCAoSUlVQywgb24gY3VycmVudCBoYXJkd2Fy ZSkgeW91IGNhbuKAmXQgZG8gcGFja2V0IHBhY2luZyB3aXRoIExTTywgYW5kIHNvIG15IHVuZGVy c3RhbmRpbmcgaXMgdGhhdCBldmVuIGZvciBUQ1AgbWFueSBwcm92aWRlcnMgZGlzYWJsZSB0aGlz IGluIHB1cnN1aXQgb2YgYmV0dGVyIGVncmVzcyBtYW5hZ2VtZW50LiAgU28gd2hhdCB3ZeKAmXJl IHJlYWxseSBzYXlpbmcgaXMgdGhhdDoNCg0KICAqICAgT24gY3VycmVudCBoYXJkd2FyZSBhbmQg T1Mgc2V0dXBzLCBVRFAgcnVucyBsZXNzIHRoYW4gaGFsZiBhcyBtdWNoIHRocm91Z2hwdXQgYXMg VENQOyB0aGF0IG5lZWRzIHNvbWUgb3B0aW1pemF0aW9uLCBhcyB3ZeKAmXZlIGFscmVhZHkgZGlz Y3Vzc2VkDQogICogICBUQ1Agd2lsbCBkcmFtYXRpY2FsbHkgZ2FpbiBwZXJmb3JtYW5jZSBvbmNl IGhhcmR3YXJlIG9mZmxvYWQgY2F0Y2hlcyB1cCBhbmQgYWxsb3dzIHBhY2VkIExTTyDwn5iKDQoN Ckhvd2V2ZXIsIGFzIE1pa2tlbCBwb2ludHMgb3V0LCB0aGUgY3J5cHRvIGNvc3RzIGFyZSBsaWtl bHkgdG8gb3ZlcndoZWxtIHRoZSBPUyB0aHJvdWdocHV0IC8gc2NoZWR1bGluZyBpc3N1ZXMgaW4g cmVhbCBkZXBsb3ltZW50cy4gIFNvIEkgdGhpbmsgdGhlIG90aGVyIHJlbGV2YW50IHBpZWNlIHRv IHVuZGVyc3RhbmRpbmcgdGhlIGNvc3QgaGVyZSBpcyB0aGlzOg0KDQogICogICBXaGF0IGlzIHRo ZSB0aHJvdWdocHV0IGFuZCByZWxhdGl2ZSBjb3N0IG9mIFRMUy9UQ1AgdmVyc3VzIFFVSUMgKGku ZS4gaG93IG11Y2ggYXJlIHRoZSBzbWFsbGVyIHVuaXRzIG9mIGVuY3J5cHRpb24gaHVydGluZyB1 cyB2ZXJzdXMsIHNheSwgMTZLQiBUTFMgcmVjb3Jkcyk/DQogICAgICogICBUTFMgaW1wbGVtZW50 YXRpb25zIGFscmVhZHkgdmFyeSBoZXJlOiAgU29tZSBpbXBsZW1lbnRhdGlvbnMgY2hvb3NlIGxh cmdlIHJlY29yZCBzaXplcywgc29tZSB2YXJ5IHJlY29yZCBzaXplcyB0byByZWR1Y2UgZGVsYXkg LyBIb0xCLCBzbyB0aGlzIHByb2JhYmx5IGlzbuKAmXQgYSBzaW5nbGUgbnVtYmVyLg0KICAqICAg SG93IG11Y2ggYWRkaXRpb25hbCBsb2FkIGRvZXMgUE5FIGFkZCB0byB0aGlzIGRpZmZlcmVuY2U/ DQogICogICBUbyB3aGF0IGV4dGVudCB3b3VsZCBQTkUgbWFrZSBmdXR1cmUgY3J5cHRvIG9mZmxv YWRzIGltcG9zc2libGUgdmVyc3VzIHJlcXVpcmVzIG1vcmUgUiZEIHRvIGRldmVsb3A/DQoNCkZy b206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtr ZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTggMToz NCBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21A ZG1hcmMuaWV0Zi5vcmc+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogSW1wYWN0IG9mIGhhcmR3YXJlIG9mZmxvYWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVyZm9ybWFu Y2UNCg0KVGhhbmtzIGZvciBzaGFyaW5nIHRoZXNlIG51bWJlcnMuDQoNCk15IGd1ZXNzIGlzIHRo YXQgdGhlc2Ugb2ZmbG9hZHMgZGVhbCB3aXRoIGtlcm5lbCBzY2hlZHVsaW5nLCBtZW1vcnkgY2Fj aGUgaXNzdWVzLCBhbmQgaW50ZXJydXB0IHNjaGVkdWxpbmcuDQoNCkl0IHByb2JhYmx5IGhhcyB2 ZXJ5IGxpdHRsZSB0byBkbyB3aXRoIGNyeXB0bywgVENQIGhlYWRlcnMsIGFuZCBhbnkgb3RoZXIg Y3B1IHNlbnNpdGl2ZSBwcm9jZXNzaW5nLg0KDQpUaGlzIGlzIHdoZXJlIG5ldG1hcCBlbnRlcnM6 IHlvdSBjYW4gdHJhbnNwYXJlbnRseSBmZWVkIHRoZSBkYXRhIGFzIGl0IGJlY29tZXMgYXZhaWxh YmxlIHdpdGggdmVyeSBsaXR0bGUgc3luYyB3b3JrIGFuZCB5b3UgY2FuIGFsc28gZWZmaWNpZW50 bHkgcGlwZWxpbmUgc28geW91IHBhc3MgZGF0YSB0byBkZWNyeXB0b3IsIHRoZW4gdG8gYXBwLCB3 aXRoIGFzIGxpdHRsZSBidXMgdHJhZmZpYyBhcyBwb3NzaWJsZS4gTm8gbmVlZCB0byBjb3B5IGRh dGEgb3Igc3luY2hyb25pemUga2VybmVsIHNwYWNlLg0KDQpGb3IgMUsgcGFja2V0cyB5b3Ugd291 bGQgdXNlIGFib3V0IDEwMDBucyAoMyBjeWNsZXMvYnl0ZSkgb24gY3J5cHRvIGFuZCB0aGlzIHdv dWxkIGhhcHBlbiBpbiBMMSBjYWNoZS4gSXQgd291bGQgb2YgY291cnNlIGNvbnN1bWUgYSBjb3Jl IHdoaWNoIGEgY3J5cHRvIG9mZmxvYWQgd291bGQgbm90LCBidXQgdGhhdCBjYW4gYmUgZGViYXRl ZCBiZWNhdXNlIHdpdGggMTggY29yZSBzeXN0ZW1zLCB5b3VyIHByb2JsZW0gaXMgbWVtb3J5IGFu ZCBuZXR3b3JrIG1vcmUgdGhhbiBDUFUuDQoNCk15IGNvbmNlcm4gd2l0aCBQTkUgaXMgZm9yIHNt YWxsIHBhY2tldHMgYW5kIGxvdyBsYXRlbmN5IHdoZXJlDQoxKSBhbiBlc3RpbWF0ZWQgMjRucyBm b3IgUE4gZW5jcnlwdGlvbiBhbmQgZGVjcnlwdGlvbiBiZWNvbWVzIG1lYXN1cmFibGUgaWYgeW91 ciBuZXR3b3JrIGlzIGZhc3QgZW5vdWdoLg0KMikgYW55IGRhbWFnZSB0byB0aGUgcGFja2V0IGJ1 ZmZlciBjYXVzZSBhbGwgc29ydHMgb2YgbWVtb3J5IGFuZCBjcHUgYnVzIHRyYWZmaWMgaXNzdWVz Lg0KDQoxKSBpcyBhbm5veWluZy4gMikgaXMgYmFkLCBjb21wbGV0ZWx5IGF2b2lkYWJsZSBidXQg bm90IGFzIFBSIDEwNzkgaXMgZm9ybXVsYXRlZCBjdXJyZW50bHkuDQoNCjIpIGlzIGFsc28gbGlr ZWx5IGJhZCBmb3IgaGFyZHdhcmUgb2ZmbG9hZCB1bml0cyBhcyB3ZWxsLg0KDQpBcyB0byBTUlYt SU8gLSBJ4oCZbSBub3QgZmFtaWxpYXIgd2l0aCBpdCwgYnV0IG9idmlvdXNseSB0aGVyZSBpcyBz b21lIElPIGFic3RyYWN0aW9uIGxheWVyIC0gdGhlIHF1ZXN0aW9uIGlzIGhvdyB5b3UgbWFrZSBp dCBhY2Nlc3NpYmxlIHRvIGFwcHMgYXMgb3Bwb3NlZCB0byBkZXZpY2UgZHJpdmVycyB0aGF0IGRv ZXMgbm9yIHdvcmsgd2l0aCB5b3UgUVVJQyBjdXN0b20gc3RhY2ssIGFuZCBuZXRtYXAgaXMgb25l IG9wdGlvbiBoZXJlLg0KDQpLaW5kIFJlZ2FyZHMsDQpNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2Vu DQoNCg0KT24gNCBBcHJpbCAyMDE4IGF0IDIyLjE1LjUyLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh biAocHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpwcmF2Yj00MG1p Y3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+KSB3cm90ZToNClNvbWUgY29tcGFyYXRpdmUgbnVt YmVycyBmcm9tIGFuIG91dCBvZiBib3ggZGVmYXVsdCBzZXR0aW5ncyBXaW5kb3dzIFNlcnZlciAy MDE2IChyZWxlYXNlZCB2ZXJzaW9uKSBmb3IgYSBzaW5nbGUgY29ubmVjdGlvbiB3aXRoIGEgbWlj cm9iZW5jaG1hcmsgdG9vbDoNCg0KT2ZmbG9hZHMgZW5hYmxlZA0KDQpUQ1AgZ2Jwcw0KDQpVRFAg Z2Jwcw0KDQpMU08gKyBMUk8gKyBjaGVja3N1bQ0KDQoyNA0KDQozLjYNCg0KQ2hlY2tzdW0gb25s eQ0KDQo3LjYNCg0KMy42DQoNCk5vbmUNCg0KNS42DQoNCjIuMw0KDQoNClRoaXMgaXMgZm9yIGEg ZnVsbHkgYm90dGxlbmVja2VkIENQVSBjb3JlIC0tIGlmIHlvdSBydW4gbG93ZXIgZGF0YSByYXRl cyB0aGVyZSBpcyBzdGlsbCBhIHNpZ25pZmljYW50IGRpZmZlcmVuY2UgaW4gQ3ljbGVzL2J5dGUg Y29zdC4gU2FtZSBpbmNyZWFzZWQgQ1BVIGNvc3QgYXBwbGllcyBmb3IgY2xpZW50IHN5c3RlbXMg Z29pbmcgb3ZlciBoaWdoIGRhdGEgcmF0ZSBXaWZpIGFuZCBjZWxsdWxhci4NCg0KVGhpcyBpcyB3 aXRob3V0IGFueSBjcnlwdG8uIE9uY2UgeW91IGFkZCBjcnlwdG8gdGhlIG51bWJlcnMgYmVjb21l IG11Y2ggd29yc2Ugd2l0aCBjcnlwdG8gY29zdCBiZWNvbWluZyBkb21pbmFudC4gQWRkaW5nIGFu b3RoZXIgY3J5cHRvIHN0ZXAgZnVydGhlciBleGFjZXJiYXRlcyB0aGUgcHJvYmxlbS4gSGVuY2Ug Y3J5cHRvIG9mZmxvYWQgZ2FpbnMgaW4gaW1wb3J0YW5jZSBmb2xsb3dlZCBieSB0aGVzZSBiYXRj aCBvZmZsb2Fkcy4NCg0KSWYgZm9sa3MgbmVlZCBhbnkgbW9yZSBudW1iZXJzIEnigJlkIGJlIGhh cHB5IHRvIHByb3ZpZGUgdGhlbS4NCg0KVGhhbmtzDQoNCg== --_000_SN1PR08MB1854E64D7C370BF0A7456977DABB0SN1PR08MB1854namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFpbG9uLCBsaS5haXJtYWlsb24sIGRp di5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjY4NTc4NzM3OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEyNTE4NjgxMTIgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6MTEzNzk4ODU5MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6OTQyOTc2MjAwIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF04oCZcyBpbnRlcmVz dGluZyBkYXRhLCBQcmF2ZWVuIOKAkyB0aGFua3MuJm5ic3A7IFRoZXJlIGlzIG9uZSBjYXZlYXQg dGhlcmUsIHdoaWNoIGlzIHRoYXQgKElJVUMsIG9uIGN1cnJlbnQgaGFyZHdhcmUpIHlvdSBjYW7i gJl0IGRvIHBhY2tldCBwYWNpbmcgd2l0aCBMU08sIGFuZCBzbyBteSB1bmRlcnN0YW5kaW5nIGlz IHRoYXQgZXZlbiBmb3IgVENQIG1hbnkgcHJvdmlkZXJzIGRpc2FibGUgdGhpcyBpbiBwdXJzdWl0 IG9mDQogYmV0dGVyIGVncmVzcyBtYW5hZ2VtZW50LiZuYnNwOyBTbyB3aGF0IHdl4oCZcmUgcmVh bGx5IHNheWluZyBpcyB0aGF0OjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9w OjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPk9uIGN1cnJlbnQgaGFyZHdh cmUgYW5kIE9TIHNldHVwcywgVURQIHJ1bnMgbGVzcyB0aGFuIGhhbGYgYXMgbXVjaCB0aHJvdWdo cHV0IGFzIFRDUDsgdGhhdCBuZWVkcyBzb21lIG9wdGltaXphdGlvbiwgYXMgd2XigJl2ZSBhbHJl YWR5IGRpc2N1c3NlZDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPlRDUCB3aWxs IGRyYW1hdGljYWxseSBnYWluIHBlcmZvcm1hbmNlIG9uY2UgaGFyZHdhcmUgb2ZmbG9hZCBjYXRj aGVzIHVwIGFuZCBhbGxvd3MNCjx1PnBhY2VkPC91PiBMU08gPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2VyaWYiPiYjMTI4NTIyOzwvc3Bh bj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgYXMgTWlra2VsIHBvaW50 cyBvdXQsIHRoZSBjcnlwdG8gY29zdHMgYXJlIGxpa2VseSB0byBvdmVyd2hlbG0gdGhlIE9TIHRo cm91Z2hwdXQgLyBzY2hlZHVsaW5nIGlzc3VlcyBpbiByZWFsIGRlcGxveW1lbnRzLiZuYnNwOyBT byBJIHRoaW5rIHRoZSBvdGhlciByZWxldmFudCBwaWVjZSB0byB1bmRlcnN0YW5kaW5nIHRoZSBj b3N0IGhlcmUgaXMgdGhpczo8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDow aW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj5XaGF0IGlzIHRoZSB0aHJvdWdo cHV0IGFuZCByZWxhdGl2ZSBjb3N0IG9mIFRMUy9UQ1AgdmVyc3VzIFFVSUMgKGkuZS4gaG93IG11 Y2ggYXJlIHRoZSBzbWFsbGVyIHVuaXRzIG9mIGVuY3J5cHRpb24gaHVydGluZyB1cyB2ZXJzdXMs IHNheSwgMTZLQiBUTFMgcmVjb3Jkcyk/PG86cD48L286cD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRv cDowaW4iIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPlRMUyBpbXBsZW1lbnRh dGlvbnMgYWxyZWFkeSB2YXJ5IGhlcmU6Jm5ic3A7IFNvbWUgaW1wbGVtZW50YXRpb25zIGNob29z ZSBsYXJnZSByZWNvcmQgc2l6ZXMsIHNvbWUgdmFyeSByZWNvcmQgc2l6ZXMgdG8gcmVkdWNlIGRl bGF5IC8gSG9MQiwgc28gdGhpcyBwcm9iYWJseSBpc27igJl0IGEgc2luZ2xlIG51bWJlci48bzpw PjwvbzpwPjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj5Ib3cgbXVjaCBhZGRp dGlvbmFsIGxvYWQgZG9lcyBQTkUgYWRkIHRvIHRoaXMgZGlmZmVyZW5jZT88bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwwIGxldmVsMSBsZm8yIj5UbyB3aGF0IGV4dGVudCB3b3VsZCBQTkUgbWFrZSBmdXR1 cmUgY3J5cHRvIG9mZmxvYWRzDQo8aT5pbXBvc3NpYmxlPC9pPiB2ZXJzdXMgPGk+cmVxdWlyZXMg bW9yZSBSJmFtcDtEIHRvIGRldmVsb3A8L2k+PzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgW21h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPk1pa2tlbCBG YWhuw7hlIErDuHJnZW5zZW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCA0LCAy MDE4IDE6MzQgUE08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtw cmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0 O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJbXBhY3Qgb2YgaGFy ZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGZvciBzaGFyaW5nIHRoZXNlIG51bWJlcnMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk15IGd1ZXNzIGlzIHRoYXQgdGhlc2Ugb2Zm bG9hZHMgZGVhbCB3aXRoIGtlcm5lbCBzY2hlZHVsaW5nLCBtZW1vcnkgY2FjaGUgaXNzdWVzLCBh bmQgaW50ZXJydXB0IHNjaGVkdWxpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPkl0IHByb2JhYmx5IGhhcyB2ZXJ5IGxpdHRsZSB0byBkbyB3aXRoIGNyeXB0bywgVENQIGhl YWRlcnMsIGFuZCBhbnkgb3RoZXIgY3B1IHNlbnNpdGl2ZSBwcm9jZXNzaW5nLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIHdoZXJlIG5ldG1hcCBlbnRlcnM6IHlv dSBjYW4gdHJhbnNwYXJlbnRseSBmZWVkIHRoZSBkYXRhIGFzIGl0IGJlY29tZXMgYXZhaWxhYmxl IHdpdGggdmVyeSBsaXR0bGUgc3luYyB3b3JrIGFuZCB5b3UgY2FuIGFsc28gZWZmaWNpZW50bHkg cGlwZWxpbmUgc28geW91IHBhc3MgZGF0YQ0KIHRvIGRlY3J5cHRvciwgdGhlbiB0byBhcHAsIHdp dGggYXMgbGl0dGxlIGJ1cyB0cmFmZmljIGFzIHBvc3NpYmxlLiBObyBuZWVkIHRvIGNvcHkgZGF0 YSBvciBzeW5jaHJvbml6ZSBrZXJuZWwgc3BhY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPkZvciAxSyBwYWNrZXRzIHlvdSB3b3VsZCB1c2UgYWJvdXQgMTAwMG5zICgzIGN5 Y2xlcy9ieXRlKSBvbiBjcnlwdG8gYW5kIHRoaXMgd291bGQgaGFwcGVuIGluIEwxIGNhY2hlLiBJ dCB3b3VsZCBvZiBjb3Vyc2UgY29uc3VtZSBhIGNvcmUgd2hpY2ggYSBjcnlwdG8gb2ZmbG9hZCB3 b3VsZCBub3QsDQogYnV0IHRoYXQgY2FuIGJlIGRlYmF0ZWQgYmVjYXVzZSB3aXRoIDE4IGNvcmUg c3lzdGVtcywgeW91ciBwcm9ibGVtIGlzIG1lbW9yeSBhbmQgbmV0d29yayBtb3JlIHRoYW4gQ1BV LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9u dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NeSBjb25jZXJuIHdpdGggUE5F IGlzIGZvciBzbWFsbCBwYWNrZXRzIGFuZCBsb3cgbGF0ZW5jeSB3aGVyZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+MSkgYW4gZXN0aW1hdGVkIDI0bnMgZm9yIFBO IGVuY3J5cHRpb24gYW5kIGRlY3J5cHRpb24gYmVjb21lcyBtZWFzdXJhYmxlIGlmIHlvdXIgbmV0 d29yayBpcyBmYXN0IGVub3VnaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjIpIGFueSBkYW1hZ2UgdG8gdGhlIHBhY2tldCBidWZmZXIgY2F1c2UgYWxsIHNvcnRz IG9mIG1lbW9yeSBhbmQgY3B1IGJ1cyB0cmFmZmljIGlzc3Vlcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+MSkgaXMgYW5ub3lpbmcuIDIpIGlzIGJhZCwgY29tcGxldGVseSBh dm9pZGFibGUgYnV0IG5vdCBhcyBQUiAxMDc5IGlzIGZvcm11bGF0ZWQgY3VycmVudGx5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yKSBpcyBhbHNvIGxpa2VseSBiYWQgZm9y IGhhcmR3YXJlIG9mZmxvYWQgdW5pdHMgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFzIHRvIFNSVi1JTyAtIEni gJltIG5vdCBmYW1pbGlhciB3aXRoIGl0LCBidXQgb2J2aW91c2x5IHRoZXJlIGlzIHNvbWUgSU8g YWJzdHJhY3Rpb24gbGF5ZXIgLSB0aGUgcXVlc3Rpb24gaXMgaG93IHlvdSBtYWtlIGl0IGFjY2Vz c2libGUgdG8gYXBwcyBhcyBvcHBvc2VkIHRvIGRldmljZSBkcml2ZXJzDQogdGhhdCBkb2VzIG5v ciB3b3JrIHdpdGggeW91IFFVSUMgY3VzdG9tIHN0YWNrLCBhbmQgbmV0bWFwIGlzIG9uZSBvcHRp b24gaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg aWQ9ImJsb29wX3NpZ25fMTUyMjg3MzM1MDQxNTEyMDEyOCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vu c2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gNCBBcHJpbCAyMDE4IGF0 IDIyLjE1LjUyLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAoPGEgaHJlZj0ibWFpbHRvOnByYXZi PTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyI+cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRt YXJjLmlldGYub3JnPC9hPikgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5T b21lIGNvbXBhcmF0aXZlIG51bWJlcnMgZnJvbSBhbiBvdXQgb2YgYm94IGRlZmF1bHQgc2V0dGlu Z3MgV2luZG93cyBTZXJ2ZXIgMjAxNiAocmVsZWFzZWQgdmVyc2lvbikgZm9yIGEgc2luZ2xlDQog Y29ubmVjdGlvbiB3aXRoIGEgbWljcm9iZW5jaG1hcmsgdG9vbDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9 IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBz ZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3Ai IHN0eWxlPSJ3aWR0aDoxMTYuODVwdDtib3JkZXI6c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXIt Ym90dG9tOnNvbGlkICM2NjY2NjYgMS41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9mZmxvYWRzIGVu YWJsZWQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2Ljlw dDtib3JkZXItdG9wOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXIt Ym90dG9tOnNvbGlkICM2NjY2NjYgMS41cHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4w cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRDUCBnYnBzPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249 InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7Ym9yZGVyLXRvcDpzb2xpZCAjOTk5OTk5IDEuMHB0 O2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjNjY2NjY2IDEuNXB0O2JvcmRl ci1yaWdodDpzb2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5VRFAgZ2Jwczwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+ DQo8L3RyPg0KPHRyPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6 MTE2Ljg1cHQ7Ym9yZGVyOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRp bmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5MU08gJiM0MzsgTFJPICYjNDM7IGNoZWNrc3VtPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0i MTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7Ym9yZGVyLXRvcDpub25lO2Jv cmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjOTk5OTk5IDEuMHB0O2JvcmRlci1y aWdodDpzb2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yNDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0 aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206 c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRk aW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+My42PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+ DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuODVwdDtib3Jk ZXI6c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowaW4gNS40cHQg MGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PkNoZWNrc3VtIG9ubHk8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk dGg6MTE2LjlwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9t OnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7cGFk ZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjcuNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9 IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTti b3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXIt cmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+My42PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0 b3AiIHN0eWxlPSJ3aWR0aDoxMTYuODVwdDtib3JkZXI6c29saWQgIzk5OTk5OSAxLjBwdDtib3Jk ZXItdG9wOm5vbmU7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk5vbmU8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZh bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2LjlwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxl ZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNv bGlkICM5OTk5OTkgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjUuNjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYu OXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQg Izk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBp biA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Mi4zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPlRoaXMgaXMgZm9yIGEgZnVsbHkgYm90dGxlbmVja2VkIENQVSBjb3JlIC0tDQo8 aT5pZiB5b3UgcnVuIGxvd2VyIGRhdGEgcmF0ZXMgdGhlcmUgaXMgc3RpbGwgYSBzaWduaWZpY2Fu dCBkaWZmZXJlbmNlIGluIEN5Y2xlcy9ieXRlIGNvc3Q8L2k+LiBTYW1lIGluY3JlYXNlZCBDUFUg Y29zdCBhcHBsaWVzIGZvciBjbGllbnQgc3lzdGVtcyBnb2luZyBvdmVyIGhpZ2ggZGF0YSByYXRl IFdpZmkgYW5kIGNlbGx1bGFyLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBpcyB3aXRo b3V0IGFueSBjcnlwdG8uIE9uY2UgeW91IGFkZCBjcnlwdG8gdGhlIG51bWJlcnMgYmVjb21lIG11 Y2ggd29yc2UNCjxpPndpdGggY3J5cHRvIGNvc3QgYmVjb21pbmcgZG9taW5hbnQ8L2k+LiBBZGRp bmcgYW5vdGhlciBjcnlwdG8gc3RlcCBmdXJ0aGVyIGV4YWNlcmJhdGVzIHRoZSBwcm9ibGVtLiBI ZW5jZSBjcnlwdG8gb2ZmbG9hZCBnYWlucyBpbiBpbXBvcnRhbmNlIGZvbGxvd2VkIGJ5IHRoZXNl IGJhdGNoIG9mZmxvYWRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklmIGZvbGtzIG5lZWQgYW55 IG1vcmUgbnVtYmVycyBJ4oCZZCBiZSBoYXBweSB0byBwcm92aWRlIHRoZW0uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_SN1PR08MB1854E64D7C370BF0A7456977DABB0SN1PR08MB1854namp_-- From nobody Thu Apr 5 14:57:05 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BC412D948 for ; Thu, 5 Apr 2018 14:56:58 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcEuux89Bq4A for ; Thu, 5 Apr 2018 14:56:45 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0112.outbound.protection.outlook.com [104.47.36.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401D712D969 for ; Thu, 5 Apr 2018 14:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b3vQpCa29vkbdRkoey4IwLaurTqAmlOkkFoVyYxw5YQ=; b=FY7Z167WjiJSAh8RLIioYFiF1JiQNexuGsgOTxTTSJUS1WXlt1L0HGicMX4uk0XFs7YM2S6Lp4E8Quu2gPyvhbgRKhsHKQZ+BAG5nkV3ZeTWN34tRCqw033LZyaoHud7OAf3TM5clrhilVKzJR/JiBi6vsx4suseuPqhh7t8a7M= Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1856.namprd08.prod.outlook.com (10.169.39.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Thu, 5 Apr 2018 21:56:41 +0000 Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0653.013; Thu, 5 Apr 2018 21:56:41 +0000 From: Mike Bishop To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Praveen Balasubramanian , IETF QUIC WG Subject: RE: Impact of hardware offloads on network stack performance Thread-Topic: Impact of hardware offloads on network stack performance Thread-Index: AdPMUbL7T8nZAW2ySiO289IPTC0ttgAApm4AADSbFZA= Date: Thu, 5 Apr 2018 21:56:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR08MB1856; 7:oVUgXNLHuJU9rLcWpcZL/U6dBBuGnlXcxM8XLkW2ftcaqmbGEA9XzQgwkne0NwPIIO1DjuEBwCsSuvXCVX7lGR+ONgU1ZBKopdj65+eKVw80uV6n+YvDm48HkK/mqRuBr4pnq3EEAioetYHppmTzxZr2by+cLAYlqwN/XVP7sKxJOLlwqwVsto4QZ/OoSwqREbLoTnZ9NZJtU5wgefGdDxsgIWi2Vy5Xl1+jdUwhhX1gSgLfdqWq1iw2ToDYBUjj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 79a81afb-403d-4dd5-3fe2-08d59b401d30 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1856; x-ms-traffictypediagnostic: SN1PR08MB1856: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231221)(944501327)(52105095)(10201501046)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(2016111802025)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1856; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1856; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(376002)(366004)(39830400003)(396003)(189003)(199004)(486006)(5250100002)(186003)(106356001)(6506007)(74482002)(19609705001)(33656002)(8936002)(102836004)(86362001)(81166006)(8676002)(81156014)(26005)(97736004)(476003)(229853002)(66066001)(3280700002)(2906002)(11346002)(446003)(53546011)(5660300001)(105586002)(316002)(790700001)(55016002)(39060400002)(7736002)(68736007)(74316002)(110136005)(3660700001)(53936002)(54896002)(6306002)(7696005)(9686003)(236005)(6246003)(6116002)(2900100001)(99286004)(25786009)(3846002)(14454004)(478600001)(6436002)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1856; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: 3VUr96vjl0P6a8XmmQgmfI+kcxOdiMqYU5OHiEjLvyjYcX0t6KcmlOkdSbjBi6T3adZPvLuYwuHwy5xT7dnGwY5gJlBvSEVOlJ9Adnym246f99HD+YVW/NaqELx0ryYanBVeZAfDYlg/bayKAUYjMdbmrQ2Sk4EGIVr5fKQBGj36TvC/5J0vw/s46oLKfFTtf2xNTrnh0HI/em12/sOs9oS0/M5gJ6fJKT3dd1Poikq4wG1eqPHQrH32YM62W9xbKJ/rYcO5YNI/khwIznVNtuBl+zAkiGf4hmzQPo5D2GXmNB9wtx11MSobXiFtVrxvcaJw9lkxLGchkW2IQ6AG3ZVeEaekl3iWy4P49FhlJMUQmuiWe8g7IK0VNNqtkgzII9HhUpRWuLR0u+jNBeB99yfG8+ZvnxcZ4sa0i8xRv+U= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR08MB1854E64D7C370BF0A7456977DABB0SN1PR08MB1854namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 79a81afb-403d-4dd5-3fe2-08d59b401d30 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 21:56:40.9894 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1856 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Apr 2018 21:56:58 -0000 --_000_SN1PR08MB1854E64D7C370BF0A7456977DABB0SN1PR08MB1854namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgaW50ZXJlc3RpbmcgZGF0YSwgUHJhdmVlbiDigJMgdGhhbmtzLiAgVGhlcmUgaXMg b25lIGNhdmVhdCB0aGVyZSwgd2hpY2ggaXMgdGhhdCAoSUlVQywgb24gY3VycmVudCBoYXJkd2Fy ZSkgeW91IGNhbuKAmXQgZG8gcGFja2V0IHBhY2luZyB3aXRoIExTTywgYW5kIHNvIG15IHVuZGVy c3RhbmRpbmcgaXMgdGhhdCBldmVuIGZvciBUQ1AgbWFueSBwcm92aWRlcnMgZGlzYWJsZSB0aGlz IGluIHB1cnN1aXQgb2YgYmV0dGVyIGVncmVzcyBtYW5hZ2VtZW50LiAgU28gd2hhdCB3ZeKAmXJl IHJlYWxseSBzYXlpbmcgaXMgdGhhdDoNCg0KICAqICAgT24gY3VycmVudCBoYXJkd2FyZSBhbmQg T1Mgc2V0dXBzLCBVRFAgcnVucyBsZXNzIHRoYW4gaGFsZiBhcyBtdWNoIHRocm91Z2hwdXQgYXMg VENQOyB0aGF0IG5lZWRzIHNvbWUgb3B0aW1pemF0aW9uLCBhcyB3ZeKAmXZlIGFscmVhZHkgZGlz Y3Vzc2VkDQogICogICBUQ1Agd2lsbCBkcmFtYXRpY2FsbHkgZ2FpbiBwZXJmb3JtYW5jZSBvbmNl IGhhcmR3YXJlIG9mZmxvYWQgY2F0Y2hlcyB1cCBhbmQgYWxsb3dzIHBhY2VkIExTTyDwn5iKDQoN Ckhvd2V2ZXIsIGFzIE1pa2tlbCBwb2ludHMgb3V0LCB0aGUgY3J5cHRvIGNvc3RzIGFyZSBsaWtl bHkgdG8gb3ZlcndoZWxtIHRoZSBPUyB0aHJvdWdocHV0IC8gc2NoZWR1bGluZyBpc3N1ZXMgaW4g cmVhbCBkZXBsb3ltZW50cy4gIFNvIEkgdGhpbmsgdGhlIG90aGVyIHJlbGV2YW50IHBpZWNlIHRv IHVuZGVyc3RhbmRpbmcgdGhlIGNvc3QgaGVyZSBpcyB0aGlzOg0KDQogICogICBXaGF0IGlzIHRo ZSB0aHJvdWdocHV0IGFuZCByZWxhdGl2ZSBjb3N0IG9mIFRMUy9UQ1AgdmVyc3VzIFFVSUMgKGku ZS4gaG93IG11Y2ggYXJlIHRoZSBzbWFsbGVyIHVuaXRzIG9mIGVuY3J5cHRpb24gaHVydGluZyB1 cyB2ZXJzdXMsIHNheSwgMTZLQiBUTFMgcmVjb3Jkcyk/DQogICAgICogICBUTFMgaW1wbGVtZW50 YXRpb25zIGFscmVhZHkgdmFyeSBoZXJlOiAgU29tZSBpbXBsZW1lbnRhdGlvbnMgY2hvb3NlIGxh cmdlIHJlY29yZCBzaXplcywgc29tZSB2YXJ5IHJlY29yZCBzaXplcyB0byByZWR1Y2UgZGVsYXkg LyBIb0xCLCBzbyB0aGlzIHByb2JhYmx5IGlzbuKAmXQgYSBzaW5nbGUgbnVtYmVyLg0KICAqICAg SG93IG11Y2ggYWRkaXRpb25hbCBsb2FkIGRvZXMgUE5FIGFkZCB0byB0aGlzIGRpZmZlcmVuY2U/ DQogICogICBUbyB3aGF0IGV4dGVudCB3b3VsZCBQTkUgbWFrZSBmdXR1cmUgY3J5cHRvIG9mZmxv YWRzIGltcG9zc2libGUgdmVyc3VzIHJlcXVpcmVzIG1vcmUgUiZEIHRvIGRldmVsb3A/DQoNCkZy b206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtr ZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTggMToz NCBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21A ZG1hcmMuaWV0Zi5vcmc+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogSW1wYWN0IG9mIGhhcmR3YXJlIG9mZmxvYWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVyZm9ybWFu Y2UNCg0KVGhhbmtzIGZvciBzaGFyaW5nIHRoZXNlIG51bWJlcnMuDQoNCk15IGd1ZXNzIGlzIHRo YXQgdGhlc2Ugb2ZmbG9hZHMgZGVhbCB3aXRoIGtlcm5lbCBzY2hlZHVsaW5nLCBtZW1vcnkgY2Fj aGUgaXNzdWVzLCBhbmQgaW50ZXJydXB0IHNjaGVkdWxpbmcuDQoNCkl0IHByb2JhYmx5IGhhcyB2 ZXJ5IGxpdHRsZSB0byBkbyB3aXRoIGNyeXB0bywgVENQIGhlYWRlcnMsIGFuZCBhbnkgb3RoZXIg Y3B1IHNlbnNpdGl2ZSBwcm9jZXNzaW5nLg0KDQpUaGlzIGlzIHdoZXJlIG5ldG1hcCBlbnRlcnM6 IHlvdSBjYW4gdHJhbnNwYXJlbnRseSBmZWVkIHRoZSBkYXRhIGFzIGl0IGJlY29tZXMgYXZhaWxh YmxlIHdpdGggdmVyeSBsaXR0bGUgc3luYyB3b3JrIGFuZCB5b3UgY2FuIGFsc28gZWZmaWNpZW50 bHkgcGlwZWxpbmUgc28geW91IHBhc3MgZGF0YSB0byBkZWNyeXB0b3IsIHRoZW4gdG8gYXBwLCB3 aXRoIGFzIGxpdHRsZSBidXMgdHJhZmZpYyBhcyBwb3NzaWJsZS4gTm8gbmVlZCB0byBjb3B5IGRh dGEgb3Igc3luY2hyb25pemUga2VybmVsIHNwYWNlLg0KDQpGb3IgMUsgcGFja2V0cyB5b3Ugd291 bGQgdXNlIGFib3V0IDEwMDBucyAoMyBjeWNsZXMvYnl0ZSkgb24gY3J5cHRvIGFuZCB0aGlzIHdv dWxkIGhhcHBlbiBpbiBMMSBjYWNoZS4gSXQgd291bGQgb2YgY291cnNlIGNvbnN1bWUgYSBjb3Jl IHdoaWNoIGEgY3J5cHRvIG9mZmxvYWQgd291bGQgbm90LCBidXQgdGhhdCBjYW4gYmUgZGViYXRl ZCBiZWNhdXNlIHdpdGggMTggY29yZSBzeXN0ZW1zLCB5b3VyIHByb2JsZW0gaXMgbWVtb3J5IGFu ZCBuZXR3b3JrIG1vcmUgdGhhbiBDUFUuDQoNCk15IGNvbmNlcm4gd2l0aCBQTkUgaXMgZm9yIHNt YWxsIHBhY2tldHMgYW5kIGxvdyBsYXRlbmN5IHdoZXJlDQoxKSBhbiBlc3RpbWF0ZWQgMjRucyBm b3IgUE4gZW5jcnlwdGlvbiBhbmQgZGVjcnlwdGlvbiBiZWNvbWVzIG1lYXN1cmFibGUgaWYgeW91 ciBuZXR3b3JrIGlzIGZhc3QgZW5vdWdoLg0KMikgYW55IGRhbWFnZSB0byB0aGUgcGFja2V0IGJ1 ZmZlciBjYXVzZSBhbGwgc29ydHMgb2YgbWVtb3J5IGFuZCBjcHUgYnVzIHRyYWZmaWMgaXNzdWVz Lg0KDQoxKSBpcyBhbm5veWluZy4gMikgaXMgYmFkLCBjb21wbGV0ZWx5IGF2b2lkYWJsZSBidXQg bm90IGFzIFBSIDEwNzkgaXMgZm9ybXVsYXRlZCBjdXJyZW50bHkuDQoNCjIpIGlzIGFsc28gbGlr ZWx5IGJhZCBmb3IgaGFyZHdhcmUgb2ZmbG9hZCB1bml0cyBhcyB3ZWxsLg0KDQpBcyB0byBTUlYt SU8gLSBJ4oCZbSBub3QgZmFtaWxpYXIgd2l0aCBpdCwgYnV0IG9idmlvdXNseSB0aGVyZSBpcyBz b21lIElPIGFic3RyYWN0aW9uIGxheWVyIC0gdGhlIHF1ZXN0aW9uIGlzIGhvdyB5b3UgbWFrZSBp dCBhY2Nlc3NpYmxlIHRvIGFwcHMgYXMgb3Bwb3NlZCB0byBkZXZpY2UgZHJpdmVycyB0aGF0IGRv ZXMgbm9yIHdvcmsgd2l0aCB5b3UgUVVJQyBjdXN0b20gc3RhY2ssIGFuZCBuZXRtYXAgaXMgb25l IG9wdGlvbiBoZXJlLg0KDQpLaW5kIFJlZ2FyZHMsDQpNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2Vu DQoNCg0KT24gNCBBcHJpbCAyMDE4IGF0IDIyLjE1LjUyLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh biAocHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpwcmF2Yj00MG1p Y3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+KSB3cm90ZToNClNvbWUgY29tcGFyYXRpdmUgbnVt YmVycyBmcm9tIGFuIG91dCBvZiBib3ggZGVmYXVsdCBzZXR0aW5ncyBXaW5kb3dzIFNlcnZlciAy MDE2IChyZWxlYXNlZCB2ZXJzaW9uKSBmb3IgYSBzaW5nbGUgY29ubmVjdGlvbiB3aXRoIGEgbWlj cm9iZW5jaG1hcmsgdG9vbDoNCg0KT2ZmbG9hZHMgZW5hYmxlZA0KDQpUQ1AgZ2Jwcw0KDQpVRFAg Z2Jwcw0KDQpMU08gKyBMUk8gKyBjaGVja3N1bQ0KDQoyNA0KDQozLjYNCg0KQ2hlY2tzdW0gb25s eQ0KDQo3LjYNCg0KMy42DQoNCk5vbmUNCg0KNS42DQoNCjIuMw0KDQoNClRoaXMgaXMgZm9yIGEg ZnVsbHkgYm90dGxlbmVja2VkIENQVSBjb3JlIC0tIGlmIHlvdSBydW4gbG93ZXIgZGF0YSByYXRl cyB0aGVyZSBpcyBzdGlsbCBhIHNpZ25pZmljYW50IGRpZmZlcmVuY2UgaW4gQ3ljbGVzL2J5dGUg Y29zdC4gU2FtZSBpbmNyZWFzZWQgQ1BVIGNvc3QgYXBwbGllcyBmb3IgY2xpZW50IHN5c3RlbXMg Z29pbmcgb3ZlciBoaWdoIGRhdGEgcmF0ZSBXaWZpIGFuZCBjZWxsdWxhci4NCg0KVGhpcyBpcyB3 aXRob3V0IGFueSBjcnlwdG8uIE9uY2UgeW91IGFkZCBjcnlwdG8gdGhlIG51bWJlcnMgYmVjb21l IG11Y2ggd29yc2Ugd2l0aCBjcnlwdG8gY29zdCBiZWNvbWluZyBkb21pbmFudC4gQWRkaW5nIGFu b3RoZXIgY3J5cHRvIHN0ZXAgZnVydGhlciBleGFjZXJiYXRlcyB0aGUgcHJvYmxlbS4gSGVuY2Ug Y3J5cHRvIG9mZmxvYWQgZ2FpbnMgaW4gaW1wb3J0YW5jZSBmb2xsb3dlZCBieSB0aGVzZSBiYXRj aCBvZmZsb2Fkcy4NCg0KSWYgZm9sa3MgbmVlZCBhbnkgbW9yZSBudW1iZXJzIEnigJlkIGJlIGhh cHB5IHRvIHByb3ZpZGUgdGhlbS4NCg0KVGhhbmtzDQoNCg== --_000_SN1PR08MB1854E64D7C370BF0A7456977DABB0SN1PR08MB1854namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFpbG9uLCBsaS5haXJtYWlsb24sIGRp di5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjY4NTc4NzM3OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEyNTE4NjgxMTIgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6MTEzNzk4ODU5MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6OTQyOTc2MjAwIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF04oCZcyBpbnRlcmVz dGluZyBkYXRhLCBQcmF2ZWVuIOKAkyB0aGFua3MuJm5ic3A7IFRoZXJlIGlzIG9uZSBjYXZlYXQg dGhlcmUsIHdoaWNoIGlzIHRoYXQgKElJVUMsIG9uIGN1cnJlbnQgaGFyZHdhcmUpIHlvdSBjYW7i gJl0IGRvIHBhY2tldCBwYWNpbmcgd2l0aCBMU08sIGFuZCBzbyBteSB1bmRlcnN0YW5kaW5nIGlz IHRoYXQgZXZlbiBmb3IgVENQIG1hbnkgcHJvdmlkZXJzIGRpc2FibGUgdGhpcyBpbiBwdXJzdWl0 IG9mDQogYmV0dGVyIGVncmVzcyBtYW5hZ2VtZW50LiZuYnNwOyBTbyB3aGF0IHdl4oCZcmUgcmVh bGx5IHNheWluZyBpcyB0aGF0OjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9w OjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPk9uIGN1cnJlbnQgaGFyZHdh cmUgYW5kIE9TIHNldHVwcywgVURQIHJ1bnMgbGVzcyB0aGFuIGhhbGYgYXMgbXVjaCB0aHJvdWdo cHV0IGFzIFRDUDsgdGhhdCBuZWVkcyBzb21lIG9wdGltaXphdGlvbiwgYXMgd2XigJl2ZSBhbHJl YWR5IGRpc2N1c3NlZDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPlRDUCB3aWxs IGRyYW1hdGljYWxseSBnYWluIHBlcmZvcm1hbmNlIG9uY2UgaGFyZHdhcmUgb2ZmbG9hZCBjYXRj aGVzIHVwIGFuZCBhbGxvd3MNCjx1PnBhY2VkPC91PiBMU08gPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2VyaWYiPiYjMTI4NTIyOzwvc3Bh bj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgYXMgTWlra2VsIHBvaW50 cyBvdXQsIHRoZSBjcnlwdG8gY29zdHMgYXJlIGxpa2VseSB0byBvdmVyd2hlbG0gdGhlIE9TIHRo cm91Z2hwdXQgLyBzY2hlZHVsaW5nIGlzc3VlcyBpbiByZWFsIGRlcGxveW1lbnRzLiZuYnNwOyBT byBJIHRoaW5rIHRoZSBvdGhlciByZWxldmFudCBwaWVjZSB0byB1bmRlcnN0YW5kaW5nIHRoZSBj b3N0IGhlcmUgaXMgdGhpczo8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDow aW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj5XaGF0IGlzIHRoZSB0aHJvdWdo cHV0IGFuZCByZWxhdGl2ZSBjb3N0IG9mIFRMUy9UQ1AgdmVyc3VzIFFVSUMgKGkuZS4gaG93IG11 Y2ggYXJlIHRoZSBzbWFsbGVyIHVuaXRzIG9mIGVuY3J5cHRpb24gaHVydGluZyB1cyB2ZXJzdXMs IHNheSwgMTZLQiBUTFMgcmVjb3Jkcyk/PG86cD48L286cD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRv cDowaW4iIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPlRMUyBpbXBsZW1lbnRh dGlvbnMgYWxyZWFkeSB2YXJ5IGhlcmU6Jm5ic3A7IFNvbWUgaW1wbGVtZW50YXRpb25zIGNob29z ZSBsYXJnZSByZWNvcmQgc2l6ZXMsIHNvbWUgdmFyeSByZWNvcmQgc2l6ZXMgdG8gcmVkdWNlIGRl bGF5IC8gSG9MQiwgc28gdGhpcyBwcm9iYWJseSBpc27igJl0IGEgc2luZ2xlIG51bWJlci48bzpw PjwvbzpwPjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj5Ib3cgbXVjaCBhZGRp dGlvbmFsIGxvYWQgZG9lcyBQTkUgYWRkIHRvIHRoaXMgZGlmZmVyZW5jZT88bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwwIGxldmVsMSBsZm8yIj5UbyB3aGF0IGV4dGVudCB3b3VsZCBQTkUgbWFrZSBmdXR1 cmUgY3J5cHRvIG9mZmxvYWRzDQo8aT5pbXBvc3NpYmxlPC9pPiB2ZXJzdXMgPGk+cmVxdWlyZXMg bW9yZSBSJmFtcDtEIHRvIGRldmVsb3A8L2k+PzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgW21h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPk1pa2tlbCBG YWhuw7hlIErDuHJnZW5zZW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCA0LCAy MDE4IDE6MzQgUE08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtw cmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0 O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJbXBhY3Qgb2YgaGFy ZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGZvciBzaGFyaW5nIHRoZXNlIG51bWJlcnMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk15IGd1ZXNzIGlzIHRoYXQgdGhlc2Ugb2Zm bG9hZHMgZGVhbCB3aXRoIGtlcm5lbCBzY2hlZHVsaW5nLCBtZW1vcnkgY2FjaGUgaXNzdWVzLCBh bmQgaW50ZXJydXB0IHNjaGVkdWxpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPkl0IHByb2JhYmx5IGhhcyB2ZXJ5IGxpdHRsZSB0byBkbyB3aXRoIGNyeXB0bywgVENQIGhl YWRlcnMsIGFuZCBhbnkgb3RoZXIgY3B1IHNlbnNpdGl2ZSBwcm9jZXNzaW5nLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIHdoZXJlIG5ldG1hcCBlbnRlcnM6IHlv dSBjYW4gdHJhbnNwYXJlbnRseSBmZWVkIHRoZSBkYXRhIGFzIGl0IGJlY29tZXMgYXZhaWxhYmxl IHdpdGggdmVyeSBsaXR0bGUgc3luYyB3b3JrIGFuZCB5b3UgY2FuIGFsc28gZWZmaWNpZW50bHkg cGlwZWxpbmUgc28geW91IHBhc3MgZGF0YQ0KIHRvIGRlY3J5cHRvciwgdGhlbiB0byBhcHAsIHdp dGggYXMgbGl0dGxlIGJ1cyB0cmFmZmljIGFzIHBvc3NpYmxlLiBObyBuZWVkIHRvIGNvcHkgZGF0 YSBvciBzeW5jaHJvbml6ZSBrZXJuZWwgc3BhY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPkZvciAxSyBwYWNrZXRzIHlvdSB3b3VsZCB1c2UgYWJvdXQgMTAwMG5zICgzIGN5 Y2xlcy9ieXRlKSBvbiBjcnlwdG8gYW5kIHRoaXMgd291bGQgaGFwcGVuIGluIEwxIGNhY2hlLiBJ dCB3b3VsZCBvZiBjb3Vyc2UgY29uc3VtZSBhIGNvcmUgd2hpY2ggYSBjcnlwdG8gb2ZmbG9hZCB3 b3VsZCBub3QsDQogYnV0IHRoYXQgY2FuIGJlIGRlYmF0ZWQgYmVjYXVzZSB3aXRoIDE4IGNvcmUg c3lzdGVtcywgeW91ciBwcm9ibGVtIGlzIG1lbW9yeSBhbmQgbmV0d29yayBtb3JlIHRoYW4gQ1BV LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9u dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NeSBjb25jZXJuIHdpdGggUE5F IGlzIGZvciBzbWFsbCBwYWNrZXRzIGFuZCBsb3cgbGF0ZW5jeSB3aGVyZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+MSkgYW4gZXN0aW1hdGVkIDI0bnMgZm9yIFBO IGVuY3J5cHRpb24gYW5kIGRlY3J5cHRpb24gYmVjb21lcyBtZWFzdXJhYmxlIGlmIHlvdXIgbmV0 d29yayBpcyBmYXN0IGVub3VnaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjIpIGFueSBkYW1hZ2UgdG8gdGhlIHBhY2tldCBidWZmZXIgY2F1c2UgYWxsIHNvcnRz IG9mIG1lbW9yeSBhbmQgY3B1IGJ1cyB0cmFmZmljIGlzc3Vlcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+MSkgaXMgYW5ub3lpbmcuIDIpIGlzIGJhZCwgY29tcGxldGVseSBh dm9pZGFibGUgYnV0IG5vdCBhcyBQUiAxMDc5IGlzIGZvcm11bGF0ZWQgY3VycmVudGx5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yKSBpcyBhbHNvIGxpa2VseSBiYWQgZm9y IGhhcmR3YXJlIG9mZmxvYWQgdW5pdHMgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFzIHRvIFNSVi1JTyAtIEni gJltIG5vdCBmYW1pbGlhciB3aXRoIGl0LCBidXQgb2J2aW91c2x5IHRoZXJlIGlzIHNvbWUgSU8g YWJzdHJhY3Rpb24gbGF5ZXIgLSB0aGUgcXVlc3Rpb24gaXMgaG93IHlvdSBtYWtlIGl0IGFjY2Vz c2libGUgdG8gYXBwcyBhcyBvcHBvc2VkIHRvIGRldmljZSBkcml2ZXJzDQogdGhhdCBkb2VzIG5v ciB3b3JrIHdpdGggeW91IFFVSUMgY3VzdG9tIHN0YWNrLCBhbmQgbmV0bWFwIGlzIG9uZSBvcHRp b24gaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg aWQ9ImJsb29wX3NpZ25fMTUyMjg3MzM1MDQxNTEyMDEyOCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vu c2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gNCBBcHJpbCAyMDE4IGF0 IDIyLjE1LjUyLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAoPGEgaHJlZj0ibWFpbHRvOnByYXZi PTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyI+cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRt YXJjLmlldGYub3JnPC9hPikgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5T b21lIGNvbXBhcmF0aXZlIG51bWJlcnMgZnJvbSBhbiBvdXQgb2YgYm94IGRlZmF1bHQgc2V0dGlu Z3MgV2luZG93cyBTZXJ2ZXIgMjAxNiAocmVsZWFzZWQgdmVyc2lvbikgZm9yIGEgc2luZ2xlDQog Y29ubmVjdGlvbiB3aXRoIGEgbWljcm9iZW5jaG1hcmsgdG9vbDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9 IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBz ZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3Ai IHN0eWxlPSJ3aWR0aDoxMTYuODVwdDtib3JkZXI6c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXIt Ym90dG9tOnNvbGlkICM2NjY2NjYgMS41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9mZmxvYWRzIGVu YWJsZWQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2Ljlw dDtib3JkZXItdG9wOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXIt Ym90dG9tOnNvbGlkICM2NjY2NjYgMS41cHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4w cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRDUCBnYnBzPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249 InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7Ym9yZGVyLXRvcDpzb2xpZCAjOTk5OTk5IDEuMHB0 O2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjNjY2NjY2IDEuNXB0O2JvcmRl ci1yaWdodDpzb2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5VRFAgZ2Jwczwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+ DQo8L3RyPg0KPHRyPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6 MTE2Ljg1cHQ7Ym9yZGVyOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRp bmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5MU08gJiM0MzsgTFJPICYjNDM7IGNoZWNrc3VtPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0i MTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7Ym9yZGVyLXRvcDpub25lO2Jv cmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjOTk5OTk5IDEuMHB0O2JvcmRlci1y aWdodDpzb2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yNDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0 aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206 c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRk aW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+My42PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+ DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuODVwdDtib3Jk ZXI6c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowaW4gNS40cHQg MGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PkNoZWNrc3VtIG9ubHk8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk dGg6MTE2LjlwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9t OnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7cGFk ZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjcuNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9 IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTti b3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXIt cmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+My42PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0 b3AiIHN0eWxlPSJ3aWR0aDoxMTYuODVwdDtib3JkZXI6c29saWQgIzk5OTk5OSAxLjBwdDtib3Jk ZXItdG9wOm5vbmU7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk5vbmU8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZh bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2LjlwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxl ZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNv bGlkICM5OTk5OTkgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjUuNjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYu OXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQg Izk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBp biA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Mi4zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPlRoaXMgaXMgZm9yIGEgZnVsbHkgYm90dGxlbmVja2VkIENQVSBjb3JlIC0tDQo8 aT5pZiB5b3UgcnVuIGxvd2VyIGRhdGEgcmF0ZXMgdGhlcmUgaXMgc3RpbGwgYSBzaWduaWZpY2Fu dCBkaWZmZXJlbmNlIGluIEN5Y2xlcy9ieXRlIGNvc3Q8L2k+LiBTYW1lIGluY3JlYXNlZCBDUFUg Y29zdCBhcHBsaWVzIGZvciBjbGllbnQgc3lzdGVtcyBnb2luZyBvdmVyIGhpZ2ggZGF0YSByYXRl IFdpZmkgYW5kIGNlbGx1bGFyLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBpcyB3aXRo b3V0IGFueSBjcnlwdG8uIE9uY2UgeW91IGFkZCBjcnlwdG8gdGhlIG51bWJlcnMgYmVjb21lIG11 Y2ggd29yc2UNCjxpPndpdGggY3J5cHRvIGNvc3QgYmVjb21pbmcgZG9taW5hbnQ8L2k+LiBBZGRp bmcgYW5vdGhlciBjcnlwdG8gc3RlcCBmdXJ0aGVyIGV4YWNlcmJhdGVzIHRoZSBwcm9ibGVtLiBI ZW5jZSBjcnlwdG8gb2ZmbG9hZCBnYWlucyBpbiBpbXBvcnRhbmNlIGZvbGxvd2VkIGJ5IHRoZXNl IGJhdGNoIG9mZmxvYWRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklmIGZvbGtzIG5lZWQgYW55 IG1vcmUgbnVtYmVycyBJ4oCZZCBiZSBoYXBweSB0byBwcm92aWRlIHRoZW0uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_SN1PR08MB1854E64D7C370BF0A7456977DABB0SN1PR08MB1854namp_-- From nobody Thu Apr 5 17:38:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD0312E85E for ; Thu, 5 Apr 2018 17:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 XIlbwS43qQZd for ; Thu, 5 Apr 2018 17:38:39 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D80B126B6E for ; Thu, 5 Apr 2018 17:38:39 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id y46-v6so29435045otd.4 for ; Thu, 05 Apr 2018 17:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w+tWSmuhzxCf3uExd+BRyT5K4rrjuhkcuCsFzoR5IUM=; b=E4HdXPXjzdReuF1iueK5e68CJDOouYpP5gcRRUxv0Ixrd8HYLP+XjhL+kbj0IyGDYb i/Hvsysp78+hK6DY0yqb45f2fQ9+KcnFDHcwTOiBe81pCR54vWpqp4bCIzht2/91j7qy 5PhsdTGAE0MonnrT5RjtEjHMjAFjuF2xyyUnbxhjAweYcVQV+Sd52B9ohgKc/F2JnnHi 8EWfOPHyP0oMBjwxaA8annF6c26SUYazeqN4xlzJkAhJNW/PEWRtt3Ta9uy2bcMyl+bH DioiHqUuhGzbYYnrtD9l59p6SwNaHY5PSYJxOO/XvHp2PVI+xpVTFj0hVPhhkmZfkaND Liqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=w+tWSmuhzxCf3uExd+BRyT5K4rrjuhkcuCsFzoR5IUM=; b=BuhZuYNbB+wj9ca6j1rkiIprOrKAhxKR+a1iLTMp7jQXA4e6+KFkUespd/6jr5Z87I 7SN0JcGKA/fwLZGRlXGYDdl0uVvzEiPkIMjJ8f1ojLlRjG7Uc6/sYE69k4vXZMRXfU+P J6HeT+YB+Btw8dK2ZwiMAaKOUyo5LrC9D7YMTMjgX8FocNcJHmgQHCJX+bAzAugcFdhZ MtsIFbqbPGa19KhnvvntYntzwX76e2CiaY+8ljyCHA37q6W/eoO4SuOlc5VWZ0n0/UdQ 5R3Bn7VC8BE0g1da9zc0wUKuDSdXBL6PlDkr/A0K3Vo08LF+2owcaunGkJYIip9q2A0o nBig== X-Gm-Message-State: ALQs6tCHYQmqKV/eMSn5zR+wZuUW45uLEYK9CZbehSjaN02LnLCrz9jr 5GkkKIbYEYkyDNOmJm8dseyQTJH/0eipX+E3Fnsz7EdJ X-Google-Smtp-Source: AIpwx49xr+osC+Nop2EcYdZk5FRNwDZYRPvEVPE0WaGkAY0EeJHMot9OrbRmb1dprnw4nut0b4+0o0kHBhvJQmFAJas= X-Received: by 2002:a9d:29ea:: with SMTP id g39-v6mr15554201otd.241.1522975118565; Thu, 05 Apr 2018 17:38:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 5 Apr 2018 17:38:38 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Martin Thomson Date: Fri, 6 Apr 2018 10:38:38 +1000 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: Christian Huitema Cc: Frederick Kautz , QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= 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, 06 Apr 2018 00:38:42 -0000 On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema wrote: >> On Apr 5, 2018, at 8:58 AM, Frederick Kautz wrote: >> >> Are you concerned that middleware boxes may be trained to reject migrations, thereby forcing a new connection with a visible negotiation? > > Yes. Hence the need to grease. For example, have clients do some gratuitous migration to a new source port number rather frequently. This seems like a simple fix, particularly since Mike recently added text that suggests occasional use of new connection IDs. In the spirit of keeping the wheels greased: https://github.com/quicwg/base-drafts/pull/1269 From nobody Thu Apr 5 18:10:54 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07A51252BA for ; Thu, 5 Apr 2018 18:10:53 -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 oKhXgZp5Dxkr for ; Thu, 5 Apr 2018 18:10:51 -0700 (PDT) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::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 7F7321200A0 for ; Thu, 5 Apr 2018 18:10:51 -0700 (PDT) Received: by mail-pl0-x230.google.com with SMTP id a39-v6so2318903pla.10 for ; Thu, 05 Apr 2018 18:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c2xe+o9NN8WAMj91TBfZCI7l9GbOp/TrI19ZNrnQXos=; b=M9wxMksrz/K52WVWWYHoMHR5N5fxzayy7/aqx01iWCHOtW1PsDNGR3THoDkZpQIejw 9L8LuIbNn1QRXBWO/RupwHzHxJS+Jue9ChePTvop9j/DJXr/bvyAiEvtXDx5lhZft8jA /CN2Ho93zcjZYK0rq8BgqsKC2DXVXBlKlJ7RJBTLiq699fsGmOPN8qHanBRDqgPG2/cI GYrGi1CBrwlINfhIjFUH8EEQ+zW980hvu3YKOgCdCbfoUT5nQW8tUc7yvnGxGXmFX4X4 LSwd2pfh4UF6A0P8fSP8Gpo/5dpmqHeGXKf23mTpKfYFvDXDny0tuqjyB6SME0oOLd46 3CNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=c2xe+o9NN8WAMj91TBfZCI7l9GbOp/TrI19ZNrnQXos=; b=oui60wrqmYIyACBVJJVQvWUlQbmZQDq/OgTyyWu3oWYO8TCkEZ21ckDbzoAdXztmKU 9kwRE/ZV8zh+BtGX2RSI77DnObxFC99ng73KtX5r8iGUi0N1HzfWASrsffid3ozQ3/bv fkrTMtEA1maEdqNUDzHBQQmxhZikTIjJ1dx0TO//ks2LLNvCdoI5ac+Oo/mOhg4DXfy6 6OeKBSPGgWsCXpHVFtkpCSJgo2aMFyg5FXC/EH2TXpKqgbO+Vh+yuR0ceacbK4JET+9D SgexKnoT/WW1PfMMOKLndz/2cf8MnqfhBc7aM0Ek0M9FfAinNB62ZCBtM36soKqlUJSK VwOA== X-Gm-Message-State: AElRT7E/l/r4KSTtrldlQYlHW8oppav4dhzwrH0S8Q6JqFidHH2aIOVo YqmI+Zh7vFjI7HQQ4IiVvvpbMsW5tsTg6ipKODI= X-Google-Smtp-Source: AIpwx49dOthWyT5TX7LDR1/VU6BbcASEHKdoDKsh1Vdw96rKf7e4JO9YOtayvN5jNlrJqcU9kFJ7cOhvrR5daFA4GqE= X-Received: by 2002:a17:902:209:: with SMTP id 9-v6mr24581565plc.403.1522977051160; Thu, 05 Apr 2018 18:10:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Thu, 5 Apr 2018 18:10:50 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <022A1A49-1E9B-4428-8EAE-4C16843715AA@gmail.com> From: Kazuho Oku Date: Fri, 6 Apr 2018 10:10:50 +0900 Message-ID: Subject: Re: Getting to consensus on packet number encryption To: "Philipp S. Tiesel" Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Praveen Balasubramanian , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Lars Eggert Content-Type: multipart/alternative; boundary="00000000000022b352056923ba25" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 01:10:54 -0000 --00000000000022b352056923ba25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-04-05 18:57 GMT+09:00 Philipp S. Tiesel : > > > On 5. Apr 2018, at 09:56, Kazuho Oku wrote: > > 2018/04/05 15:00=E3=80=81Mikkel Fahn=C3=B8e J=C3=B8rgensen =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > > There is also the concern raised by some that packet reordering in transi= t > could happen without PN - this is always an issue - but is it worth the > cost, and is it still a real concern for a protocol that was not designed > to be strictly ordered? > > > I agree that reordering by middleboxes *might not* happen. But I would > also argue that we should encrypt the PN if we think reordering *might* > happen. > > If we encrypt PN now, we will have the chance to revisit the design in th= e > future versions of QUIC. But if we ship without PNE and then find out > middleboxes start using the PN under the assumption that they are sent > in-order, we would forever be forced to stick to them sent in-order, in > cleartext. > > Ossification closes the door to future modifications. > > > For the case of the PN, I also see this problem, but (inspired by Brian), > I started thinking of this from a different perspective: > > What if we think of the "clear PN" as a path signal, which is > coincidentally used as PN in the transport in v1. > I am not sure if that would solve the middlebox reordering issue or any ossification caused by the assumption that packet numbers increase in the order the packets are being sent. It's confusing, but the discussion about reordering / ossification is about what happens on each path, while the discussion about privacy is about what happens when switching to a new 5-tuple. For me, the consequences seem the following: > - It instantly becomes somewhat of an invariant, for which we can clearl= y > define > behaviour (monotonically increasing, jumps infrequent, =E2=80=A6) > - Need to design the "clear PN=E2=80=9D for space efficiency =E2=80=93 u= se a variable > length > integer that can reduce to one byte if we have a "transport PN" in the > encrypted > part in v2 > > Maybe a =E2=80=9Cfaster=E2=80=9D way forward without needing to feel ossi= fied. > > > > How does WebRTC work in this context? > > > On 5 April 2018 at 01.42.23, Praveen Balasubramanian (pravb@microsoft.com= ) > wrote: > > What is the privacy issue if you are not doing migration? Migration + PNE > (or multiple PN spaces) should go hand in hand. > > > AVE! > Philipp S. Tiesel / phils=E2=80=A6 > -- > {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----= , > wenn w eine aube ist dn man au dran dre en = | > o Schr an muss hc h (Kurt Schwitters)= | > :wq! <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----= ' > > --=20 Kazuho Oku --00000000000022b352056923ba25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-04-05 18:57 GMT+09:00 Philipp S. Tiesel <phils@in-panik.de>= ;:


On 5. Apr 2018, at 09:56, Kazuho Oku <kazuhooku@gmail.com> wrot= e:

= 2018/04/05 15= :00=E3=80=81Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>=E3=81=AE=E3=83=A1=E3=83= =BC=E3=83=AB:

There is also the co= ncern raised by some that packet reordering in transit could happen without= PN - this is always an issue - but is it worth the cost, and is it still a= real concern for a protocol that was not designed to be strictly ordered?<= /div>

I agree that reordering by middleboxes *might not* happen. But I would a= lso argue that we should encrypt the PN if we think reordering *might* happ= en.

If we encrypt PN now, we will have the chanc= e to revisit the design in the future versions of QUIC. But if we ship with= out PNE and then find out middleboxes start using the PN under the assumpti= on that they are sent in-order, we would forever be forced to stick to them= sent in-order, in cleartext.=C2=A0

Ossification closes the door to future modificat= ions.

For the case o= f the PN, I also see this problem, but (inspired by Brian),=C2=A0
I started thinking of this from a different perspective:

What if we think of the "clear PN" as a path signal, whic= h is coincidentally used as PN in the transport in v1.

I am not sure if that would solve the middleb= ox reordering issue or any ossification caused by the assumption that packe= t numbers increase in the order the packets are being sent.

<= /div>
It's confusing, but the discussion about reordering / ossific= ation is about what happens on each path, while the discussion about privac= y is about what happens when switching to a new 5-tuple.

For me, the consequences seem the followin= g:
=C2=A0- It instantly becomes somewhat of an invariant, for whi= ch we can clearly define
=C2=A0 =C2=A0behaviour (monotonically in= creasing, jumps infrequent, =E2=80=A6)=C2=A0
=C2=A0- Need to desi= gn the "clear PN=E2=80=9D for space efficiency =E2=80=93 use a variabl= e length
=C2=A0 =C2=A0integer that can reduce to one byte if we h= ave a "transport PN" in the encrypted
=C2=A0 =C2=A0part= in v2

Maybe a =E2=80=9Cfaster=E2=80=9D way forwar= d without needing to feel ossified.



How does WebRTC work in this context?

=

On 5 April 2018 at 01.42.23, Praveen Balasubramanian (pravb@microsoft.com) wrote:

What is the privacy issue if you are not doing migrat= ion? Migration + PNE (or multiple PN spaces) should go hand in hand.=

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




--
Kazuho Oku<= /div>
--00000000000022b352056923ba25-- From nobody Thu Apr 5 19:06:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193D31241F3 for ; Thu, 5 Apr 2018 19:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 XzvW0ez6esS7 for ; Thu, 5 Apr 2018 19:06:02 -0700 (PDT) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::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 D7FAB1205F0 for ; Thu, 5 Apr 2018 19:06:01 -0700 (PDT) Received: by mail-pl0-x234.google.com with SMTP id k6-v6so16618393pls.5 for ; Thu, 05 Apr 2018 19:06: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=Pr2xegpcHnzXPl2vuWnFdozwP4gj50GU8i2IMDyAUTw=; b=PFd0k+1sI62+mzGQh7tBS5R8/XwcIVOUvFnX/lb6WnIUPztMFO1yOTujTz+F4EWTvd uAQllDgsg+5r8qzp/UTyHt/k8uFpDKjtRXzcLE3FK3yvj7SM7silj6NtmbtnrlQomohw i7ySl8Bfwe31dCTnH1zkFK19cjs06xDeR2W4RU3dm2H0DutUN8mQPPYrQBik4hmhguh6 CtpTSu5rUPXjzjCKDdsma1zFPOqDV7f3SmOVcjzxq11u3HmXfyVSEEHJH5Ccwn3MAmsk HijbZ+O1p+M0N0oj70iGNF0E9Xgf/BjOrXcxvfpqur9w4AbMcfDb3elmfc3rjnKw5Rbk sBOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=Pr2xegpcHnzXPl2vuWnFdozwP4gj50GU8i2IMDyAUTw=; b=qubXgHbP9Fei58mBl8ap4wDtgXvrlA3RnrjfhrgdVI9/XfrLBUtxgWXQ4+s78GYsZL 6Oaw0R6CQRzQmDLefj6r13jUcn1V9aP3nQscsvJ/A4IMgsVV1pEmTrYDof7mKzc7rKf7 fuLIXJe4/ey1Q5RxmxHy6iPll3wyEaALtSXAI0AFScXDOlkPTOeufuiZ0jdj1/y+0pES F/r1adC+tQXLGQw/4X33PGxxiS65/6ycqDpI5rLn9Vau75uSK7a/MT/+raZLOmVJZgS/ X17S9oacuu49eGkiIumtuUiGl9yCXRR0hpjiLeE+0alkuZl/vMoWEc0dFOcn3gwi/E7+ 4OtQ== X-Gm-Message-State: AElRT7GPdvrQ075QCk+DLv+4BABDQ+qiC3vMjprX4tJog6olbI4DzFRp WxTqhzK+pB5Vj3omd97Hu8dG+NNuamf2gw/VY+s= X-Google-Smtp-Source: AIpwx4+XJwm9sA595TcQTehxlM7z5YS4vEkO+Gj4sx5tOrNzSYu+1zR6+5laGcOhi6FCWH4lT06Lw7En7G+z4ec1qtw= X-Received: by 2002:a17:902:209:: with SMTP id 9-v6mr24744899plc.403.1522980361395; Thu, 05 Apr 2018 19:06:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Thu, 5 Apr 2018 19:06:00 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Kazuho Oku Date: Fri, 6 Apr 2018 11:06:00 +0900 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: Martin Thomson Cc: Christian Huitema , QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Frederick Kautz Content-Type: multipart/alternative; boundary="00000000000070e2080569247f23" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 02:06:04 -0000 --00000000000070e2080569247f23 Content-Type: text/plain; charset="UTF-8" 2018-04-06 9:38 GMT+09:00 Martin Thomson : > On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema > wrote: > >> On Apr 5, 2018, at 8:58 AM, Frederick Kautz > wrote: > >> > >> Are you concerned that middleware boxes may be trained to reject > migrations, thereby forcing a new connection with a visible negotiation? > > > > Yes. Hence the need to grease. For example, have clients do some > gratuitous migration to a new source port number rather frequently. > > This seems like a simple fix, particularly since Mike recently added > text that suggests occasional use of new connection IDs. In the > spirit of keeping the wheels greased: > > https://github.com/quicwg/base-drafts/pull/1269 > > Would you mind explaining how you would solve the issue? If I understand correctly, Christian's concern is that some middleboxes might only create a hole if the first packet sent by a client (using a new port) looks like a Initial packet. Consider the case where you want to build a middlebox that allows QUIC, but no other UDP-based protocols. By observing the QUIC packets, you think that you can implement such a middlebox by creating a hole only when the UDP flow starts with a packet starting with 0xff (long header + Initial). But such a design will block migration. The question is if we need to address the issue proactively, and how. FWIW, I can see at least three possible approaches here. 1. frequent gratuitous migration by clients, so that middlebox vendors can notice that there design is wrong prior to shipping it 2. make long header packets not easily indistinguishable from short header packets (by encrypting the type field) 3. mimic 0-RTT handshake when gratuitously switching to a new UDP flow (depends on #1262) 1 and 2 have been discussed on this thread. I haven't yet seen 3 being discussed. The concerns so far being raised for 1 is that NATs might run out of unassigned ports and that switching to a new path might trigger the restart of congestion control on large-scale NATs that use multiple public addresses. The concern so far being raised for 2 is that stateless load balancers would be required to decrypt the type field (or the entire packet, depending on how we encrypt) to determine if a packet is trying to initiate a new connection. -- Kazuho Oku --00000000000070e2080569247f23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-04-06 9:38 GMT+09:00 Martin Thomson <martin.thomson@gmail= .com>:
On = Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema <huitema@huitema.net> wrote:
>> On Apr 5, 2018, at 8:58 AM, Frederick Kautz <fkautz@alumni.cmu.edu> wrote:
>>
>> Are you concerned that middleware boxes may be trained to reject m= igrations, thereby forcing a new connection with a visible negotiation?
>
> Yes. Hence the need to grease. For example, have clients do some gratu= itous migration to a new source port number rather frequently.

This seems like a simple fix, particularly since Mike recently added=
text that suggests occasional use of new connection IDs.=C2=A0 In the
spirit of keeping the wheels greased:

https://github.com/quicwg/base-drafts/pull/1269<= /a>


Would you mind expl= aining how you would solve the issue?

<= /div>
If I understand correctly, Christian's = concern is that some middleboxes might only create a hole if the first pack= et sent by a client (using a new port) looks like a Initial packet.

Consider the = case where you want to build a middlebox that allows QUIC, but no other UDP= -based protocols.

By observing the QUIC packets, you think that you can implement= such a middlebox by creating a hole only when the UDP flow starts with a p= acket starting with 0xff (long header + Initial). But such a design will bl= ock migration.

The question is if w= e need to address the issue proactively, and how.

FWIW, I can see at least three = possible approaches here.

1. frequent gratuitous migration by clients, so that mi= ddlebox vendors can notice that there design is wrong prior to shipping it<= /div>
2. make long header packets not easily indi= stinguishable from short header packets (by encrypting the type field)
3. mimic 0-RTT handshake when gratuitously swit= ching to a new UDP flow (depends on #1262)
=

1 and 2 have been discussed on this thread. I haven'= ;t yet seen 3 being discussed.

The concerns so far= being raised for 1 is that NATs might run out of unassigned ports and that= switching to a new path might trigger the restart of congestion control on= large-scale NATs that use multiple public addresses.

<= div>The concern so far being raised for 2 is that stateless load balancers = would be required to decrypt the type field (or the entire packet, dependin= g on how we encrypt) to determine if a packet is trying to initiate a new c= onnection.

--
Kazuho Oku
--00000000000070e2080569247f23-- From nobody Thu Apr 5 19:06:21 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950991205F0 for ; Thu, 5 Apr 2018 19:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA5i7aXTMhBk for ; Thu, 5 Apr 2018 19:06:17 -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 963E612E87C for ; Thu, 5 Apr 2018 19:06:13 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id d6so30938885iog.1 for ; Thu, 05 Apr 2018 19:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C2s7Jt/8cM1Y8ySBBqRNEDkgz63hIP+AczFFJvY5Frc=; b=tuk1ZBFDPaXFNSd/0w5oZ5KB5XiytRr/mlhJAkuIVpCo9ToCVVN2+flTAud6qf+Fit bzw8bw0a4+yCHrwf1B3o7iLoxjAKApbnBRD19SFlLlfj3Gnp+Pe5eEgOKkbD+sf/v84G YVex4zJTyOp7HX5Dc3+0IfVdIQ+eo/pwqduDirIMUpWZFjrBmX4jtRiPy2K8YbC+Ftew +WzxApgGxTHI+nxdRUk7+nyXDv7DDoT8GeX78wNQXjsrP/JcKGBBWUEFvBh4UTdfsHu3 JM3S0Rvs9/crFE4zUeiFzMtyYlJJiWC5FuFJc5v012cqlPRZA6m0A0oTYsQ1Ok0Qp4uP UgVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C2s7Jt/8cM1Y8ySBBqRNEDkgz63hIP+AczFFJvY5Frc=; b=FH83EicJiHAEc8zIQ/FsKPNg4f1/fCF0M49Hbm8m7EQcSSNB7QoSehk6yse27Q0tzf d7/f+ntq2LZuWpHzZO0oe00m03x1r6zb1ptQNMe9+kf9k1mIDl9bbLc698cp13qBOLdk nX35sYrV3iBdSii3oVzRzqhVN+YLkVSB6NXfeRNcqY57x1HdCuVhgwuLWndVt26VeSu4 yLd98O9wFnt7FhOEms6dgwZ+WS0aeWnYLMWdNBLJd11TjpObmJPjeBvNbyXayO6n3ZK6 jgB58DYkuIAUfT4rpyMe+ox5wA8P0p2Kj5rARQV9a3k4VACEqMW2M6fIrZjd1LxB+0zd 35bg== X-Gm-Message-State: AElRT7HbseNJ+2nwhxRtxllTkDIWnQsZ0vNYLC+u+Rs7ej2ajtI/fCmY grL9xLfnyqD843mC+OqoIbvoQ3Ps4yB5AbtcaAxljWcI X-Google-Smtp-Source: AIpwx4/GXxkVG0ZJXEPke4TRz/olPG42heM5pEDByHd8NhRbYHO4yxOCFgmL0Nh6T9TAUAUarmTStWgdJaS/f8uubYQ= X-Received: by 10.107.222.18 with SMTP id v18mr24016910iog.212.1522980372558; Thu, 05 Apr 2018 19:06:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Fri, 06 Apr 2018 02:06:01 +0000 Message-ID: Subject: Re: Impact of hardware offloads on network stack performance To: Mike Bishop Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Praveen Balasubramanian , IETF QUIC WG Content-Type: multipart/alternative; boundary="f403043ce4301bdcca056924807a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 02:06:20 -0000 --f403043ce4301bdcca056924807a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 5, 2018 at 5:57 PM Mike Bishop wrote: > That=E2=80=99s interesting data, Praveen =E2=80=93 thanks. There is one = caveat there, > which is that (IIUC, on current hardware) you can=E2=80=99t do packet pac= ing with > LSO, and so my understanding is that even for TCP many providers disable > this in pursuit of better egress management. So what we=E2=80=99re reall= y saying > is that: > > - On current hardware and OS setups, UDP runs less than half as much > throughput as TCP; that needs some optimization, as we=E2=80=99ve alre= ady discussed > - TCP will dramatically gain performance once hardware offload catches > up and allows *paced* LSO =F0=9F=98=8A > > > > However, as Mikkel points out, the crypto costs are likely to overwhelm > the OS throughput / scheduling issues in real deployments. So I think th= e > other relevant piece to understanding the cost here is this: > I have a few cases(both client and server) where my UDP send costs are more than 30%(in some cases 50%) of CPU consumption, and crypto is less than 10%. So currently, I assume crypto is cheap(especially AES-GCM when hardware acceleration is available) and egress is expensive. UDP ingres is not that expensive, but could use a bit of optimization as well. The only 'fancy' thing our current code is doing for crypto is encrypting in place, which was a ~2% win. Nice, but not transformative. See EncryptInPlace I haven't done much work benchmarking Windows, so possibly the Windows UDP stack is really fast, and so crypto seems really slow in comparison? > > - What is the throughput and relative cost of TLS/TCP versus QUIC > (i.e. how much are the smaller units of encryption hurting us versus, = say, > 16KB TLS records)? > - TLS implementations already vary here: Some implementations > choose large record sizes, some vary record sizes to reduce delay /= HoLB, > so this probably isn=E2=80=99t a single number. > - How much additional load does PNE add to this difference? > - To what extent would PNE make future crypto offloads *impossible* > versus *requires more R&D to develop*? > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahn=C3= =B8e > J=C3=B8rgensen > *Sent:* Wednesday, April 4, 2018 1:34 PM > *To:* Praveen Balasubramanian ; > IETF QUIC WG > *Subject:* Re: Impact of hardware offloads on network stack performance > > > > Thanks for sharing these numbers. > > > > My guess is that these offloads deal with kernel scheduling, memory cache > issues, and interrupt scheduling. > > > > It probably has very little to do with crypto, TCP headers, and any other > cpu sensitive processing. > > > > This is where netmap enters: you can transparently feed the data as it > becomes available with very little sync work and you can also efficiently > pipeline so you pass data to decryptor, then to app, with as little bus > traffic as possible. No need to copy data or synchronize kernel space. > > > > For 1K packets you would use about 1000ns (3 cycles/byte) on crypto and > this would happen in L1 cache. It would of course consume a core which a > crypto offload would not, but that can be debated because with 18 core > systems, your problem is memory and network more than CPU. > > > > My concern with PNE is for small packets and low latency where > > 1) an estimated 24ns for PN encryption and decryption becomes measurable > if your network is fast enough. > > 2) any damage to the packet buffer cause all sorts of memory and cpu bus > traffic issues. > > > > 1) is annoying. 2) is bad, completely avoidable but not as PR 1079 is > formulated currently. > > > > 2) is also likely bad for hardware offload units as well. > > > > As to SRV-IO - I=E2=80=99m not familiar with it, but obviously there is s= ome IO > abstraction layer - the question is how you make it accessible to apps as > opposed to device drivers that does nor work with you QUIC custom stack, > and netmap is one option here. > > > > Kind Regards, > > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > > On 4 April 2018 at 22.15.52, Praveen Balasubramanian ( > pravb=3D40microsoft.com@dmarc.ietf.org) wrote: > > Some comparative numbers from an out of box default settings Windows > Server 2016 (released version) for a single connection with a > microbenchmark tool: > > > > *Offloads enabled* > > *TCP gbps* > > *UDP gbps* > > *LSO + LRO + checksum* > > 24 > > 3.6 > > *Checksum only* > > 7.6 > > 3.6 > > *None* > > 5.6 > > 2.3 > > > > This is for a fully bottlenecked CPU core -- *if you run lower data rates > there is still a significant difference in Cycles/byte cost*. Same > increased CPU cost applies for client systems going over high data rate > Wifi and cellular. > > > > This is without any crypto. Once you add crypto the numbers become much > worse *with crypto cost becoming dominant*. Adding another crypto step > further exacerbates the problem. Hence crypto offload gains in importance > followed by these batch offloads. > > > > If folks need any more numbers I=E2=80=99d be happy to provide them. > > > > Thanks > > > > --f403043ce4301bdcca056924807a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


That=E2=80=99s interesting data, Praveen =E2=80=93 t= hanks.=C2=A0 There is one caveat there, which is that (IIUC, on current har= dware) you can=E2=80=99t do packet pacing with LSO, and so my understanding= is that even for TCP many providers disable this in pursuit of better egress management.=C2=A0 So what we=E2=80=99re really saying is tha= t:

  • On current hardware and OS setups, UDP runs less than half as much thro= ughput as TCP; that needs some optimization, as we=E2=80=99ve already discu= ssed
  • TCP will dramatically gain performance once hard= ware offload catches up and allows paced LSO =F0=9F=98=8A

=C2=A0

However, as Mikkel points out, the crypto costs are = likely to overwhelm the OS throughput / scheduling issues in real deploymen= ts.=C2=A0 So I think the other relevant piece to understanding the cost her= e is this:


I have a few cas= es(both client and server) where my UDP send costs are more than 30%(in som= e cases 50%) of CPU consumption, and crypto is less than 10%.=C2=A0 So curr= ently, I assume crypto is cheap(especially AES-GCM when hardware accelerati= on is available) and egress is expensive.=C2=A0 UDP ingres is not that expe= nsive, but could use a bit of optimization as well.

The only 'fancy' thing our current code is doing for crypto is en= crypting in place, which was a ~2% win.=C2=A0 Nice, but not transformative.= =C2=A0 See EncryptInPlace

I haven't done much work benchmarking Windows, so pos= sibly the Windows UDP stack is really fast, and so crypto seems really slow= in comparison?
=C2=A0

  • What is the throughput and relative cost of TLS/TCP versus QUIC (i.e. h= ow much are the smaller units of encryption hurting us versus, say, 16KB TL= S records)?
    • TLS implementations already vary here:=C2=A0 Some implementations choos= e large record sizes, some vary record sizes to reduce delay / HoLB, so thi= s probably isn=E2=80=99t a single number.
  • How much additional load does PNE add to this difference?
  • To what extent would PNE make future crypto offloads impossible versus requires more R&D to develop?=

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen
Sent: Wednesday, April 4, 2018 1:34 PM
To: Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org&= gt;; IETF QUIC WG <qu= ic@ietf.org>
Subject: Re: Impact of hardware offloads on network stack performanc= e

=C2=A0

Thanks for sharing these numbers.

=C2=A0

My guess is that these offloads deal with kernel = scheduling, memory cache issues, and interrupt scheduling.

=C2=A0

It probably has very little to do with crypto, TC= P headers, and any other cpu sensitive processing.

=C2=A0

This is where netmap enters: you can transparentl= y feed the data as it becomes available with very little sync work and you = can also efficiently pipeline so you pass data to decryptor, then to app, with as little bus traffic as possible. No need= to copy data or synchronize kernel space.

=C2=A0

For 1K packets you would use about 1000ns (3 cycl= es/byte) on crypto and this would happen in L1 cache. It would of course co= nsume a core which a crypto offload would not, but that can be debated because with 18 core systems, your problem is memo= ry and network more than CPU.

=C2=A0

My concern with PNE is for small packets and low = latency where

1) an estimated 24ns for PN encryption and decryp= tion becomes measurable if your network is fast enough.

2) any damage to the packet buffer cause all sort= s of memory and cpu bus traffic issues.

=C2=A0

1) is annoying. 2) is bad, completely avoidable b= ut not as PR 1079 is formulated currently.

=C2=A0

2) is also likely bad for hardware offload units = as well.

=C2=A0

As to SRV-IO - I=E2=80=99m not familiar with it, = but obviously there is some IO abstraction layer - the question is how you = make it accessible to apps as opposed to device drivers that does nor work with you QUIC custom stack, and netmap is one option he= re.

=C2=A0

Kind Regards,

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

=C2=A0

On 4 April 2018 at 22.15.52= , Praveen Balasubramanian (pravb=3D40microsoft.com@dmarc.ietf.org) wro= te:

Some comparative numbers from an out of box defau= lt settings Windows Server 2016 (released version) for a single connection with a microbenchmark tool:

=C2=A0

Offloads enabled

TCP gbps

UDP gbps

LSO + LRO + checksum

24

3.6

Checksum only

7.6

3.6

None

5.6

2.3

=C2=A0

This is for a fully bottlenecked CPU core -- if you run lower data rates there is still a significant difference in C= ycles/byte cost. Same increased CPU cost applies for client systems goi= ng over high data rate Wifi and cellular.

=C2=A0

This is without any crypto. Once you add crypto t= he numbers become much worse with crypto cost becoming dominant. Adding another crypto step furth= er exacerbates the problem. Hence crypto offload gains in importance follow= ed by these batch offloads.

=C2=A0

If folks need any more numbers I=E2=80=99d be hap= py to provide them.

=C2=A0

Thanks

=C2=A0

--f403043ce4301bdcca056924807a-- From nobody Thu Apr 5 19:15:46 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C64612946D for ; Thu, 5 Apr 2018 19:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElcD-LvV7KHL for ; Thu, 5 Apr 2018 19:15:41 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58128126FB3 for ; Thu, 5 Apr 2018 19:15:40 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id y66so9803117pfi.7 for ; Thu, 05 Apr 2018 19:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KY++CjaVPY/WVovf6uipMXuz5kYdkTmm5ENpRnX4Qng=; b=oMubDFTy9znivFY1lBH7wlUSFPxt4T6GHUSO0JL7Ey1yRjv3H/SRa3nUcsoD9OkJab 02c1HIFJ0nl+ImrcoLXWSind8cl1vqYV2ZDPVuOJmzd3377ejz8udFr+nD7XI7D1qRBN vL/VbyHVLT/A3nYUFuNcPLj4Gy7FFb2dcBuCb8gfppfmu6smhLB1+pIJfnTaRYmNCFNz nuXn4MsAMm+TI0+aBNA6OhkKhydxMsyUJ2cHwIxhYpUKUnbxxbxjstzA8s2s8xi5HYck 5G8v8dghih3cbYwCVix8n3jp3mVXIxYTr4Dg3nL1Yj0ndAjLXpXvo5vh1RmcWSGXPfB0 Zr6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=KY++CjaVPY/WVovf6uipMXuz5kYdkTmm5ENpRnX4Qng=; b=uDlonl/Z4ewWmDphX9Hdg7FYVZmB72e7Ewlbjh1DdGsGMOcrj6eRPg/e9iJtKrGE/2 aEQRW0r01unqA53+ZsvSfZiDFJj9fGhvbqT3tn0gpRolL3AsMRqcmumb12jgv1kac+kL wRkpigG5H1Nt0eX0C6EFSkig8ljUSn2ZoDinbXvol7d5dVAPrjPfAtlMiazQgvhSkIr6 OpV/T4h/PJvacIMiTnc9gQm3o3f5gWUlSyKKw44bfzvwRop6EDSRSiSI3eAPLJtZaWGR 9ZXNZyRAMog2AvZpvr7cd4Y5yd+WgI/t13GXaX/2/KILQa3u0RU3XpmsTeYYo6IL47Af jZTw== X-Gm-Message-State: AElRT7FLXH26jaJrlAaV+zFsxA1fjA0z4ulqvwUZee+p2IJlBWWqinBN TmY5aT9bGr/zi60pF6yVQp7bx62ATpe/C6g1tU2CJQ== X-Google-Smtp-Source: AIpwx49JYGgzTCgmcvm2oUpIu4+EDS78x2xSUIIhUkLJCiMdNo1vXwg3N3amPBiKGtL7B6zWeAVqUzhuVWFvNV9Wg2k= X-Received: by 10.101.89.5 with SMTP id f5mr16347945pgu.428.1522980939896; Thu, 05 Apr 2018 19:15:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Thu, 5 Apr 2018 19:15:39 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Kazuho Oku Date: Fri, 6 Apr 2018 11:15:39 +0900 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: "Lubashev, Igor" Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Mike Bishop , Christian Huitema , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Frederick Kautz Content-Type: multipart/alternative; boundary="089e08233f14ec1c0d056924a1ae" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 02:15:43 -0000 --089e08233f14ec1c0d056924a1ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-04-06 2:59 GMT+09:00 Lubashev, Igor : > > - I'd prefer making handshake packets indistinguishable from short > header packets. In essence, you move the flags of the long header insi= de > the AEAD-protected area. An endpoint that receives a packet carrying a= CID > that does not belong to any known connection trial-decrypts the packet= as a > initial packet and handles it as a connection initiation, or sends a > stateful reset if the trial-decryption fails. > > This change would wreck stateless load balancers that rely on being able > to distinguish CI packets (and route them based on IPs) from other packet= s > (and route them based on CID). > Reconsidering this, thanks to symmetric CID, I think we now have a way to statelessly determine whether or not a packet is initial without decrypting it, even if the type field is encrypted. Initial packets always carry a DCID of 8 octets. So if you could configure your servers to use DCID of any other size, you can determine if a packet is initial or not just by checking the size of DCID. And assuming that there would be non-neglible amount of servers using DCID of 8 octets, the size of the field would be unusable as a way to detect if a packet is initial from the middlebox's point of view. Igor, Praveen, does the approach alleviate your concern? > > > - Igor > > > > *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] > *Sent:* Thursday, April 05, 2018 1:31 PM > *To:* Mike Bishop ; Christian Huitema < > huitema@huitema.net>; Kazuho Oku > *Cc:* IETF QUIC WG ; Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch>; Frederick Kautz > *Subject:* RE: Privacy holes (was: Re: Getting to consensus on packet > number encryption) > > > > Hi > > > > On 5 April 2018 at 19.27.24, Mike Bishop (mbishop@evequefou.be) wrote: > > An endpoint that receives a packet carrying a CID that does not belong > to any known connection trial-decrypts the packet as a initial packet and > handles it as a connection initiation, or sends a stateful reset if the > trial-decryption fails. > > I can see hiding things may be a good thing, but having to trial decrypt > all unknown packets as potentially creating a huge load, unless you combi= ne > it with my proposal to add a checksum to the encrypted packet number so y= ou > only need one crypto block on average to reject random packet content. > > It won=E2=80=99t solve all DDoS, but it will help. Forcing trial decrypti= on fo the > full packet makes me a bit anxious. > > > > Mikkel > > > --=20 Kazuho Oku --089e08233f14ec1c0d056924a1ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-04-06 2:59 GMT+09:00 Lubashev, Igor <ilubashe@akamai.com&g= t;:
  • I'd prefer making handshake packets indistinguishable from short header= packets. In essence, you move the flags of the long header inside the AEAD= -protected area. An endpoint that receives a packet carrying a CID that doe= s not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connecti= on initiation, or sends a stateful reset if the trial-decryption fails.<= /u>

This change would wreck stateless load balancers tha= t rely on being able to distinguish CI packets (and route them based on IPs= ) from other packets (and route them based on CID).


Reconsidering this, thanks to symmetric CID, I thi= nk we now have a way to statelessly determine whether or not a packet is in= itial without decrypting it, even if the type field is encrypted.

Initial packets always carry a DCID of 8 octets.
=
So if you could configure your servers to use DCID of any ot= her size, you can determine if a packet is initial or not just by checking = the size of DCID.

And assuming that there would be= non-neglible amount of servers using DCID of 8 octets, the size of the fie= ld would be unusable as a way to detect if a packet is initial from the mid= dlebox's point of view.

Igor, Praveen, does th= e approach alleviate your concern?
=C2=A0

=C2=A0

- Igor

=C2=A0

From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mail= to:mikkelfj@gmail.c= om]
Sent: Thursday, April 05, 2018 1:31 PM
To: Mike Bishop <mbishop@evequefou.be>; Christian Huitema <huitema@huitema.net>; = Kazuho Oku <kaz= uhooku@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>; Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.= ch>; Frederick Kautz <fkautz@alumni.cmu.edu>
Subject: RE: Privacy holes (was: Re: Getting to consensus on = packet number encryption)

=C2=A0

Hi

=C2=A0

On 5 April 2018 at 19.27.24= , Mike Bishop (mbishop@evequefou.be) wrote:

=C2=A0An endpoint th= at receives a packet carrying a CID that does not belong to any known conne= ction trial-decrypts the packet as a initial packet and handles it as a connection initiation, or sends a stateful reset if the trial-decrypt= ion fails.

I can see hiding things may be a good thing, but having to trial decr= ypt all unknown packets as potentially creating a huge load, unless you com= bine it with my proposal to add a checksum to the encrypted packet number so you only need one crypto block on average t= o reject random packet content.

It won=E2=80=99t solve all DDoS, but it will help. Forcing trial decr= yption fo the full packet makes me a bit anxious.

=C2=A0

Mikkel

=C2=A0




--
Kazuho Oku
--089e08233f14ec1c0d056924a1ae-- From nobody Thu Apr 5 19:34:22 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4918124F57 for ; Thu, 5 Apr 2018 19:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 olBeAjBXlH_K for ; Thu, 5 Apr 2018 19:34:18 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FCD124235 for ; Thu, 5 Apr 2018 19:34:18 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id e123-v6so24277783oih.13 for ; Thu, 05 Apr 2018 19:34: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=B4S2L7rOpGj8GK+anUr+P8KMtOnvYvr0pr1J2nScrg8=; b=SffIVPhEuvCYPfqgcHdwSZ65EpM5J/KGYOkyMIc5KLWZ26/qwmAWCA0Lad8loPLD4B cx4qHvE/4DJFENJcR8J4Ft03pbMLQbsixKJVwzM8EJQLcpOK/AnxJCuzk4JXV35c6KnT jYZrDHiRI7WIxTML3AIYGq1pDo0t2TbLwD8BD0HccEVpHBQRreNgzsd7lJaDCtD+Pl6f /QAs7XW+uEU6hRpdEJSwgJCvraVVxLO5P0I8QkglISZ2eXfLrd+2GZ4JdOO4Nrdwq1Sl jgDFwv/6WbvD2s9x5UhAgiVRr88+A0uiRC00zifBWCO7qiYaQyM/RtwSCMITJT1bCJOq vn4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=B4S2L7rOpGj8GK+anUr+P8KMtOnvYvr0pr1J2nScrg8=; b=mBdzJFvogdFujSPfYoU8c3UqKzb3uLd5Oh1Ykr9mP0CXMD+SRkvRPdCdMqCy/lYDe8 x3ZI/qqopI/71gQCNREWoDMWSziJlTfynNCzLsRBYLafF1tvmPurZe5BapT/OxCgfBoQ Qo73YYYXNz4qs+8jRkK1IskhXrL2OF5UW0IeSJCAEgb6+a9tlF28zEiqAi8xgnIvFm/P +zIReEopyFn8ZRAdv9dlS7M1FJPzYdvwX59c3HuuVZlRMs+YWtZ350KhKxUbl71Ai12Q 6RMy3eFR7Q/QCapluHAmXjyBafqb74o0VFh/v1lwXQc8Dxp1M7o6ZbJL4q15ktM5aSB5 xk+A== X-Gm-Message-State: ALQs6tAzgm5R6C2xhrcSrRcFafS+nYLwh0D423rITylUmCGCRN55V+pp VCHv0hs8p04tp5OBDdFJJCf88hzT2oyUJpUQyGU= X-Google-Smtp-Source: AIpwx4/0BpSF4UaZCUmPLB65E6vAoG4W2ZKwEeB+PmwL1uPhEzou7fXI+Dx36k4qyQmOH0u6JgZDQdGYfEp6+8ND1SE= X-Received: by 2002:aca:4ac2:: with SMTP id x185-v6mr13275175oia.295.1522982058011; Thu, 05 Apr 2018 19:34:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 5 Apr 2018 19:34:17 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Martin Thomson Date: Fri, 6 Apr 2018 12:34:17 +1000 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: Kazuho Oku Cc: Christian Huitema , QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Frederick Kautz 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, 06 Apr 2018 02:34:21 -0000 On Fri, Apr 6, 2018 at 12:06 PM, Kazuho Oku wrote: > If I understand correctly, Christian's concern is that some middleboxes > might only create a hole if the first packet sent by a client (using a new > port) looks like a Initial packet. Oh, I didn't get the same impression, but it does seem like a valid concern. The idea I had was to have clients migrate often enough that those middleboxes will see those migrations and not incorrectly assume that flows have to start with Initial packets. Of course, migrating often like this might not provide enough incentive to avoid that practice because clients will likely make new connections when the old one fails. But given that this sort of failure probably involves a timeout before the repair, it's probably still noticeable enough to generate support tickets (and incentive to allow the migration to pass). Existing middleboxes that pass UDP will be fine, so we at least have that in our favour. > 1. frequent gratuitous migration by clients, so that middlebox vendors can > notice that there design is wrong prior to shipping it That is what this was angling for. The question being how frequent. > 3. mimic 0-RTT handshake when gratuitously switching to a new UDP flow > (depends on #1262) > > 1 and 2 have been discussed on this thread. I haven't yet seen 3 being > discussed. It has been suggested a few times elsewhere. The question is how far you go: do you send Initial and Handshake packets that use the handshake packet protection and carry apparently real ClientHello and ServerHello messages? Do you restrict the flow of packets to match 0-RTT? > The concerns so far being raised for 1 is that NATs might run out of > unassigned ports and that switching to a new path might trigger the restart > of congestion control on large-scale NATs that use multiple public > addresses. That is possible, but it depends on how often you attempt this. CGNAT does try to keep IP addresses for the same device stable. If not, then a congestion controller reset for relatively infrequent migrations isn't so bad if heuristics fail. It's only when you have very frequent migration that the resets becomes burdensome. > The concern so far being raised for 2 is that stateless load balancers would > be required to decrypt the type field (or the entire packet, depending on > how we encrypt) to determine if a packet is trying to initiate a new > connection. Yeah, that's hard. Having the load balancer hit the slow path for every packet seems pretty fatal. From nobody Thu Apr 5 19:56:45 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C7D12D947 for ; Thu, 5 Apr 2018 19:56:44 -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 4srr9c35lkaj for ; Thu, 5 Apr 2018 19:56:42 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 51C5C126B72 for ; Thu, 5 Apr 2018 19:56:42 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id j2so9897911pff.10 for ; Thu, 05 Apr 2018 19:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MLwio2PFdcYc1leW4FU4oUbL2muCfFwMPeFgXFQu16s=; b=Aa6lIrryc4FMQx4UHVEOPULc0LI4a/ilxTnK1dNc0gn5QFz+S37N8OIHAmz/C3yIyN +cSlwx4AY8J0cHx7WeTp7WSaRyAL1SNXF9acskAY88Pnk6XgsgjnR/Ezh6UQscDPHxYX GPGt+lWVxm/xurFVmbdVVn1EqNW2hoPB21y4Wn7+hWu0adZihot4vUMB9dgVThL/m+wX sJUbMJHnk02kmnx1svvkkDQuOgtATu4X4L6Fi0te4TADpuRczC+jE5UJGvExtXTmQRC1 K+vTgiwuaqy7UEQcgC20MsFXeWMB03nSjSP8w/swa5c0kEbVpT874Haydx/DJ0PPVS25 Necg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=MLwio2PFdcYc1leW4FU4oUbL2muCfFwMPeFgXFQu16s=; b=LtzMgV0menKXRXn3kMc++jkVsq7x4TeD6bWf/HaL92UKC8NZ0nitUZ6TxVCCVgGzbM K0CCP6wuyPS41nbTXaEjJXBpPBp9a5cvoPLNS0t2Mcxp2VpoyYWrc97nmgNbmgRnqXd8 o5iV7lzmkuwoiX8a62h8teDEmsPEVm9T0aeB0oj9QsmrWZTYg77BGwUOJLtt7HWmcRsG r02PuhQ0m7YLFcTCoJ2dsNfHHY0WMeJBNjwO6G7Vp6C0r0oiMpsnEfhSRiNOAL6UX1R9 UoUlr4DQ3V9UKSq4NvanclaGEi3DHyZ+mv26KB68qIEdaRKq1trhEvqvSIprLrU25kZ2 X8LQ== X-Gm-Message-State: AElRT7EMhbcWlciAGK64Tw3N8xXBj4cjnTqbqOs4X9px4cUCPUE1fz7a SxZfM2Fm/tfgW7zGms3F0MC4Jvt+2As6K8pqXuo= X-Google-Smtp-Source: AIpwx48QEomVbmP8n/V3OPtVidyMbKuIbGsfpsLvJ1hbt/b8d/NQJ3gEV6+I7gaPh6eTcVvakpW3ma9ClplY23b031g= X-Received: by 10.101.89.5 with SMTP id f5mr16425039pgu.428.1522983401727; Thu, 05 Apr 2018 19:56:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Thu, 5 Apr 2018 19:56:41 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> From: Kazuho Oku Date: Fri, 6 Apr 2018 11:56:41 +0900 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: Martin Thomson Cc: Christian Huitema , QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Frederick Kautz Content-Type: multipart/alternative; boundary="089e08233f14a8aa45056925346c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 02:56:44 -0000 --089e08233f14a8aa45056925346c Content-Type: text/plain; charset="UTF-8" Hi Martin, Thank you for the response. My comments inline. 2018-04-06 11:34 GMT+09:00 Martin Thomson : > On Fri, Apr 6, 2018 at 12:06 PM, Kazuho Oku wrote: > > If I understand correctly, Christian's concern is that some middleboxes > > might only create a hole if the first packet sent by a client (using a > new > > port) looks like a Initial packet. > > Oh, I didn't get the same impression, but it does seem like a valid > concern. The idea I had was to have clients migrate often enough that > those middleboxes will see those migrations and not incorrectly assume > that flows have to start with Initial packets. > > Of course, migrating often like this might not provide enough > incentive to avoid that practice because clients will likely make new > connections when the old one fails. But given that this sort of > failure probably involves a timeout before the repair, it's probably > still noticeable enough to generate support tickets (and incentive to > allow the migration to pass). > > Existing middleboxes that pass UDP will be fine, so we at least have > that in our favour. > > > 1. frequent gratuitous migration by clients, so that middlebox vendors > can > > notice that there design is wrong prior to shipping it > > That is what this was angling for. The question being how frequent. > > > 3. mimic 0-RTT handshake when gratuitously switching to a new UDP flow > > (depends on #1262) > > > > 1 and 2 have been discussed on this thread. I haven't yet seen 3 being > > discussed. > > It has been suggested a few times elsewhere. The question is how far > you go: do you send Initial and Handshake packets that use the > handshake packet protection and carry apparently real ClientHello and > ServerHello messages? Do you restrict the flow of packets to match > 0-RTT? > > > The concerns so far being raised for 1 is that NATs might run out of > > unassigned ports and that switching to a new path might trigger the > restart > > of congestion control on large-scale NATs that use multiple public > > addresses. > > That is possible, but it depends on how often you attempt this. CGNAT > does try to keep IP addresses for the same device stable. If not, > then a congestion controller reset for relatively infrequent > migrations isn't so bad if heuristics fail. It's only when you have > very frequent migration that the resets becomes burdensome. > How frequent is the issue here. If it's too frequent, some NATs could run out of unassigned ports, and if depending on their eviction algorithm, shutdown UDP-based flows running other protocols that do not do gratuitous switching. Other NATs could start assigning new public addresses as they run out of unassigned ports. If it's too infrequent, then the chance of seeing misimplemented middlebox becomes higher. > > The concern so far being raised for 2 is that stateless load balancers > would > > be required to decrypt the type field (or the entire packet, depending on > > how we encrypt) to determine if a packet is trying to initiate a new > > connection. > > Yeah, that's hard. Having the load balancer hit the slow path for > every packet seems pretty fatal. > That was my understanding until I started to consider the impact of symmetric CIDs. The length of DCID can be a signal to the stateless load balancers for distinguishing an initial packet. If people interested in using that type of load balancer can agree that they will be using CID other than 8 octets, the length can be used as the signal by them. More detail about using DCID can be found on https://www.ietf.org/mail-archive/web/quic/current/msg03809.html. -- Kazuho Oku --089e08233f14a8aa45056925346c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thank you for the response= . My comments inline.

2018-04-06 11:34 GMT+09:00 Martin Thomson <martin.= thomson@gmail.com>:
On Fri, Apr 6, 2018 at 12:06 PM, Kazuho Oku &l= t;kazuhooku@gmail.com> wrote:=
> If I understand correctly, Christian's concern is that some middle= boxes
> might only create a hole if the first packet sent by a client (using a= new
> port) looks like a Initial packet.

Oh, I didn't get the same impression, but it does seem like a va= lid
concern.=C2=A0 The idea I had was to have clients migrate often enough that=
those middleboxes will see those migrations and not incorrectly assume
that flows have to start with Initial packets.

Of course, migrating often like this might not provide enough
incentive to avoid that practice because clients will likely make new
connections when the old one fails.=C2=A0 But given that this sort of
failure probably involves a timeout before the repair, it's probably still noticeable enough to generate support tickets (and incentive to
allow the migration to pass).

Existing middleboxes that pass UDP will be fine, so we at least have
that in our favour.

> 1. frequent gratuitous migration by clients, so that middlebox vendors= can
> notice that there design is wrong prior to shipping it

That is what this was angling for.=C2=A0 The question being how freq= uent.

> 3. mimic 0-RTT handshake when gratuitously switching to a new UDP flow=
> (depends on #1262)
>
> 1 and 2 have been discussed on this thread. I haven't yet seen 3 b= eing
> discussed.

It has been suggested a few times elsewhere.=C2=A0 The question is h= ow far
you go: do you send Initial and Handshake packets that use the
handshake packet protection and carry apparently real ClientHello and
ServerHello messages?=C2=A0 Do you restrict the flow of packets to match 0-RTT?

> The concerns so far being raised for 1 is that NATs might run out of > unassigned ports and that switching to a new path might trigger the re= start
> of congestion control on large-scale NATs that use multiple public
> addresses.

That is possible, but it depends on how often you attempt this.=C2= =A0 CGNAT
does try to keep IP addresses for the same device stable.=C2=A0 If not,
then a congestion controller reset for relatively infrequent
migrations isn't so bad if heuristics fail.=C2=A0 It's only when yo= u have
very frequent migration that the resets becomes burdensome.

How frequent is the issue here.

If it's too frequent, some NATs could run out of unassigned ports, a= nd if depending on their eviction algorithm, shutdown UDP-based flows runni= ng other protocols that do not do gratuitous switching. Other NATs could st= art assigning new public addresses as they run out of unassigned ports.

If it's too infrequent, then the chance of seeing= misimplemented middlebox becomes higher.


> The concern so far being raised for 2 is that stateless load balancers= would
> be required to decrypt the type field (or the entire packet, depending= on
> how we encrypt) to determine if a packet is trying to initiate a new > connection.

Yeah, that's hard.=C2=A0 Having the load balancer hit the slow p= ath for
every packet seems pretty fatal.

That was my understanding until I started to conside= r the impact of symmetric CIDs.

<= div class=3D"gmail_extra">The length of DCID can be a signal to the statele= ss load balancers for distinguishing an initial packet. If people intereste= d in using that type of load balancer can agree that they will be using CID= other than 8 octets, the length can be used as the signal by them.

More detail about using DCID can be found on = https://www.ietf.org/mail-archive/web/quic/current/msg03809.html.
=

--
Kazuho Oku
--089e08233f14a8aa45056925346c-- From nobody Thu Apr 5 20:48:57 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC1912E87D for ; Thu, 5 Apr 2018 20:48:55 -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=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 Jh2fZTyHVCvl for ; Thu, 5 Apr 2018 20:48:53 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B71312420B for ; Thu, 5 Apr 2018 20:48:53 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w363l6BP008109; Fri, 6 Apr 2018 04:48:42 +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=Q1Q0TiFHONaIDk+QIYd6QeizMmxvMz62PSGpd/CF6Ig=; b=W8ksehe9QviaTvD/kzfp+SRzPO7Zht2ehABfC5Ff/vdV5KcmRwndtv+UZQsTmX/6FtCQ KLsuOl6oLLXvH2DHfBHl+S42eJEzmIwBaHK8/YCGlgx03+SIv5Hx1xBJ5HTV8W9EajND F4YXBceqZ2ZFd8vWQVtnLmoYTIINNfTdE4IVdhg7y4RWHzeeWdcxAXQOebkzPhzHuJZX 71VcXIYzaptPaeDIFJM0oID6Vd4n93do111R1q7i8hMw02UZc6Ek5X9I4qbxX/6h9nN4 vqTBGjxks6gEX6x3+UWO0NzcnFawo/uwJ58NYuLNcKo9t+mC0t7wVQ9J8j6PUNmvf4Wy VQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2h4r0x5vtu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 Apr 2018 04:48:42 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w363l9LW003165; Thu, 5 Apr 2018 23:48:41 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2h25nvw0t0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 23:48:41 -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.1365.1; Thu, 5 Apr 2018 23:48:40 -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.1365.000; Thu, 5 Apr 2018 23:48:40 -0400 From: "Lubashev, Igor" To: "martin.thomson@gmail.com" , "kazuhooku@gmail.com" CC: "quic@ietf.org" , "mirja.kuehlewind@tik.ee.ethz.ch" , "huitema@huitema.net" , "fkautz@alumni.cmu.edu" Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Index: AQHTzPOeCspMmk/31UumuO1CInS8X6PylyoAgAACsQCAAI6AAIAAGGkAgAAH54CAAAZCgP//y3hU Date: Fri, 6 Apr 2018 03:48:39 +0000 Message-ID: <65cf3a3009944ca288a0cd6768d09339@usma1ex-dag1mb5.msg.corp.akamai.com> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_65cf3a3009944ca288a0cd6768d09339usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-06_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804060037 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-06_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804060037 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 03:48:55 -0000 --_000_65cf3a3009944ca288a0cd6768d09339usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The length of DCID can be a signal to the stateless load balancers. Short headers do not have an explicit CID length, so we are back to validat= ing the integrity of CID, no? What am I missing? -----Original Message----- From: Kazuho Oku [kazuhooku@gmail.com] Received: Thursday, 05 Apr 2018, 10:56PM To: Martin Thomson [martin.thomson@gmail.com] CC: Mirja K=FChlewind [mirja.kuehlewind@tik.ee.ethz.ch]; QUIC WG [quic@ietf= .org]; Christian Huitema [huitema@huitema.net]; Frederick Kautz [fkautz@alu= mni.cmu.edu] Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number = encryption) Hi Martin, Thank you for the response.. My comments inline. 2018-04-06 11:34 GMT+09:00 Martin Thomson >: On Fri, Apr 6, 2018 at 12:06 PM, Kazuho Oku > wrote: > If I understand correctly, Christian's concern is that some middleboxes > might only create a hole if the first packet sent by a client (using a ne= w > port) looks like a Initial packet. Oh, I didn't get the same impression, but it does seem like a valid concern. The idea I had was to have clients migrate often enough that those middleboxes will see those migrations and not incorrectly assume that flows have to start with Initial packets. Of course, migrating often like this might not provide enough incentive to avoid that practice because clients will likely make new connections when the old one fails. But given that this sort of failure probably involves a timeout before the repair, it's probably still noticeable enough to generate support tickets (and incentive to allow the migration to pass). Existing middleboxes that pass UDP will be fine, so we at least have that in our favour. > 1. frequent gratuitous migration by clients, so that middlebox vendors ca= n > notice that there design is wrong prior to shipping it That is what this was angling for. The question being how frequent. > 3. mimic 0-RTT handshake when gratuitously switching to a new UDP flow > (depends on #1262) > > 1 and 2 have been discussed on this thread. I haven't yet seen 3 being > discussed. It has been suggested a few times elsewhere. The question is how far you go: do you send Initial and Handshake packets that use the handshake packet protection and carry apparently real ClientHello and ServerHello messages? Do you restrict the flow of packets to match 0-RTT? > The concerns so far being raised for 1 is that NATs might run out of > unassigned ports and that switching to a new path might trigger the resta= rt > of congestion control on large-scale NATs that use multiple public > addresses. That is possible, but it depends on how often you attempt this. CGNAT does try to keep IP addresses for the same device stable. If not, then a congestion controller reset for relatively infrequent migrations isn't so bad if heuristics fail. It's only when you have very frequent migration that the resets becomes burdensome. How frequent is the issue here. If it's too frequent, some NATs could run out of unassigned ports, and if d= epending on their eviction algorithm, shutdown UDP-based flows running othe= r protocols that do not do gratuitous switching. Other NATs could start ass= igning new public addresses as they run out of unassigned ports. If it's too infrequent, then the chance of seeing misimplemented middlebox = becomes higher. > The concern so far being raised for 2 is that stateless load balancers wo= uld > be required to decrypt the type field (or the entire packet, depending on > how we encrypt) to determine if a packet is trying to initiate a new > connection. Yeah, that's hard. Having the load balancer hit the slow path for every packet seems pretty fatal. That was my understanding until I started to consider the impact of symmetr= ic CIDs. The length of DCID can be a signal to the stateless load balancers for dist= inguishing an initial packet. If people interested in using that type of lo= ad balancer can agree that they will be using CID other than 8 octets, the = length can be used as the signal by them. More detail about using DCID can be found on https://www.ietf.org/mail-arch= ive/web/quic/current/msg03809.html. -- Kazuho Oku --_000_65cf3a3009944ca288a0cd6768d09339usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The length of DCID can be a signal to the stateless l= oad balancers.

Short headers do not have an explicit CID length, so we are back to validat= ing the integrity of CID, no? What am I missing?

-----Original Message-----
From: Kazuho Oku [kazuhooku@gmail.com]
Received: Thursday, 05 Apr 2018, 10:56PM
To: Martin Thomson [martin.thomson@gmail.com]
CC: Mirja K=FChlewind [mirja.kuehlewind@tik.ee.ethz.ch]; QUIC WG [qu= ic@ietf.org]; Christian Huitema [huitema@huitema.net]; Frederick Kautz [fka= utz@alumni.cmu.edu]
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet = number encryption)
Hi Martin,

Thank you for the response.. My comments inline.=

2018-04-06 11:34 GMT+09:00 Martin Thomson <martin.th= omson@gmail.com>:
On Fri, Apr 6, 2018 at 12:06 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
> If I understand correctly, Christian's concern is that some middleboxe= s
> might only create a hole if the first packet sent by a client (using a= new
> port) looks like a Initial packet.

Oh, I didn't get the same impression, but it does seem like a valid<= br> concern.  The idea I had was to have clients migrate often enough that=
those middleboxes will see those migrations and not incorrectly assume
that flows have to start with Initial packets.

Of course, migrating often like this might not provide enough
incentive to avoid that practice because clients will likely make new
connections when the old one fails.  But given that this sort of
failure probably involves a timeout before the repair, it's probably
still noticeable enough to generate support tickets (and incentive to
allow the migration to pass).

Existing middleboxes that pass UDP will be fine, so we at least have
that in our favour.

> 1. frequent gratuitous migration by clients, so that middlebox vendors= can
> notice that there design is wrong prior to shipping it

That is what this was angling for.  The question being how freq= uent.

> 3. mimic 0-RTT handshake when gratuitously switching to a new UDP flow=
> (depends on #1262)
>
> 1 and 2 have been discussed on this thread. I haven't yet seen 3 being=
> discussed.

It has been suggested a few times elsewhere.  The question is h= ow far
you go: do you send Initial and Handshake packets that use the
handshake packet protection and carry apparently real ClientHello and
ServerHello messages?  Do you restrict the flow of packets to match 0-RTT?

> The concerns so far being raised for 1 is that NATs might run out of > unassigned ports and that switching to a new path might trigger the re= start
> of congestion control on large-scale NATs that use multiple public
> addresses.

That is possible, but it depends on how often you attempt this. = ; CGNAT
does try to keep IP addresses for the same device stable.  If not,
then a congestion controller reset for relatively infrequent
migrations isn't so bad if heuristics fail.  It's only when you have very frequent migration that the resets becomes burdensome.

How frequent is the issue here.

If it's too frequent, some NATs could run out of unassigned ports, and= if depending on their eviction algorithm, shutdown UDP-based flows running= other protocols that do not do gratuitous switching. Other NATs could star= t assigning new public addresses as they run out of unassigned ports.

If it's too infrequent, then the chance of seeing misimplemented middl= ebox becomes higher.


> The concern so far being raised for 2 is that stateless load balancers= would
> be required to decrypt the type field (or the entire packet, depending= on
> how we encrypt) to determine if a packet is trying to initiate a new > connection.

Yeah, that's hard.  Having the load balancer hit the slow path = for
every packet seems pretty fatal.

That was my understanding until I started to consider the impact of symmetr= ic CIDs.

The length of DCID can be a signal to the statel= ess load balancers for distinguishing an initial packet. If people interest= ed in using that type of load balancer can agree that they will be using CI= D other than 8 octets, the length can be used as the signal by them.

More detail about using DCID can be found on https://www.ietf.org/mail-archive/web/quic/current/msg03809.html.

--
Kazuho Oku
--_000_65cf3a3009944ca288a0cd6768d09339usma1exdag1mb5msgcorpak_-- From nobody Thu Apr 5 21:02:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6C01243FE for ; Thu, 5 Apr 2018 21:02:29 -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, FREEMAIL_FROM=0.001, 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=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 wcK1WNnloPNP for ; Thu, 5 Apr 2018 21:02:26 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC80112420B for ; Thu, 5 Apr 2018 21:02:25 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id f15so10033706pfn.0 for ; Thu, 05 Apr 2018 21:02: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=UJy6v+8rdRqKiqufi78swQaiKVvJXqslscePGwKSLMs=; b=jO07Mi7tiATznHW6NTpEOL2j8wRfvY3hKoGnYqGhPd5B3o/SYv2gUYrwO10PsRds3I egFZjAVcAgALWRlctKY/j41I46iNppurMJh1hi+lMJGaoc/203he5cBN7wsyzBevPNcl ADxHHbVLLCeXFhpi2yJyWQLIJegJijz7iavOfOEH40QOzMFGR1bHafL/XzzEHikDMjva qmF0B9S68cTy38STmr53aT/HsyH1S/fEUcq7navOhwHM+Rn2PVE994RMDhIANAwVnWeK Z8UTUSMP5ALpXeYqbnZp7Cdh86hyHD4pf2LNckqhkSYn4tMAYF2PKLnRYOzBdDoDXmZu IuPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=UJy6v+8rdRqKiqufi78swQaiKVvJXqslscePGwKSLMs=; b=nX0GCjWYJkZVSPBNAcByzRdL7ecxb3erBmP32v55+iJH7uzQ7RR4GB2XpIt206NFo+ Mz57sUBzuQiBJhveteIi3K++HvENHvbN2iqL/icF2e0IAAZJXzw9mUN2ErDap4r/JbHl eAfZ4udlydfJmvOoLoy2i8qbHXWlziZfgEqzF09zhYQN7daWUsHO65KSTQyNk4kI+pyS 9xlMFtIdDVR3ffbJ5DLqAvv7lJjf4fbqqHgTSE+eBqLn2rY9TOwQTkK5bHLbH2Iu4EIU vI4DBMwSjjatyss1XE4AfeOA8W/3xOvQEQz/6wgZ7CyvCFoOwFpwokCNN3ywPrpbv3Np fgTQ== X-Gm-Message-State: AElRT7HQgQcNVWEeOyKKRnVm1xqZRVmWrIF4LfjXG9t6mgk+kcUf5aiA ETE2kxTlKwhUfYM6nnpOZcPkMVh2hNdzFgjREaY= X-Google-Smtp-Source: AIpwx48Xykkx4dZtYCk2IFcYmJst3awtWUPvLL8OdjZhSio8TLwPk0MLRfeVH3mckaImL46IsvdNsBF7IrxRjZqA/T4= X-Received: by 10.101.86.198 with SMTP id w6mr16614847pgs.294.1522987344086; Thu, 05 Apr 2018 21:02:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Thu, 5 Apr 2018 21:02:23 -0700 (PDT) In-Reply-To: <65cf3a3009944ca288a0cd6768d09339@usma1ex-dag1mb5.msg.corp.akamai.com> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <65cf3a3009944ca288a0cd6768d09339@usma1ex-dag1mb5.msg.corp.akamai.com> From: Kazuho Oku Date: Fri, 6 Apr 2018 13:02:23 +0900 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: "Lubashev, Igor" Cc: "martin.thomson@gmail.com" , "quic@ietf.org" , "mirja.kuehlewind@tik.ee.ethz.ch" , "huitema@huitema.net" , "fkautz@alumni.cmu.edu" Content-Type: multipart/alternative; boundary="089e0826a784a44cdc0569261fa9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 04:02:29 -0000 --089e0826a784a44cdc0569261fa9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-04-06 12:48 GMT+09:00 Lubashev, Igor : > > The length of DCID can be a signal to the stateless load balancers. > > Short headers do not have an explicit CID length, so we are back to > validating the integrity of CID, no? What am I missing? > Yeah I missed that, apparently. Thank you for pointing that out. So I would propose to encrypt the type bits _and_ have DCID length in the header in cleartext. By doing that, it will still be possible for stateless load balancers to determine if a packet is initial (by checking if DCIL is 8) without decrypting the packet, at the same time being impossible for a middlebox to reliably determine the same thing (assuming that some servers will advertise DCID of 8 octets). > > > -----Original Message----- > *From:* Kazuho Oku [kazuhooku@gmail.com] > *Received:* Thursday, 05 Apr 2018, 10:56PM > *To:* Martin Thomson [martin.thomson@gmail.com] > *CC:* Mirja K=C3=BChlewind [mirja.kuehlewind@tik.ee.ethz.ch]; QUIC WG [ > quic@ietf.org]; Christian Huitema [huitema@huitema.net]; Frederick Kautz = [ > fkautz@alumni.cmu.edu] > *Subject:* Re: Privacy holes (was: Re: Getting to consensus on packet > number encryption) > > Hi Martin, > > Thank you for the response.. My comments inline. > > 2018-04-06 11:34 GMT+09:00 Martin Thomson : > >> On Fri, Apr 6, 2018 at 12:06 PM, Kazuho Oku wrote: >> > If I understand correctly, Christian's concern is that some middleboxe= s >> > might only create a hole if the first packet sent by a client (using a >> new >> > port) looks like a Initial packet. >> >> Oh, I didn't get the same impression, but it does seem like a valid >> concern. The idea I had was to have clients migrate often enough that >> those middleboxes will see those migrations and not incorrectly assume >> that flows have to start with Initial packets. >> >> Of course, migrating often like this might not provide enough >> incentive to avoid that practice because clients will likely make new >> connections when the old one fails. But given that this sort of >> failure probably involves a timeout before the repair, it's probably >> still noticeable enough to generate support tickets (and incentive to >> allow the migration to pass). >> >> Existing middleboxes that pass UDP will be fine, so we at least have >> that in our favour. >> >> > 1. frequent gratuitous migration by clients, so that middlebox vendors >> can >> > notice that there design is wrong prior to shipping it >> >> That is what this was angling for. The question being how frequent. >> >> > 3. mimic 0-RTT handshake when gratuitously switching to a new UDP flow >> > (depends on #1262) >> > >> > 1 and 2 have been discussed on this thread. I haven't yet seen 3 being >> > discussed. >> >> It has been suggested a few times elsewhere. The question is how far >> you go: do you send Initial and Handshake packets that use the >> handshake packet protection and carry apparently real ClientHello and >> ServerHello messages? Do you restrict the flow of packets to match >> 0-RTT? >> >> > The concerns so far being raised for 1 is that NATs might run out of >> > unassigned ports and that switching to a new path might trigger the >> restart >> > of congestion control on large-scale NATs that use multiple public >> > addresses. >> >> That is possible, but it depends on how often you attempt this. CGNAT >> does try to keep IP addresses for the same device stable. If not, >> then a congestion controller reset for relatively infrequent >> migrations isn't so bad if heuristics fail. It's only when you have >> very frequent migration that the resets becomes burdensome. >> > > How frequent is the issue here. > > If it's too frequent, some NATs could run out of unassigned ports, and if > depending on their eviction algorithm, shutdown UDP-based flows running > other protocols that do not do gratuitous switching. Other NATs could sta= rt > assigning new public addresses as they run out of unassigned ports. > > If it's too infrequent, then the chance of seeing misimplemented middlebo= x > becomes higher. > > >> > The concern so far being raised for 2 is that stateless load balancers >> would >> > be required to decrypt the type field (or the entire packet, depending >> on >> > how we encrypt) to determine if a packet is trying to initiate a new >> > connection. >> >> Yeah, that's hard. Having the load balancer hit the slow path for >> every packet seems pretty fatal. >> > > That was my understanding until I started to consider the impact of > symmetric CIDs. > > The length of DCID can be a signal to the stateless load balancers for > distinguishing an initial packet. If people interested in using that type > of load balancer can agree that they will be using CID other than 8 octet= s, > the length can be used as the signal by them. > > More detail about using DCID can be found on https://www.ietf.org/mail- > archive/web/quic/current/msg03809.html > > . > > -- > Kazuho Oku > --=20 Kazuho Oku --089e0826a784a44cdc0569261fa9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-04-06 12:48 GMT+09:00 Lubashev, Igor <ilubashe@akamai.com&g= t;:
> The length of DCID can be a signal to the stateless loa= d balancers.

Short headers do not have an explicit CID length, so we are back to validat= ing the integrity of CID, no? What am I missing?
<= div>
Yeah I missed that, apparently. Thank you for pointing t= hat out.

So I would propose to encrypt the type bi= ts _and_ have DCID length in the header in cleartext.

<= div>By doing that, it will still be possible for stateless load balancers t= o determine if a packet is initial (by checking if DCIL is 8) without decry= pting the packet, at the same time being impossible for a middlebox to reli= ably determine the same thing (assuming that some servers will advertise DC= ID of 8 octets).
=C2=A0=C2=A0


-----Original Message-----
From: Kazuho Oku [kazuhooku@gmail.com]
Received: Thursday, 05 Apr 2018, 10:56PM
To: Martin Thomson [martin.thomson@gmail.com]
CC: Mirja K=C3=BChlewind [mirja.kuehlewind@tik.ee.ethz.ch]; QUIC = WG [quic@ietf.org]; = Christian Huitema [huitema@huitema.net]; Frederick Kautz [fkautz@alumni.cmu.edu]
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet = number encryption)
Hi Martin,

Thank you for the response.. My comments inline.=

2018-04-06 11:34 GMT+09:00 Martin Thomson <martin.th= omson@gmail.com>:
On Fri, Apr 6, 2018 at 12:06 P= M, Kazuho Oku <= kazuhooku@gmail.com> wrote:
> If I understand correctly, Christian's concern is that some middle= boxes
> might only create a hole if the first packet sent by a client (using a= new
> port) looks like a Initial packet.

Oh, I didn't get the same impression, but it does seem like a va= lid
concern.=C2=A0 The idea I had was to have clients migrate often enough that=
those middleboxes will see those migrations and not incorrectly assume
that flows have to start with Initial packets.

Of course, migrating often like this might not provide enough
incentive to avoid that practice because clients will likely make new
connections when the old one fails.=C2=A0 But given that this sort of
failure probably involves a timeout before the repair, it's probably still noticeable enough to generate support tickets (and incentive to
allow the migration to pass).

Existing middleboxes that pass UDP will be fine, so we at least have
that in our favour.

> 1. frequent gratuitous migration by clients, so that middlebox vendors= can
> notice that there design is wrong prior to shipping it

That is what this was angling for.=C2=A0 The question being how freq= uent.

> 3. mimic 0-RTT handshake when gratuitously switching to a new UDP flow=
> (depends on #1262)
>
> 1 and 2 have been discussed on this thread. I haven't yet seen 3 b= eing
> discussed.

It has been suggested a few times elsewhere.=C2=A0 The question is h= ow far
you go: do you send Initial and Handshake packets that use the
handshake packet protection and carry apparently real ClientHello and
ServerHello messages?=C2=A0 Do you restrict the flow of packets to match 0-RTT?

> The concerns so far being raised for 1 is that NATs might run out of > unassigned ports and that switching to a new path might trigger the re= start
> of congestion control on large-scale NATs that use multiple public
> addresses.

That is possible, but it depends on how often you attempt this.=C2= =A0 CGNAT
does try to keep IP addresses for the same device stable.=C2=A0 If not,
then a congestion controller reset for relatively infrequent
migrations isn't so bad if heuristics fail.=C2=A0 It's only when yo= u have
very frequent migration that the resets becomes burdensome.

How frequent is the issue here.

If it's too frequent, some NATs could run out of unassigned ports,= and if depending on their eviction algorithm, shutdown UDP-based flows run= ning other protocols that do not do gratuitous switching. Other NATs could = start assigning new public addresses as they run out of unassigned ports.

If it's too infrequent, then the chance of seeing misimplemented m= iddlebox becomes higher.


> The concern so far being raised for 2 is that stateless load balancers= would
> be required to decrypt the type field (or the entire packet, depending= on
> how we encrypt) to determine if a packet is trying to initiate a new > connection.

Yeah, that's hard.=C2=A0 Having the load balancer hit the slow p= ath for
every packet seems pretty fatal.

That was my understanding until I started to consider the impact of symmetr= ic CIDs.

The length of DCID can be a signal to the statel= ess load balancers for distinguishing an initial packet. If people interest= ed in using that type of load balancer can agree that they will be using CI= D other than 8 octets, the length can be used as the signal by them.


--
Kazuho Oku



--
Kazuho Oku
--089e0826a784a44cdc0569261fa9-- From nobody Thu Apr 5 21:34:02 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F019127863 for ; Thu, 5 Apr 2018 21:34:01 -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, FREEMAIL_FROM=0.001, 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=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 BHJrCZpnKws3 for ; Thu, 5 Apr 2018 21:33:57 -0700 (PDT) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::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 A89CF12E87D for ; Thu, 5 Apr 2018 21:33:57 -0700 (PDT) Received: by mail-pl0-x230.google.com with SMTP id a39-v6so2633519pla.10 for ; Thu, 05 Apr 2018 21:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=w5hryrXAt2CCo6hlxdoKbAJC44MJhgoCHYsCuAeA2RI=; b=B6zaW5bA+8s8S5ewWjjASFyBALkmSHntlTC8O2ekYZQzpIFXe03VHc5xUkmbMpyPlY 1eiAF1qgtRtdTIiDiZ9+pKUqj+VBDm+w0ScNchBIHS7exS614tsgpxDToxaKNg1tjIpQ Szvd3ColM06nsxIHsRd2dM8207wUaCai93ARUeRI4vUcySJ36Clr0GLazL1dhNvZEztz 1mc1FBF9ofWAcM/L3i1NH/mH8yPQTrfPtgJ+8iKs+PD1/rSsM/IU6oaQ6mwEfxp+yGJa 9Pk4SoMKRocNmmffEABjjIL5JgxkHkprC4JtzWU2R0ygBOyeqsoCaEJmCkLGk/90vxdl VQvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=w5hryrXAt2CCo6hlxdoKbAJC44MJhgoCHYsCuAeA2RI=; b=ALpbJdtdVnyO2AJg9q7kH1nrwWUI/FIZk3KRvbiFExKBbmTZrmOgVmT1ZXJ/hpGax9 UtNI8wR+7u+cApMPO3+lf0rYGq2sV/NvG8essU8zVwnjyyyaOu9v/+8ZWjI0SKvb202z zwLyRR4fXSR7ycZZAst4L1z+DPIc5RCeIYHDtL5BritMcWXHbT+rajEGp+xgOFbyM1MY HxVDeOeKr/gB0xIowDmyBkpt59TEMlsYb7ZQuGre1FrldnL/KuMePq3w7DSbgrnA6WWr iABvQJoMWjQQ0gjdUxxJA03R3entf7Xa/eiIeatJc/FZlwLZmgt5cpLkoitM4ChFM+GT avGw== X-Gm-Message-State: AElRT7HZ7wohMB+HHcshM6O1begFVkguMuMIDTHyyBODNIlILNtgpls0 jQzyyt6XH0faFlFzZAIsUng= X-Google-Smtp-Source: AIpwx4/IDMQ5rTOc9/iREOqFzPh44SbuTrICuxiCpZ/MlhaFf6OYpnVpmTp+0y6AbnAimD/48LYTeg== X-Received: by 2002:a17:902:bd4a:: with SMTP id b10-v6mr23594027plx.271.1522989237197; Thu, 05 Apr 2018 21:33:57 -0700 (PDT) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id d12sm9334405pgq.41.2018.04.05.21.33.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Apr 2018 21:33:56 -0700 (PDT) From: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Kazuho Oku , "Lubashev, Igor" CC: "mirja.kuehlewind@tik.ee.ethz.ch" , "huitema@huitema.net" , "quic@ietf.org" , "martin.thomson@gmail.com" , "fkautz@alumni.cmu.edu" Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption) Thread-Index: AQHTzPOipWEBPIFckUWx4XrXrFfv2aPyVBsAgAACsQCAAI6BAIAAGGkAgAAH54CAAAZCgIAADoWAgAAD1oCAAAjLpw== X-MS-Exchange-MessageSentRepresentingType: 2 Date: Fri, 6 Apr 2018 04:33:51 +0000 Message-ID: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <65cf3a3009944ca288a0cd6768d09339@usma1ex-dag1mb5.msg.corp.akamai.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB17669E3FDBABEB0173715F40ACBA0DB6PR10MB1766EURP_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 04:34:01 -0000 --_000_DB6PR10MB17669E3FDBABEB0173715F40ACBA0DB6PR10MB1766EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So eventually CID's will ossify into certain lenghts by convention to thing= s working smoothly in the general case? ________________________________ From: QUIC on behalf of Kazuho Oku Sent: Friday, April 6, 2018 6:02:23 AM To: Lubashev, Igor Cc: mirja.kuehlewind@tik.ee.ethz.ch; huitema@huitema.net; quic@ietf.org; ma= rtin.thomson@gmail.com; fkautz@alumni.cmu.edu Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number = encryption) 2018-04-06 12:48 GMT+09:00 Lubashev, Igor >: > The length of DCID can be a signal to the stateless load balancers. Short headers do not have an explicit CID length, so we are back to validat= ing the integrity of CID, no? What am I missing? Yeah I missed that, apparently. Thank you for pointing that out. So I would propose to encrypt the type bits _and_ have DCID length in the h= eader in cleartext. By doing that, it will still be possible for stateless load balancers to de= termine if a packet is initial (by checking if DCIL is 8) without decryptin= g the packet, at the same time being impossible for a middlebox to reliably= determine the same thing (assuming that some servers will advertise DCID o= f 8 octets). -----Original Message----- From: Kazuho Oku [kazuhooku@gmail.com] Received: Thursday, 05 Apr 2018, 10:56PM To: Martin Thomson [martin.thomson@gmail.com] CC: Mirja K=FChlewind [mirja.kuehlewind@tik.ee.ethz.ch]; QUIC WG [quic@ietf.org]; Christ= ian Huitema [huitema@huitema.net]; Frederick Ka= utz [fkautz@alumni.cmu.edu] Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number = encryption) Hi Martin, Thank you for the response.. My comments inline. 2018-04-06 11:34 GMT+09:00 Martin Thomson >: On Fri, Apr 6, 2018 at 12:06 PM, Kazuho Oku > wrote: > If I understand correctly, Christian's concern is that some middleboxes > might only create a hole if the first packet sent by a client (using a ne= w > port) looks like a Initial packet. Oh, I didn't get the same impression, but it does seem like a valid concern. The idea I had was to have clients migrate often enough that those middleboxes will see those migrations and not incorrectly assume that flows have to start with Initial packets. Of course, migrating often like this might not provide enough incentive to avoid that practice because clients will likely make new connections when the old one fails. But given that this sort of failure probably involves a timeout before the repair, it's probably still noticeable enough to generate support tickets (and incentive to allow the migration to pass). Existing middleboxes that pass UDP will be fine, so we at least have that in our favour. > 1. frequent gratuitous migration by clients, so that middlebox vendors ca= n > notice that there design is wrong prior to shipping it That is what this was angling for. The question being how frequent. > 3. mimic 0-RTT handshake when gratuitously switching to a new UDP flow > (depends on #1262) > > 1 and 2 have been discussed on this thread. I haven't yet seen 3 being > discussed. It has been suggested a few times elsewhere. The question is how far you go: do you send Initial and Handshake packets that use the handshake packet protection and carry apparently real ClientHello and ServerHello messages? Do you restrict the flow of packets to match 0-RTT? > The concerns so far being raised for 1 is that NATs might run out of > unassigned ports and that switching to a new path might trigger the resta= rt > of congestion control on large-scale NATs that use multiple public > addresses. That is possible, but it depends on how often you attempt this. CGNAT does try to keep IP addresses for the same device stable. If not, then a congestion controller reset for relatively infrequent migrations isn't so bad if heuristics fail. It's only when you have very frequent migration that the resets becomes burdensome. How frequent is the issue here. If it's too frequent, some NATs could run out of unassigned ports, and if d= epending on their eviction algorithm, shutdown UDP-based flows running othe= r protocols that do not do gratuitous switching. Other NATs could start ass= igning new public addresses as they run out of unassigned ports. If it's too infrequent, then the chance of seeing misimplemented middlebox = becomes higher. > The concern so far being raised for 2 is that stateless load balancers wo= uld > be required to decrypt the type field (or the entire packet, depending on > how we encrypt) to determine if a packet is trying to initiate a new > connection. Yeah, that's hard. Having the load balancer hit the slow path for every packet seems pretty fatal. That was my understanding until I started to consider the impact of symmetr= ic CIDs. The length of DCID can be a signal to the stateless load balancers for dist= inguishing an initial packet. If people interested in using that type of lo= ad balancer can agree that they will be using CID other than 8 octets, the = length can be used as the signal by them. More detail about using DCID can be found on https://www.ietf.org/mail-arch= ive/web/quic/current/msg03809.html. -- Kazuho Oku -- Kazuho Oku --_000_DB6PR10MB17669E3FDBABEB0173715F40ACBA0DB6PR10MB1766EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So eventually CID’s will ossify into cer= tain lenghts by convention to things working smoothly in the general case?<= /div>

From: QUIC <quic-bounces= @ietf.org> on behalf of Kazuho Oku <kazuhooku@gmail.com>
Sent: Friday, April 6, 2018 6:02:23 AM
To: Lubashev, Igor
Cc: mirja.kuehlewind@tik.ee.ethz.ch; huitema@huitema.net; quic@ietf.= org; martin.thomson@gmail.com; fkautz@alumni.cmu.edu
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet = number encryption)
 


2018-04-06 12:48 GMT+09:00 Lubashev, Igor <ilubashe@akama= i.com>:
> The length of DCID can be a signal to the statel= ess load balancers.

Short headers do not have an explicit CID length, so we are back to validat= ing the integrity of CID, no? What am I missing?

Yeah I missed that, apparently. Thank you for pointing that out.

So I would propose to encrypt the type bits _and_ have DCID length in = the header in cleartext.

By doing that, it will still be possible for stateless load balancers = to determine if a packet is initial (by checking if DCIL is 8) without decr= ypting the packet, at the same time being impossible for a middlebox to rel= iably determine the same thing (assuming that some servers will advertise DCID of 8 octets).
  


-----Original Message-----
From: Kazuho Oku [kazuhooku@gmail.com]
Received: Thursday, 05 Apr 2018, 10:56PM
To: Martin Thomson [martin.thomson@gmail.com]
CC: Mirja K=FChlewind [mirja.kuehlewind@tik.ee.ethz.ch]; QUIC WG = [quic@ietf.org]; Chr= istian Huitema [hu= itema@huitema.net]; Frederick Kautz [fkautz@alumni.cmu.edu]
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet = number encryption)
Hi Martin,

Thank you for the response.. My comments inline.=

2018-04-06 11:34 GMT+09:00 Martin Thomson <martin.th= omson@gmail.com>:
On Fri, Apr 6, 2018 at 12:06 P= M, Kazuho Oku <= kazuhooku@gmail.com> wrote:
> If I understand correctly, Christian's concern is that some middleboxe= s
> might only create a hole if the first packet sent by a client (using a= new
> port) looks like a Initial packet.

Oh, I didn't get the same impression, but it does seem like a valid<= br> concern.  The idea I had was to have clients migrate often enough that=
those middleboxes will see those migrations and not incorrectly assume
that flows have to start with Initial packets.

Of course, migrating often like this might not provide enough
incentive to avoid that practice because clients will likely make new
connections when the old one fails.  But given that this sort of
failure probably involves a timeout before the repair, it's probably
still noticeable enough to generate support tickets (and incentive to
allow the migration to pass).

Existing middleboxes that pass UDP will be fine, so we at least have
that in our favour.

> 1. frequent gratuitous migration by clients, so that middlebox vendors= can
> notice that there design is wrong prior to shipping it

That is what this was angling for.  The question being how freq= uent.

> 3. mimic 0-RTT handshake when gratuitously switching to a new UDP flow=
> (depends on #1262)
>
> 1 and 2 have been discussed on this thread. I haven't yet seen 3 being=
> discussed.

It has been suggested a few times elsewhere.  The question is h= ow far
you go: do you send Initial and Handshake packets that use the
handshake packet protection and carry apparently real ClientHello and
ServerHello messages?  Do you restrict the flow of packets to match 0-RTT?

> The concerns so far being raised for 1 is that NATs might run out of > unassigned ports and that switching to a new path might trigger the re= start
> of congestion control on large-scale NATs that use multiple public
> addresses.

That is possible, but it depends on how often you attempt this. = ; CGNAT
does try to keep IP addresses for the same device stable.  If not,
then a congestion controller reset for relatively infrequent
migrations isn't so bad if heuristics fail.  It's only when you have very frequent migration that the resets becomes burdensome.

How frequent is the issue here.

If it's too frequent, some NATs could run out of unassigned ports, and= if depending on their eviction algorithm, shutdown UDP-based flows running= other protocols that do not do gratuitous switching. Other NATs could star= t assigning new public addresses as they run out of unassigned ports.

If it's too infrequent, then the chance of seeing misimplemented middl= ebox becomes higher.


> The concern so far being raised for 2 is that stateless load balancers= would
> be required to decrypt the type field (or the entire packet, depending= on
> how we encrypt) to determine if a packet is trying to initiate a new > connection.

Yeah, that's hard.  Having the load balancer hit the slow path = for
every packet seems pretty fatal.

That was my understanding until I started to consider the impact of symmetr= ic CIDs.

The length of DCID can be a signal to the statel= ess load balancers for distinguishing an initial packet. If people interest= ed in using that type of load balancer can agree that they will be using CI= D other than 8 octets, the length can be used as the signal by them.


--
Kazuho Oku



--
Kazuho Oku
--_000_DB6PR10MB17669E3FDBABEB0173715F40ACBA0DB6PR10MB1766EURP_-- From nobody Thu Apr 5 21:45:32 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA373127867 for ; Thu, 5 Apr 2018 21:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 f5teMIyZa616 for ; Thu, 5 Apr 2018 21:45:27 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 BB3B612783A for ; Thu, 5 Apr 2018 21:45:27 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id o16so4720581pfk.9 for ; Thu, 05 Apr 2018 21:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=1+cpPu17UglI7lM0ImLgoOmwoD40pyw6PlJSZCGeN0k=; b=dnJSBqVZIssR3/ZT/SSDMT4320TAOMC6E4ISP/h8lqkzhHklmeJjQJ88jX40DVDlnu mvUNVZ+kzXpdXKwf50KoTJJio/lycpngfG/EWUq0V74MdzP1IpYpTvsZJJX3zlqL8ltb B5w8f+Vl0LAiNFc4InLzLrMVm0X3hlt34ddooGUOFZr5sjfUzGvSONuTDk2MS5kOeGl2 8GHYimPee1dkgbc6CpEJs38vcTvoQ8FG3eIFKdZ8YvOaI8PuVP0rz2LjhwDcB+e68zv2 Trt78welxSfWEaziV8ZhQ+S7lROcXDDekTHB6gqG2kXTPZRbm0abz7X95TY2z2bl4Prh XSPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=1+cpPu17UglI7lM0ImLgoOmwoD40pyw6PlJSZCGeN0k=; b=ZF03zolW10l8RMxaO6TkSlsgNrcHsf92XsLLdSiXfJx5lXVAHQUtmTCYHlwmO1iLJq mURdTCLmIoVPGym8WB1k8QYET4Yp1VfU2KJ0j+Xnv8tMep2tZXOu2O5O7cxNTC5LgJW/ Ukk8RdZBlwlRsrDRBBHy/tpYrbXIMbFQAtJXX+9RpbiEtg3kcwX1d3f5ILIY7YmWTB+3 zW++rzs6tUlPjXdGkq2r8trUH5BW2S+ztT9gq2bEbJ0X2UqlSqdRn2YESE7n+zT0w0xu tk0xBSY4FzprScOip05zLMe3sJP2oIaiWQx0k8tKkBwq2BxbkEdgFSXF5v9WBeJqmHtN gIVQ== X-Gm-Message-State: ALQs6tBZuKX3EVZQKpxPCztnq3KYGkyMaDmqH+Z3Xt4JweDlsGu1Rlzh oVxFFY7ZzNkmamLiyLFLvZQ= X-Google-Smtp-Source: AIpwx4/k60l7eRryFSs9YpGGUbnDUm4NfL6X5kzpUm0GL1Vcoi/CTmzMDsgBcYmTxtadbPUcvM0rEQ== X-Received: by 10.99.126.92 with SMTP id o28mr6699987pgn.50.1522989927080; Thu, 05 Apr 2018 21:45:27 -0700 (PDT) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id b4sm13894329pfa.64.2018.04.05.21.45.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Apr 2018 21:45:26 -0700 (PDT) From: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= To: Ian Swett , Mike Bishop CC: Praveen Balasubramanian , IETF QUIC WG Subject: Re: Impact of hardware offloads on network stack performance Thread-Topic: Impact of hardware offloads on network stack performance Thread-Index: ATBFREQw9pGMyhwcHYjcndXohYuvq1FrcXErMDlGRDFRZUEtSMB369TF X-MS-Exchange-MessageSentRepresentingType: 2 Date: Fri, 6 Apr 2018 04:45:22 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB1766789B25E31EBE70564BD3ACBA0DB6PR10MB1766EURP_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 04:45:31 -0000 --_000_DB6PR10MB1766789B25E31EBE70564BD3ACBA0DB6PR10MB1766EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gYmUgY2xlYXIgLSBJIGRvbuKAmXQgdGhpbmsgY3J5cHRvIGlzIG92ZXJzaGFkb3dpbmcgb3Ro ZXIgaXNzdWVzIGFzIE1pa2UgcmVhZCBteSBwb3N0LiBJdCBjZXJ0YWlubHkgY29tZXMgYXQgYSBj b3N0LCBidXQgZWl0aGVyIG11bHRpcGxlIGNvcmVzIG9yIGNvLXByb2Nlc3NvcnMgd2lsbCBkZWFs IHdpdGggdGhpcy4gMTAwMG5zIGlzIDEwR2JwcyBjcnlwdG8gc3BlZWQgb24gb25lIGNvcmUgYW5k IGl0IGlzIGhpZ2x5IHBhcmFsbGVsaXNhYmxlIGFuZCBjYWNoZSBmcmllbmRseS4NCg0KQnV0IGlm IHlvdSBoYXZlIHRvIGRyaXAgeW91ciBwYWNrZXRzIHRocm91Z2ggYSB0cmFkaXRpb25hbCBzZW5k IGludGVyZmFjZSB0aGF0IGlzIGNvcHlpbmcsIGJ1ZmZlcmluZyBvciBibG9ja2luZywgYW5kIGNl cnRhaW5seSBzeW5j4oCZaW5nIHdpdGggdGhlIGtlcm5lbCAtIGl0IGlzIGdvaW5nIHRvIGJlIHRv dWdoLg0KDQpGb3IgcmVjZWl2ZSB5b3UgcmlzayBoaWdoIGxhdGVuY3kgb3IgdG9wIG11Y2ggc2No ZWR1bGluZyBpbiByZWNlaXZlIGJ1ZmZlcnMuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpGcm9tOiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+DQpTZW50OiBGcmlk YXksIEFwcmlsIDYsIDIwMTggNDowNjowMSBBTQ0KVG86IE1pa2UgQmlzaG9wDQpDYzogTWlra2Vs IEZhaG7DuGUgSsO4cmdlbnNlbjsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW47IElFVEYgUVVJQyBX Rw0KU3ViamVjdDogUmU6IEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0 YWNrIHBlcmZvcm1hbmNlDQoNCg0KDQpPbiBUaHUsIEFwciA1LCAyMDE4IGF0IDU6NTcgUE0gTWlr ZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5i ZT4+IHdyb3RlOg0KVGhhdOKAmXMgaW50ZXJlc3RpbmcgZGF0YSwgUHJhdmVlbiDigJMgdGhhbmtz LiAgVGhlcmUgaXMgb25lIGNhdmVhdCB0aGVyZSwgd2hpY2ggaXMgdGhhdCAoSUlVQywgb24gY3Vy cmVudCBoYXJkd2FyZSkgeW91IGNhbuKAmXQgZG8gcGFja2V0IHBhY2luZyB3aXRoIExTTywgYW5k IHNvIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBldmVuIGZvciBUQ1AgbWFueSBwcm92aWRlcnMg ZGlzYWJsZSB0aGlzIGluIHB1cnN1aXQgb2YgYmV0dGVyIGVncmVzcyBtYW5hZ2VtZW50LiAgU28g d2hhdCB3ZeKAmXJlIHJlYWxseSBzYXlpbmcgaXMgdGhhdDoNCg0KICAqICAgT24gY3VycmVudCBo YXJkd2FyZSBhbmQgT1Mgc2V0dXBzLCBVRFAgcnVucyBsZXNzIHRoYW4gaGFsZiBhcyBtdWNoIHRo cm91Z2hwdXQgYXMgVENQOyB0aGF0IG5lZWRzIHNvbWUgb3B0aW1pemF0aW9uLCBhcyB3ZeKAmXZl IGFscmVhZHkgZGlzY3Vzc2VkDQogICogICBUQ1Agd2lsbCBkcmFtYXRpY2FsbHkgZ2FpbiBwZXJm b3JtYW5jZSBvbmNlIGhhcmR3YXJlIG9mZmxvYWQgY2F0Y2hlcyB1cCBhbmQgYWxsb3dzIHBhY2Vk IExTTyDwn5iKDQoNCkhvd2V2ZXIsIGFzIE1pa2tlbCBwb2ludHMgb3V0LCB0aGUgY3J5cHRvIGNv c3RzIGFyZSBsaWtlbHkgdG8gb3ZlcndoZWxtIHRoZSBPUyB0aHJvdWdocHV0IC8gc2NoZWR1bGlu ZyBpc3N1ZXMgaW4gcmVhbCBkZXBsb3ltZW50cy4gIFNvIEkgdGhpbmsgdGhlIG90aGVyIHJlbGV2 YW50IHBpZWNlIHRvIHVuZGVyc3RhbmRpbmcgdGhlIGNvc3QgaGVyZSBpcyB0aGlzOg0KDQpJIGhh dmUgYSBmZXcgY2FzZXMoYm90aCBjbGllbnQgYW5kIHNlcnZlcikgd2hlcmUgbXkgVURQIHNlbmQg Y29zdHMgYXJlIG1vcmUgdGhhbiAzMCUoaW4gc29tZSBjYXNlcyA1MCUpIG9mIENQVSBjb25zdW1w dGlvbiwgYW5kIGNyeXB0byBpcyBsZXNzIHRoYW4gMTAlLiAgU28gY3VycmVudGx5LCBJIGFzc3Vt ZSBjcnlwdG8gaXMgY2hlYXAoZXNwZWNpYWxseSBBRVMtR0NNIHdoZW4gaGFyZHdhcmUgYWNjZWxl cmF0aW9uIGlzIGF2YWlsYWJsZSkgYW5kIGVncmVzcyBpcyBleHBlbnNpdmUuICBVRFAgaW5ncmVz IGlzIG5vdCB0aGF0IGV4cGVuc2l2ZSwgYnV0IGNvdWxkIHVzZSBhIGJpdCBvZiBvcHRpbWl6YXRp b24gYXMgd2VsbC4NCg0KVGhlIG9ubHkgJ2ZhbmN5JyB0aGluZyBvdXIgY3VycmVudCBjb2RlIGlz IGRvaW5nIGZvciBjcnlwdG8gaXMgZW5jcnlwdGluZyBpbiBwbGFjZSwgd2hpY2ggd2FzIGEgfjIl IHdpbi4gIE5pY2UsIGJ1dCBub3QgdHJhbnNmb3JtYXRpdmUuICBTZWUgRW5jcnlwdEluUGxhY2U8 aHR0cHM6Ly9jcy5jaHJvbWl1bS5vcmcvY2hyb21pdW0vc3JjL25ldC9xdWljL2NvcmUvcXVpY19m cmFtZXIuY2M/c3E9cGFja2FnZTpjaHJvbWl1bSZsPTE4OTM+DQoNCkkgaGF2ZW4ndCBkb25lIG11 Y2ggd29yayBiZW5jaG1hcmtpbmcgV2luZG93cywgc28gcG9zc2libHkgdGhlIFdpbmRvd3MgVURQ IHN0YWNrIGlzIHJlYWxseSBmYXN0LCBhbmQgc28gY3J5cHRvIHNlZW1zIHJlYWxseSBzbG93IGlu IGNvbXBhcmlzb24/DQoNCg0KICAqICAgV2hhdCBpcyB0aGUgdGhyb3VnaHB1dCBhbmQgcmVsYXRp dmUgY29zdCBvZiBUTFMvVENQIHZlcnN1cyBRVUlDIChpLmUuIGhvdyBtdWNoIGFyZSB0aGUgc21h bGxlciB1bml0cyBvZiBlbmNyeXB0aW9uIGh1cnRpbmcgdXMgdmVyc3VzLCBzYXksIDE2S0IgVExT IHJlY29yZHMpPw0KICAgICAqICAgVExTIGltcGxlbWVudGF0aW9ucyBhbHJlYWR5IHZhcnkgaGVy ZTogIFNvbWUgaW1wbGVtZW50YXRpb25zIGNob29zZSBsYXJnZSByZWNvcmQgc2l6ZXMsIHNvbWUg dmFyeSByZWNvcmQgc2l6ZXMgdG8gcmVkdWNlIGRlbGF5IC8gSG9MQiwgc28gdGhpcyBwcm9iYWJs eSBpc27igJl0IGEgc2luZ2xlIG51bWJlci4NCiAgKiAgIEhvdyBtdWNoIGFkZGl0aW9uYWwgbG9h ZCBkb2VzIFBORSBhZGQgdG8gdGhpcyBkaWZmZXJlbmNlPw0KICAqICAgVG8gd2hhdCBleHRlbnQg d291bGQgUE5FIG1ha2UgZnV0dXJlIGNyeXB0byBvZmZsb2FkcyBpbXBvc3NpYmxlIHZlcnN1cyBy ZXF1aXJlcyBtb3JlIFImRCB0byBkZXZlbG9wPw0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYg T2YgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA0LCAy MDE4IDE6MzQgUE0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmI9NDBtaWNyb3Nv ZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5v cmc+PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4N ClN1YmplY3Q6IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFj ayBwZXJmb3JtYW5jZQ0KDQpUaGFua3MgZm9yIHNoYXJpbmcgdGhlc2UgbnVtYmVycy4NCg0KTXkg Z3Vlc3MgaXMgdGhhdCB0aGVzZSBvZmZsb2FkcyBkZWFsIHdpdGgga2VybmVsIHNjaGVkdWxpbmcs IG1lbW9yeSBjYWNoZSBpc3N1ZXMsIGFuZCBpbnRlcnJ1cHQgc2NoZWR1bGluZy4NCg0KSXQgcHJv YmFibHkgaGFzIHZlcnkgbGl0dGxlIHRvIGRvIHdpdGggY3J5cHRvLCBUQ1AgaGVhZGVycywgYW5k IGFueSBvdGhlciBjcHUgc2Vuc2l0aXZlIHByb2Nlc3NpbmcuDQoNClRoaXMgaXMgd2hlcmUgbmV0 bWFwIGVudGVyczogeW91IGNhbiB0cmFuc3BhcmVudGx5IGZlZWQgdGhlIGRhdGEgYXMgaXQgYmVj b21lcyBhdmFpbGFibGUgd2l0aCB2ZXJ5IGxpdHRsZSBzeW5jIHdvcmsgYW5kIHlvdSBjYW4gYWxz byBlZmZpY2llbnRseSBwaXBlbGluZSBzbyB5b3UgcGFzcyBkYXRhIHRvIGRlY3J5cHRvciwgdGhl biB0byBhcHAsIHdpdGggYXMgbGl0dGxlIGJ1cyB0cmFmZmljIGFzIHBvc3NpYmxlLiBObyBuZWVk IHRvIGNvcHkgZGF0YSBvciBzeW5jaHJvbml6ZSBrZXJuZWwgc3BhY2UuDQoNCkZvciAxSyBwYWNr ZXRzIHlvdSB3b3VsZCB1c2UgYWJvdXQgMTAwMG5zICgzIGN5Y2xlcy9ieXRlKSBvbiBjcnlwdG8g YW5kIHRoaXMgd291bGQgaGFwcGVuIGluIEwxIGNhY2hlLiBJdCB3b3VsZCBvZiBjb3Vyc2UgY29u c3VtZSBhIGNvcmUgd2hpY2ggYSBjcnlwdG8gb2ZmbG9hZCB3b3VsZCBub3QsIGJ1dCB0aGF0IGNh biBiZSBkZWJhdGVkIGJlY2F1c2Ugd2l0aCAxOCBjb3JlIHN5c3RlbXMsIHlvdXIgcHJvYmxlbSBp cyBtZW1vcnkgYW5kIG5ldHdvcmsgbW9yZSB0aGFuIENQVS4NCg0KTXkgY29uY2VybiB3aXRoIFBO RSBpcyBmb3Igc21hbGwgcGFja2V0cyBhbmQgbG93IGxhdGVuY3kgd2hlcmUNCjEpIGFuIGVzdGlt YXRlZCAyNG5zIGZvciBQTiBlbmNyeXB0aW9uIGFuZCBkZWNyeXB0aW9uIGJlY29tZXMgbWVhc3Vy YWJsZSBpZiB5b3VyIG5ldHdvcmsgaXMgZmFzdCBlbm91Z2guDQoyKSBhbnkgZGFtYWdlIHRvIHRo ZSBwYWNrZXQgYnVmZmVyIGNhdXNlIGFsbCBzb3J0cyBvZiBtZW1vcnkgYW5kIGNwdSBidXMgdHJh ZmZpYyBpc3N1ZXMuDQoNCjEpIGlzIGFubm95aW5nLiAyKSBpcyBiYWQsIGNvbXBsZXRlbHkgYXZv aWRhYmxlIGJ1dCBub3QgYXMgUFIgMTA3OSBpcyBmb3JtdWxhdGVkIGN1cnJlbnRseS4NCg0KMikg aXMgYWxzbyBsaWtlbHkgYmFkIGZvciBoYXJkd2FyZSBvZmZsb2FkIHVuaXRzIGFzIHdlbGwuDQoN CkFzIHRvIFNSVi1JTyAtIEnigJltIG5vdCBmYW1pbGlhciB3aXRoIGl0LCBidXQgb2J2aW91c2x5 IHRoZXJlIGlzIHNvbWUgSU8gYWJzdHJhY3Rpb24gbGF5ZXIgLSB0aGUgcXVlc3Rpb24gaXMgaG93 IHlvdSBtYWtlIGl0IGFjY2Vzc2libGUgdG8gYXBwcyBhcyBvcHBvc2VkIHRvIGRldmljZSBkcml2 ZXJzIHRoYXQgZG9lcyBub3Igd29yayB3aXRoIHlvdSBRVUlDIGN1c3RvbSBzdGFjaywgYW5kIG5l dG1hcCBpcyBvbmUgb3B0aW9uIGhlcmUuDQoNCktpbmQgUmVnYXJkcywNCk1pa2tlbCBGYWhuw7hl IErDuHJnZW5zZW4NCg0KDQpPbiA0IEFwcmlsIDIwMTggYXQgMjIuMTUuNTIsIFByYXZlZW4gQmFs YXN1YnJhbWFuaWFuIChwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRv OnByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4pIHdyb3RlOg0KU29tZSBjb21w YXJhdGl2ZSBudW1iZXJzIGZyb20gYW4gb3V0IG9mIGJveCBkZWZhdWx0IHNldHRpbmdzIFdpbmRv d3MgU2VydmVyIDIwMTYgKHJlbGVhc2VkIHZlcnNpb24pIGZvciBhIHNpbmdsZSBjb25uZWN0aW9u IHdpdGggYSBtaWNyb2JlbmNobWFyayB0b29sOg0KDQpPZmZsb2FkcyBlbmFibGVkDQoNClRDUCBn YnBzDQoNClVEUCBnYnBzDQoNCkxTTyArIExSTyArIGNoZWNrc3VtDQoNCjI0DQoNCjMuNg0KDQpD aGVja3N1bSBvbmx5DQoNCjcuNg0KDQozLjYNCg0KTm9uZQ0KDQo1LjYNCg0KMi4zDQoNCg0KVGhp cyBpcyBmb3IgYSBmdWxseSBib3R0bGVuZWNrZWQgQ1BVIGNvcmUgLS0gaWYgeW91IHJ1biBsb3dl ciBkYXRhIHJhdGVzIHRoZXJlIGlzIHN0aWxsIGEgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZSBpbiBD eWNsZXMvYnl0ZSBjb3N0LiBTYW1lIGluY3JlYXNlZCBDUFUgY29zdCBhcHBsaWVzIGZvciBjbGll bnQgc3lzdGVtcyBnb2luZyBvdmVyIGhpZ2ggZGF0YSByYXRlIFdpZmkgYW5kIGNlbGx1bGFyLg0K DQpUaGlzIGlzIHdpdGhvdXQgYW55IGNyeXB0by4gT25jZSB5b3UgYWRkIGNyeXB0byB0aGUgbnVt YmVycyBiZWNvbWUgbXVjaCB3b3JzZSB3aXRoIGNyeXB0byBjb3N0IGJlY29taW5nIGRvbWluYW50 LiBBZGRpbmcgYW5vdGhlciBjcnlwdG8gc3RlcCBmdXJ0aGVyIGV4YWNlcmJhdGVzIHRoZSBwcm9i bGVtLiBIZW5jZSBjcnlwdG8gb2ZmbG9hZCBnYWlucyBpbiBpbXBvcnRhbmNlIGZvbGxvd2VkIGJ5 IHRoZXNlIGJhdGNoIG9mZmxvYWRzLg0KDQpJZiBmb2xrcyBuZWVkIGFueSBtb3JlIG51bWJlcnMg SeKAmWQgYmUgaGFwcHkgdG8gcHJvdmlkZSB0aGVtLg0KDQpUaGFua3MNCg0K --_000_DB6PR10MB1766789B25E31EBE70564BD3ACBA0DB6PR10MB1766EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8L2hlYWQ+DQo8Ym9keT4NCjxkaXYgaWQ9ImNvbXBvc2UtY29udGFpbmVy IiBpdGVtc2NvcGU9IiIgaXRlbXR5cGU9Imh0dHBzOi8vc2NoZW1hLm9yZy9FbWFpbE1lc3NhZ2Ui IHN0eWxlPSJkaXJlY3Rpb246bHRyIj4NCjxzcGFuIGl0ZW1wcm9wPSJjcmVhdG9yIiBpdGVtc2Nv cGU9IiIgaXRlbXR5cGU9Imh0dHBzOi8vc2NoZW1hLm9yZy9Pcmdhbml6YXRpb24iPjxzcGFuIGl0 ZW1wcm9wPSJuYW1lIj48L3NwYW4+PC9zcGFuPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJk aXJlY3Rpb246bHRyIj5UbyBiZSBjbGVhciAtIEkgZG9u4oCZdCB0aGluayBjcnlwdG8gaXMgb3Zl cnNoYWRvd2luZyBvdGhlciBpc3N1ZXMgYXMgTWlrZSByZWFkIG15IHBvc3QuIEl0IGNlcnRhaW5s eSBjb21lcyBhdCBhIGNvc3QsIGJ1dCBlaXRoZXIgbXVsdGlwbGUgY29yZXMgb3IgY28tcHJvY2Vz c29ycyB3aWxsIGRlYWwgd2l0aCB0aGlzLiAxMDAwbnMgaXMgMTBHYnBzIGNyeXB0byBzcGVlZCBv biBvbmUgY29yZSBhbmQgaXQNCiBpcyBoaWdseSBwYXJhbGxlbGlzYWJsZSBhbmQgY2FjaGUgZnJp ZW5kbHkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOmx0 ciI+QnV0IGlmIHlvdSBoYXZlIHRvIGRyaXAgeW91ciBwYWNrZXRzIHRocm91Z2ggYSB0cmFkaXRp b25hbCBzZW5kIGludGVyZmFjZSB0aGF0IGlzIGNvcHlpbmcsIGJ1ZmZlcmluZyBvciBibG9ja2lu ZywgYW5kIGNlcnRhaW5seSBzeW5j4oCZaW5nIHdpdGggdGhlIGtlcm5lbCAtIGl0IGlzIGdvaW5n IHRvIGJlIHRvdWdoLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImRpcmVj dGlvbjpsdHIiPkZvciByZWNlaXZlIHlvdSByaXNrIGhpZ2ggbGF0ZW5jeSBvciB0b3AgbXVjaCBz Y2hlZHVsaW5nIGluIHJlY2VpdmUgYnVmZmVycy48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9ImFjb21wbGlfc2lnbmF0dXJlIj48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8aHIgdGFiaW5kZXg9Ii0xIiBzdHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7IHdpZHRo Ojk4JSI+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZvbnQgZmFjZT0iQ2Fs aWJyaSwgc2Fucy1zZXJpZiIgY29sb3I9IiMwMDAwMDAiIHN0eWxlPSJmb250LXNpemU6MTFwdCI+ PGI+RnJvbTo8L2I+IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCA2LCAyMDE4IDQ6MDY6MDEgQU08YnI+DQo8Yj5Ubzo8 L2I+IE1pa2UgQmlzaG9wPGJyPg0KPGI+Q2M6PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2Vu OyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbjsgSUVURiBRVUlDIFdHPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJm b3JtYW5jZTwvZm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGRp cj0ibHRyIj48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0i bHRyIj5PbiBUaHUsIEFwciA1LCAyMDE4IGF0IDU6NTcgUE0gTWlrZSBCaXNob3AgJmx0OzxhIGhy ZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+ Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4OyBib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDsgcGFk ZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGxhbmc9IkVOLVVTIj4NCjxkaXYgY2xhc3M9Im1fLTkwMDQ5 MTcxNDk0MDU1OTQxNDNXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdOKA mXMgaW50ZXJlc3RpbmcgZGF0YSwgUHJhdmVlbiDigJMgdGhhbmtzLiZuYnNwOyBUaGVyZSBpcyBv bmUgY2F2ZWF0IHRoZXJlLCB3aGljaCBpcyB0aGF0IChJSVVDLCBvbiBjdXJyZW50IGhhcmR3YXJl KSB5b3UgY2Fu4oCZdCBkbyBwYWNrZXQgcGFjaW5nIHdpdGggTFNPLCBhbmQgc28gbXkgdW5kZXJz dGFuZGluZyBpcyB0aGF0IGV2ZW4gZm9yIFRDUCBtYW55IHByb3ZpZGVycyBkaXNhYmxlIHRoaXMg aW4gcHVyc3VpdCBvZg0KIGJldHRlciBlZ3Jlc3MgbWFuYWdlbWVudC4mbmJzcDsgU28gd2hhdCB3 ZeKAmXJlIHJlYWxseSBzYXlpbmcgaXMgdGhhdDo8dT48L3U+PHU+PC91PjwvcD4NCjx1bCB0eXBl PSJkaXNjIiBzdHlsZT0ibWFyZ2luLXRvcDowaW4iPg0KPGxpIGNsYXNzPSJtXy05MDA0OTE3MTQ5 NDA1NTk0MTQzTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbiI+T24gY3Vy cmVudCBoYXJkd2FyZSBhbmQgT1Mgc2V0dXBzLCBVRFAgcnVucyBsZXNzIHRoYW4gaGFsZiBhcyBt dWNoIHRocm91Z2hwdXQgYXMgVENQOyB0aGF0IG5lZWRzIHNvbWUgb3B0aW1pemF0aW9uLCBhcyB3 ZeKAmXZlIGFscmVhZHkgZGlzY3Vzc2VkPHU+PC91Pjx1PjwvdT48L2xpPjxsaSBjbGFzcz0ibV8t OTAwNDkxNzE0OTQwNTU5NDE0M01zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW4iPlRDUCB3aWxsIGRyYW1hdGljYWxseSBnYWluIHBlcmZvcm1hbmNlIG9uY2UgaGFyZHdhcmUg b2ZmbG9hZCBjYXRjaGVzIHVwIGFuZCBhbGxvd3MNCjx1PnBhY2VkPC91PiBMU08gPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2VyaWYiPvCf mIo8L3NwYW4+PHU+PC91Pjx1PjwvdT48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIGFz IE1pa2tlbCBwb2ludHMgb3V0LCB0aGUgY3J5cHRvIGNvc3RzIGFyZSBsaWtlbHkgdG8gb3Zlcndo ZWxtIHRoZSBPUyB0aHJvdWdocHV0IC8gc2NoZWR1bGluZyBpc3N1ZXMgaW4gcmVhbCBkZXBsb3lt ZW50cy4mbmJzcDsgU28gSSB0aGluayB0aGUgb3RoZXIgcmVsZXZhbnQgcGllY2UgdG8gdW5kZXJz dGFuZGluZyB0aGUgY29zdCBoZXJlIGlzIHRoaXM6PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgaGF2ZSBhIGZldyBjYXNlcyhib3Ro IGNsaWVudCBhbmQgc2VydmVyKSB3aGVyZSBteSBVRFAgc2VuZCBjb3N0cyBhcmUgbW9yZSB0aGFu IDMwJShpbiBzb21lIGNhc2VzIDUwJSkgb2YgQ1BVIGNvbnN1bXB0aW9uLCBhbmQgY3J5cHRvIGlz IGxlc3MgdGhhbiAxMCUuJm5ic3A7IFNvIGN1cnJlbnRseSwgSSBhc3N1bWUgY3J5cHRvIGlzIGNo ZWFwKGVzcGVjaWFsbHkgQUVTLUdDTSB3aGVuIGhhcmR3YXJlIGFjY2VsZXJhdGlvbiBpcyBhdmFp bGFibGUpDQogYW5kIGVncmVzcyBpcyBleHBlbnNpdmUuJm5ic3A7IFVEUCBpbmdyZXMgaXMgbm90 IHRoYXQgZXhwZW5zaXZlLCBidXQgY291bGQgdXNlIGEgYml0IG9mIG9wdGltaXphdGlvbiBhcyB3 ZWxsLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIG9ubHkgJ2ZhbmN5JyB0aGlu ZyBvdXIgY3VycmVudCBjb2RlIGlzIGRvaW5nIGZvciBjcnlwdG8gaXMgZW5jcnlwdGluZyBpbiBw bGFjZSwgd2hpY2ggd2FzIGEgfjIlIHdpbi4mbmJzcDsgTmljZSwgYnV0IG5vdCB0cmFuc2Zvcm1h dGl2ZS4mbmJzcDsgU2VlDQo8YSBocmVmPSJodHRwczovL2NzLmNocm9taXVtLm9yZy9jaHJvbWl1 bS9zcmMvbmV0L3F1aWMvY29yZS9xdWljX2ZyYW1lci5jYz9zcT1wYWNrYWdlOmNocm9taXVtJmFt cDtsPTE4OTMiPg0KRW5jcnlwdEluUGxhY2U8L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5JIGhhdmVuJ3QgZG9uZSBtdWNoIHdvcmsgYmVuY2htYXJraW5nIFdpbmRvd3MsIHNvIHBv c3NpYmx5IHRoZSBXaW5kb3dzIFVEUCBzdGFjayBpcyByZWFsbHkgZmFzdCwgYW5kIHNvIGNyeXB0 byBzZWVtcyByZWFsbHkgc2xvdyBpbiBjb21wYXJpc29uPzxicj4NCjwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjow IDAgMCAuOGV4OyBib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+ DQo8ZGl2IGxhbmc9IkVOLVVTIj4NCjxkaXYgY2xhc3M9Im1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91Pjx1PjwvdT48L3A+DQo8 dWwgdHlwZT0iZGlzYyIgc3R5bGU9Im1hcmdpbi10b3A6MGluIj4NCjxsaSBjbGFzcz0ibV8tOTAw NDkxNzE0OTQwNTU5NDE0M01zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW4i PldoYXQgaXMgdGhlIHRocm91Z2hwdXQgYW5kIHJlbGF0aXZlIGNvc3Qgb2YgVExTL1RDUCB2ZXJz dXMgUVVJQyAoaS5lLiBob3cgbXVjaCBhcmUgdGhlIHNtYWxsZXIgdW5pdHMgb2YgZW5jcnlwdGlv biBodXJ0aW5nIHVzIHZlcnN1cywgc2F5LCAxNktCIFRMUyByZWNvcmRzKT88dT48L3U+PHU+PC91 Pg0KPHVsIHR5cGU9ImNpcmNsZSIgc3R5bGU9Im1hcmdpbi10b3A6MGluIj4NCjxsaSBjbGFzcz0i bV8tOTAwNDkxNzE0OTQwNTU5NDE0M01zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW4iPlRMUyBpbXBsZW1lbnRhdGlvbnMgYWxyZWFkeSB2YXJ5IGhlcmU6Jm5ic3A7IFNvbWUg aW1wbGVtZW50YXRpb25zIGNob29zZSBsYXJnZSByZWNvcmQgc2l6ZXMsIHNvbWUgdmFyeSByZWNv cmQgc2l6ZXMgdG8gcmVkdWNlIGRlbGF5IC8gSG9MQiwgc28gdGhpcyBwcm9iYWJseSBpc27igJl0 IGEgc2luZ2xlIG51bWJlci48dT48L3U+PHU+PC91PjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNz PSJtXy05MDA0OTE3MTQ5NDA1NTk0MTQzTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbiI+SG93IG11Y2ggYWRkaXRpb25hbCBsb2FkIGRvZXMgUE5FIGFkZCB0byB0aGlzIGRp ZmZlcmVuY2U/PHU+PC91Pjx1PjwvdT48L2xpPjxsaSBjbGFzcz0ibV8tOTAwNDkxNzE0OTQwNTU5 NDE0M01zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPlRvIHdoYXQgZXh0 ZW50IHdvdWxkIFBORSBtYWtlIGZ1dHVyZSBjcnlwdG8gb2ZmbG9hZHMNCjxpPmltcG9zc2libGU8 L2k+IHZlcnN1cyA8aT5yZXF1aXJlcyBtb3JlIFImYW1wO0QgdG8gZGV2ZWxvcDwvaT4/PHU+PC91 Pjx1PjwvdT48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+ PC91PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTsgYm9yZGVyLXRvcDpzb2xp ZCAjZTFlMWUxIDEuMHB0OyBwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwv YT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48YnI+DQo8 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDE4IDE6MzQgUE08YnI+DQo8Yj5Ubzo8 L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2Yj08YSBocmVmPSJtYWlsdG86NDBt aWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBtaWNyb3NvZnQu Y29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs7IElFVEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBu ZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8ZGl2IGlk PSJtXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3Igc2hhcmluZyB0aGVzZSBudW1i ZXJzLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tOTAwNDkx NzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9Im1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TXkgZ3Vlc3MgaXMgdGhhdCB0aGVz ZSBvZmZsb2FkcyBkZWFsIHdpdGgga2VybmVsIHNjaGVkdWxpbmcsIG1lbW9yeSBjYWNoZSBpc3N1 ZXMsIGFuZCBpbnRlcnJ1cHQgc2NoZWR1bGluZy48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9Im1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PHU+PC91PiZuYnNwOzx1 PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy05MDA0OTE3MTQ5NDA1NTk0MTQz Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPkl0IHByb2JhYmx5IGhhcyB2ZXJ5IGxpdHRsZSB0byBkbyB3aXRoIGNyeXB0bywgVENQIGhl YWRlcnMsIGFuZCBhbnkgb3RoZXIgY3B1IHNlbnNpdGl2ZSBwcm9jZXNzaW5nLjx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Js b29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTkw MDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBpcyB3aGVyZSBuZXRtYXAgZW50ZXJzOiB5b3UgY2Fu IHRyYW5zcGFyZW50bHkgZmVlZCB0aGUgZGF0YSBhcyBpdCBiZWNvbWVzIGF2YWlsYWJsZSB3aXRo IHZlcnkgbGl0dGxlIHN5bmMgd29yayBhbmQgeW91IGNhbiBhbHNvIGVmZmljaWVudGx5IHBpcGVs aW5lIHNvIHlvdSBwYXNzIGRhdGENCiB0byBkZWNyeXB0b3IsIHRoZW4gdG8gYXBwLCB3aXRoIGFz IGxpdHRsZSBidXMgdHJhZmZpYyBhcyBwb3NzaWJsZS4gTm8gbmVlZCB0byBjb3B5IGRhdGEgb3Ig c3luY2hyb25pemUga2VybmVsIHNwYWNlLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0ibV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48dT48L3U+Jm5ic3A7PHU+PC91 Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9v cF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Rm9yIDFLIHBhY2tldHMgeW91IHdvdWxkIHVzZSBhYm91dCAxMDAwbnMgKDMgY3ljbGVzL2J5dGUp IG9uIGNyeXB0byBhbmQgdGhpcyB3b3VsZCBoYXBwZW4gaW4gTDEgY2FjaGUuIEl0IHdvdWxkIG9m IGNvdXJzZSBjb25zdW1lIGEgY29yZSB3aGljaCBhIGNyeXB0byBvZmZsb2FkIHdvdWxkIG5vdCwN CiBidXQgdGhhdCBjYW4gYmUgZGViYXRlZCBiZWNhdXNlIHdpdGggMTggY29yZSBzeXN0ZW1zLCB5 b3VyIHByb2JsZW0gaXMgbWVtb3J5IGFuZCBuZXR3b3JrIG1vcmUgdGhhbiBDUFUuPHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy05MDA0OTE3MTQ5NDA1NTk0MTQz Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8t OTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5NeSBjb25jZXJuIHdpdGggUE5FIGlzIGZvciBzbWFsbCBw YWNrZXRzIGFuZCBsb3cgbGF0ZW5jeSB3aGVyZTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0ibV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4xKSBhbiBlc3RpbWF0ZWQg MjRucyBmb3IgUE4gZW5jcnlwdGlvbiBhbmQgZGVjcnlwdGlvbiBiZWNvbWVzIG1lYXN1cmFibGUg aWYgeW91ciBuZXR3b3JrIGlzIGZhc3QgZW5vdWdoLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0ibV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yKSBhbnkgZGFtYWdl IHRvIHRoZSBwYWNrZXQgYnVmZmVyIGNhdXNlIGFsbCBzb3J0cyBvZiBtZW1vcnkgYW5kIGNwdSBi dXMgdHJhZmZpYyBpc3N1ZXMuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJtXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3Rv bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4xKSBpcyBh bm5veWluZy4gMikgaXMgYmFkLCBjb21wbGV0ZWx5IGF2b2lkYWJsZSBidXQgbm90IGFzIFBSIDEw NzkgaXMgZm9ybXVsYXRlZCBjdXJyZW50bHkuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJtXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjx1PjwvdT4mbmJzcDs8dT48 L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Js b29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4yKSBpcyBhbHNvIGxpa2VseSBiYWQgZm9yIGhhcmR3YXJlIG9mZmxvYWQgdW5pdHMgYXMgd2Vs bC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTkwMDQ5MTcx NDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFzIHRvIFNSVi1JTyAtIEni gJltIG5vdCBmYW1pbGlhciB3aXRoIGl0LCBidXQgb2J2aW91c2x5IHRoZXJlIGlzIHNvbWUgSU8g YWJzdHJhY3Rpb24gbGF5ZXIgLSB0aGUgcXVlc3Rpb24gaXMgaG93IHlvdSBtYWtlIGl0IGFjY2Vz c2libGUgdG8gYXBwcyBhcyBvcHBvc2VkIHRvIGRldmljZSBkcml2ZXJzDQogdGhhdCBkb2VzIG5v ciB3b3JrIHdpdGggeW91IFFVSUMgY3VzdG9tIHN0YWNrLCBhbmQgbmV0bWFwIGlzIG9uZSBvcHRp b24gaGVyZS48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+ DQo8ZGl2IGlkPSJtXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3Bfc2lnbl8xNTIyODczMzUwNDE1 MTIwMTI4Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PktpbmQgUmVnYXJkcyw8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjx1PjwvdT48dT48L3U+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJtXy05MDA0 OTE3MTQ5NDA1NTk0MTQzYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDQgQXByaWwg MjAxOCBhdCAyMi4xNS41MiwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gKDxhIGhyZWY9Im1haWx0 bzpwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5w cmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+KQ0KIHdyb3RlOjx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0OyBt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U29tZSBjb21wYXJhdGl2ZSBudW1iZXJzIGZyb20g YW4gb3V0IG9mIGJveCBkZWZhdWx0IHNldHRpbmdzIFdpbmRvd3MgU2VydmVyIDIwMTYgKHJlbGVh c2VkIHZlcnNpb24pIGZvciBhIHNpbmdsZSBjb25uZWN0aW9uIHdpdGggYSBtaWNyb2JlbmNobWFy ayB0b29sOjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHRhYmxl IGNsYXNzPSJtXy05MDA0OTE3MTQ5NDA1NTk0MTQzTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOmNv bGxhcHNlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5 bGU9IndpZHRoOjExNi44NXB0OyBib3JkZXI6c29saWQgIzk5OTk5OSAxLjBwdDsgYm9yZGVyLWJv dHRvbTpzb2xpZCAjNjY2NjY2IDEuNXB0OyBwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PZmZsb2FkcyBlbmFi bGVkPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwv cD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYu OXB0OyBib3JkZXItdG9wOnNvbGlkICM5OTk5OTkgMS4wcHQ7IGJvcmRlci1sZWZ0Om5vbmU7IGJv cmRlci1ib3R0b206c29saWQgIzY2NjY2NiAxLjVwdDsgYm9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5 OTkgMS4wcHQ7IHBhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRDUCBnYnBzPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1 NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0OyBib3JkZXItdG9wOnNvbGlkICM5 OTk5OTkgMS4wcHQ7IGJvcmRlci1sZWZ0Om5vbmU7IGJvcmRlci1ib3R0b206c29saWQgIzY2NjY2 NiAxLjVwdDsgYm9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7IHBhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPlVEUCBnYnBzPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0i dG9wIiBzdHlsZT0id2lkdGg6MTE2Ljg1cHQ7IGJvcmRlcjpzb2xpZCAjOTk5OTk5IDEuMHB0OyBi b3JkZXItdG9wOm5vbmU7IHBhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkxTTyAmIzQzOyBMUk8gJiM0MzsgY2hl Y2tzdW08L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjEx Ni45cHQ7IGJvcmRlci10b3A6bm9uZTsgYm9yZGVyLWxlZnQ6bm9uZTsgYm9yZGVyLWJvdHRvbTpz b2xpZCAjOTk5OTk5IDEuMHB0OyBib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDsgcGFk ZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+MjQ8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRo PSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2LjlwdDsgYm9yZGVyLXRvcDpub25l OyBib3JkZXItbGVmdDpub25lOyBib3JkZXItYm90dG9tOnNvbGlkICM5OTk5OTkgMS4wcHQ7IGJv cmRlci1yaWdodDpzb2xpZCAjOTk5OTk5IDEuMHB0OyBwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40 cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 IGZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4zLjY8dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB3aWR0aD0iMTU2IiB2 YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi44NXB0OyBib3JkZXI6c29saWQgIzk5OTk5OSAx LjBwdDsgYm9yZGVyLXRvcDpub25lOyBwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5DaGVja3N1bSBvbmx5PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwv dGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0OyBi b3JkZXItdG9wOm5vbmU7IGJvcmRlci1sZWZ0Om5vbmU7IGJvcmRlci1ib3R0b206c29saWQgIzk5 OTk5OSAxLjBwdDsgYm9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7IHBhZGRpbmc6MGlu IDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPjcuNjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIg dmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0OyBib3JkZXItdG9wOm5vbmU7IGJvcmRl ci1sZWZ0Om5vbmU7IGJvcmRlci1ib3R0b206c29saWQgIzk5OTk5OSAxLjBwdDsgYm9yZGVyLXJp Z2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7IHBhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjMuNjx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0i dG9wIiBzdHlsZT0id2lkdGg6MTE2Ljg1cHQ7IGJvcmRlcjpzb2xpZCAjOTk5OTk5IDEuMHB0OyBi b3JkZXItdG9wOm5vbmU7IHBhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk5vbmU8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0i MTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7IGJvcmRlci10b3A6bm9uZTsg Ym9yZGVyLWxlZnQ6bm9uZTsgYm9yZGVyLWJvdHRvbTpzb2xpZCAjOTk5OTk5IDEuMHB0OyBib3Jk ZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDsgcGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+NS42PHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5 bGU9IndpZHRoOjExNi45cHQ7IGJvcmRlci10b3A6bm9uZTsgYm9yZGVyLWxlZnQ6bm9uZTsgYm9y ZGVyLWJvdHRvbTpzb2xpZCAjOTk5OTk5IDEuMHB0OyBib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5 OSAxLjBwdDsgcGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Mi4zPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIGZvciBhIGZ1bGx5IGJvdHRs ZW5lY2tlZCBDUFUgY29yZSAtLQ0KPGk+aWYgeW91IHJ1biBsb3dlciBkYXRhIHJhdGVzIHRoZXJl IGlzIHN0aWxsIGEgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZSBpbiBDeWNsZXMvYnl0ZSBjb3N0PC9p Pi4gU2FtZSBpbmNyZWFzZWQgQ1BVIGNvc3QgYXBwbGllcyBmb3IgY2xpZW50IHN5c3RlbXMgZ29p bmcgb3ZlciBoaWdoIGRhdGEgcmF0ZSBXaWZpIGFuZCBjZWxsdWxhci4NCjx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5UaGlzIGlzIHdpdGhvdXQgYW55IGNyeXB0by4gT25jZSB5b3UgYWRkIGNy eXB0byB0aGUgbnVtYmVycyBiZWNvbWUgbXVjaCB3b3JzZQ0KPGk+d2l0aCBjcnlwdG8gY29zdCBi ZWNvbWluZyBkb21pbmFudDwvaT4uIEFkZGluZyBhbm90aGVyIGNyeXB0byBzdGVwIGZ1cnRoZXIg ZXhhY2VyYmF0ZXMgdGhlIHByb2JsZW0uIEhlbmNlIGNyeXB0byBvZmZsb2FkIGdhaW5zIGluIGlt cG9ydGFuY2UgZm9sbG93ZWQgYnkgdGhlc2UgYmF0Y2ggb2ZmbG9hZHMuPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPklmIGZvbGtzIG5lZWQgYW55IG1vcmUgbnVtYmVycyBJ4oCZZCBiZSBoYXBw eSB0byBwcm92aWRlIHRoZW0uPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rczx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DB6PR10MB1766789B25E31EBE70564BD3ACBA0DB6PR10MB1766EURP_-- From nobody Thu Apr 5 22:08:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246C8127867 for ; Thu, 5 Apr 2018 22:08:39 -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, FREEMAIL_FROM=0.001, 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=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 0IZRmV3lEHUx for ; Thu, 5 Apr 2018 22:08:36 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 C785912783A for ; Thu, 5 Apr 2018 22:08:36 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id o16so4754637pfk.9 for ; Thu, 05 Apr 2018 22:08:36 -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=njlppaPVfnMjAKO6+zY28b0cMFdfPY01KE7zR9TKvzU=; b=KfcoR3pNKRJ3apN1UGLdVZxtN+0ughGCayLk2uJl9ZbTHKzsskqFEar9//OWsVOPtv nlu2vrf6p223kTuNu3zjeKYXdffA5J6PVjlxjQDm0rO4aL/WvLAHHMteKSyip/81XOMl xVjPA7YCtLg5KbmbCm8BKLn8GyovRVDSH5awvPiPFfJszswtr41bclD+YiRdRP1DjHHz iSke9yh1PWj5rJfbhMYZo+sF1jqNQZtFeilw0JfXZ+nbN3wb0e9xDf9pHyeGBwW8VprT CIvDPpEjtJrdCkJxDqHGSBGCYWCulIJy0L7hjDkcG0kIrYm3CBEBB2YsFHgs62cIDrbf HXhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=njlppaPVfnMjAKO6+zY28b0cMFdfPY01KE7zR9TKvzU=; b=tc/C+V1kLYqhnrS1osAmduallJO5AVtdRD0bvMA+4C/r2gzYueOvfLysotgo2fQZKP BPEyO4CzmY9zXF/UaHy4gqTnwoJ1LEGk07GMnMHz85a8TtSOsYOCBcUYfSMYugoixIAA QOZ6oG1PVGifroKPKOBMmGDuejRKPUbqjHGzP5HydLwQF2CIjYYdEEn6D1Fh9L0wb0zR lmuNBMPc+74dFkofoqsPtc5ZUPRmAjIUAWjIKqMrBISyRk3lSjNOG6Wuil08rqgbTgV6 3Gj1W7+CRnNYrp8jWxAMGHO9UNU+IbkCXL/bUos2nZIgCObFaZeU5I20TLXpztch9ftX aMuA== X-Gm-Message-State: AElRT7FxvagUD1LjeAC01au1/mTt37zvkIeuHmXAXo/3XcmWhan+yG0P xBMH/pCsmlNUjsFyZqJu0MRxO21SnfnBczSK8r8= X-Google-Smtp-Source: AIpwx49Pqv/8DYDshe6Dy8RsWvUvI3ngYPkv4Y6ewM3EK+6Q04NgMUXD+nXCPD6aV9IBAeiQ3MjqfLBwPqYhnwRRO+s= X-Received: by 10.98.139.143 with SMTP id e15mr19446241pfl.134.1522991316289; Thu, 05 Apr 2018 22:08:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Thu, 5 Apr 2018 22:08:35 -0700 (PDT) In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <65cf3a3009944ca288a0cd6768d09339@usma1ex-dag1mb5.msg.corp.akamai.com> From: Kazuho Oku Date: Fri, 6 Apr 2018 14:08:35 +0900 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: "Lubashev, Igor" , "mirja.kuehlewind@tik.ee.ethz.ch" , "huitema@huitema.net" , "quic@ietf.org" , "martin.thomson@gmail.com" , "fkautz@alumni.cmu.edu" Content-Type: multipart/alternative; boundary="f403045c2f4067503a0569270cdd" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 05:08:39 -0000 --f403045c2f4067503a0569270cdd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-04-06 13:33 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen : > So eventually CID=E2=80=99s will ossify into certain lenghts by conventio= n to > things working smoothly in the general case? > That is a good point, but I think that the answer is no. In the long header format, the lengths of CID's are sent in clear in the latest working version of the draft. And if I recall correctly, people are interested in greasing the CID lengths by advertising CIDs longer than necessary against a minor portion of the clients. We assume that the shortest length of CID is zero, and an endpoint that uses a zero-length CID can grease it to any length. To summarize, we will be greasing CID length regardless of if we include it as part of the short header. > ------------------------------ > *From:* QUIC on behalf of Kazuho Oku < > kazuhooku@gmail.com> > *Sent:* Friday, April 6, 2018 6:02:23 AM > *To:* Lubashev, Igor > *Cc:* mirja.kuehlewind@tik.ee.ethz.ch; huitema@huitema.net; quic@ietf.org= ; > martin.thomson@gmail.com; fkautz@alumni.cmu.edu > > *Subject:* Re: Privacy holes (was: Re: Getting to consensus on packet > number encryption) > > > > 2018-04-06 12:48 GMT+09:00 Lubashev, Igor : > >> > The length of DCID can be a signal to the stateless load balancers. >> >> Short headers do not have an explicit CID length, so we are back to >> validating the integrity of CID, no? What am I missing? >> > > Yeah I missed that, apparently. Thank you for pointing that out. > > So I would propose to encrypt the type bits _and_ have DCID length in the > header in cleartext. > > By doing that, it will still be possible for stateless load balancers to > determine if a packet is initial (by checking if DCIL is 8) without > decrypting the packet, at the same time being impossible for a middlebox = to > reliably determine the same thing (assuming that some servers will > advertise DCID of 8 octets). > > >> >> >> -----Original Message----- >> *From:* Kazuho Oku [kazuhooku@gmail.com] >> *Received:* Thursday, 05 Apr 2018, 10:56PM >> *To:* Martin Thomson [martin.thomson@gmail.com] >> *CC:* Mirja K=C3=BChlewind [mirja.kuehlewind@tik.ee.ethz.ch]; QUIC WG [ >> quic@ietf.org]; Christian Huitema [huitema@huitema.net]; Frederick Kautz >> [fkautz@alumni.cmu.edu ] >> *Subject:* Re: Privacy holes (was: Re: Getting to consensus on packet >> number encryption) >> >> Hi Martin, >> >> Thank you for the response.. My comments inline. >> >> 2018-04-06 11:34 GMT+09:00 Martin Thomson : >> >>> On Fri, Apr 6, 2018 at 12:06 PM, Kazuho Oku wrote= : >>> > If I understand correctly, Christian's concern is that some middlebox= es >>> > might only create a hole if the first packet sent by a client (using = a >>> new >>> > port) looks like a Initial packet. >>> >>> Oh, I didn't get the same impression, but it does seem like a valid >>> concern. The idea I had was to have clients migrate often enough that >>> those middleboxes will see those migrations and not incorrectly assume >>> that flows have to start with Initial packets. >>> >>> Of course, migrating often like this might not provide enough >>> incentive to avoid that practice because clients will likely make new >>> connections when the old one fails. But given that this sort of >>> failure probably involves a timeout before the repair, it's probably >>> still noticeable enough to generate support tickets (and incentive to >>> allow the migration to pass). >>> >>> Existing middleboxes that pass UDP will be fine, so we at least have >>> that in our favour. >>> >>> > 1. frequent gratuitous migration by clients, so that middlebox vendor= s >>> can >>> > notice that there design is wrong prior to shipping it >>> >>> That is what this was angling for. The question being how frequent. >>> >>> > 3. mimic 0-RTT handshake when gratuitously switching to a new UDP flo= w >>> > (depends on #1262) >>> > >>> > 1 and 2 have been discussed on this thread. I haven't yet seen 3 bein= g >>> > discussed. >>> >>> It has been suggested a few times elsewhere. The question is how far >>> you go: do you send Initial and Handshake packets that use the >>> handshake packet protection and carry apparently real ClientHello and >>> ServerHello messages? Do you restrict the flow of packets to match >>> 0-RTT? >>> >>> > The concerns so far being raised for 1 is that NATs might run out of >>> > unassigned ports and that switching to a new path might trigger the >>> restart >>> > of congestion control on large-scale NATs that use multiple public >>> > addresses. >>> >>> That is possible, but it depends on how often you attempt this. CGNAT >>> does try to keep IP addresses for the same device stable. If not, >>> then a congestion controller reset for relatively infrequent >>> migrations isn't so bad if heuristics fail. It's only when you have >>> very frequent migration that the resets becomes burdensome. >>> >> >> How frequent is the issue here. >> >> If it's too frequent, some NATs could run out of unassigned ports, and i= f >> depending on their eviction algorithm, shutdown UDP-based flows running >> other protocols that do not do gratuitous switching. Other NATs could st= art >> assigning new public addresses as they run out of unassigned ports. >> >> If it's too infrequent, then the chance of seeing misimplemented >> middlebox becomes higher. >> >> >>> > The concern so far being raised for 2 is that stateless load balancer= s >>> would >>> > be required to decrypt the type field (or the entire packet, dependin= g >>> on >>> > how we encrypt) to determine if a packet is trying to initiate a new >>> > connection. >>> >>> Yeah, that's hard. Having the load balancer hit the slow path for >>> every packet seems pretty fatal. >>> >> >> That was my understanding until I started to consider the impact of >> symmetric CIDs. >> >> The length of DCID can be a signal to the stateless load balancers for >> distinguishing an initial packet. If people interested in using that typ= e >> of load balancer can agree that they will be using CID other than 8 octe= ts, >> the length can be used as the signal by them. >> >> More detail about using DCID can be found on >> https://www.ietf.org/mail-archive/web/quic/current/msg03809.html >> >> . >> >> -- >> Kazuho Oku >> > > > > -- > Kazuho Oku > --=20 Kazuho Oku --f403045c2f4067503a0569270cdd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-04-06 13:33 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkel= fj@gmail.com>:
So eventually CID=E2=80=99s will ossify into c= ertain lenghts by convention to things working smoothly in the general case= ?

That is a g= ood point, but I think that the answer is no.

In t= he long header format, the lengths of CID's are sent in clear in the la= test working version of the draft. And if I recall correctly, people are in= terested in greasing the CID lengths by advertising CIDs longer than necess= ary against a minor portion of the clients. We assume that the shortest len= gth of CID is zero, and an endpoint that uses a zero-length CID can grease = it to any length.

To summarize, we will be greasin= g CID length regardless of if we include it as part of the short header.


From:= QUIC <quic-b= ounces@ietf.org> on behalf of Kazuho Oku <kazuhooku@gmail.com>
Sent: Friday, April 6, 2018 6:02:23 AM
To: Lubashev, Igor
Cc: mirja.kuehlewind@tik.ee.ethz.ch; huitema@huitema.net; quic@ietf.org; martin.thomson@gmail.com; fkautz@alumni.cmu.edu

Subject: Re: Privacy holes (was: Re: Getting to consensus on packet = number encryption)
=C2=A0


2018-04-06 12:48 GMT+09:00 Lubashev, Igor <ilubashe@akama= i.com>:
> The length of DCID can be a signal to the stateles= s load balancers.

Short headers do not have an explicit CID length, so we are back to validat= ing the integrity of CID, no? What am I missing?

Yeah I missed that, apparently. Thank you for pointing that out.

So I would propose to encrypt the type bits _and_ have DCID length in = the header in cleartext.

By doing that, it will still be possible for stateless load balancers = to determine if a packet is initial (by checking if DCIL is 8) without decr= ypting the packet, at the same time being impossible for a middlebox to rel= iably determine the same thing (assuming that some servers will advertise DCID of 8 octets).
=C2=A0=C2=A0


-----Original Message-----
From: Kazuho Oku [kazuhooku@gmail.com]
Received: Thursday, 05 Apr 2018, 10:56PM
To: Martin Thomson [martin.thomson@gmail.com]
CC: Mirja K=C3=BChlewind [mirja.kuehlewind@tik.ee.ethz.ch]; QUIC = WG [quic@ietf.org]; = Christian Huitema [huitema@huitema.net]; Frederick Kautz [fkautz@alumni.cmu.edu]
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet = number encryption)
Hi Martin,

Thank you for the response.. My comments inline.=

2018-04-06 11:34 GMT+09:00 Martin Thomson <martin.th= omson@gmail.com>:
On Fri, = Apr 6, 2018 at 12:06 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
> If I understand correctly, Christian's concern is that some middle= boxes
> might only create a hole if the first packet sent by a client (using a= new
> port) looks like a Initial packet.

Oh, I didn't get the same impression, but it does seem like a va= lid
concern.=C2=A0 The idea I had was to have clients migrate often enough that=
those middleboxes will see those migrations and not incorrectly assume
that flows have to start with Initial packets.

Of course, migrating often like this might not provide enough
incentive to avoid that practice because clients will likely make new
connections when the old one fails.=C2=A0 But given that this sort of
failure probably involves a timeout before the repair, it's probably still noticeable enough to generate support tickets (and incentive to
allow the migration to pass).

Existing middleboxes that pass UDP will be fine, so we at least have
that in our favour.

> 1. frequent gratuitous migration by clients, so that middlebox vendors= can
> notice that there design is wrong prior to shipping it

That is what this was angling for.=C2=A0 The question being how freq= uent.

> 3. mimic 0-RTT handshake when gratuitously switching to a new UDP flow=
> (depends on #1262)
>
> 1 and 2 have been discussed on this thread. I haven't yet seen 3 b= eing
> discussed.

It has been suggested a few times elsewhere.=C2=A0 The question is h= ow far
you go: do you send Initial and Handshake packets that use the
handshake packet protection and carry apparently real ClientHello and
ServerHello messages?=C2=A0 Do you restrict the flow of packets to match 0-RTT?

> The concerns so far being raised for 1 is that NATs might run out of > unassigned ports and that switching to a new path might trigger the re= start
> of congestion control on large-scale NATs that use multiple public
> addresses.

That is possible, but it depends on how often you attempt this.=C2= =A0 CGNAT
does try to keep IP addresses for the same device stable.=C2=A0 If not,
then a congestion controller reset for relatively infrequent
migrations isn't so bad if heuristics fail.=C2=A0 It's only when yo= u have
very frequent migration that the resets becomes burdensome.

How frequent is the issue here.

If it's too frequent, some NATs could run out of unassigned ports,= and if depending on their eviction algorithm, shutdown UDP-based flows run= ning other protocols that do not do gratuitous switching. Other NATs could = start assigning new public addresses as they run out of unassigned ports.

If it's too infrequent, then the chance of seeing misimplemented m= iddlebox becomes higher.


> The concern so far being raised for 2 is that stateless load balancers= would
> be required to decrypt the type field (or the entire packet, depending= on
> how we encrypt) to determine if a packet is trying to initiate a new > connection.

Yeah, that's hard.=C2=A0 Having the load balancer hit the slow p= ath for
every packet seems pretty fatal.

That was my understanding until I started to consider the impact of symmetr= ic CIDs.

The length of DCID can be a signal to the statel= ess load balancers for distinguishing an initial packet. If people interest= ed in using that type of load balancer can agree that they will be using CI= D other than 8 octets, the length can be used as the signal by them.


--
= Kazuho Oku



--
Kazuho Oku



--
Kazuho Oku
--f403045c2f4067503a0569270cdd-- From nobody Fri Apr 6 00:16:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79F2126CE8 for ; Fri, 6 Apr 2018 00:16:38 -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 YK7kX4-Mp1uU for ; Fri, 6 Apr 2018 00:16:36 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3792E126C26 for ; Fri, 6 Apr 2018 00:16:36 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id D4A65340D7A; Fri, 6 Apr 2018 09:16:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.14077); Fri, 6 Apr 2018 09:16:33 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri, 6 Apr 2018 09:16:33 +0200 (CEST) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50820116; Fri, 06 Apr 2018 09:16:33 +0200 From: "Brian Trammell (IETF)" Message-Id: <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_79C6A98C-4F4E-482F-92F3-9F85EA4F530E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) Date: Fri, 6 Apr 2018 09:16:32 +0200 In-Reply-To: Cc: Christian Huitema , QUIC WG , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Frederick Kautz To: Martin Thomson References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 07:16:39 -0000 --Apple-Mail=_79C6A98C-4F4E-482F-92F3-9F85EA4F530E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (Repeating and expanding my comment on #1269 to the list) +1 to CID rotation being pointless if we don't do this. However, this = seems dangerous if not done carefully, and it links CID rotation rate to = the maximum usable UDP port consumption rate, which is (most probably) = widely variable across access networks and (AFAICT) largely unknown in = the literature. We have anecdata here, and we need data. Note that QUIC presently doesn't have an advisory on-path state = clearance signal (we hsd discussed this as a signal bound to public = reset in #20, but it morphed into Stateless Reset, which has completely = different semantics), which means that there is neither a present nor = yet a potential future method to reduce the NAT state load this will = generate. I'd feel a lot less apprehensive about this if there were an advisory, = integrity-protected signal meant for path consumption to clear state for = a path. Of course it wouldn't be used at all on day one, but the = tradeoff it presents is "hey, this is QUIC, it will burn through your = UDP port state faster than any other UDP protocol and multiplicatively = faster than TCP; but hey look, you can clear state when you see this = path-verifiable singal to reduce the impact this has." Cheers, Brian > On 6 Apr 2018, at 02:38, Martin Thomson = wrote: >=20 > On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema = wrote: >>> On Apr 5, 2018, at 8:58 AM, Frederick Kautz = wrote: >>>=20 >>> Are you concerned that middleware boxes may be trained to reject = migrations, thereby forcing a new connection with a visible negotiation? >>=20 >> Yes. Hence the need to grease. For example, have clients do some = gratuitous migration to a new source port number rather frequently. >=20 > This seems like a simple fix, particularly since Mike recently added > text that suggests occasional use of new connection IDs. In the > spirit of keeping the wheels greased: >=20 > https://github.com/quicwg/base-drafts/pull/1269 >=20 --Apple-Mail=_79C6A98C-4F4E-482F-92F3-9F85EA4F530E 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlrHHtAACgkQihK3vwvq RqOVzw/+Muh9JIl/QS9Q6UIuWKKSM8UihCPEwfj6RsDNZfH069CMVwRQ/IttJs0u 8FmKXlk8wqfK21puo0qm5v9wT2+RaCoDh55QRFfD90Tia+TGwojaMJHp70kz92cV pJBW8okC+uioTF6h8nBUP1uP70WJsSFxDCprC4TQ+U1WIU1PNbkwKF3DUKfV1Sf9 zMHxh7e91Oo7Fx/H+InWbnDBGesZIcNa+5fh0n2/Lpd4mC+UYPdg3tOWkqATvR8M J26de25hSw1FAEcNJN4uZlZuaEsy1VubohRPMjN8FHCSB+o4XIZany6lO5FWGeN0 SiB1NoLpH9rSAcmtqwXUJQj64zcljovk5K/MxTe+2SXVi4YBINN6DM6hrQ1fuTyb oi5bHsfU/6vD7hXJmhw1CAws5BaE5sNxt24SoGzfMDQomqWk01sfZgMOFvLlChvH yH/jzaB+MrM9gT30nZeGi4OXJjLnAlV2Gm6BLNHgNxxZOPS9d/HYCIHZQQqkvFck 08V7gPLvKGPY3Uny06JH8D68gahCKdIaMPCz5EEa3Hdn9YzDemXvk2QOBQVe9+vA tUzB3olCgIcuKN2xRIB4lqvKwRYrTmk0hV7Crcy4k3AWu2yq/afDM6z/ZzLAetSk Gkn80zoDCTAOdcDiKENSVONkzUPL8DJtfz9czj1Z47LEIT/vYU0= =ssiV -----END PGP SIGNATURE----- --Apple-Mail=_79C6A98C-4F4E-482F-92F3-9F85EA4F530E-- From nobody Fri Apr 6 00:45:10 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48862128961 for ; Fri, 6 Apr 2018 00:45: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 6R3Bg7QWy0gK for ; Fri, 6 Apr 2018 00:45:07 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE76212426E for ; Fri, 6 Apr 2018 00:45:06 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id f63-v6so243374oic.4 for ; Fri, 06 Apr 2018 00:45: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:content-transfer-encoding; bh=d79hz63rTVm+OVRGbcn65DimbRP3voQYMEjaCqnGuko=; b=pwVayTsg06td5Gc4k7Ekv/Zjpjgz+XZqELGcCARKlLDYKsDLAQeapQD+KBorHVgBOR qIraLWJus2JMky9SpCIh5uVef+DAJ4aXcbCHKfOPbEk1PaESN6YNByEjW64kK1j1dmUx LQK7Jn/IXlgo3MIgDSEC4jLnScVUMArkx+wKbydcFczRteWJHz5y3jCEgSxjNdjY7FkL nDUNiZsJaquin4eu7eaeupT1Qn0mQu+NIce/+JL8mBpryLDlQ32WYbFL0fIas08XnwNU FlhLaPy+EuNxEMGlPIp3PwVwcT+a1rty+q3F/OABdy3TgndZFeW1TycNVPffu1ixqPh0 0tuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=d79hz63rTVm+OVRGbcn65DimbRP3voQYMEjaCqnGuko=; b=nBA3jnTeWBZBIxXY8vwD2XYbMemHNSVSDKy8OZoDkqzLrhI4BMP8RakISnPT10jyT5 IceQQH8VODbKC95BsG0HxQ0khl4GcvpN0hVMfFRlOLBl1Q7d/8lPn2lVFtMAgfkxLMZD zJP1SnkP48JrkgeJ7SVB1jmP6p7DajkfeSsKswhob4PcJmc4ViWGUbbZAiA7e7J38dUJ LTsuQvu3pckFZh+kBzDUPs1oNgHAmwqzwmzhqLkQkekiq8biqEsaSElPO3xTXWlJvc1l 609GFr28EJ6GURr1BwBG5hHHBbRIwWI3WCnpMyfNUDi9kJlChHQTo8wgC2btHAZIqrYb WTeg== X-Gm-Message-State: ALQs6tBlWKPrCzgIFWGxPAkz38k/nbqWs+TZ1UzKQj1s7AISYmUdTnOi N17J3RVH/ucs2uyyaYnvgcHKgC1CmXE/Moe1A88= X-Google-Smtp-Source: AIpwx4+y28HGFjT7Tyg9nY+ZLXqOFBAwtN56mtZSzyb5R98O0/vck7jWHbOm0R+1KbQRe+lDISKvBpdxNkad6/jrXCI= X-Received: by 2002:aca:ebd1:: with SMTP id j200-v6mr15375723oih.110.1523000706078; Fri, 06 Apr 2018 00:45:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Fri, 6 Apr 2018 00:45:05 -0700 (PDT) In-Reply-To: <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch> From: Martin Thomson Date: Fri, 6 Apr 2018 17:45:05 +1000 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: "Brian Trammell (IETF)" Cc: Christian Huitema , QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Frederick Kautz 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: Fri, 06 Apr 2018 07:45:09 -0000 We do have data about rate of binding creation, courtesy of tests done for WebRTC. In essence, bindings can be created at rates that exceed most needs (I think that they went down to single digit milliseconds, far lower than I think is relevant here). Justin Uberti has the numbers, but I struggled to find the email or slides; we can ask if you care. This result differed from the data that was available when STUN was first developed, where it was found that there were non-trivial numbers of NAT devices that lost bindings below 20ms (see https://tools.ietf.org/html/rfc5245#appendix-B.1). The question about exhaustion is relevant, I agree. There, the value doesn't need measurement as much as asking the right person what their configuration is. Take the number of ports open for bindings per IP, the duration of a binding, and how many clients are expected to be behind each IP address or how many bindings each client is limited to. We'd probably need to just ask a few CGNAT operators; anything smaller is unlikely to be as sensitive as something that runs at a decent scale. But getting data in the usual fashion - making bindings until something breaks - might be a little antisocial. If we're going to saturate NAT bindings with this, then a signal might be a good solution. Or it might just be that we can recommend a rate limit on these little migrations. Based on typical timeouts on UDP (30s is very common, see also experience with ICE), we could say that a little migration every 10s is OK and you only have each connection taking 3 bindings. That doesn't seem that bad. On Fri, Apr 6, 2018 at 5:16 PM, Brian Trammell (IETF) wr= ote: > (Repeating and expanding my comment on #1269 to the list) > > +1 to CID rotation being pointless if we don't do this. However, this see= ms dangerous if not done carefully, and it links CID rotation rate to the m= aximum usable UDP port consumption rate, which is (most probably) widely va= riable across access networks and (AFAICT) largely unknown in the literatur= e. We have anecdata here, and we need data. > > Note that QUIC presently doesn't have an advisory on-path state clearance= signal (we hsd discussed this as a signal bound to public reset in #20, bu= t it morphed into Stateless Reset, which has completely different semantics= ), which means that there is neither a present nor yet a potential future m= ethod to reduce the NAT state load this will generate. > > I'd feel a lot less apprehensive about this if there were an advisory, in= tegrity-protected signal meant for path consumption to clear state for a pa= th. Of course it wouldn't be used at all on day one, but the tradeoff it pr= esents is "hey, this is QUIC, it will burn through your UDP port state fast= er than any other UDP protocol and multiplicatively faster than TCP; but he= y look, you can clear state when you see this path-verifiable singal to red= uce the impact this has." > > Cheers, > > Brian > >> On 6 Apr 2018, at 02:38, Martin Thomson wrote= : >> >> On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema = wrote: >>>> On Apr 5, 2018, at 8:58 AM, Frederick Kautz wr= ote: >>>> >>>> Are you concerned that middleware boxes may be trained to reject migra= tions, thereby forcing a new connection with a visible negotiation? >>> >>> Yes. Hence the need to grease. For example, have clients do some gratui= tous migration to a new source port number rather frequently. >> >> This seems like a simple fix, particularly since Mike recently added >> text that suggests occasional use of new connection IDs. In the >> spirit of keeping the wheels greased: >> >> https://github.com/quicwg/base-drafts/pull/1269 >> > From nobody Fri Apr 6 01:36:46 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E76128961 for ; Fri, 6 Apr 2018 01:36:45 -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 7llpB_aWZH3w for ; Fri, 6 Apr 2018 01:36:42 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A98126D74 for ; Fri, 6 Apr 2018 01:36:42 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C87EE340D70; Fri, 6 Apr 2018 10:36:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.12935); Fri, 6 Apr 2018 10:36:40 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri, 6 Apr 2018 10:36:40 +0200 (CEST) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50831713; Fri, 06 Apr 2018 10:36:39 +0200 From: "Brian Trammell (IETF)" Message-Id: <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_33932BA0-55B4-4982-9C4D-5311DA223E92"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) Date: Fri, 6 Apr 2018 10:36:38 +0200 In-Reply-To: Cc: Christian Huitema , QUIC WG , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Frederick Kautz To: Martin Thomson References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 08:36:45 -0000 --Apple-Mail=_33932BA0-55B4-4982-9C4D-5311DA223E92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 6 Apr 2018, at 09:45, Martin Thomson = wrote: >=20 > We do have data about rate of binding creation, courtesy of tests done > for WebRTC. In essence, bindings can be created at rates that exceed > most needs (I think that they went down to single digit milliseconds, > far lower than I think is relevant here). There are two relevant metrics here: binding creation rate and maximum = concurrent state. The latter is where I expect there to be more = variability, and potential unfortunate side effects of an engineering = decision made with a single consideration. "People stuck behind marginal = NATs outside their own control don't deserve to use QUIC" is not a great = statement to make, even accidentally. > Justin Uberti has the numbers, but I struggled to find the email or > slides; we can ask if you care. This result differed from the data > that was available when STUN was first developed, where it was found > that there were non-trivial numbers of NAT devices that lost bindings > below 20ms (see https://tools.ietf.org/html/rfc5245#appendix-B.1). This is useful, thanks! > The question about exhaustion is relevant, I agree. There, the value > doesn't need measurement as much as asking the right person what their > configuration is. Take the number of ports open for bindings per IP, > the duration of a binding, and how many clients are expected to be > behind each IP address or how many bindings each client is limited to. > We'd probably need to just ask a few CGNAT operators; anything smaller > is unlikely to be as sensitive as something that runs at a decent > scale. But getting data in the usual fashion - making bindings until > something breaks - might be a little antisocial. Agreed that CGNAT is where the highest pain magnitude will be, but there = is a very long tail of CPE out there, where configuration information = will be harder to come by. But that's why we have a TCP fallback, I = guess. > If we're going to saturate NAT bindings with this, then a signal might > be a good solution. Or it might just be that we can recommend a rate > limit on these little migrations. Based on typical timeouts on UDP > (30s is very common, see also experience with ICE), we could say that > a little migration every 10s is OK and you only have each connection > taking 3 bindings. That doesn't seem that bad. It's multiplicative by a factor of three, which means that the max flow = concurrency will reduce by a factor of three. I agree it's probably = tolerable, but we do need to understand what we're actually getting for = that cost. I remain dubious about the actual privacy benefits WRT third = party passive surveillance here -- they don't accrue at all unless = there's a CGNAT in the way that doesn't bind an address/port range to a = customer at a given point in time. In the common case, ISTM that just = burn more in-network state than they additionally require at the = surveillance point to track the change. Defenses with such scaling = curves are not a good idea. Another issue this raises: this will wreak varying levels havoc on = anything that uses IPFIX, NetFlow, sFlow, or similar technologies for = accounting or forensics. For accounting, whether two flow records happen = to represent the same flow is irrelevant, since they'll generally be = dumped into larger aggregates anyway. Replacing a single long-lived flow = (a common max active time is 30min) with its equivalent split into 10s = windows will lead to a 180x increase in export bandwidth for these flows = in the first stage of the collection infrastructure, but the flow counts = handled by these infrastructures (when connected to the open Internet) = are usually dominated by single-packet UDP and ICMP garbage anyway, so = this probably won't have too terrible an impact. Most such infrastructures are sampled (sFlow explicitly so), and there = are well-known issues with differential visibility of packet-sampled = flows based on flow duration. QUIC flows rotating ports every 10s would = be systematically undercounted with respect to long-duration TCP flows, = which will provide a strong incentive for correction if it materially = impacts settlement. Especially forensics for operational security will remain very = interested in understanding whether a group of 5-tuple flows are related = to the same activity. In most enterprise environments, though, any CGNAT = mappings are reversable, so there will not necessarily be a strong = incentive I want to like this proposal, but I'm increasingly left with the = impression that this is neither a particularly useful nor a completely = safe thing to do at scale. Cheers, Brian >=20 > On Fri, Apr 6, 2018 at 5:16 PM, Brian Trammell (IETF) = wrote: >> (Repeating and expanding my comment on #1269 to the list) >>=20 >> +1 to CID rotation being pointless if we don't do this. However, this = seems dangerous if not done carefully, and it links CID rotation rate to = the maximum usable UDP port consumption rate, which is (most probably) = widely variable across access networks and (AFAICT) largely unknown in = the literature. We have anecdata here, and we need data. >>=20 >> Note that QUIC presently doesn't have an advisory on-path state = clearance signal (we hsd discussed this as a signal bound to public = reset in #20, but it morphed into Stateless Reset, which has completely = different semantics), which means that there is neither a present nor = yet a potential future method to reduce the NAT state load this will = generate. >>=20 >> I'd feel a lot less apprehensive about this if there were an = advisory, integrity-protected signal meant for path consumption to clear = state for a path. Of course it wouldn't be used at all on day one, but = the tradeoff it presents is "hey, this is QUIC, it will burn through = your UDP port state faster than any other UDP protocol and = multiplicatively faster than TCP; but hey look, you can clear state when = you see this path-verifiable singal to reduce the impact this has." >>=20 >> Cheers, >>=20 >> Brian >>=20 >>> On 6 Apr 2018, at 02:38, Martin Thomson = wrote: >>>=20 >>> On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema = wrote: >>>>> On Apr 5, 2018, at 8:58 AM, Frederick Kautz = wrote: >>>>>=20 >>>>> Are you concerned that middleware boxes may be trained to reject = migrations, thereby forcing a new connection with a visible negotiation? >>>>=20 >>>> Yes. Hence the need to grease. For example, have clients do some = gratuitous migration to a new source port number rather frequently. >>>=20 >>> This seems like a simple fix, particularly since Mike recently added >>> text that suggests occasional use of new connection IDs. In the >>> spirit of keeping the wheels greased: >>>=20 >>> https://github.com/quicwg/base-drafts/pull/1269 >>>=20 >>=20 --Apple-Mail=_33932BA0-55B4-4982-9C4D-5311DA223E92 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlrHMZYACgkQihK3vwvq RqN+3w/+I7kHihRRo/F1X0IEnUBK8oy15A310HN74GNxyP0Y9hL1NdnqaM4Oq255 Xz/DiCeyR4Dr0sSDRuwqxfq/rL8QgHD/z6AhXVhPNucuyy6M+HBrzVZrinpTCcUa cML2ddoaxSV3Qd0mWm+RIVy89GMNffEOgu54YR1njK/s0Wb480GXa+naMhX3edBC afDV4MHWNSj3NWrPUfNs+rY+8LBk4yaoqz8znyozqvKS8pSGAMwpvCQfNXyDTchY RNJ9Gw8AbvYNB91I//w7++G698UpGlQGzpK2DyTD37rHANdYLkZ8LfMY8yTKww50 JcOTW0iLh1T7s16JSsLmzxaTIAnPE1lehxNRrI63cAep3wk40LM9BmNzWkOO++AD FTcCEbc2SzS5RtKBfxQnrWLPjZl1/p7Fd2P9o2o7X0jyErUEE+kXyYTOxyqMAtrW RmY31hkpwHV/VSyw0LV9JG5UV22ussGO2X5jdpFcLdxpURTQFMw0boPbozyrmaey UcPcENTQ/JXQ77FlTbGt51DCYvPQavzywfmyy+6b17yb1EHSVhHd4Pwxa3K9p61V Qbo7iJ3XJbteA+EwbBqieBOW785dcDibYye1DE5R8S4VxNgb3CzYMJIWjRNEJwb0 7VQHUtBFuv7C+y43M1WNme5rOjCic7+aHIvbiglKsfqmjlS64j0= =N3lI -----END PGP SIGNATURE----- --Apple-Mail=_33932BA0-55B4-4982-9C4D-5311DA223E92-- From nobody Fri Apr 6 02:14:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF8C1200F1 for ; Fri, 6 Apr 2018 02:14:46 -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 Xxlo9XCQVrl2 for ; Fri, 6 Apr 2018 02:14:42 -0700 (PDT) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::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 811AA120047 for ; Fri, 6 Apr 2018 02:14:42 -0700 (PDT) Received: by mail-pl0-x22e.google.com with SMTP id s10-v6so273777plp.0 for ; Fri, 06 Apr 2018 02:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ahALOtNVHBto2+OGZ7wu1cM0exRHJDSSXS3BkuMqY8w=; b=NkMWb94bfk//KLi6dHGsRYi8t8SrwdQaHBQovI4UcqibSnduPe7HMN3rxzVLDsH2h8 K5F4i+LpVCLET9ZOc2kBuvlaJ9msMTCJTCOJT84mFNSeePoJEHLEbL+8NMNBTaSua7VJ Lp30kj9FRnJqi6VU6lW6O6HYC/wbipA2jogV+15daOqgWZr7SKE0tf3QO19BYEd+0nmE w69C2+dApb0MHMCBOP6Xkz47rnPgMraFAUcTfYL13Wd3auDQAODOWqvTvrjVM1l+p77m /e1pls3Kh/ldTBMBa5YdZPDD7vXWpDrKzD7l21Kq5Qcj+99/0V3ARmK05OXuhyWTO/lS 01SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=ahALOtNVHBto2+OGZ7wu1cM0exRHJDSSXS3BkuMqY8w=; b=EpMs7Pz51Gv4NZo7rRMlX9s7jUWqcJF6GUnUmQn9xJ/8MutnF5LtHv/nQWVqpBfdGD XI4/H5oWd9WIv8yzgR0+3iw4Px/8u9N+kEVqfESDUlUNsiIotqLQPodci7RDXiyP9niz HC3WVDXsk3pPR2h4G5N0qceaRyMpSBYVQ+vRusR8qzS+dsT2jTTjG/LeEkz9JlOjZTcn r003HtO7a2WZ8kTaTNN1tJNwRKVxCYjnA0CG+K0z6rBGRhSNvFbR6xJ3+XBLzbwVyD6m 9jH7DJsCBohN2OuNdmPlUc1tLExOG9DisURXR8ngiJzY1yQicoTheJed0TcF5Y6zLSqP WCMw== X-Gm-Message-State: AElRT7FWa8zvgL5FegV73s1510BB6ihd/7ZvSGrRFryKYroeQRXBA2IK xyMwCJOwjC+c0fRFIKICg170aM9qexS2g5xBnGw= X-Google-Smtp-Source: AIpwx481iJBGnX/JJmvK71ah8ORBcD/nOuofs8gumsLxiulEaTyT9jOCvWfgVFaSYWkndm1hvtmr8Og8n74MTz3AD8M= X-Received: by 2002:a17:902:bd91:: with SMTP id q17-v6mr24650113pls.330.1523006082028; Fri, 06 Apr 2018 02:14:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.130 with HTTP; Fri, 6 Apr 2018 02:14:41 -0700 (PDT) In-Reply-To: <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch> References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch> <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch> From: Kazuho Oku Date: Fri, 6 Apr 2018 18:14:41 +0900 Message-ID: Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) To: "Brian Trammell (IETF)" Cc: Martin Thomson , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , QUIC WG , Christian Huitema , Frederick Kautz Content-Type: multipart/alternative; boundary="00000000000082993105692a7cbd" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 09:14:46 -0000 --00000000000082993105692a7cbd Content-Type: text/plain; charset="UTF-8" 2018-04-06 17:36 GMT+09:00 Brian Trammell (IETF) : > > > > On 6 Apr 2018, at 09:45, Martin Thomson > wrote: > > > > We do have data about rate of binding creation, courtesy of tests done > > for WebRTC. In essence, bindings can be created at rates that exceed > > most needs (I think that they went down to single digit milliseconds, > > far lower than I think is relevant here). > > There are two relevant metrics here: binding creation rate and maximum > concurrent state. The latter is where I expect there to be more > variability, and potential unfortunate side effects of an engineering > decision made with a single consideration. "People stuck behind marginal > NATs outside their own control don't deserve to use QUIC" is not a great > statement to make, even accidentally. > > > Justin Uberti has the numbers, but I struggled to find the email or > > slides; we can ask if you care. This result differed from the data > > that was available when STUN was first developed, where it was found > > that there were non-trivial numbers of NAT devices that lost bindings > > below 20ms (see https://tools.ietf.org/html/rfc5245#appendix-B.1). > > This is useful, thanks! > > > The question about exhaustion is relevant, I agree. There, the value > > doesn't need measurement as much as asking the right person what their > > configuration is. Take the number of ports open for bindings per IP, > > the duration of a binding, and how many clients are expected to be > > behind each IP address or how many bindings each client is limited to. > > We'd probably need to just ask a few CGNAT operators; anything smaller > > is unlikely to be as sensitive as something that runs at a decent > > scale. But getting data in the usual fashion - making bindings until > > something breaks - might be a little antisocial. > > Agreed that CGNAT is where the highest pain magnitude will be, but there > is a very long tail of CPE out there, where configuration information will > be harder to come by. But that's why we have a TCP fallback, I guess. > > > If we're going to saturate NAT bindings with this, then a signal might > > be a good solution. Or it might just be that we can recommend a rate > > limit on these little migrations. Based on typical timeouts on UDP > > (30s is very common, see also experience with ICE), we could say that > > a little migration every 10s is OK and you only have each connection > > taking 3 bindings. That doesn't seem that bad. > > It's multiplicative by a factor of three, which means that the max flow > concurrency will reduce by a factor of three. I agree it's probably > tolerable, but we do need to understand what we're actually getting for > that cost. I remain dubious about the actual privacy benefits WRT third > party passive surveillance here -- they don't accrue at all unless there's > a CGNAT in the way that doesn't bind an address/port range to a customer at > a given point in time. In the common case, ISTM that just burn more > in-network state than they additionally require at the surveillance point > to track the change. Defenses with such scaling curves are not a good idea. > I think I share the same concern. One way to minimize the impact could be to suggest certain amount of connections (e.g., 5%) to gratuitously migrate to a new tuple just once, right after the connection is being established. If we specify that way, we can assume that the impact on the NAT will be having 5% more flows. Middlebox vendor that mistakenly tries to use the cleartext bits in the packet header as the signal of connection initiation will also see failures at the same rate. > Another issue this raises: this will wreak varying levels havoc on > anything that uses IPFIX, NetFlow, sFlow, or similar technologies for > accounting or forensics. For accounting, whether two flow records happen to > represent the same flow is irrelevant, since they'll generally be dumped > into larger aggregates anyway. Replacing a single long-lived flow (a common > max active time is 30min) with its equivalent split into 10s windows will > lead to a 180x increase in export bandwidth for these flows in the first > stage of the collection infrastructure, but the flow counts handled by > these infrastructures (when connected to the open Internet) are usually > dominated by single-packet UDP and ICMP garbage anyway, so this probably > won't have too terrible an impact. > > Most such infrastructures are sampled (sFlow explicitly so), and there are > well-known issues with differential visibility of packet-sampled flows > based on flow duration. QUIC flows rotating ports every 10s would be > systematically undercounted with respect to long-duration TCP flows, which > will provide a strong incentive for correction if it materially impacts > settlement. > > Especially forensics for operational security will remain very interested > in understanding whether a group of 5-tuple flows are related to the same > activity. In most enterprise environments, though, any CGNAT mappings are > reversable, so there will not necessarily be a strong incentive > > I want to like this proposal, but I'm increasingly left with the > impression that this is neither a particularly useful nor a completely safe > thing to do at scale. > > Cheers, > > Brian > > > > > On Fri, Apr 6, 2018 at 5:16 PM, Brian Trammell (IETF) > wrote: > >> (Repeating and expanding my comment on #1269 to the list) > >> > >> +1 to CID rotation being pointless if we don't do this. However, this > seems dangerous if not done carefully, and it links CID rotation rate to > the maximum usable UDP port consumption rate, which is (most probably) > widely variable across access networks and (AFAICT) largely unknown in the > literature. We have anecdata here, and we need data. > >> > >> Note that QUIC presently doesn't have an advisory on-path state > clearance signal (we hsd discussed this as a signal bound to public reset > in #20, but it morphed into Stateless Reset, which has completely different > semantics), which means that there is neither a present nor yet a potential > future method to reduce the NAT state load this will generate. > >> > >> I'd feel a lot less apprehensive about this if there were an advisory, > integrity-protected signal meant for path consumption to clear state for a > path. Of course it wouldn't be used at all on day one, but the tradeoff it > presents is "hey, this is QUIC, it will burn through your UDP port state > faster than any other UDP protocol and multiplicatively faster than TCP; > but hey look, you can clear state when you see this path-verifiable singal > to reduce the impact this has." > >> > >> Cheers, > >> > >> Brian > >> > >>> On 6 Apr 2018, at 02:38, Martin Thomson > wrote: > >>> > >>> On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema > wrote: > >>>>> On Apr 5, 2018, at 8:58 AM, Frederick Kautz > wrote: > >>>>> > >>>>> Are you concerned that middleware boxes may be trained to reject > migrations, thereby forcing a new connection with a visible negotiation? > >>>> > >>>> Yes. Hence the need to grease. For example, have clients do some > gratuitous migration to a new source port number rather frequently. > >>> > >>> This seems like a simple fix, particularly since Mike recently added > >>> text that suggests occasional use of new connection IDs. In the > >>> spirit of keeping the wheels greased: > >>> > >>> https://github.com/quicwg/base-drafts/pull/1269 > >>> > >> > > -- Kazuho Oku --00000000000082993105692a7cbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-04-06 17:36 GMT+09:00 Brian Trammell (IETF) <= ietf@trammell.ch&= gt;:


> On 6 Apr 2018, at 09:45, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> We do have data about rate of binding creation, courtesy of tests done=
> for WebRTC.=C2=A0 In essence, bindings can be created at rates that ex= ceed
> most needs (I think that they went down to single digit milliseconds,<= br> > far lower than I think is relevant here).

There are two relevant metrics here: binding creation rate and maxim= um concurrent state. The latter is where I expect there to be more variabil= ity, and potential unfortunate side effects of an engineering decision made= with a single consideration. "People stuck behind marginal NATs outsi= de their own control don't deserve to use QUIC" is not a great sta= tement to make, even accidentally.

> Justin Uberti has the numbers, but I struggled to find the email or > slides; we can ask if you care. This result differed from the data
> that was available when STUN was first developed, where it was found > that there were non-trivial numbers of NAT devices that lost bindings<= br> > below 20ms (see https://tools.ietf.org/html/rfc5245#appendix-B.1).

This is useful, thanks!

> The question about exhaustion is relevant, I agree.=C2=A0 There, the v= alue
> doesn't need measurement as much as asking the right person what t= heir
> configuration is.=C2=A0 Take the number of ports open for bindings per= IP,
> the duration of a binding, and how many clients are expected to be
> behind each IP address or how many bindings each client is limited to.=
> We'd probably need to just ask a few CGNAT operators; anything sma= ller
> is unlikely to be as sensitive as something that runs at a decent
> scale.=C2=A0 But getting data in the usual fashion - making bindings u= ntil
> something breaks - might be a little antisocial.

Agreed that CGNAT is where the highest pain magnitude will be, but t= here is a very long tail of CPE out there, where configuration information = will be harder to come by. But that's why we have a TCP fallback, I gue= ss.

> If we're going to saturate NAT bindings with this, then a signal m= ight
> be a good solution.=C2=A0 Or it might just be that we can recommend a = rate
> limit on these little migrations.=C2=A0 Based on typical timeouts on U= DP
> (30s is very common, see also experience with ICE), we could say that<= br> > a little migration every 10s is OK and you only have each connection > taking 3 bindings.=C2=A0 That doesn't seem that bad.

It's multiplicative by a factor of three, which means that the m= ax flow concurrency will reduce by a factor of three. I agree it's prob= ably tolerable, but we do need to understand what we're actually gettin= g for that cost. I remain dubious about the actual privacy benefits WRT thi= rd party passive surveillance here -- they don't accrue at all unless t= here's a CGNAT in the way that doesn't bind an address/port range t= o a customer at a given point in time. In the common case, ISTM that just b= urn more in-network state than they additionally require at the surveillanc= e point to track the change. Defenses with such scaling curves are not a go= od idea.

I think I share the same conce= rn.

One way to minimize the impact could be to sug= gest certain amount of connections (e.g., 5%) to gratuitously migrate to a = new tuple just once, right after the connection is being established.
=

If we specify that way, we can assume that the impact o= n the NAT will be having 5% more flows. Middlebox vendor that mistakenly tr= ies to use the cleartext bits in the packet header as the signal of connect= ion initiation will also see failures at the same rate.


Another issue this raises: this will wreak varying levels havoc on anything= that uses IPFIX, NetFlow, sFlow, or similar technologies for accounting or= forensics. For accounting, whether two flow records happen to represent th= e same flow is irrelevant, since they'll generally be dumped into large= r aggregates anyway. Replacing a single long-lived flow (a common max activ= e time is 30min) with its equivalent split into 10s windows will lead to a = 180x increase in export bandwidth for these flows in the first stage of the= collection infrastructure, but the flow counts handled by these infrastruc= tures (when connected to the open Internet) are usually dominated by single= -packet UDP and ICMP garbage anyway, so this probably won't have too te= rrible an impact.

Most such infrastructures are sampled (sFlow explicitly so), and there are = well-known issues with differential visibility of packet-sampled flows base= d on flow duration. QUIC flows rotating ports every 10s would be systematic= ally undercounted with respect to long-duration TCP flows, which will provi= de a strong incentive for correction if it materially impacts settlement.
Especially forensics for operational security will remain very interested i= n understanding whether a group of 5-tuple flows are related to the same ac= tivity. In most enterprise environments, though, any CGNAT mappings are rev= ersable, so there will not necessarily be a strong incentive

I want to like this proposal, but I'm increasingly left with the impres= sion that this is neither a particularly useful nor a completely safe thing= to do at scale.

Cheers,

Brian

>
> On Fri, Apr 6, 2018 at 5:16 PM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>> (Repeating and expanding my comment on #1269 to the list)
>>
>> +1 to CID rotation being pointless if we don't do this. Howeve= r, this seems dangerous if not done carefully, and it links CID rotation ra= te to the maximum usable UDP port consumption rate, which is (most probably= ) widely variable across access networks and (AFAICT) largely unknown in th= e literature. We have anecdata here, and we need data.
>>
>> Note that QUIC presently doesn't have an advisory on-path stat= e clearance signal (we hsd discussed this as a signal bound to public reset= in #20, but it morphed into Stateless Reset, which has completely differen= t semantics), which means that there is neither a present nor yet a potenti= al future method to reduce the NAT state load this will generate.
>>
>> I'd feel a lot less apprehensive about this if there were an a= dvisory, integrity-protected signal meant for path consumption to clear sta= te for a path. Of course it wouldn't be used at all on day one, but the= tradeoff it presents is "hey, this is QUIC, it will burn through your= UDP port state faster than any other UDP protocol and multiplicatively fas= ter than TCP; but hey look, you can clear state when you see this path-veri= fiable singal to reduce the impact this has."
>>
>> Cheers,
>>
>> Brian
>>
>>> On 6 Apr 2018, at 02:38, Martin Thomson <martin.thomson@gmail.com> wrote:
>>>
>>> On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema <huitema@huitema.net> wrote:
>>>>> On Apr 5, 2018, at 8:58 AM, Frederick Kautz <fkautz@alumni.cmu.edu> wrote:
>>>>>
>>>>> Are you concerned that middleware boxes may be trained= to reject migrations, thereby forcing a new connection with a visible nego= tiation?
>>>>
>>>> Yes. Hence the need to grease. For example, have clients d= o some gratuitous migration to a new source port number rather frequently.<= br> >>>
>>> This seems like a simple fix, particularly since Mike recently= added
>>> text that suggests occasional use of new connection IDs.=C2=A0= In the
>>> spirit of keeping the wheels greased:
>>>
>>> https://github.com/quicwg/base-draf= ts/pull/1269
>>>
>>




--
=
Kazuho Ok= u
--00000000000082993105692a7cbd-- From nobody Fri Apr 6 02:39:02 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D90120725 for ; Fri, 6 Apr 2018 02:39:01 -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 D-dmnI737qXs for ; Fri, 6 Apr 2018 02:38:59 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38CA1200F1 for ; Fri, 6 Apr 2018 02:38:58 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 40AE334054E; Fri, 6 Apr 2018 11:38:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.27613); Fri, 6 Apr 2018 11:38:56 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri, 6 Apr 2018 11:38:56 +0200 (CEST) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50841368; Fri, 06 Apr 2018 11:38:56 +0200 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_995ECBAE-A056-450C-828B-4C8A82642BC4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption)) Date: Fri, 6 Apr 2018 11:38:55 +0200 In-Reply-To: Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , Christian Huitema , QUIC WG , Martin Thomson , Frederick Kautz To: Kazuho Oku References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch> <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 09:39:01 -0000 --Apple-Mail=_995ECBAE-A056-450C-828B-4C8A82642BC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Kazuho, > On 6 Apr 2018, at 11:14, Kazuho Oku wrote: >=20 >> It's multiplicative by a factor of three, which means that the max = flow concurrency will reduce by a factor of three. I agree it's probably = tolerable, but we do need to understand what we're actually getting for = that cost. I remain dubious about the actual privacy benefits WRT third = party passive surveillance here -- they don't accrue at all unless = there's a CGNAT in the way that doesn't bind an address/port range to a = customer at a given point in time. In the common case, ISTM that just = burn more in-network state than they additionally require at the = surveillance point to track the change. Defenses with such scaling = curves are not a good idea. >>=20 > I think I share the same concern. >=20 > One way to minimize the impact could be to suggest certain amount of = connections (e.g., 5%) to gratuitously migrate to a new tuple just once, = right after the connection is being established. >=20 > If we specify that way, we can assume that the impact on the NAT will = be having 5% more flows. Middlebox vendor that mistakenly tries to use = the cleartext bits in the packet header as the signal of connection = initiation will also see failures at the same rate. If the goal is only ossification agility, ensuring that migration can = actually work, then this seems like a much better approach. However, I would submit that if we think we are in a position where: - there is a strong incentive for firewalls/NATs to want to see start- = (and end-) of flow (which seems to me to be the threat model we're = trying to mitigate with this); and - we do not want arbitrary information in the QUIC wire image to be used = to detect these conditions, since that might cause bits of the wire = image we don't want to end up in the accidental invariants; then we really should consider adding explicit advisory flow state = signals, both for establishment and teardown. The theory here is that if = you give in-network functions a "grip" in the wire image of the protocol = they can use for state management, they won't try to grab on to the = slippery bits. Together with probabilistic migration, these signals = would divorce "on-path state" from "transport session state", reducing = the privacy impact with respect to SYN/FIN in TCP. (The alternative is to make the wire image so inscrutable that on-path = state tracking becomes completely futile and goes away. I'm not sure = we're that good at inscrutable wire images.) Cheers, Brian --Apple-Mail=_995ECBAE-A056-450C-828B-4C8A82642BC4 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlrHQC8ACgkQihK3vwvq RqP/1xAAtblx+djmudMe7EHEPB4musg9ogf4L314CfA70UXtY/A5ie3vCOSfbM0E CPdsMdwGiLF+CST50QOxuXv5e8fBMX5tTDhHlSzS2vFg2YyChu5Qx9AQIdi96Ze2 GLu7WevIBsjbevdojSi+N2hzwsSATnnqa2R+jAaq0RaWo4Ba+uQL3q96pHdwPnA9 N+qyRXPS+Ocgp3BZyujdN8pONn3iPpUPdvzuUCsxOcvmMfV3Yr45c7fUa5Pl2Eyp 96Ind17ORUSfHDLfC35LfvYTnuVKCTZGVfjEpKSlCnl2ImnSCPalCIm/S5YIkXqI NJzDTJVEcPmlgodv7pkjuD7wBy6vQhES0+n3O3+51AwSNs0ZmNUWa9OwU9qjPtN+ a4wsnaHI8XVg0eLTcwQwtU6sulT20ip8di2WXKByD0FIh3DqllFPVB0W12GUNr2C RQyAAQ/LR+O6BeTCsFlUSxLJHUJEJ8qAJ+hCq4juoKGXjLQZgO33Oj0EPk0HjxKZ Epr5KJGz7w+1g+dthW2L47Th2a4Um2Crd0Lz/3EaU6KaAtx9tAjtWeAqgr+wZVis xHw8yoSq50Xv01Q6nPpCAIHEup2M2pdYjj0Gdx927BU1v8QOT4lS1SfKRxa9kNYQ 9g0eXnis/2WrZ43sTHCps2ZfeX7W6A8raq6T1gH5VUC82UHqQuQ= =A5A1 -----END PGP SIGNATURE----- --Apple-Mail=_995ECBAE-A056-450C-828B-4C8A82642BC4-- From nobody Fri Apr 6 02:44:18 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D77120725 for ; Fri, 6 Apr 2018 02:44:17 -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 f_LHGStoo2tJ for ; Fri, 6 Apr 2018 02:44:15 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 241731241F3 for ; Fri, 6 Apr 2018 02:44:15 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id h143-v6so1095845ita.4 for ; Fri, 06 Apr 2018 02:44:15 -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=ckotiVvGsgX1AY2z3xStcLYD6P0Jts63CXrSORl4UeU=; b=EPtQORYqvzSEdHDFpJxbd38WE+SVLWr1H4flCkvxVjAEPZRH8XD2UClysXe8+mWOxP dcI/v5GQc+RjgQYTM6+URcjMjnKDNo+zqwBf96o/WxXqNp9SuhiZNPT1Q6ikyuiQ3NJ0 JIhYJVA+6RwdAqp+0injUC5XaMgEoBWEAzQqhTgmgCkiAoqH0A8cDv5qiIf+s1NBi604 Sudw7eaP+I2qAT9OuC8cZ3FzgGR28P/MEIy2ERTZm7VMStwzqC1ttvXoG/heT3tmInS1 CibDMlDOES6xlQFYwuTliLZRVJPhxuIJ6EzfOjKBNaiy66Wt3ePPyC0CaUDqVgra5nEV uRfw== 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=ckotiVvGsgX1AY2z3xStcLYD6P0Jts63CXrSORl4UeU=; b=h7hbtf4yaJbobY2k+M0nCVVMYkRstaWgEtUrBR2PO/sQNHsMpeM8hH5PV1u9qXcCjn vIaTPkznOIjGmPbXTdRIcIDuGGaLjA9TcijoWmQsPS1wZbTEKzP0C0MD0OwZtnvXTyDU kP3YCiKsRvIPXosCpLMz8GnkcgatT2px+eIBQ90p9m6cHxp0omJfmRcIFO1IMEEpcHnk gNoRC8ZnMKRY/9rp8hItNj5TOdqBR8JTFvZlIGxeM2M80Uw1RndP94vY+fFStIaZbrDo GjU7LJ/YycwuSq0phGZCMqUGd5RFc3YW+Xwx6RlTiFQxLWactBOXbFGi77kcPOKVTYB5 D+rQ== X-Gm-Message-State: ALQs6tD4U9rEoDrIKFhXq7Bvfa9CflIFrLo95ex1YNygPCJK44UEGBC0 73KPTM58AHjMdrtIKKTT/iiNU2odkxdCLCUVHLU= X-Google-Smtp-Source: AIpwx48J6Xg65EOr0Y/vA0ZDKGswPmsU/Lu2ksP6mEUJQ/TecWgJ6zHzY55tDwomPEmFzWKZQmdXDxPYzfwEe9gq614= X-Received: by 2002:a24:7088:: with SMTP id f130-v6mr17157508itc.39.1523007854427; Fri, 06 Apr 2018 02:44:14 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 6 Apr 2018 02:44:13 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch> <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 6 Apr 2018 02:44:13 -0700 Message-ID: Subject: Re: Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption)) To: "Brian Trammell (IETF)" , Kazuho Oku Cc: Frederick Kautz , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , QUIC WG , Martin Thomson , Christian Huitema Content-Type: multipart/alternative; boundary="0000000000002742fa05692ae65a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 09:44:17 -0000 --0000000000002742fa05692ae65a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adding a =E2=80=9Cgrib=E2=80=9D sounds reasonable. I previously mentioned my concern with CID ossification because length or content might be used in lack of anything better. The defense suggested - to grease the CID, will not work when a load balancer says =E2=80=9CI only support QUIC connections that use CID length = x, and sets the upper two bits like this.=E2=80=9D, and this load balancer then ge= ts a big market share. Then greasing is out the window. So it is better to provide an explicit signal for the cases that are immediately obvious. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 6 April 2018 at 11.39.07, Brian Trammell (IETF) (ietf@trammell.ch) wrote= : Hi, Kazuho, > On 6 Apr 2018, at 11:14, Kazuho Oku wrote: > >> It's multiplicative by a factor of three, which means that the max flow concurrency will reduce by a factor of three. I agree it's probably tolerable, but we do need to understand what we're actually getting for that cost. I remain dubious about the actual privacy benefits WRT third party passive surveillance here -- they don't accrue at all unless there's a CGNAT in the way that doesn't bind an address/port range to a customer at a given point in time. In the common case, ISTM that just burn more in-network state than they additionally require at the surveillance point to track the change. Defenses with such scaling curves are not a good idea. >> > I think I share the same concern. > > One way to minimize the impact could be to suggest certain amount of connections (e.g., 5%) to gratuitously migrate to a new tuple just once, right after the connection is being established. > > If we specify that way, we can assume that the impact on the NAT will be having 5% more flows. Middlebox vendor that mistakenly tries to use the cleartext bits in the packet header as the signal of connection initiation will also see failures at the same rate. If the goal is only ossification agility, ensuring that migration can actually work, then this seems like a much better approach. However, I would submit that if we think we are in a position where: - there is a strong incentive for firewalls/NATs to want to see start- (and end-) of flow (which seems to me to be the threat model we're trying to mitigate with this); and - we do not want arbitrary information in the QUIC wire image to be used to detect these conditions, since that might cause bits of the wire image we don't want to end up in the accidental invariants; then we really should consider adding explicit advisory flow state signals, both for establishment and teardown. The theory here is that if you give in-network functions a "grip" in the wire image of the protocol they can use for state management, they won't try to grab on to the slippery bits. Together with probabilistic migration, these signals would divorce "on-path state" from "transport session state", reducing the privacy impact with respect to SYN/FIN in TCP. (The alternative is to make the wire image so inscrutable that on-path state tracking becomes completely futile and goes away. I'm not sure we're that good at inscrutable wire images.) Cheers, Brian --0000000000002742fa05692ae65a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Adding a =E2=80=9Cgr= ib=E2=80=9D sounds reasonable.

I previously mentioned my concern with CID ossification because l= ength or content might be used in lack of anything better.

The defense suggested - to grease the= CID, will not work when a load balancer says =E2=80=9CI only support QUIC = connections that use CID length x, and sets the upper two bits like this.= =E2=80=9D, and this load balancer then gets a big market share. Then greasi= ng is out the window.

So it is better to provide an explicit signal for the cases that are immed= iately obvious.

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


On 6 April 2018 at 11.39.07, Brian Trammell (IETF) (ietf@trammell.ch) wrote:

Hi, Kazuho,

> On 6 Apr 2018, at 11:14, Kazuho Oku <kazuhooku@gmail.com> wrote:
> =20
>> It's multiplicative by a factor of three, which means that= the max flow concurrency will reduce by a factor of three. I agree it'= s probably tolerable, but we do need to understand what we're actually = getting for that cost. I remain dubious about the actual privacy benefits W= RT third party passive surveillance here -- they don't accrue at all un= less there's a CGNAT in the way that doesn't bind an address/port r= ange to a customer at a given point in time. In the common case, ISTM that = just burn more in-network state than they additionally require at the surve= illance point to track the change. Defenses with such scaling curves are no= t a good idea.
>> =20
> I think I share the same concern.
> =20
> One way to minimize the impact could be to suggest certain amount = of connections (e.g., 5%) to gratuitously migrate to a new tuple just once,= right after the connection is being established.
> =20
> If we specify that way, we can assume that the impact on the NAT w= ill be having 5% more flows. Middlebox vendor that mistakenly tries to use = the cleartext bits in the packet header as the signal of connection initiat= ion will also see failures at the same rate.

If the goal is only ossification agility, ensuring that migration can a= ctually work, then this seems like a much better approach.

However, I would submit that if we think we are in a position where:

- there is a strong incentive for firewalls/NATs to want to see start- = (and end-) of flow (which seems to me to be the threat model we're tryi= ng to mitigate with this); and

- we do not want arbitrary information in the QUIC wire image to be use= d to detect these conditions, since that might cause bits of the wire image= we don't want to end up in the accidental invariants;

then we really should consider adding explicit advisory flow state sign= als, both for establishment and teardown. The theory here is that if you gi= ve in-network functions a "grip" in the wire image of the protoco= l they can use for state management, they won't try to grab on to the s= lippery bits. Together with probabilistic migration, these signals would di= vorce "on-path state" from "transport session state", r= educing the privacy impact with respect to SYN/FIN in TCP.

(The alternative is to make the wire image so inscrutable that on-path = state tracking becomes completely futile and goes away. I'm not sure we= 're that good at inscrutable wire images.)

Cheers,

Brian
--0000000000002742fa05692ae65a-- From nobody Fri Apr 6 03:01:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5FE1241F3 for ; Fri, 6 Apr 2018 03:01: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 1KSYE-fHIFfZ for ; Fri, 6 Apr 2018 03:01:29 -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 E3EFB1241F5 for ; Fri, 6 Apr 2018 03:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1523008884; s=strato-dkim-0002; d=zinks.de; h=Content-Type:In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=858NEVh9l0WNIcEL2hDOxkTOyVqiyrn4oNF6u2Axltk=; b=oRzAsnMiXKDLq3Y0YRTL31rnkyLQiuH8qpaq7yIlbOpligwadbQ2XfLqlSglzq/zLI +9xJioy75jSqa0ZiUcP+N4UqCVPmdyAR/+6PasYOcY51nrcrB9qVLGv+q3OWffzliPqE kqKnrL8TiTZC00pHNymPXMrz6sfcrb8dEaY5VWlqdhf5JC6rIwmtl0AQZUo2R+TsEdS1 mqqx3gvAQe1M/DZyP8SVMvHMc+iJBzTxM1xLTryps37Yy9T3LKxmofBG/uvXeXKSoGDw pFmyXkQSPh3Xj5GuPIgBhwLzsBOnK4hfq+bjU0Fpc20XNuBPJrtt4ovmjduCjYzINSAB JieQ== X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1YaZ2OgvlDQIHaew1mI= X-RZG-CLASS-ID: mo00 Received: from [10.10.10.94] (p54A6DFF0.dip0.t-ipconnect.de [84.166.223.240]) by smtp.strato.de (RZmta 43.1 DYNA|AUTH) with ESMTPSA id k07273u36A1NP3M (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, 6 Apr 2018 12:01:23 +0200 (CEST) Subject: Re: Privacy holes To: quic@ietf.org References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch> From: Roland Zink Message-ID: Date: Fri, 6 Apr 2018 12:01:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F9493F59364E51565A21D643" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Apr 2018 10:01:36 -0000 This is a multi-part message in MIME format. --------------F9493F59364E51565A21D643 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Am 06.04.2018 um 09:45 schrieb Martin Thomson: > We do have data about rate of binding creation, courtesy of tests done > for WebRTC. In essence, bindings can be created at rates that exceed > most needs (I think that they went down to single digit milliseconds, > far lower than I think is relevant here). > > Justin Uberti has the numbers, but I struggled to find the email or > slides; we can ask if you care. This result differed from the data > that was available when STUN was first developed, where it was found > that there were non-trivial numbers of NAT devices that lost bindings > below 20ms (see https://tools.ietf.org/html/rfc5245#appendix-B.1). > > The question about exhaustion is relevant, I agree. There, the value > doesn't need measurement as much as asking the right person what their > configuration is. Take the number of ports open for bindings per IP, > the duration of a binding, and how many clients are expected to be > behind each IP address or how many bindings each client is limited to. > We'd probably need to just ask a few CGNAT operators; anything smaller > is unlikely to be as sensitive as something that runs at a decent > scale. But getting data in the usual fashion - making bindings until > something breaks - might be a little antisocial. > > If we're going to saturate NAT bindings with this, then a signal might > be a good solution. Or it might just be that we can recommend a rate > limit on these little migrations. Based on typical timeouts on UDP > (30s is very common, see also experience with ICE), we could say that > a little migration every 10s is OK and you only have each connection > taking 3 bindings. That doesn't seem that bad. I have found this : RFC 4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (https://tools.ietf.org/html/rfc4787#page-12):    REQ-5:  A NAT UDP mapping timer MUST NOT expire in less than two       minutes, unless REQ-5a applies.       a) For specific destination ports in the well-known port range          (ports 0-1023), a NAT MAY have shorter UDP mapping timers that          are specific to the IANA-registered application running over          that specific destination port. RFC6888 Common Requirements for Carrier-Grade NATs (CGNs):   REQ-8:  Once an external port is deallocated, it SHOULD NOT be       reallocated to a new mapping until at least 120 seconds have       passed, with the exceptions being: a. If the CGN tracks TCP sessions (e.g., with a state machine, as inSection 3.5.2.2 of [RFC6146] ), TCP ports MAY be reused immediately. b. If external ports are statically assigned to internal addresses (e.g., address X with port range 1000-1999 is assigned to subscriber A, 2000-2999 to subscriber B, etc.), and the assignment remains constant across state loss, then ports MAY be reused immediately. c. If the allocated external ports used address-dependent or address-and-port-dependent filtering before state loss, they MAY be reused immediately. The length of time and the maximum number of ports in this state MUST be configurable by the CGN administrator. So assuming 30 seconds seems a bit short. When there would be signals for session start and end then NATs could track how long mappings are necessary. Avoiding that and creating many bindings may be unsocial. > On Fri, Apr 6, 2018 at 5:16 PM, Brian Trammell (IETF) wrote: >> (Repeating and expanding my comment on #1269 to the list) >> >> +1 to CID rotation being pointless if we don't do this. However, this seems dangerous if not done carefully, and it links CID rotation rate to the maximum usable UDP port consumption rate, which is (most probably) widely variable across access networks and (AFAICT) largely unknown in the literature. We have anecdata here, and we need data. >> >> Note that QUIC presently doesn't have an advisory on-path state clearance signal (we hsd discussed this as a signal bound to public reset in #20, but it morphed into Stateless Reset, which has completely different semantics), which means that there is neither a present nor yet a potential future method to reduce the NAT state load this will generate. >> >> I'd feel a lot less apprehensive about this if there were an advisory, integrity-protected signal meant for path consumption to clear state for a path. Of course it wouldn't be used at all on day one, but the tradeoff it presents is "hey, this is QUIC, it will burn through your UDP port state faster than any other UDP protocol and multiplicatively faster than TCP; but hey look, you can clear state when you see this path-verifiable singal to reduce the impact this has." >> >> Cheers, >> >> Brian >> >>> On 6 Apr 2018, at 02:38, Martin Thomson wrote: >>> >>> On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema wrote: >>>>> On Apr 5, 2018, at 8:58 AM, Frederick Kautz wrote: >>>>> >>>>> Are you concerned that middleware boxes may be trained to reject migrations, thereby forcing a new connection with a visible negotiation? >>>> Yes. Hence the need to grease. For example, have clients do some gratuitous migration to a new source port number rather frequently. >>> This seems like a simple fix, particularly since Mike recently added >>> text that suggests occasional use of new connection IDs. In the >>> spirit of keeping the wheels greased: >>> >>> https://github.com/quicwg/base-drafts/pull/1269 >>> --------------F9493F59364E51565A21D643 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 06.04.2018 um 09:45 schrieb Martin Thomson:
We do have data about rate of binding creation, courtesy of tests done
for WebRTC.  In essence, bindings can be created at rates that exceed
most needs (I think that they went down to single digit milliseconds,
far lower than I think is relevant here).

Justin Uberti has the numbers, but I struggled to find the email or
slides; we can ask if you care. This result differed from the data
that was available when STUN was first developed, where it was found
that there were non-trivial numbers of NAT devices that lost bindings
below 20ms (see https://tools.ietf.org/html/rfc5245#appendix-B.1).

The question about exhaustion is relevant, I agree.  There, the value
doesn't need measurement as much as asking the right person what their
configuration is.  Take the number of ports open for bindings per IP,
the duration of a binding, and how many clients are expected to be
behind each IP address or how many bindings each client is limited to.
We'd probably need to just ask a few CGNAT operators; anything smaller
is unlikely to be as sensitive as something that runs at a decent
scale.  But getting data in the usual fashion - making bindings until
something breaks - might be a little antisocial.

If we're going to saturate NAT bindings with this, then a signal might
be a good solution.  Or it might just be that we can recommend a rate
limit on these little migrations.  Based on typical timeouts on UDP
(30s is very common, see also experience with ICE), we could say that
a little migration every 10s is OK and you only have each connection
taking 3 bindings.  That doesn't seem that bad.
I have found this :

RFC 4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (https://tools.ietf.org/html/rfc4787#page-12):
   REQ-5:  A NAT UDP mapping timer MUST NOT expire in less than two
      minutes, unless REQ-5a applies.

      a) For specific destination ports in the well-known port range
         (ports 0-1023), a NAT MAY have shorter UDP mapping timers that
         are specific to the IANA-registered application running over
         that specific destination port.

RFC6888 Common Requirements for Carrier-Grade NATs (CGNs):

  REQ-8:  Once an external port is deallocated, it SHOULD NOT be
      reallocated to a new mapping until at least 120 seconds have
      passed, with the exceptions being:
      a.  If the CGN tracks TCP sessions (e.g., with a state machine, as
          in Section 3.5.2.2 of [RFC6146]), TCP ports MAY be reused
          immediately.

      b.  If external ports are statically assigned to internal
          addresses (e.g., address X with port range 1000-1999 is
          assigned to subscriber A, 2000-2999 to subscriber B, etc.),
          and the assignment remains constant across state loss, then
          ports MAY be reused immediately.

      c.  If the allocated external ports used address-dependent or
          address-and-port-dependent filtering before state loss, they
          MAY be reused immediately.

      The length of time and the maximum number of ports in this state
      MUST be configurable by the CGN administrator.

So assuming 30 seconds seems a bit short. When there would be signals for session start and end then NATs could track how long mappings are necessary. Avoiding that and creating many bindings may be unsocial.

On Fri, Apr 6, 2018 at 5:16 PM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:

(Repeating and expanding my comment on #1269 to the list)

+1 to CID rotation being pointless if we don't do this. However, this seems dangerous if not done carefully, and it links CID rotation rate to the maximum usable UDP port consumption rate, which is (most probably) widely variable across access networks and (AFAICT) largely unknown in the literature. We have anecdata here, and we need data.

Note that QUIC presently doesn't have an advisory on-path state clearance signal (we hsd discussed this as a signal bound to public reset in #20, but it morphed into Stateless Reset, which has completely different semantics), which means that there is neither a present nor yet a potential future method to reduce the NAT state load this will generate.

I'd feel a lot less apprehensive about this if there were an advisory, integrity-protected signal meant for path consumption to clear state for a path. Of course it wouldn't be used at all on day one, but the tradeoff it presents is "hey, this is QUIC, it will burn through your UDP port state faster than any other UDP protocol and multiplicatively faster than TCP; but hey look, you can clear state when you see this path-verifiable singal to reduce the impact this has."

Cheers,

Brian


On 6 Apr 2018, at 02:38, Martin Thomson <martin.thomson@gmail.com> wrote:

On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema <huitema@huitema.net> wrote:

On Apr 5, 2018, at 8:58 AM, Frederick Kautz <fkautz@alumni.cmu.edu> wrote:

Are you concerned that middleware boxes may be trained to reject migrations, thereby forcing a new connection with a visible negotiation?

Yes. Hence the need to grease. For example, have clients do some gratuitous migration to a new source port number rather frequently.

This seems like a simple fix, particularly since Mike recently added
text that suggests occasional use of new connection IDs.  In the
spirit of keeping the wheels greased:

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



      

      

    

    

  


--------------F9493F59364E51565A21D643--


From nobody Fri Apr  6 03:10:55 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA71126DD9 for ; Fri,  6 Apr 2018 03:10:54 -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 gqGW-CjjfVqO for ; Fri,  6 Apr 2018 03:10:52 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62A1120725 for ; Fri,  6 Apr 2018 03:10:52 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id c78so396077pfj.6 for ; Fri, 06 Apr 2018 03:10: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:content-transfer-encoding; bh=+nD05NXsvL0l5JUPPm95Pl3GFBFxDsvJxQxd/635eio=; b=sCe8vB9G8mFml4b5dzWgVei2KcGdOufV/uAhy1sbQyv3R9gyWWcHoDaJzowqJPv6Rq euNeGWwPLSIsn77dCXS40RDYZrfXLVRWVnv62vyl19TK2hYmV/YLsVTiHIyKgURTxMAe fnYKBSwT2O/2IV3CLtfASOECkmH1BnDpYn3bQHVB1wLMya+glfHSOspP66ayHzq28/Pz D4lb/arF+xTDZDjvFg1PisjPo0+w0pxTPsRJax9yDmNBA0Wcok6xWjPc+cpB6BnC8wUs Q4KQpUw/p0xoriGnF6C3JNYtZD8HH2sfOV/ascJcOvvVHnmdPYXyRkjgQ4vpWbUeJsJv hPTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=+nD05NXsvL0l5JUPPm95Pl3GFBFxDsvJxQxd/635eio=; b=VNjUUUMAQJIDQ35/NscDTWR36QZUS1aWaAAq8PObnpeZ02c/ESzJ4gdSNuEu+e8FWU i8mDxx6k4AHQnFem+K5d0IJEXnYbJyxGuB1r5Gmdu0V2AIHBzq6wnWYijEePcqTeKZt4 zUchdy7ds34GlP2akoivUxpOk1vM7bZYrkGs1kNFAV+R77JzxLthoJUQ9Da5mxAOgLUx AbUPkYzKiJvTCyWZirNYnOchbi5w7YGxIa7ELW0LY/lb2UEVt4FsD82c7ipy8BNyAV5/ SwFvOslRSsZzs80qbhrJh8pAFTf8iNf8ibp8nO5p5Q85lvkmTPsDuXKuwnYg8DFrcrfj o0lw==
X-Gm-Message-State: AElRT7G5LKxyO3JKy0KLNVLR7XTDYu0lnJZF5gp2U8BkGzlCRbe0WQSe TzFHZW7H0BkMJPdm+KGwY2CF5Lm3rxiUBDoyeUSjRQ==
X-Google-Smtp-Source: AIpwx48rTszyxM0HDKhTcST3r5I6J74gosXsnDIQuzvm1TcVq1N8cG/QeO6qwLCHiG8J+D6QsiGgL0kgVdWZLUM6JzU=
X-Received: by 10.98.139.143 with SMTP id e15mr20099275pfl.134.1523009452164;  Fri, 06 Apr 2018 03:10:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Fri, 6 Apr 2018 03:10:51 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>    <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch>  <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch>  
From: Kazuho Oku 
Date: Fri, 6 Apr 2018 19:10:51 +0900
Message-ID: 
Subject: Re: Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption))
To: "Brian Trammell (IETF)" 
Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= ,  Christian Huitema , QUIC WG ,  Martin Thomson , Frederick Kautz 
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: Fri, 06 Apr 2018 10:10:54 -0000

Hi Brian,

My comments inline.

2018-04-06 18:38 GMT+09:00 Brian Trammell (IETF) :
> Hi, Kazuho,
>
>> On 6 Apr 2018, at 11:14, Kazuho Oku  wrote:
>>
>>> It's multiplicative by a factor of three, which means that the max flow=
 concurrency will reduce by a factor of three. I agree it's probably tolera=
ble, but we do need to understand what we're actually getting for that cost=
. I remain dubious about the actual privacy benefits WRT third party passiv=
e surveillance here -- they don't accrue at all unless there's a CGNAT in t=
he way that doesn't bind an address/port range to a customer at a given poi=
nt in time. In the common case, ISTM that just burn more in-network state t=
han they additionally require at the surveillance point to track the change=
. Defenses with such scaling curves are not a good idea.
>>>
>> I think I share the same concern.
>>
>> One way to minimize the impact could be to suggest certain amount of con=
nections (e.g., 5%) to gratuitously migrate to a new tuple just once, right=
 after the connection is being established.
>>
>> If we specify that way, we can assume that the impact on the NAT will be=
 having 5% more flows. Middlebox vendor that mistakenly tries to use the cl=
eartext bits in the packet header as the signal of connection initiation wi=
ll also see failures at the same rate.
>
> If the goal is only ossification agility, ensuring that migration can act=
ually work, then this seems like a much better approach.
>
> However, I would submit that if we think we are in a position where:
>
> - there is a strong incentive for firewalls/NATs to want to see start- (a=
nd end-) of flow (which seems to me to be the threat model we're trying to =
mitigate with this); and
>
> - we do not want arbitrary information in the QUIC wire image to be used =
to detect these conditions, since that might cause bits of the wire image w=
e don't want to end up in the accidental invariants;
>
> then we really should consider adding explicit advisory flow state signal=
s, both for establishment and teardown. The theory here is that if you give=
 in-network functions a "grip" in the wire image of the protocol they can u=
se for state management, they won't try to grab on to the slippery bits. To=
gether with probabilistic migration, these signals would divorce "on-path s=
tate" from "transport session state", reducing the privacy impact with resp=
ect to SYN/FIN in TCP.

I think that this is a very interesting question asking what the
requirements of QUIC as a protocol is. Thank you for bringing the
topic to table.

My argument against having an explicit signal for flow creation is
that it is impossible to have such signal in a reliable way, and that
trying to have no signal is better than having an unreliable signal.

Let me explain why I think we cannot have a reliable signal.

Consider the case where two NAT's exist. Such deployments exist, for
example when you connect through a Wifi router connected to a cellular
network.

There is a possibility that the NAT running next to the client (e.g.,
Wifi router) rebinding an existing QUIC connection to a new source
port without client intentionally requesting it. In such case, the
second NAT will start seeing a new flow that starts with a packet that
the client thinks it is part of an existing flow.

I think that in this example it is clear that a signal of flow
creation cannot be delivered to the second NAT, since the client does
not even know that a flow has been created.

The same argument goes for running an observer outside any number of NAT.

For flow closure, I think saving the battery by not sending a FIN
packet after quiescence is more important than sending good signal to
middleboxes.

> (The alternative is to make the wire image so inscrutable that on-path st=
ate tracking becomes completely futile and goes away. I'm not sure we're th=
at good at inscrutable wire images.)

I would rather argue that the goal of the alternative approach is to
make the intentional flow creation not easily distinguishable to the
extent that the middlebox vendors will refer to the RFC. Then, they
can decide either to not limit QUIC flows starting from a 1-RTT
packet, or to drop QUIC completely. And the issue is solved.

>
> Cheers,
>
> Brian



--=20
Kazuho Oku


From nobody Fri Apr  6 03:40:11 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2669126BF3 for ; Fri,  6 Apr 2018 03:40: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 Qx5HkC3rYu-g for ; Fri,  6 Apr 2018 03:40:07 -0700 (PDT)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 A7B631243FE for ; Fri,  6 Apr 2018 03:40:07 -0700 (PDT)
Received: by mail-ot0-x232.google.com with SMTP id v64-v6so679300otb.13 for ; Fri, 06 Apr 2018 03:40: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=il0Esi1adiAWnSqd0uzr9Ku4+IfWT9h37AHgGIIqDwg=; b=nZe0b7navlBjFxa4HINlar7ZHljrsKHeSTwXP14gbdM28/B9JoL8KU7gA79eTeldQ6 ZS9+kEH8O/moBvGM1HgGnOO0avhSnFL8wrQTFW4OB4pkuMT2hLu2W/t91IxgwQVS7YHh kYkHLeUVr7K4usjGxgUsEX24W86agPqDqf4T0UehwNaw4e9JMgQm/8v3Ky2mTJjeeM9q boX7OJx6fGBnFJWNdOQdlW0mhdc1wVa7oz+1/vvEzkZofUEsCkTKt8XPEC/a3mlXf7Wf FYOK7SJHFmTCU1fGJfMYIGZabWYRYmXWraso0qQmLxm3GAYr0g0b7BHVVEuNqAUQc+DH zegw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=il0Esi1adiAWnSqd0uzr9Ku4+IfWT9h37AHgGIIqDwg=; b=OicIjncqe2o9kPVBi9dpCL8JeeuZvljy3gSUbddM3fKVuqvd4+kLD2PT13zJVjcQKX nf2o711OesYEXJ85OpX/WC9szPHoSb/R2tTbYh2rsfGW9M0LHo+BjR/flhSOAPQVZj1h Z04TyZ3/4+vRDwEnttNFCowZanLn2TnYoj0jso3MIj+X7kh+8is/5jw95VzFootu7Aau tireWCK+Fuayljfvujqd6R0JvRbukbXj6jZeUSZnHkQA5esl2p6TdWQorLRdWvRzXbGv h5sXhfzV2KSUCMoPVvO7wfMk8pvn/wJ0w4TM77HxnYz/ddkfb88k/y9QQEeKzorhaiHE G87A==
X-Gm-Message-State: ALQs6tBzLd5k4BWQ28bGv4UYrmuKrENmIzjyDZ5A+BaBhlR6ZuXXMeWx Kv/vzPjwY+Mb5lspOQmYYFwcPijJK+Rcu1IxrFI=
X-Google-Smtp-Source: AIpwx49crOXpRT2Nqjb9uNra7nYCENZ1sJnGQ24aNhluFCh7RYYJni2MnIlK/XCmX5Dp17GxM/t01O0uoXxiuvnU2vs=
X-Received: by 2002:a9d:2a09:: with SMTP id t9-v6mr7197523ota.392.1523011207013;  Fri, 06 Apr 2018 03:40:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Fri, 6 Apr 2018 03:40:06 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>    <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch>  <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch> 
From: Martin Thomson 
Date: Fri, 6 Apr 2018 20:40:06 +1000
Message-ID: 
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)
To: Kazuho Oku 
Cc: "Brian Trammell (IETF)" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= ,  QUIC WG , Christian Huitema ,  Frederick Kautz 
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, 06 Apr 2018 10:40:10 -0000

On Fri, Apr 6, 2018 at 7:14 PM, Kazuho Oku  wrote:
> One way to minimize the impact could be to suggest certain amount of
> connections (e.g., 5%) to gratuitously migrate to a new tuple just once,
> right after the connection is being established.

I like this idea.  Do it rarely, but with a high enough probability
that it is noticed.

I don't think that we need to specify it, rather permit it (maybe with
observations about the costs of doing it too often), then establish a
convention.  We can reach enough of the client population in this
group that we can probably coordinate effectively such that we reach a
common enough proportion.  Add migrate-after-idle as the current PR
suggests, which has a much lower chance of expanding state and I'm not
seeing much need for "grips".

> If we specify that way, we can assume that the impact on the NAT will be
> having 5% more flows.

5% more only during the first timeout interval (whatever that is) and
thereafter no more with this design.


From nobody Fri Apr  6 03:55:17 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A941243FE for ; Fri,  6 Apr 2018 03:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 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_MUTUALBENEFIT=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ff34rjUK38Y for ; Fri,  6 Apr 2018 03:55:13 -0700 (PDT)
Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BAA124205 for ; Fri,  6 Apr 2018 03:55:13 -0700 (PDT)
Received: by mail-ot0-x234.google.com with SMTP id p33-v6so713278otp.11 for ; Fri, 06 Apr 2018 03:55: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:content-transfer-encoding; bh=v61C8s2dq/voseLP2iRFYU3XUIdkZIV6Fq0ICFCkZxU=; b=MHYK9jgRK8rXCQR1jJkCXXlgDXO/7ohpuI9C6B34xHIT57SOlUzOPBbfITx51mGk9Z bjlSy7bQ1H1r6d6s1QvGisPE8zymFQSib2sQkYJinSI7ODMjMUJ0ewPo0DR5Xf7QO6+u 2UYVbyl15T4l32bUmXnfcBUMHjZWIBfkq5dSP09SDPHqJ6mdG1wkR8ux9LmdbdWtqr6N Z0VyPAmUyEx7Z0GoNx+RrQCpd2YJ3a+vyxmXtVFpxHa0kxjYe2p70RKpzLQGjM96meaP egsOGBM+asXFHKyYc/VMb5bZXBj+PD2hxR7wqWnes8CEk93FcBDkGnxrUpY8RhrOylkl r5Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=v61C8s2dq/voseLP2iRFYU3XUIdkZIV6Fq0ICFCkZxU=; b=uNz6Mgi6IZTtPHUD0cDciWbix737ChSJ8sygO/+VdatsPZZVR4zO43BQsq7EDydQnX 8N+hdQHj0GKhhfUW+MfQl6QxcuEbNfLTALMTFiv/oeD51t06YSnUBwTXF3WFqT/cwFyB RvyQ4+W6FtldvgdrFY4ZtlfmcuGoq8NB8XgBQH38xVpy8eIJCIw95LNdJXdlA9Rwpiwp vag5L6OzA5xcYmHJM4zaTF8NfgbhxUYSXo3zvzjBjrcQW06lFd+slmhLsy3b7RqsXsZ4 OGvG4XrDlYez4J6VDyXuGkk55fgCiWTy+fL5/Y3o3XjBCgxRZocBSBiBxPKWDwpNrtdu QGig==
X-Gm-Message-State: ALQs6tBPPVAOBIovaDZUmi5+uxqnfJG6nVzotyyrSXyvPqZi3ai4kfvm M0QuhdJjaGHv4E9Gy4BW7MffsvUormuqKhB28xo=
X-Google-Smtp-Source: AIpwx4+s77newWTMWdpTNXubR1V8ET+N12IjL0HmBNk5mg8JXZvqIGMCs57lqQXazxBRfu4qwbavqlljA8apK6dRaPU=
X-Received: by 2002:a9d:4c81:: with SMTP id m1-v6mr10503344otf.396.1523012112807;  Fri, 06 Apr 2018 03:55:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Fri, 6 Apr 2018 03:55:11 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>    <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch>  <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch>  
From: Martin Thomson 
Date: Fri, 6 Apr 2018 20:55:12 +1000
Message-ID: 
Subject: Re: Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption))
To: "Brian Trammell (IETF)" 
Cc: Kazuho Oku ,  =?UTF-8?Q?Mirja_K=C3=BChlewind?= ,  Christian Huitema , QUIC WG ,  Frederick Kautz 
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: Fri, 06 Apr 2018 10:55:15 -0000

I don't know how to game this one out.

If we're looking for mutual benefit, the best I can come up with is
that the middlebox knows about flow up/down, so it can extend timeouts
for most flows and endpoints thereby enjoy better chance of flow
liveness after longer periods of quiescence.  That would be something
like with TCP where you can expect timeouts to be in the order of
minutes or tens of minutes (30 minutes if you pick the right port
number) and not merely tens of seconds.

The problem here is that you need enough of the middlebox population
to extend timeouts in the common case.  Tuning to specific networks is
difficult and time-consuming.  So endpoints would deploy this "grip"
without any expectation of reciprocation for potentially a very long
time.  That's in the order of the end-of-life cycle for home routers,
or an entire Internet era.

In the meantime, endpoints have to assume flow liveness based on the
Internet of today.  30s is the benchmark now, despite the wishful
"requirement" for 2 minutes in RFC 4787.

Thus we end up with the tension between the documented wire image that
says that there is a "done" signal, and the actual wire image, which
has activity every 30 seconds.  Add genuine cases of migration,
crashes, stateless resets, and the other reasons that the "done"
signal doesn't appear and the timer has to come down.

There might be benefits if everything comes together, but it's a long
game to play.

On Fri, Apr 6, 2018 at 7:38 PM, Brian Trammell (IETF)  wr=
ote:
> Hi, Kazuho,
>
>> On 6 Apr 2018, at 11:14, Kazuho Oku  wrote:
>>
>>> It's multiplicative by a factor of three, which means that the max flow=
 concurrency will reduce by a factor of three. I agree it's probably tolera=
ble, but we do need to understand what we're actually getting for that cost=
. I remain dubious about the actual privacy benefits WRT third party passiv=
e surveillance here -- they don't accrue at all unless there's a CGNAT in t=
he way that doesn't bind an address/port range to a customer at a given poi=
nt in time. In the common case, ISTM that just burn more in-network state t=
han they additionally require at the surveillance point to track the change=
. Defenses with such scaling curves are not a good idea.
>>>
>> I think I share the same concern.
>>
>> One way to minimize the impact could be to suggest certain amount of con=
nections (e.g., 5%) to gratuitously migrate to a new tuple just once, right=
 after the connection is being established.
>>
>> If we specify that way, we can assume that the impact on the NAT will be=
 having 5% more flows. Middlebox vendor that mistakenly tries to use the cl=
eartext bits in the packet header as the signal of connection initiation wi=
ll also see failures at the same rate.
>
> If the goal is only ossification agility, ensuring that migration can act=
ually work, then this seems like a much better approach.
>
> However, I would submit that if we think we are in a position where:
>
> - there is a strong incentive for firewalls/NATs to want to see start- (a=
nd end-) of flow (which seems to me to be the threat model we're trying to =
mitigate with this); and
>
> - we do not want arbitrary information in the QUIC wire image to be used =
to detect these conditions, since that might cause bits of the wire image w=
e don't want to end up in the accidental invariants;
>
> then we really should consider adding explicit advisory flow state signal=
s, both for establishment and teardown. The theory here is that if you give=
 in-network functions a "grip" in the wire image of the protocol they can u=
se for state management, they won't try to grab on to the slippery bits. To=
gether with probabilistic migration, these signals would divorce "on-path s=
tate" from "transport session state", reducing the privacy impact with resp=
ect to SYN/FIN in TCP.
>
> (The alternative is to make the wire image so inscrutable that on-path st=
ate tracking becomes completely futile and goes away. I'm not sure we're th=
at good at inscrutable wire images.)
>
> Cheers,
>
> Brian


From nobody Fri Apr  6 05:40:10 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AECD126CC7 for ; Fri,  6 Apr 2018 05:40:08 -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 qkx__cktK1eS for ; Fri,  6 Apr 2018 05:40:06 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7CD81201FA for ; Fri,  6 Apr 2018 05:40:04 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5D080341015; Fri,  6 Apr 2018 14:40:02 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.4073);  Fri,  6 Apr 2018 14:40:00 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri,  6 Apr 2018 14:40:00 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50862650; Fri, 06 Apr 2018 14:40:00 +0200
From: "Brian Trammell (IETF)" 
Message-Id: <8AAF21B8-5008-46EE-ACE1-FA2588DE9D20@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_6791374E-CE7B-4240-AD54-D5FCEE983C1A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption))
Date: Fri, 6 Apr 2018 14:39:58 +0200
In-Reply-To: 
Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , Christian Huitema , QUIC WG , Martin Thomson , Frederick Kautz 
To: Kazuho Oku 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>    <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch>  <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch>   
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 06 Apr 2018 12:40:09 -0000

--Apple-Mail=_6791374E-CE7B-4240-AD54-D5FCEE983C1A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

hi Kazuho,

Thanks for your message, comments inline, omitting some history for =
clarity...

> On 6 Apr 2018, at 12:10, Kazuho Oku  wrote:
>=20
> Hi Brian,
>=20
> My comments inline.
>=20
> 2018-04-06 18:38 GMT+09:00 Brian Trammell (IETF) :
>>=20
>>=20
>> However, I would submit that if we think we are in a position where:
>>=20
>> - there is a strong incentive for firewalls/NATs to want to see =
start- (and end-) of flow (which seems to me to be the threat model =
we're trying to mitigate with this); and
>>=20
>> - we do not want arbitrary information in the QUIC wire image to be =
used to detect these conditions, since that might cause bits of the wire =
image we don't want to end up in the accidental invariants;
>>=20
>> then we really should consider adding explicit advisory flow state =
signals, both for establishment and teardown. The theory here is that if =
you give in-network functions a "grip" in the wire image of the protocol =
they can use for state management, they won't try to grab on to the =
slippery bits. Together with probabilistic migration, these signals =
would divorce "on-path state" from "transport session state", reducing =
the privacy impact with respect to SYN/FIN in TCP.
>=20
> I think that this is a very interesting question asking what the
> requirements of QUIC as a protocol is. Thank you for bringing the
> topic to table.
>=20
> My argument against having an explicit signal for flow creation is
> that it is impossible to have such signal in a reliable way, and that
> trying to have no signal is better than having an unreliable signal.

I should say I'm not all that convinced that an advisory "flow start" =
signal is a good idea(*) -- I'm just saying that we seem to be trying =
very hard to keep a de facto advisory flow start signal from forming =
(which I would agree would be extremely undesirable indeed)... and we =
should step back and think about what properties flow start and end =
should have in QUIC, explicitly, as a function of requirements as =
opposed to philosophy.

> Let me explain why I think we cannot have a reliable signal.

 All this makes very good sense and I agree with it: the signal =
cannot possibly be reliable in the general case.

> For flow closure, I think saving the battery by not sending a FIN
> packet after quiescence is more important than sending good signal to
> middleboxes

This is a hard problem, and it cuts both ways; if a server wants to =
maintain the ability to connect a client after more than the standard =
UDP NAT timeout (30s), it needs to send keepalives more often than once =
every 30s (thereby waking the client if it's on battery). Which side of =
this coin wastes more power is difficult to determine, since it's =
entirely dependent on the prevalence of each kind of activity in a given =
network. We can make plausible guesses both in favor of "get rid of FIN, =
it wastes endpoint power" or "we really need FIN to keep from wasting =
endpoint power".

So I'm more convinced of the value of advisory-end than advisory-start.

>> (The alternative is to make the wire image so inscrutable that =
on-path state tracking becomes completely futile and goes away. I'm not =
sure we're that good at inscrutable wire images.)
>=20
> I would rather argue that the goal of the alternative approach is to
> make the intentional flow creation not easily distinguishable to the
> extent that the middlebox vendors will refer to the RFC. Then, they
> can decide either to not limit QUIC flows starting from a 1-RTT
> packet, or to drop QUIC completely. And the issue is solved.


Let me try to rephrase this in wildly different terminology: "we can't =
come up with a grip that we think will wotk, so we should make flow =
start as slippery as possible"; or rather, a middlebox that thinks it's =
seeing QUIC should make its drop decision based on "this is QUIC" and =
not anything based on the state of the connection. That definitely has =
desirable properties with respect to future flexibility -- the start and =
end signaling would end up in the invariants rather quickly whether =
intentional or not. And ISTM that the probabilistic migration behavior =
would help to achieve it.

Cheers,

Brian


(*): "Advisory flow start" is somewhat different than "path-visible =
proof of return routability" and "path-visible indication of consent to =
continue communicating". The latter, IMO, has more value as part of a =
design to support in-network rejection of UDP garbage. But it's a more =
complex signal, since it involves revealing things that are hard to fake =
at flow establishment time, and is of course subject to the =
philosophical question of whether that's a good idea.


--Apple-Mail=_6791374E-CE7B-4240-AD54-D5FCEE983C1A
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-----

iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlrHap8ACgkQihK3vwvq
RqOMeQ//YYmnS67h4uxqGvPMY4qnvEic27DBm8imAMhaca6xIY7sWqzIGyYRCa/X
fU9iteM9QakeICgqsdcFg5WxrGY8PYPlU86qBd5Nx2ffdsAmcCZvhs73Z51svvUZ
ba8HhHjpYIbGzR4uSrFu/x8irTBwLz7TUJlCbOcUl4X15DzybrrHVIqTofjDIXXx
wu82ZojAsM5A8GWcjhKJxROujFirIppzoXyWoMunxgVqn/JNpqNDoqmojcs9vQLY
iabG5Wf/sSacqSErNnv4FNH4NbnyPBBLlK2NqzDitfsaeoYpsw1EW+fD9RI0/Ah4
YY71L9HvPu/mLQbB/RxmNTvGMI9tuZRv4AOix3FyI4VJZBIKO8rtbiFMfO2Ai3/M
2QUQO2y/Zh8E3qbVu9avt13dA2Kmk/kB3S8cahFTNuvHTUQSvrityryz+ac8nYQ8
KPkbT6tACrAY26Ui9LdL1GbEHok1R9G/+enZhoh5+54bwhmTN90VlAOcKnlCJXOF
iKnKPJlzlaksSYFdAt5C3tZ7qEeYppOD7EgVe21ptYSGYv/AauI64LmWKrf97xhU
GmpE78GpO9vg91isnHiELL7a6PWtwK/+lIjxxZuNemjZuAirSJXrwxs/ArNLzLVR
w1k1N1wXh43vkvfYzr/7hNHqaWc69xRyYEdF4lw+/UHQhNK1MLc=
=ar9O
-----END PGP SIGNATURE-----

--Apple-Mail=_6791374E-CE7B-4240-AD54-D5FCEE983C1A--


From nobody Fri Apr  6 05:54:36 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C7C126CC7 for ; Fri,  6 Apr 2018 05:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_MUTUALBENEFIT=2, RCVD_IN_DNSWL_LOW=-0.7] 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 XQo9pbWJ8jOo for ; Fri,  6 Apr 2018 05:54:33 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6EF1201FA for ; Fri,  6 Apr 2018 05:54:33 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2AED734113E; Fri,  6 Apr 2018 14:54:32 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.6560);  Fri,  6 Apr 2018 14:54:32 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri,  6 Apr 2018 14:54:32 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50864538; Fri, 06 Apr 2018 14:54:31 +0200
From: "Brian Trammell (IETF)" 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_376CF9D4-0AA8-451E-A703-FBBBEEBB6FE0"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption))
Date: Fri, 6 Apr 2018 14:54:30 +0200
In-Reply-To: 
Cc: Christian Huitema , QUIC WG , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Frederick Kautz , Kazuho Oku 
To: Martin Thomson 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>    <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch>  <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch>   
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 06 Apr 2018 12:54:35 -0000

--Apple-Mail=_376CF9D4-0AA8-451E-A703-FBBBEEBB6FE0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

hi Martin,

> On 6 Apr 2018, at 12:55, Martin Thomson  =
wrote:
>=20
> I don't know how to game this one out.
>=20
> If we're looking for mutual benefit, the best I can come up with is
> that the middlebox knows about flow up/down, so it can extend timeouts
> for most flows and endpoints thereby enjoy better chance of flow
> liveness after longer periods of quiescence.  That would be something
> like with TCP where you can expect timeouts to be in the order of
> minutes or tens of minutes (30 minutes if you pick the right port
> number) and not merely tens of seconds.

Flow down in this case is way more useful than flow up.

> The problem here is that you need enough of the middlebox population
> to extend timeouts in the common case.  Tuning to specific networks is
> difficult and time-consuming.  So endpoints would deploy this "grip"
> without any expectation of reciprocation for potentially a very long
> time.  That's in the order of the end-of-life cycle for home routers,
> or an entire Internet era.

We, as a community, are currently managing transitions that have taken =
that long. Insert your favorite IPv6 joke here, of course, but ECN comes =
to mind as well.

> In the meantime, endpoints have to assume flow liveness based on the
> Internet of today.  30s is the benchmark now, despite the wishful
> "requirement" for 2 minutes in RFC 4787.

"Flow liveness" is a path property, not a global one, a function of the =
minimum timeout of all connection-breaking state along the path. I =
suspect that endpoint pairs in a world ruled by UDP state timeout will =
end up widely deploy simple probing algorithms to discover it whether or =
not there's a simple way to signal that state can be disposed of early.

This is really a separate issue, though -- the question about state =
disposal is disjoiny from how to keep flow start signaling from =
ossifying into an unintentional magic packet sequence you have to show =
the network. It makes sense to think about the "grippiness" of the =
protocol in terms of the eventual endpoint as well as management reqt's =
though.

> Thus we end up with the tension between the documented wire image that
> says that there is a "done" signal, and the actual wire image, which
> has activity every 30 seconds.  Add genuine cases of migration,
> crashes, stateless resets, and the other reasons that the "done"
> signal doesn't appear and the timer has to come down.
>=20
> There might be benefits if everything comes together, but it's a long
> game to play.

I've been having some variant of this particular conversation for =
(checks watch) about four years now. ;)

Cheers,

Brian


--Apple-Mail=_376CF9D4-0AA8-451E-A703-FBBBEEBB6FE0
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-----

iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlrHbgYACgkQihK3vwvq
RqMJUg/9GSuoJ7kYiUO+PpqIyhZUYGuDv+Mv9yJy0J7eArCY7HqLYYCU87qZFRR+
3M2ZvABWvtgDarHp4QcgIod0bTQqYzpId4mrAwYOgaZ6fT8N+aAifaRoPiQsxVAB
0wPsPWuZ8xVs9smhPEewQxULUNfhgVAuCiXrXr6UuDDgPG2Ch/KklWjO7B0Il+F5
2DVQ5XtkvMG13l745OBMYjYSkQlCBe7OuW49WFBOBrB4CoBxdnmbN4jW2xDDzTqQ
j/uLfw7iw6V+aeXEKhta71b6yb/d+sMgxRfY8O9sNVCDDVY1rx32qdUZPFA0Kpip
u8YRFCL7JtUP1osJvhlWeCbqQGZIXc/DmyYifgfXV9oWMaILVdCAhGWeFXaHdnwQ
N/MzkIUfHJrOTQfM9L8SA4m4wIaDRRdZ/E8CHk637mqmz4K2XNZruegGYP1SPkiM
CeyKmE84XrnTCncoS8wCtnIzJJ13tx6GvgG1dYsHv7CBMn5yjqLCJZuew+Ax/5fQ
QPV/WpNrEJnsW3RoKBMHfSPaZqEdZSyJN7TJr+Gg9jKrqdsdmN8jiHvbYYQ3GXro
MsUGq8Iq8jZ2ZEI2DuRfrIKxQTzu9fgbikXX+jBNTb9ksxgCQNjv1qyUg6Q+Q0ct
yEjgoWSfFBpE/jwMMZTc8x16jijrEdjsA+IVzCfur5mkyB++VIc=
=XnCG
-----END PGP SIGNATURE-----

--Apple-Mail=_376CF9D4-0AA8-451E-A703-FBBBEEBB6FE0--


From nobody Fri Apr  6 05:55:32 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439DA124BE8 for ; Fri,  6 Apr 2018 05:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0hEz6Cv6dj9 for ; Fri,  6 Apr 2018 05:55:27 -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 4094B1201FA for ; Fri,  6 Apr 2018 05:55:27 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id q84so1599497iod.10 for ; Fri, 06 Apr 2018 05:55:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8dMtntBw6NK2j8nrTgs05sne9j9dwLxpTeCsaDoDh+A=; b=BNcLLeFlEDyKTvy7SqvucNR5s56zJyl9AvvcgwVKXAEJOV39GG1vA2HHOiqNdbcHkz JOU7hLGt8OiJHrZVC+1Q2lpcgTQDbMwEjgvyK1+4x5Iu7it6yknyBYkL9qISU2g4f44T RF/hTdJLQFXYK9W7gxI1jrptHZ3BnCVygNKcpOKpYuHqUB3ZjXuDz8V7jdJGe0yFiILO SHLOhDATkURrsYSaSDQacnQ15jwpR6H4YbOzop948gsa3wjSOhcoi4c9I3Y91yjW9P/D iD80qalOoLlK0hOl1zs9+lLD573DcS5J+Wew56iguMrCoav1EqdompoO8jrcSYCzyMD3 H5ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8dMtntBw6NK2j8nrTgs05sne9j9dwLxpTeCsaDoDh+A=; b=rI9xHEhUZx/fv/RTl/B2ySmvotX2LCFjiRL67aetXonIYpDOV0jpwcX3Vnrr8tTPxM XiSJd1TsmIwFj2PbLo6Jd6GuMP2DlZuvggvEaDR4lKKpgn/igpWyPaw881Q7gvwksaH2 9Gs8GVpSqYj6SV8N6zdxg5GE2yV7dVSZNWCIgznmSghgxP7r+5Q171vMLkeB7Y2/3HII 1lAEk5xcYHzmxvifZh79UsAzAgaLAcybAeos5V1kkq2/bvi/TA5xK4kCw9mEVfDdLGA8 i365GIYsqDHAcLNVbNGTe5lonaaDUzf2I2by6kBMtGUmzDHX39GHrzEbcvpe1iuLqQrP Me0Q==
X-Gm-Message-State: ALQs6tBIi8A5VMTEnJcUKlJTSVt7q9R722dCv0akO3+bbdV3/lZ1+nUt IaZqUMz6e8iwRm5MKixDOzYjUfjPFzFtXLIowZ0qcQyloYA=
X-Google-Smtp-Source: AIpwx4/+noN65hq0/BiALEZrPoVcZ9UzYPCsaHwHVKT49w9OUhui05lPdY8i1rMAPrhTVPZ89+GRfmsxoQx7k/5v7G8=
X-Received: by 10.107.131.83 with SMTP id f80mr23891108iod.102.1523019326306;  Fri, 06 Apr 2018 05:55:26 -0700 (PDT)
MIME-Version: 1.0
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>    <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch>  
In-Reply-To: 
From: Ian Swett 
Date: Fri, 06 Apr 2018 12:55:14 +0000
Message-ID: 
Subject: Re: Privacy holes
To: roland@zinks.de
Cc: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="001a113f998aeeb9d005692d91f5"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 06 Apr 2018 12:55:31 -0000

--001a113f998aeeb9d005692d91f5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

There's some slightly older data from QUIC on slide 10 in this IETF
presenation:
https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf

TLDR: 90% of networks have at least a 1 minute timeout, but only 50% have
at least a 2 minute timeout.

On Fri, Apr 6, 2018 at 6:01 AM Roland Zink  wrote:

>
> Am 06.04.2018 um 09:45 schrieb Martin Thomson:
>
> We do have data about rate of binding creation, courtesy of tests done
> for WebRTC.  In essence, bindings can be created at rates that exceed
> most needs (I think that they went down to single digit milliseconds,
> far lower than I think is relevant here).
>
> Justin Uberti has the numbers, but I struggled to find the email or
> slides; we can ask if you care. This result differed from the data
> that was available when STUN was first developed, where it was found
> that there were non-trivial numbers of NAT devices that lost bindings
> below 20ms (see https://tools.ietf.org/html/rfc5245#appendix-B.1).
>
> The question about exhaustion is relevant, I agree.  There, the value
> doesn't need measurement as much as asking the right person what their
> configuration is.  Take the number of ports open for bindings per IP,
> the duration of a binding, and how many clients are expected to be
> behind each IP address or how many bindings each client is limited to.
> We'd probably need to just ask a few CGNAT operators; anything smaller
> is unlikely to be as sensitive as something that runs at a decent
> scale.  But getting data in the usual fashion - making bindings until
> something breaks - might be a little antisocial.
>
> If we're going to saturate NAT bindings with this, then a signal might
> be a good solution.  Or it might just be that we can recommend a rate
> limit on these little migrations.  Based on typical timeouts on UDP
> (30s is very common, see also experience with ICE), we could say that
> a little migration every 10s is OK and you only have each connection
> taking 3 bindings.  That doesn't seem that bad.
>
> I have found this :
>
> RFC 4787 Network Address Translation (NAT) Behavioral Requirements for
> Unicast UDP (https://tools.ietf.org/html/rfc4787#page-12):
>    REQ-5:  A NAT UDP mapping timer MUST NOT expire in less than two
>       minutes, unless REQ-5a applies.
>
>       a) For specific destination ports in the well-known port range
>          (ports 0-1023), a NAT MAY have shorter UDP mapping timers that
>          are specific to the IANA-registered application running over
>          that specific destination port.
>
> RFC6888 Common Requirements for Carrier-Grade NATs (CGNs):
>
>   REQ-8:  Once an external port is deallocated, it SHOULD NOT be
>       reallocated to a new mapping until at least 120 seconds have
>       passed, with the exceptions being:
>
>       a.  If the CGN tracks TCP sessions (e.g., with a state machine, as
>           in Section 3.5.2.2 of [RFC6146] ), TCP ports MAY be reused
>           immediately.
>
>       b.  If external ports are statically assigned to internal
>           addresses (e.g., address X with port range 1000-1999 is
>           assigned to subscriber A, 2000-2999 to subscriber B, etc.),
>           and the assignment remains constant across state loss, then
>           ports MAY be reused immediately.
>
>       c.  If the allocated external ports used address-dependent or
>           address-and-port-dependent filtering before state loss, they
>           MAY be reused immediately.
>
>       The length of time and the maximum number of ports in this state
>       MUST be configurable by the CGN administrator.
>
>
>
> So assuming 30 seconds seems a bit short. When there would be signals for
> session start and end then NATs could track how long mappings are
> necessary. Avoiding that and creating many bindings may be unsocial.
>
>
> On Fri, Apr 6, 2018 at 5:16 PM, Brian Trammell (IETF)  =
 wrote:
>
> (Repeating and expanding my comment on #1269 to the list)
>
> +1 to CID rotation being pointless if we don't do this. However, this see=
ms dangerous if not done carefully, and it links CID rotation rate to the m=
aximum usable UDP port consumption rate, which is (most probably) widely va=
riable across access networks and (AFAICT) largely unknown in the literatur=
e. We have anecdata here, and we need data.
>
> Note that QUIC presently doesn't have an advisory on-path state clearance=
 signal (we hsd discussed this as a signal bound to public reset in #20, bu=
t it morphed into Stateless Reset, which has completely different semantics=
), which means that there is neither a present nor yet a potential future m=
ethod to reduce the NAT state load this will generate.
>
> I'd feel a lot less apprehensive about this if there were an advisory, in=
tegrity-protected signal meant for path consumption to clear state for a pa=
th. Of course it wouldn't be used at all on day one, but the tradeoff it pr=
esents is "hey, this is QUIC, it will burn through your UDP port state fast=
er than any other UDP protocol and multiplicatively faster than TCP; but he=
y look, you can clear state when you see this path-verifiable singal to red=
uce the impact this has."
>
> Cheers,
>
> Brian
>
>
> On 6 Apr 2018, at 02:38, Martin Thomson   wrote:
>
> On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema  <=
huitema@huitema.net> wrote:
>
> On Apr 5, 2018, at 8:58 AM, Frederick Kautz   wrote:
>
> Are you concerned that middleware boxes may be trained to reject migratio=
ns, thereby forcing a new connection with a visible negotiation?
>
>
> Yes. Hence the need to grease. For example, have clients do some gratuito=
us migration to a new source port number rather frequently.
>
>
> This seems like a simple fix, particularly since Mike recently added
> text that suggests occasional use of new connection IDs.  In the
> spirit of keeping the wheels greased:
> https://github.com/quicwg/base-drafts/pull/1269
>
>
>

--001a113f998aeeb9d005692d91f5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


There's some slightly older data from QUIC on slide 10=
 in this IETF presenation:

TLDR: 90% of =
networks have at least a 1 minute timeout, but only 50% have at least a 2 m=
inute timeout.

O=
n Fri, Apr 6, 2018 at 6:01 AM Roland Zink <roland@zinks.de> wrote:

    

    
Am 06.04.2018 um 09=
:45 schrieb Martin
      Thomson:

    

    

      
We do have data about rate of binding creation, courtesy of test=
s done
for WebRTC.  In essence, bindings can be created at rates that exceed
most needs (I think that they went down to single digit milliseconds,
far lower than I think is relevant here).

Justin Uberti has the numbers, but I struggled to find the email or
slides; we can ask if you care. This result differed from the data
that was available when STUN was first developed, where it was found
that there were non-trivial numbers of NAT devices that lost bindings
below 20ms (see ht=
tps://tools.ietf.org/html/rfc5245#appendix-B.1).

The question about exhaustion is relevant, I agree.  There, the value
doesn't need measurement as much as asking the right person what their
configuration is.  Take the number of ports open for bindings per IP,
the duration of a binding, and how many clients are expected to be
behind each IP address or how many bindings each client is limited to.
We'd probably need to just ask a few CGNAT operators; anything smaller
is unlikely to be as sensitive as something that runs at a decent
scale.  But getting data in the usual fashion - making bindings until
something breaks - might be a little antisocial.

If we're going to saturate NAT bindings with this, then a signal might
be a good solution.  Or it might just be that we can recommend a rate
limit on these little migrations.  Based on typical timeouts on UDP
(30s is very common, see also experience with ICE), we could say that
a little migration every 10s is OK and you only have each connection
taking 3 bindings.  That doesn't seem that bad.


    

    I have found this :

    

    RFC 4787 Network Address Translation (NAT) Behavioral Requirements
    for Unicast UDP (ht=
tps://tools.ietf.org/html/rfc4787#page-12):

    =C2=A0=C2=A0 REQ-5:=C2=A0 A NAT UDP mapping timer MUST NOT expire in le=
ss than two

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 minutes, unless REQ-5a applies.

    

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a) For specific destination ports in the=
 well-known port range

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (ports 0-1023), a NAT =
MAY have shorter UDP mapping timers
    that

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 are specific to the IA=
NA-registered application running
    over

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that specific destinat=
ion port.

    

    RFC6888 Common Requirements for Carrier-Grade NATs (CGNs):

    

    =C2=A0 REQ-8:=C2=A0 Once an external port is deallocated, it SHOULD NOT=
 be

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reallocated to a new mapping until at le=
ast 120 seconds have

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 passed, with the exceptions being:

    
      =
a.  If the CGN tracks TCP sessions (e.g., with a state machine, as
          in Section=C2=A03.5.2.2 of [RFC6146]), TCP ports MAY b=
e reused
          immediately.

      b.  If external ports are statically assigned to internal
          addresses (e.g., address X with port range 1000-1999 is
          assigned to subscriber A, 2000-2999 to subscriber B, etc.),
          and the assignment remains constant across state loss, then
          ports MAY be reused immediately.

      c.  If the allocated external ports used address-dependent or
          address-and-port-dependent filtering before state loss, they
          MAY be reused immediately.

      The length of time and the maximum number of ports in this state
      MUST be configurable by the CGN administrator.



    

    So assuming 30 seconds seems a bit short. When there would be
    signals for session start and end then NATs could track how long
    mappings are necessary. Avoiding that and creating many bindings may
    be unsocial.

    

    

      
On Fri, Apr 6, 2018 at 5:16 PM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:


      

        
(Repeating and expanding my comment on #1269 to the list)

+1 to CID rotation being pointless if we don't do this. However, this s=
eems dangerous if not done carefully, and it links CID rotation rate to the=
 maximum usable UDP port consumption rate, which is (most probably) widely =
variable across access networks and (AFAICT) largely unknown in the literat=
ure. We have anecdata here, and we need data.

Note that QUIC presently doesn't have an advisory on-path state clearan=
ce signal (we hsd discussed this as a signal bound to public reset in #20, =
but it morphed into Stateless Reset, which has completely different semanti=
cs), which means that there is neither a present nor yet a potential future=
 method to reduce the NAT state load this will generate.

I'd feel a lot less apprehensive about this if there were an advisory, =
integrity-protected signal meant for path consumption to clear state for a =
path. Of course it wouldn't be used at all on day one, but the tradeoff=
 it presents is "hey, this is QUIC, it will burn through your UDP port=
 state faster than any other UDP protocol and multiplicatively faster than =
TCP; but hey look, you can clear state when you see this path-verifiable si=
ngal to reduce the impact this has."

Cheers,

Brian



        

          
On 6 Apr 2018, at 02:38, Martin Thomson <martin.thomson@gmail.com> wrote:

On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema <huitema@huitema.net> wrote:


          

            

              
On Apr 5, 2018, at 8:58 AM, Frederick Kautz <fkautz@alumni.cmu.edu> wrote:

Are you concerned that middleware boxes may be trained to reject migrations=
, thereby forcing a new connection with a visible negotiation?


            

            
Yes. Hence the need to grease. For example, have clients do some gratuitous=
 migration to a new source port number rather frequently.


          

          
This seems like a simple fix, particularly since Mike recently added
text that suggests occasional use of new connection IDs.  In the
spirit of keeping the wheels greased:

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



        

        

      

      

    

    

  





--001a113f998aeeb9d005692d91f5--


From nobody Fri Apr  6 07:02:09 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3401201FA for ; Fri,  6 Apr 2018 07:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 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_MUTUALBENEFIT=2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiX8JUpUGyYj for ; Fri,  6 Apr 2018 07:02:06 -0700 (PDT)
Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E611200FC for ; Fri,  6 Apr 2018 07:02:06 -0700 (PDT)
Received: by mail-yb0-x229.google.com with SMTP id k199-v6so409106ybk.12 for ; Fri, 06 Apr 2018 07:02: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=FPWSYCZXnWkQkQT5LOmb/1U07uELRYZRroh7+CtaiWU=; b=LRblPIuDuNpNS5zR23zI7XosX6HKnhQUSFGcX4LZ/VQuclBj0k1jk0S5XCPg8gBkWg pVrNDhkJWMtKda+COc5//iaowXvJk7hHxJVddMwiqxqK8IqbS0/YEwYpDRXCQb54KLlW 0zEGAveOECnU5z6zz8+qYdhz1FVQnZ+rkrI0MHjxcYazuZYEjCKV3L9HG3qCAh9KeFeS aIaAok87qFQ+RisSj4qQyTqeeOxKkaW60dyX/RJwJmsTOxMzb/j3xmE0Y2iQQ5niAao1 uz8p0gJtX+KcV/JPg1LznnZJEYFlrllOk1QcBD0rB0MbPRX2HiZX1ijr0D5wjEvAu1J0 6uyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=FPWSYCZXnWkQkQT5LOmb/1U07uELRYZRroh7+CtaiWU=; b=tykg/H2Ur5gMXVWKXyisRSekf/hVcUkq0p7nScjR6YwBtxxHbKLwPMo3n13oah/zo0 NLae7bx+XwLmGfqs9H8Km6mvtkFEoqqFXyGuLrSjYvY0uhzhNK6qd65zw3TMfIiEmgH7 t73u/z95pPFy5HUfOeOlbi7os3fTwb3Ibw9NSEYL3cHKP7s9w0N8XzcaFzEOZnUbPReQ Mk4lN4VKmk1nS9qzFG9H7KqJxHPIiC1A9Ka4QKSoyMdm2X13PrZDJUnDueSf90MZWxBK HfN9M8H1k3vI7rg7OAm52KxXukR7Bkr+ouHEp12KFcxPioOBjFprlgAAfz8IfY8v2JC1 nx/A==
X-Gm-Message-State: ALQs6tAzmz6MF23AGfF/wM5cOCp/I3XA+LQQrJbNaEN1X3BYFzTKdviA suvf3nm2Prp7JZKcmRwYCp/DRRdpW3DM0W2zOvg=
X-Google-Smtp-Source: AIpwx4/bCfy+tdAytzqD9Y7sjjNJ0bkFtNz829XEGKcqHDpwJd6sjzAfbdN9BSGFRRCJMmrWCZu4sTJxL7g9cyx+9Fc=
X-Received: by 2002:a25:1a42:: with SMTP id a63-v6mr15267657yba.235.1523023324671;  Fri, 06 Apr 2018 07:02:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:e757:0:0:0:0:0 with HTTP; Fri, 6 Apr 2018 07:02:04 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>    <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch>  <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch>    
From: Spencer Dawkins at IETF 
Date: Fri, 6 Apr 2018 09:02:04 -0500
Message-ID: 
Subject: Re: Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption))
To: "Brian Trammell (IETF)" 
Cc: Martin Thomson ,  =?UTF-8?Q?Mirja_K=C3=BChlewind?= ,  QUIC WG , Christian Huitema ,  Frederick Kautz , Kazuho Oku 
Content-Type: multipart/alternative; boundary="00000000000040726305692e805f"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 06 Apr 2018 14:02:08 -0000

--00000000000040726305692e805f
Content-Type: text/plain; charset="UTF-8"

Hi, Brian,

On Fri, Apr 6, 2018 at 7:54 AM, Brian Trammell (IETF) 
wrote:

> hi Martin,
>
> > On 6 Apr 2018, at 12:55, Martin Thomson 
> wrote:
> >
> > I don't know how to game this one out.
> >
> > If we're looking for mutual benefit, the best I can come up with is
> > that the middlebox knows about flow up/down, so it can extend timeouts
> > for most flows and endpoints thereby enjoy better chance of flow
> > liveness after longer periods of quiescence.  That would be something
> > like with TCP where you can expect timeouts to be in the order of
> > minutes or tens of minutes (30 minutes if you pick the right port
> > number) and not merely tens of seconds.
>
> Flow down in this case is way more useful than flow up.
>
> > The problem here is that you need enough of the middlebox population
> > to extend timeouts in the common case.  Tuning to specific networks is
> > difficult and time-consuming.  So endpoints would deploy this "grip"
> > without any expectation of reciprocation for potentially a very long
> > time.  That's in the order of the end-of-life cycle for home routers,
> > or an entire Internet era.
>
> We, as a community, are currently managing transitions that have taken
> that long. Insert your favorite IPv6 joke here, of course, but ECN comes to
> mind as well.
>
> > In the meantime, endpoints have to assume flow liveness based on the
> > Internet of today.  30s is the benchmark now, despite the wishful
> > "requirement" for 2 minutes in RFC 4787.
>
> "Flow liveness" is a path property, not a global one, a function of the
> minimum timeout of all connection-breaking state along the path. I suspect
> that endpoint pairs in a world ruled by UDP state timeout will end up
> widely deploy simple probing algorithms to discover it whether or not
> there's a simple way to signal that state can be disposed of early.
>
> This is really a separate issue, though -- the question about state
> disposal is disjoiny from how to keep flow start signaling from ossifying
> into an unintentional magic packet sequence you have to show the network.
> It makes sense to think about the "grippiness" of the protocol in terms of
> the eventual endpoint as well as management reqt's though.
>
> > Thus we end up with the tension between the documented wire image that
> > says that there is a "done" signal, and the actual wire image, which
> > has activity every 30 seconds.  Add genuine cases of migration,
> > crashes, stateless resets, and the other reasons that the "done"
> > signal doesn't appear and the timer has to come down.
> >
> > There might be benefits if everything comes together, but it's a long
> > game to play.
>
> I've been having some variant of this particular conversation for (checks
> watch) about four years now. ;)


Honestly, we should be checking a sundial.

If I'm understanding that the problem is what happens when signals are
unreliable and devices have to include workarounds that accommodate missed
signals, I THINK that's a conversation I overheard sometime around 2000, in
L2Triggers. I wasn't a participant in that conversation, but IIRC, the
reason that TRIGTRAN's scope was limited to first-hop routers in 2002 was
because of the problems L2Triggers had identified with signals coming from
routers that weren't locally attached, and we couldn't turn TRIGTRAN into
something useful even with that limitation.

The signals being discussed aren't the same signals, but the problems sound
very, very familiar.

Keeping in mind that I started Section 4 of
https://tools.ietf.org/html/draft-dawkins-panrg-what-not-to-do-00 with
TRIGTRAN, that's probably not an good sign ...

Do the right thing, of course.

Spencer

--00000000000040726305692e805f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi, Brian,

On Fri, Apr 6, 2018 at 7:54 AM, Brian Trammell (IETF) <ietf@t=
rammell.ch> wrote:
hi Martin,



> On 6 Apr 2018, at 12:55, Martin Thomson <martin.thomson@gmail.com> wrote:

>

> I don't know how to game this one out.

>

> If we're looking for mutual benefit, the best I can come up with i=
s

> that the middlebox knows about flow up/down, so it can extend timeouts=


> for most flows and endpoints thereby enjoy better chance of flow

> liveness after longer periods of quiescence.=C2=A0 That would be somet=
hing

> like with TCP where you can expect timeouts to be in the order of

> minutes or tens of minutes (30 minutes if you pick the right port

> number) and not merely tens of seconds.



Flow down in this case is way more useful than flow up.



> The problem here is that you need enough of the middlebox population
> to extend timeouts in the common case.=C2=A0 Tuning to specific networ=
ks is

> difficult and time-consuming.=C2=A0 So endpoints would deploy this &qu=
ot;grip"

> without any expectation of reciprocation for potentially a very long
> time.=C2=A0 That's in the order of the end-of-life cycle for home =
routers,

> or an entire Internet era.



We, as a community, are currently managing transitions that have tak=
en that long. Insert your favorite IPv6 joke here, of course, but ECN comes=
 to mind as well.



> In the meantime, endpoints have to assume flow liveness based on the
> Internet of today.=C2=A0 30s is the benchmark now, despite the wishful=


> "requirement" for 2 minutes in RFC 4787.



"Flow liveness" is a path property, not a global one, a fu=
nction of the minimum timeout of all connection-breaking state along the pa=
th. I suspect that endpoint pairs in a world ruled by UDP state timeout wil=
l end up widely deploy simple probing algorithms to discover it whether or =
not there's a simple way to signal that state can be disposed of early.=




This is really a separate issue, though -- the question about state disposa=
l is disjoiny from how to keep flow start signaling from ossifying into an =
unintentional magic packet sequence you have to show the network. It makes =
sense to think about the "grippiness" of the protocol in terms of=
 the eventual endpoint as well as management reqt's though.



> Thus we end up with the tension between the documented wire image that=


> says that there is a "done" signal, and the actual wire imag=
e, which

> has activity every 30 seconds.=C2=A0 Add genuine cases of migration,
> crashes, stateless resets, and the other reasons that the "done&q=
uot;

> signal doesn't appear and the timer has to come down.

>

> There might be benefits if everything comes together, but it's a l=
ong

> game to play.



I've been having some variant of this particular conversation fo=
r (checks watch) about four years now. ;)

H=
onestly, we should be checking a sundial.=C2=A0

If=
 I'm understanding that the problem is what happens when signals are un=
reliable and devices have to include workarounds that accommodate missed si=
gnals, I THINK that's a conversation I overheard sometime around 2000, =
in L2Triggers. I wasn't a participant in that conversation, but IIRC, t=
he reason that TRIGTRAN's scope was limited to first-hop routers in 200=
2 was because of the problems L2Triggers had identified with signals coming=
 from routers that weren't locally attached, and we couldn't turn T=
RIGTRAN into something useful even with that limitation.=C2=A0
The signals being discussed aren't the same signals, but t=
he problems sound very, very familiar.=C2=A0

Keepi=
ng in mind that I started Section 4 of=C2=A0https://tools.ietf.org/html/=
draft-dawkins-panrg-what-not-to-do-00 with TRIGTRAN, that's probabl=
y not an good sign ...=C2=A0

Do the right thing, o=
f course.

Spencer


--00000000000040726305692e805f--


From nobody Fri Apr  6 09:11:04 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492AC1204DA for ; Fri,  6 Apr 2018 09:11: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, 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 vh3a-4lI1uP4 for ; Fri,  6 Apr 2018 09:11:00 -0700 (PDT)
Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::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 03891126BF7 for ; Fri,  6 Apr 2018 09:11:00 -0700 (PDT)
Received: by mail-pl0-x22a.google.com with SMTP id 91-v6so911722pld.3 for ; Fri, 06 Apr 2018 09:10:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7ozfEsnmO0I1sHGeuruGo1Txd1paEOT7w8hLhaFevqo=; b=RPcHF3nudSQoubIB7eL39LEl3a+aqVgR/qwWugGqxP0jETFuvEbKk2RoRcVkfsGZcR PmSfqhVGH+RGSLvWzP1RQMXV16S1raolzJVmStMsJRM7C8q3iwd9YVTfHimBpk1D/KUx +KTrzB7jADudldlXIN8SQJyC+/FNnlsLiubx+MYoh3SkmcWg0YR5/4DcmBTSgGOh4IIs /CQP6KHAXeq7g26h5RD+Z8HJZZ3DMc3jKN7jA8jvjyn2XJ5MWSgpzBGlU4vsVEbwCIIf 7ewXvvkdYTjHFLxPjgCbGtLB5CZLs0rQ29wIIiC9tbDcWLRlridOZtNUA3cyxmLjeSHC 3duw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=7ozfEsnmO0I1sHGeuruGo1Txd1paEOT7w8hLhaFevqo=; b=eI2leIdfQ06Tz9lLrhA4FwcpPYNOZ01rHo0Fs5gj9sCc9TeWik6mrxS5cxjRkqzFMc wM91YyOIV71JknKwnF+YZh8UDo5jEMGuMX8qC2kG3isaQtMr17U2PMQ+v2mgpMSTQHQc 7LpXi/QyefEDLH7evHQ9Po8l6hQONYvVfVxdzXxj/9Fll5fswv97vRlkK7wkp+YmOTr2 RRbHuXAcqKO/PhVXwE//jaSVszyiRSHwiyxG7B2ZhWurUx8AymCKnqXPJCmHWY1zyWT3 /dfJS6ftjy+hjJxPpX7Wj8EgJvL5wSn20led7QsG+rptkYj0AFX+Q00w0SV7UlluqxIy 22hA==
X-Gm-Message-State: AElRT7HePh+TFgOGPT9Wy1DzNKBS5kH2E074UesLHfXZqF0m9dcZvlll KfMTJhJ/GJ7TbvnYkxm9DYoCM7+lFxxpwraF3amgOUtN
X-Google-Smtp-Source: AIpwx4/EMGzLD/EqsmlW04JJAAAmyPIfZWMCy7krbQwIKAbv9cirMc5o7NHPJyltiPPOGiPec0yrrKemma0IDsPXBDs=
X-Received: by 2002:a17:902:bd91:: with SMTP id q17-v6mr26109251pls.330.1523031059230;  Fri, 06 Apr 2018 09:10:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Fri, 6 Apr 2018 09:10:58 -0700 (PDT)
In-Reply-To: <8AAF21B8-5008-46EE-ACE1-FA2588DE9D20@trammell.ch>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>    <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch>  <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch>    <8AAF21B8-5008-46EE-ACE1-FA2588DE9D20@trammell.ch>
From: Kazuho Oku 
Date: Sat, 7 Apr 2018 01:10:58 +0900
Message-ID: 
Subject: Re: Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption))
To: "Brian Trammell (IETF)" 
Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= ,  Christian Huitema , QUIC WG ,  Martin Thomson , Frederick Kautz 
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: Fri, 06 Apr 2018 16:11:02 -0000

2018-04-06 21:39 GMT+09:00 Brian Trammell (IETF) :
> hi Kazuho,
>
> Thanks for your message, comments inline, omitting some history for clari=
ty...
>
>> On 6 Apr 2018, at 12:10, Kazuho Oku  wrote:
>>
>> Hi Brian,
>>
>> My comments inline.
>>
>> 2018-04-06 18:38 GMT+09:00 Brian Trammell (IETF) :
>>>
>>>
>>> However, I would submit that if we think we are in a position where:
>>>
>>> - there is a strong incentive for firewalls/NATs to want to see start- =
(and end-) of flow (which seems to me to be the threat model we're trying t=
o mitigate with this); and
>>>
>>> - we do not want arbitrary information in the QUIC wire image to be use=
d to detect these conditions, since that might cause bits of the wire image=
 we don't want to end up in the accidental invariants;
>>>
>>> then we really should consider adding explicit advisory flow state sign=
als, both for establishment and teardown. The theory here is that if you gi=
ve in-network functions a "grip" in the wire image of the protocol they can=
 use for state management, they won't try to grab on to the slippery bits. =
Together with probabilistic migration, these signals would divorce "on-path=
 state" from "transport session state", reducing the privacy impact with re=
spect to SYN/FIN in TCP.
>>
>> I think that this is a very interesting question asking what the
>> requirements of QUIC as a protocol is. Thank you for bringing the
>> topic to table.
>>
>> My argument against having an explicit signal for flow creation is
>> that it is impossible to have such signal in a reliable way, and that
>> trying to have no signal is better than having an unreliable signal.
>
> I should say I'm not all that convinced that an advisory "flow start" sig=
nal is a good idea(*) -- I'm just saying that we seem to be trying very har=
d to keep a de facto advisory flow start signal from forming (which I would=
 agree would be extremely undesirable indeed)... and we should step back an=
d think about what properties flow start and end should have in QUIC, expli=
citly, as a function of requirements as opposed to philosophy.

Thank you for the clarification.

>> Let me explain why I think we cannot have a reliable signal.
>
>  All this makes very good sense and I agree with it: the signal can=
not possibly be reliable in the general case.
>
>> For flow closure, I think saving the battery by not sending a FIN
>> packet after quiescence is more important than sending good signal to
>> middleboxes
>
> This is a hard problem, and it cuts both ways; if a server wants to maint=
ain the ability to connect a client after more than the standard UDP NAT ti=
meout (30s), it needs to send keepalives more often than once every 30s (th=
ereby waking the client if it's on battery). Which side of this coin wastes=
 more power is difficult to determine, since it's entirely dependent on the=
 prevalence of each kind of activity in a given network. We can make plausi=
ble guesses both in favor of "get rid of FIN, it wastes endpoint power" or =
"we really need FIN to keep from wasting endpoint power".

The case of server reviving the connection is interesting.

If we are to have some signal, I think that should be "path-visible
indication of consent to continue communicating" as you describe,
specifically, as a signal that can be set on every packet for which,
at the moment of sending, the endpoint is sure that the server will
not send any more packets unless it receives a new packet from the
client.

A NAT aware of the signal can drop an idle UDP flow on which the last
packet had that flag set, after couple of round-trips, thereby giving
other flows a longer idle timeout.

The benefit of defining the signal this way is that there would be no
need to send FIN after quiescence to shut down the hole.

That said, I would prefer not discussing this as a feature of QUICv1
for several reasons: i) this can be implemented in v2 ii) having such
signal is not going give us benefit in the short-term, so no need to
hurry iii) many of us are interested in shipping v1 as early as
possible iv) HTTP (which is the application protocol in focus for v1)
is not going to suffer a lot from the server-revives-connection
problem since HTTP is a request-response protocol.

>
> So I'm more convinced of the value of advisory-end than advisory-start.
>
>>> (The alternative is to make the wire image so inscrutable that on-path =
state tracking becomes completely futile and goes away. I'm not sure we're =
that good at inscrutable wire images.)
>>
>> I would rather argue that the goal of the alternative approach is to
>> make the intentional flow creation not easily distinguishable to the
>> extent that the middlebox vendors will refer to the RFC. Then, they
>> can decide either to not limit QUIC flows starting from a 1-RTT
>> packet, or to drop QUIC completely. And the issue is solved.
>
>
> Let me try to rephrase this in wildly different terminology: "we can't co=
me up with a grip that we think will wotk, so we should make flow start as =
slippery as possible"; or rather, a middlebox that thinks it's seeing QUIC =
should make its drop decision based on "this is QUIC" and not anything base=
d on the state of the connection. That definitely has desirable properties =
with respect to future flexibility -- the start and end signaling would end=
 up in the invariants rather quickly whether intentional or not. And ISTM t=
hat the probabilistic migration behavior would help to achieve it.
>
> Cheers,
>
> Brian
>
>
> (*): "Advisory flow start" is somewhat different than "path-visible proof=
 of return routability" and "path-visible indication of consent to continue=
 communicating". The latter, IMO, has more value as part of a design to sup=
port in-network rejection of UDP garbage. But it's a more complex signal, s=
ince it involves revealing things that are hard to fake at flow establishme=
nt time, and is of course subject to the philosophical question of whether =
that's a good idea.
>



--=20
Kazuho Oku


From nobody Fri Apr  6 09:15:40 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D0B1204DA for ; Fri,  6 Apr 2018 09:15:38 -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 esjW5mD11j_s for ; Fri,  6 Apr 2018 09:15:36 -0700 (PDT)
Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::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 951B71200C5 for ; Fri,  6 Apr 2018 09:15:36 -0700 (PDT)
Received: by mail-pl0-x22a.google.com with SMTP id b6-v6so905490pla.11 for ; Fri, 06 Apr 2018 09:15:36 -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=gbqXfB1+ddM5jydrXDrE+WdYPXlgf2BfxGfSR6iquR4=; b=fe2SXqmG3aEKL+GHUbrvNS9JKX6DdhTaM0ALVcRib1eNaUr2vwS+NYYJAZayCZbiYo eR8x8X8yprkFzH4/xIXO69wunWNDt059kk6nX99b5mtonCGNAuh5U9fCfGhY8ESTRNc0 3ezjHxqA/xOfQBI86s1dxdpNQPEZfAsFUhiZSaloaIVfxgwpAlDc0V1Z1CopZ5ssUn6d +2Bac258vq6EAGjpqGRH2ztr71p9O2gMwi4A29oSqL8hUilIcjorx6k7HTPjxdQCj7fJ wddlkOlNj+cQ3hxCyv5Ak2P4LXJiW+qcBU6Fqbzf8r4Ub5kBmF3iomBrCMyxnjSqqBQB uPyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=gbqXfB1+ddM5jydrXDrE+WdYPXlgf2BfxGfSR6iquR4=; b=N4KBA81TC7zaHSM99zxF7JB/CcvXur5BVOzotTVVtj8+WWZPl8aOJmk4F5RmpGIyHg WjWqUatbzHWM8ebdKhWmrHjyQii6lYeaZ2qftyuIeOgOlkOhdOTPq/ckiflakOWW1OJM xZCHTIDpPz8yqAoa2U7qseHiNKcHQBicZv5V/acv9GTc/uWQOeW88jkXLjX9yyMey9L2 o0WDgyfZakypiU/azRIck2pZSasyWaxd/KyQcSZMrhmRzsiPDsT5qC25sv7g1GDjxoEC hw25Xe5liPC1RIQwzYJlHl/H51QipMJ7uY/nCeNOleo7wCvm631YLNuHxS+eRimvdCGQ 8rkQ==
X-Gm-Message-State: AElRT7HuzC1PrXTx1UZB0rPARMxT+75tblWQJaKfaj8bznE+qUltrCwt lYw1Rr2aeXlD8sg2bQaIsl25BJivNctzfrm3+v0=
X-Google-Smtp-Source: AIpwx48xhOybzjHzPdV07Wh6iS8Z5SJ1+NqokxHRP4x8mn+tQOSI92/IBx3MTdoldeHI5vDRHZjLDxemR3mr6HLSqt8=
X-Received: by 2002:a17:902:8ec8:: with SMTP id x8-v6mr28557257plo.179.1523031336213;  Fri, 06 Apr 2018 09:15:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Fri, 6 Apr 2018 09:15:35 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>    <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch>  <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch>  
From: Kazuho Oku 
Date: Sat, 7 Apr 2018 01:15:35 +0900
Message-ID: 
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)
To: Martin Thomson 
Cc: "Brian Trammell (IETF)" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= ,  QUIC WG , Christian Huitema ,  Frederick Kautz 
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, 06 Apr 2018 16:15:38 -0000

2018-04-06 19:40 GMT+09:00 Martin Thomson :
> On Fri, Apr 6, 2018 at 7:14 PM, Kazuho Oku  wrote:
>> One way to minimize the impact could be to suggest certain amount of
>> connections (e.g., 5%) to gratuitously migrate to a new tuple just once,
>> right after the connection is being established.
>
> I like this idea.  Do it rarely, but with a high enough probability
> that it is noticed.
>
> I don't think that we need to specify it, rather permit it (maybe with
> observations about the costs of doing it too often), then establish a
> convention.  We can reach enough of the client population in this
> group that we can probably coordinate effectively such that we reach a
> common enough proportion.  Add migrate-after-idle as the current PR
> suggests, which has a much lower chance of expanding state and I'm not
> seeing much need for "grips".

+1 to all the comments. The approach has very small (not if the least)
impact on existing QUIC implementations, middleboxes, and the
specification.

>
>> If we specify that way, we can assume that the impact on the NAT will be
>> having 5% more flows.
>
> 5% more only during the first timeout interval (whatever that is) and
> thereafter no more with this design.

Thank you for the correction. Nice catch :-)

-- 
Kazuho Oku


From nobody Fri Apr  6 09:31:58 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C12B126BF7 for ; Fri,  6 Apr 2018 09:31:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523032317; bh=sQjziYnvwUdJkn0vUPO8+gR1ii6bnRi6sx0+COX4z/c=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To; b=ah1H49/LxvmoNiFY7Hvfq2AKtFPvDz/h8hp7HjdxeU2vn9BUSSZFUuv/x+AheQrTr J9HCy1OSJU2JhhKKwegseWfXBvlKI87q7XuwKrn1V+7BVzmO0JrE6zl0Ti1nW0j1+o mN2YY9+rK918Hxl18C9H1B6L/FmzgzX+IUZE+5eM=
X-Mailbox-Line: From pravb@microsoft.com  Fri Apr  6 09:31:57 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 097E912025C; Fri,  6 Apr 2018 09:31:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523032317; bh=sQjziYnvwUdJkn0vUPO8+gR1ii6bnRi6sx0+COX4z/c=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To; b=ah1H49/LxvmoNiFY7Hvfq2AKtFPvDz/h8hp7HjdxeU2vn9BUSSZFUuv/x+AheQrTr J9HCy1OSJU2JhhKKwegseWfXBvlKI87q7XuwKrn1V+7BVzmO0JrE6zl0Ti1nW0j1+o mN2YY9+rK918Hxl18C9H1B6L/FmzgzX+IUZE+5eM=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECD2124D68 for ; Fri,  6 Apr 2018 09:31:56 -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, 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 QbrCZ6gxL5ZM for ; Fri,  6 Apr 2018 09:31:53 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe44::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32F212025C for ; Fri,  6 Apr 2018 09:31: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=sQjziYnvwUdJkn0vUPO8+gR1ii6bnRi6sx0+COX4z/c=; b=g6HS0crQjQdFKncKrVQSokHcCpABikJ+aORWZCC3mWZo/g16mT+6V9W8B3VHNs4rFI6vBaqmDwo5ylRfCp7pqFYpH00qsrxIacc7QHjjlVpR1+6utibjTg2la4du1pJHcIaRR/6ObYHH83UsdJz34YsM0qZb8qOpj5m8vXLNWzY=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0119.namprd21.prod.outlook.com (10.173.189.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Fri, 6 Apr 2018 16:31:51 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.005; Fri, 6 Apr 2018 16:31:51 +0000
From: Praveen Balasubramanian 
CC: Lars Eggert , Mark Nottingham , IETF QUIC WG , Patrick McManus 
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwkIMAgADKCACAADzkAIAAwwoggAAk8ACAAW7ogA==
Date: Fri, 6 Apr 2018 16:31:51 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>     <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:e::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0119; 7:4zQU+M9vhcxWliGc06WjVss9z/H3Y6jFJEpbQimpBga5L51O+ZyiCTA7RquZEwO0p5101xK+UVWw61Qz87xIMxTBRGWvuKRbZUkOen7kcQU1ThrWR//Z4q4OzxlMQAT6Pkuy+283sKDFzWtZ+rHdZNzF2jmC7A0nkBKbDpnydkdPRPjmA0DguZD93vmPte/I9hT4isW5GC2RIUxhhmbA1kupcSjsxw9I96eKfl7PCIdyv1j/3X0FMjf1hNZfB4ZN; 20:VivWvAZs/HKG7dNmihT59Nn6C3dCNZMrBzxEcL8VUazmJaorhr8FudUQso800v6lRV+J+/po/5PtWrJOwOKj8Usf5eVsxOjgc7fjZEnipz/7zmcvphrtDCI2F3LkzvjjLFeBU+OomWuPY9Y3Ke9yzCPczyZkOXx9YKS61Vuw7Ic=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: cd915fad-dc24-4347-e7df-08d59bdbe6b2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0119; 
x-ms-traffictypediagnostic: CY4PR21MB0119:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(85827821059158)(100405760836317); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0119; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0119; 
x-forefront-prvs: 0634F37BFF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39380400002)(366004)(39860400002)(189003)(199004)(13464003)(51444003)(5660300001)(81166006)(10290500003)(105586002)(10090500001)(99286004)(8990500004)(86612001)(8936002)(81156014)(8676002)(186003)(74316002)(102836004)(33656002)(53546011)(6506007)(7736002)(46003)(54906003)(305945005)(110136005)(53936002)(9686003)(6306002)(55016002)(4326008)(6246003)(106356001)(39060400002)(97736004)(2900100001)(6436002)(14454004)(25786009)(3660700001)(76176011)(6116002)(7696005)(2906002)(229853002)(86362001)(68736007)(11346002)(59450400001)(5250100002)(966005)(316002)(446003)(3280700002)(478600001)(486006)(476003)(22452003)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0119; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: r/fHlJ7jgJ2kgsD/Ml/a4H2DC7XV1QYpWCbLsaQtee3dbp+vV185+a6dqTJpf3sYMuzfX0ltkfwsSgUM8bjK3NRVL1XhBUz9JQn30GDX3cS8usfNEoCYfpREGsEKf9ptlG2p1Nf3AuF8xqCwAoEVeYbeMYXHSEBFskwWZ8EmFhuqTBnZhi444YBBZTUcVPs9Ei8bOtzto5LtpJZyM4TsByHUtO3ptQTp2FZ89nAieg70iFZIoDMW5eEPOP625CuJIQQ0ZKchUNfLjmtq0B5QmcN745y91HYKKj+NGDy2w1MhZcK26Eco8wVwmv8/U/3isd5xOjqRfF/bxaqXwgSBdvm5ZScRjJ/flFob81/gWDyARz0OtqIv3MhmofSDVfqgeneEB+B9vGjTNpbXK6d/dCkRimGWNmNUAyYgPTZuLbU=
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-Network-Message-Id: cd915fad-dc24-4347-e7df-08d59bdbe6b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 16:31:51.1819 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0119
To: Praveen Balasubramanian 
To: Martin Thomson 
To: Kazuho Oku 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 06 Apr 2018 16:31:57 -0000

VHJhbnNwb3J0IHBhcmFtZXRlcnMgY2FuIGFsc28gYmUgdXNlZCBmb3IgbmVnb3RpYXRpb24uIE9w
ZW5lZCBpc3N1ZSAjMTI3MSBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lz
c3Vlcy8xMjcxIGZvciBuZWdvdGlhdGlvbiBvZiBjb25uZWN0aW9uIG1pZ3JhdGlvbi4NCg0KLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KU2VudDogVGh1
cnNkYXksIEFwcmlsIDUsIDIwMTggMTE6MjcgQU0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh
biA8cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPjsgTWFydGluIFRob21zb24g
PG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5j
b20+DQpDYzogTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz47IE1hcmsgTm90dGluZ2hhbSA8
bW5vdEBtbm90Lm5ldD47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IFBhdHJpY2sgTWNN
YW51cyA8cG1jbWFudXNAbW96aWxsYS5jb20+DQpTdWJqZWN0OiBSRTogR2V0dGluZyB0byBjb25z
ZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCknigJlkIGxpa2UgdG8gY2xhcmlm
eSB0aGF0IHdoZW4gSSBzYWlkIHYxIGFuZCB2MiB0aGF0IHdlIHdpbGwgc2ltIHNoaXAgdGhlbSBp
biB0aGUgc2FtZSBSRkMuIEkgZGlkIG5vdCBpbnRlbmQgdG8gc3VnZ2VzdCBtb3ZpbmcgbWlncmF0
aW9uIG91dCBvZiBzY29wZS4gQW5kIHRoZW4gY2xpZW50cyB0aGF0IHdhbnQgdG8gbWlncmF0ZSBh
bmQgc2VydmVycyB0aGF0IHN1cHBvcnQgbWlncmF0aW9uIHdpbGwgbmVnb3RpYXRlIHYyIGFuZCBy
ZXN0IG9mIHRoZSBjYXNlcyB3aWxsICBiZSB2MS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP
ZiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDUsIDIwMTgg
OTo0MiBBTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+OyBL
YXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPg0KQ2M6IExhcnMgRWdnZXJ0IDxsYXJzQGVn
Z2VydC5vcmc+OyBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ+OyBJRVRGIFFVSUMgV0cg
PHF1aWNAaWV0Zi5vcmc+OyBQYXRyaWNrIE1jTWFudXMgPHBtY21hbnVzQG1vemlsbGEuY29tPg0K
U3ViamVjdDogUkU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlw
dGlvbg0KDQpMb3ZlIHRoaXMgaWRlYS4gRXhwYW5kaW5nIGl0IGEgYml0IGZ1cnRoZXIgSSBkb27i
gJl0IHRoaW5rIHdlIG5lZWQgdG8gbWFrZSBQTiB0cmFuc2Zvcm0gYSB0cmFuc3BvcnQgcGFyYW1l
dGVyIGJ1dCByYXRoZXIgY29ubmVjdGlvbiBtaWdyYXRpb24gaXRzZWxmLiBXZSBjb3VsZCBhbHNv
IHNpbXBseSB1c2UgUVVJQyB2ZXJzaW9uaW5nIGZvciB0aGlzLiANCg0KMS4gU2hpcCBRVUlDIHYx
IHdpdGggbm8gc3VwcG9ydCBmb3IgY29ubmVjdGlvbiBtaWdyYXRpb24uIFNlcnZlcnMgYmVoaW5k
IGxvYWQgYmFsYW5jZXJzIHRoYXQgYXJlIG5vdCBRVUlDIGF3YXJlIHdpbGwgb25seSBhZHZlcnRp
c2UgdGhpcyB2ZXJzaW9uLiBJIGV4cGVjdCB0aGlzIHRvIGJlIGEgbGFyZ2UgZnJhY3Rpb24gb2Yg
c2VydmVycyBlc3BlY2lhbGx5IHRob3NlIGhvc3RlZCBpbiBBV1MsIEF6dXJlLCBHQ1AuICpUaGlz
IGlzIGltcG9ydGFudCAtIEkgd2FudCB0aGUgZ3JvdXAgdG8gYWNrbm93bGVkZ2UgdGhhdCBzZXJ2
ZXJzIG5lZWRzIHRvIGJlIGFibGUgdG8gYWR2ZXJ0aXNlIHN1cHBvcnQgZm9yIGNvbm5lY3Rpb24g
bWlncmF0aW9uKi4NCjIuIFNoaXAgUVVJQyB2MiB3aXRoIHN1cHBvcnQgZm9yIGNvbm5lY3Rpb24g
bWlncmF0aW9uLiBJZiBhIGNsaWVudCBhbmQgc2VydmVyIHVzZSB0aGlzIHZlcnNpb24gdGhleSBN
VVNUIGRvIFBORSBhcyBwZXIgIzEwNzkuIElmIHdlIGZpbmQgYSBtb3JlIGVmZmljaWVudCBzY2hl
bWUgYmVmb3JlIE5vdmVtYmVyIHRoZW4gd2UgdXNlIHRoYXQgaW5zdGVhZC4gDQoNCkV2ZW50dWFs
bHkgd2Ugd2lsbCBzaGlwIFFVSVYgdk4gd2hpY2ggaGFzIHN1cHBvcnQgZm9yIG11bHRpLXBhdGgg
YW5kIHdlIGNhbiByZXZpc2l0IGlmIFBORSBpcyBuZWVkZWQgb3IgbXVsdGlwbGUgUE4gc3BhY2Vz
IHdpbGwgd29yay4gVW50aWwgdGhlbiBJIGNhbiBsaXZlIHdpdGggaGlnaGVyIENQVSBjb3N0IGZv
ciB0aGUgZnJhY3Rpb24gb2YgY29ubmVjdGlvbnMgdGhhdCB3aWxsIG1pZ3JhdGUuIA0KDQpOb3cg
dGhlcmUgaXMgdGhlIG9zc2lmaWNhdGlvbiBwcm9ibGVtIGluIFFVSUMgdjEgYXMgcmVmZXJyZWQg
dG8gYWJvdmUuIFdlIGFscmVhZHkgcmVxdWlyZSBhIHJhbmRvbSBzdGFydGluZyBQTi4gVGhlIG5l
eHQgcHJvYmxlbSBpcyBvbmUgdGhhdCBLYXp1aG8gYnJvdWdodCB1cCB3aGVyZSBtaWRkbGVib3hl
cyB3aWxsIHN0YXJ0IHNlZWluZyBzdHJpY3QgaW5jcmVhc2luZyBQTiBhbmQgdHJ5IHRvIHJlb3Jk
ZXIuIEkgd2FzIHRoaW5raW5nIGFib3V0IHNob3J0IHJhbmRvbSBqdW1wcyB0byBmaXggdGhpcyBw
cm9ibGVtIGJ1dCB0aGUgbW9ub3RvbmljIGluY3JlYXNlIHdpbGwgcmVtYWluLiBXaGlsZSBJIHRo
aW5rIHNhbmUgbWlkZGxlYm94ZXMgd2lsbCBub3QgZG8gYW55IHJlb3JkZXJpbmcsIHRoZXJlIG1p
Z2h0IGJlIGEgZmV3IGNyYXp5IG91dGxpZXJzIGxpa2Ugd2l0aCBUQ1AuIEkgdGhpbmsgd2UgY2Fu
IHNvbHZlIHRoaXMgYnkgbWFraW5nIHRoZSBpbiBjbGVhciBQTiBqdW1wIGJvdGggZm9yd2FyZCBh
bmQgYmFjayB3aXRoaW4gYSAicmVvcmRlcmluZyBkZWdyZWUiLiBJIGFtIHRoaW5raW5nIGFib3V0
IHNvbWUgaWRlYXMgaGVyZSBhbmQgd2lsbCByZXBseSBiYWNrIGlmIEkgZmluZCBhIHNpbXBsZSBz
Y2hlbWUuDQoNCj4+IEZXSVcsIHdoYXQgSSBnb3QgZnJvbSB0aGUgaW5mbyB0aGF0IFByYXZlZW4g
YW5kIElhbiBoYXZlIHNoYXJlZCBpcyANCj4+IHRoYXQgdGhlcmUgYXJlIGVub3VnaCBwcm9ibGVt
cyB0byBzb2x2ZSB3aXRoIFVEUCB0aGF0IHdvcnJ5aW5nIGFib3V0IA0KPj4gdGhlIHBlcmZvcm1h
bmNlIGhpdCBmcm9tIGVuY3J5cHRpb24gaXMgcHJlbWF0dXJlDQpNYXJ0aW4sIHdlIGhhdmUgcGxh
bnMgdG8gbWFrZSBVRFAgc2NyZWFtaW5nIGZhc3QgaW4gc29mdHdhcmUuIEJ1dCB0aGUgcmVhbCBh
ZHZhbnRhZ2UgZm9yIFRDUCBjb21lcyBmcm9tIHRoZSBiYXRjaCBvZmZsb2FkcyAoc2VlIGVtYWls
IHdpdGggc3ViamVjdCAiIEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0
YWNrIHBlcmZvcm1hbmNlIikuIEJhdGNoIG9mZmxvYWRzIGZvciBRVUlDIGFyZSBpbXBvc3NpYmxl
IHRvIGRvIHdpdGhvdXQgY3J5cHRvIG9mZmxvYWQuIEkgd291bGQgYmUgaGFwcHkgdG8gZXhwbGFp
biBtb3JlIG9uIHRoaXMgZnJvbnQuIEkgdGhpbmsgd2Ugd2lsbCBleGhhdXN0IHNvZnR3YXJlIG9w
dGltaXphdGlvbnMgc29vbiBhbmQgdGhlbiBnZXQgYmxvY2tlZCBvbiBjcnlwdG8gb2ZmbG9hZC4N
Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMt
Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnRpbiBUaG9tc29uDQpTZW50OiBXZWRu
ZXNkYXksIEFwcmlsIDQsIDIwMTggOTozNiBQTQ0KVG86IEthenVobyBPa3UgPGthenVob29rdUBn
bWFpbC5jb20+DQpDYzogTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz47IE1hcmsgTm90dGlu
Z2hhbSA8bW5vdEBtbm90Lm5ldD47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IFBhdHJp
Y2sgTWNNYW51cyA8cG1jbWFudXNAbW96aWxsYS5jb20+DQpTdWJqZWN0OiBSZTogR2V0dGluZyB0
byBjb25zZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCk9uIFRodSwgQXByIDUs
IDIwMTggYXQgMTA6NTcgQU0sIEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+IHdyb3Rl
Og0KPiBJdCBpcyB0cnVlIHRoYXQgIzEwNzkgaGFzIGlzc3VlcyB3aXRoIGhhcmR3YXJlIGNyeXB0
byBvZmZsb2FkLiBJIGFtIA0KPiBoYXBweSB0byBzdXBwb3J0IHN3aXRjaGluZyB0byBhIGJldHRl
ciBlbmNyeXB0aW9uIHNjaGVtZSAoaWYgd2UgZmluZA0KPiBvbmUpIGF0IGFueSBtb21lbnQ7IGUu
Zy4sIGR1cmluZyB0aGUgc3RhbmRhcmRpemF0aW9uIG9mIFFVSUN2MSwgb3IgYXMgDQo+IGFuIGV4
dGVuc2lvbiB0byB2MSwgb3IgcGFydCBvZiB2WC4NCg0KVW50aWwgdGhpcyBjYW1lIHVwLCBJIGhh
ZG4ndCBjb25zaWRlcmVkIHRoZSB1c2Ugb2YgYW4gZXh0ZW5zaW9uL3RyYW5zcG9ydCBwYXJhbWV0
ZXIgdG8gbmVnb3RpYXRlIGEgbmV3IHNjaGVtZSwgYnV0IGl0J3Mgb2J2aW91cy4gIFRoaXMgZml0
cyBiZXN0IHdpdGggbXkgdmlldyBvZiB0aGluZ3MuDQoNCklmIHRoYXQgbWVhbnMgdGhhdCB3ZSBn
ZXQgdGhlIERDLVFVSUMgb3B0aW9uIHRoYXQgdHVybnMgdGhlIHBhY2tldCBudW1iZXIgZW5jcnlw
dGlvbiBmdW5jdGlvbiBpbnRvIGlkZW50aXR5IG9yIHNvbWUgY2hlYXBlciBmdW5jdGlvbiwgdGhl
biBJIHRoaW5rIHRoYXQncyBhbiBPSyBvdXRjb21lLiAgV2Ugc2hvdWxkIHN0b3AgcHJldGVuZGlu
ZyB0aGF0IG9uZSBzaXplIGZpdHMgYWxsIGlzIGFjaGlldmFibGU7IGl0J3Mgbm90IGJlZW4gdGhl
IGNhc2UgZm9yIHllYXJzIGFscmVhZHkuDQoNCkZXSVcsIHdoYXQgSSBnb3QgZnJvbSB0aGUgaW5m
byB0aGF0IFByYXZlZW4gYW5kIElhbiBoYXZlIHNoYXJlZCBpcyB0aGF0IHRoZXJlIGFyZSBlbm91
Z2ggcHJvYmxlbXMgdG8gc29sdmUgd2l0aCBVRFAgdGhhdCB3b3JyeWluZyBhYm91dCB0aGUgcGVy
Zm9ybWFuY2UgaGl0IGZyb20gZW5jcnlwdGlvbiBpcyBwcmVtYXR1cmUuDQoNCg==


From nobody Fri Apr  6 09:32:04 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71179127136 for ; Fri,  6 Apr 2018 09:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 N5lBerfa6c1f for ; Fri,  6 Apr 2018 09:31:53 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0128.outbound.protection.outlook.com [104.47.36.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3377124D37 for ; Fri,  6 Apr 2018 09:31: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=sQjziYnvwUdJkn0vUPO8+gR1ii6bnRi6sx0+COX4z/c=; b=g6HS0crQjQdFKncKrVQSokHcCpABikJ+aORWZCC3mWZo/g16mT+6V9W8B3VHNs4rFI6vBaqmDwo5ylRfCp7pqFYpH00qsrxIacc7QHjjlVpR1+6utibjTg2la4du1pJHcIaRR/6ObYHH83UsdJz34YsM0qZb8qOpj5m8vXLNWzY=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0119.namprd21.prod.outlook.com (10.173.189.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Fri, 6 Apr 2018 16:31:51 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.005; Fri, 6 Apr 2018 16:31:51 +0000
From: Praveen Balasubramanian 
To: Praveen Balasubramanian , Martin Thomson , Kazuho Oku 
CC: Lars Eggert , Mark Nottingham , IETF QUIC WG , Patrick McManus 
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwkIMAgADKCACAADzkAIAAwwoggAAk8ACAAW7ogA==
Date: Fri, 6 Apr 2018 16:31:51 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>     <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:e::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0119; 7:4zQU+M9vhcxWliGc06WjVss9z/H3Y6jFJEpbQimpBga5L51O+ZyiCTA7RquZEwO0p5101xK+UVWw61Qz87xIMxTBRGWvuKRbZUkOen7kcQU1ThrWR//Z4q4OzxlMQAT6Pkuy+283sKDFzWtZ+rHdZNzF2jmC7A0nkBKbDpnydkdPRPjmA0DguZD93vmPte/I9hT4isW5GC2RIUxhhmbA1kupcSjsxw9I96eKfl7PCIdyv1j/3X0FMjf1hNZfB4ZN; 20:VivWvAZs/HKG7dNmihT59Nn6C3dCNZMrBzxEcL8VUazmJaorhr8FudUQso800v6lRV+J+/po/5PtWrJOwOKj8Usf5eVsxOjgc7fjZEnipz/7zmcvphrtDCI2F3LkzvjjLFeBU+OomWuPY9Y3Ke9yzCPczyZkOXx9YKS61Vuw7Ic=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: cd915fad-dc24-4347-e7df-08d59bdbe6b2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0119; 
x-ms-traffictypediagnostic: CY4PR21MB0119:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(85827821059158)(100405760836317); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0119; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0119; 
x-forefront-prvs: 0634F37BFF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39380400002)(366004)(39860400002)(189003)(199004)(13464003)(51444003)(5660300001)(81166006)(10290500003)(105586002)(10090500001)(99286004)(8990500004)(86612001)(8936002)(81156014)(8676002)(186003)(74316002)(102836004)(33656002)(53546011)(6506007)(7736002)(46003)(54906003)(305945005)(110136005)(53936002)(9686003)(6306002)(55016002)(4326008)(6246003)(106356001)(39060400002)(97736004)(2900100001)(6436002)(14454004)(25786009)(3660700001)(76176011)(6116002)(7696005)(2906002)(229853002)(86362001)(68736007)(11346002)(59450400001)(5250100002)(966005)(316002)(446003)(3280700002)(478600001)(486006)(476003)(22452003)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0119; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: r/fHlJ7jgJ2kgsD/Ml/a4H2DC7XV1QYpWCbLsaQtee3dbp+vV185+a6dqTJpf3sYMuzfX0ltkfwsSgUM8bjK3NRVL1XhBUz9JQn30GDX3cS8usfNEoCYfpREGsEKf9ptlG2p1Nf3AuF8xqCwAoEVeYbeMYXHSEBFskwWZ8EmFhuqTBnZhi444YBBZTUcVPs9Ei8bOtzto5LtpJZyM4TsByHUtO3ptQTp2FZ89nAieg70iFZIoDMW5eEPOP625CuJIQQ0ZKchUNfLjmtq0B5QmcN745y91HYKKj+NGDy2w1MhZcK26Eco8wVwmv8/U/3isd5xOjqRfF/bxaqXwgSBdvm5ZScRjJ/flFob81/gWDyARz0OtqIv3MhmofSDVfqgeneEB+B9vGjTNpbXK6d/dCkRimGWNmNUAyYgPTZuLbU=
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-Network-Message-Id: cd915fad-dc24-4347-e7df-08d59bdbe6b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 16:31:51.1819 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0119
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 06 Apr 2018 16:31:57 -0000

VHJhbnNwb3J0IHBhcmFtZXRlcnMgY2FuIGFsc28gYmUgdXNlZCBmb3IgbmVnb3RpYXRpb24uIE9w
ZW5lZCBpc3N1ZSAjMTI3MSBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lz
c3Vlcy8xMjcxIGZvciBuZWdvdGlhdGlvbiBvZiBjb25uZWN0aW9uIG1pZ3JhdGlvbi4NCg0KLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KU2VudDogVGh1
cnNkYXksIEFwcmlsIDUsIDIwMTggMTE6MjcgQU0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh
biA8cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPjsgTWFydGluIFRob21zb24g
PG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5j
b20+DQpDYzogTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz47IE1hcmsgTm90dGluZ2hhbSA8
bW5vdEBtbm90Lm5ldD47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IFBhdHJpY2sgTWNN
YW51cyA8cG1jbWFudXNAbW96aWxsYS5jb20+DQpTdWJqZWN0OiBSRTogR2V0dGluZyB0byBjb25z
ZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCknigJlkIGxpa2UgdG8gY2xhcmlm
eSB0aGF0IHdoZW4gSSBzYWlkIHYxIGFuZCB2MiB0aGF0IHdlIHdpbGwgc2ltIHNoaXAgdGhlbSBp
biB0aGUgc2FtZSBSRkMuIEkgZGlkIG5vdCBpbnRlbmQgdG8gc3VnZ2VzdCBtb3ZpbmcgbWlncmF0
aW9uIG91dCBvZiBzY29wZS4gQW5kIHRoZW4gY2xpZW50cyB0aGF0IHdhbnQgdG8gbWlncmF0ZSBh
bmQgc2VydmVycyB0aGF0IHN1cHBvcnQgbWlncmF0aW9uIHdpbGwgbmVnb3RpYXRlIHYyIGFuZCBy
ZXN0IG9mIHRoZSBjYXNlcyB3aWxsICBiZSB2MS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP
ZiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDUsIDIwMTgg
OTo0MiBBTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+OyBL
YXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPg0KQ2M6IExhcnMgRWdnZXJ0IDxsYXJzQGVn
Z2VydC5vcmc+OyBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ+OyBJRVRGIFFVSUMgV0cg
PHF1aWNAaWV0Zi5vcmc+OyBQYXRyaWNrIE1jTWFudXMgPHBtY21hbnVzQG1vemlsbGEuY29tPg0K
U3ViamVjdDogUkU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlw
dGlvbg0KDQpMb3ZlIHRoaXMgaWRlYS4gRXhwYW5kaW5nIGl0IGEgYml0IGZ1cnRoZXIgSSBkb27i
gJl0IHRoaW5rIHdlIG5lZWQgdG8gbWFrZSBQTiB0cmFuc2Zvcm0gYSB0cmFuc3BvcnQgcGFyYW1l
dGVyIGJ1dCByYXRoZXIgY29ubmVjdGlvbiBtaWdyYXRpb24gaXRzZWxmLiBXZSBjb3VsZCBhbHNv
IHNpbXBseSB1c2UgUVVJQyB2ZXJzaW9uaW5nIGZvciB0aGlzLiANCg0KMS4gU2hpcCBRVUlDIHYx
IHdpdGggbm8gc3VwcG9ydCBmb3IgY29ubmVjdGlvbiBtaWdyYXRpb24uIFNlcnZlcnMgYmVoaW5k
IGxvYWQgYmFsYW5jZXJzIHRoYXQgYXJlIG5vdCBRVUlDIGF3YXJlIHdpbGwgb25seSBhZHZlcnRp
c2UgdGhpcyB2ZXJzaW9uLiBJIGV4cGVjdCB0aGlzIHRvIGJlIGEgbGFyZ2UgZnJhY3Rpb24gb2Yg
c2VydmVycyBlc3BlY2lhbGx5IHRob3NlIGhvc3RlZCBpbiBBV1MsIEF6dXJlLCBHQ1AuICpUaGlz
IGlzIGltcG9ydGFudCAtIEkgd2FudCB0aGUgZ3JvdXAgdG8gYWNrbm93bGVkZ2UgdGhhdCBzZXJ2
ZXJzIG5lZWRzIHRvIGJlIGFibGUgdG8gYWR2ZXJ0aXNlIHN1cHBvcnQgZm9yIGNvbm5lY3Rpb24g
bWlncmF0aW9uKi4NCjIuIFNoaXAgUVVJQyB2MiB3aXRoIHN1cHBvcnQgZm9yIGNvbm5lY3Rpb24g
bWlncmF0aW9uLiBJZiBhIGNsaWVudCBhbmQgc2VydmVyIHVzZSB0aGlzIHZlcnNpb24gdGhleSBN
VVNUIGRvIFBORSBhcyBwZXIgIzEwNzkuIElmIHdlIGZpbmQgYSBtb3JlIGVmZmljaWVudCBzY2hl
bWUgYmVmb3JlIE5vdmVtYmVyIHRoZW4gd2UgdXNlIHRoYXQgaW5zdGVhZC4gDQoNCkV2ZW50dWFs
bHkgd2Ugd2lsbCBzaGlwIFFVSVYgdk4gd2hpY2ggaGFzIHN1cHBvcnQgZm9yIG11bHRpLXBhdGgg
YW5kIHdlIGNhbiByZXZpc2l0IGlmIFBORSBpcyBuZWVkZWQgb3IgbXVsdGlwbGUgUE4gc3BhY2Vz
IHdpbGwgd29yay4gVW50aWwgdGhlbiBJIGNhbiBsaXZlIHdpdGggaGlnaGVyIENQVSBjb3N0IGZv
ciB0aGUgZnJhY3Rpb24gb2YgY29ubmVjdGlvbnMgdGhhdCB3aWxsIG1pZ3JhdGUuIA0KDQpOb3cg
dGhlcmUgaXMgdGhlIG9zc2lmaWNhdGlvbiBwcm9ibGVtIGluIFFVSUMgdjEgYXMgcmVmZXJyZWQg
dG8gYWJvdmUuIFdlIGFscmVhZHkgcmVxdWlyZSBhIHJhbmRvbSBzdGFydGluZyBQTi4gVGhlIG5l
eHQgcHJvYmxlbSBpcyBvbmUgdGhhdCBLYXp1aG8gYnJvdWdodCB1cCB3aGVyZSBtaWRkbGVib3hl
cyB3aWxsIHN0YXJ0IHNlZWluZyBzdHJpY3QgaW5jcmVhc2luZyBQTiBhbmQgdHJ5IHRvIHJlb3Jk
ZXIuIEkgd2FzIHRoaW5raW5nIGFib3V0IHNob3J0IHJhbmRvbSBqdW1wcyB0byBmaXggdGhpcyBw
cm9ibGVtIGJ1dCB0aGUgbW9ub3RvbmljIGluY3JlYXNlIHdpbGwgcmVtYWluLiBXaGlsZSBJIHRo
aW5rIHNhbmUgbWlkZGxlYm94ZXMgd2lsbCBub3QgZG8gYW55IHJlb3JkZXJpbmcsIHRoZXJlIG1p
Z2h0IGJlIGEgZmV3IGNyYXp5IG91dGxpZXJzIGxpa2Ugd2l0aCBUQ1AuIEkgdGhpbmsgd2UgY2Fu
IHNvbHZlIHRoaXMgYnkgbWFraW5nIHRoZSBpbiBjbGVhciBQTiBqdW1wIGJvdGggZm9yd2FyZCBh
bmQgYmFjayB3aXRoaW4gYSAicmVvcmRlcmluZyBkZWdyZWUiLiBJIGFtIHRoaW5raW5nIGFib3V0
IHNvbWUgaWRlYXMgaGVyZSBhbmQgd2lsbCByZXBseSBiYWNrIGlmIEkgZmluZCBhIHNpbXBsZSBz
Y2hlbWUuDQoNCj4+IEZXSVcsIHdoYXQgSSBnb3QgZnJvbSB0aGUgaW5mbyB0aGF0IFByYXZlZW4g
YW5kIElhbiBoYXZlIHNoYXJlZCBpcyANCj4+IHRoYXQgdGhlcmUgYXJlIGVub3VnaCBwcm9ibGVt
cyB0byBzb2x2ZSB3aXRoIFVEUCB0aGF0IHdvcnJ5aW5nIGFib3V0IA0KPj4gdGhlIHBlcmZvcm1h
bmNlIGhpdCBmcm9tIGVuY3J5cHRpb24gaXMgcHJlbWF0dXJlDQpNYXJ0aW4sIHdlIGhhdmUgcGxh
bnMgdG8gbWFrZSBVRFAgc2NyZWFtaW5nIGZhc3QgaW4gc29mdHdhcmUuIEJ1dCB0aGUgcmVhbCBh
ZHZhbnRhZ2UgZm9yIFRDUCBjb21lcyBmcm9tIHRoZSBiYXRjaCBvZmZsb2FkcyAoc2VlIGVtYWls
IHdpdGggc3ViamVjdCAiIEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0
YWNrIHBlcmZvcm1hbmNlIikuIEJhdGNoIG9mZmxvYWRzIGZvciBRVUlDIGFyZSBpbXBvc3NpYmxl
IHRvIGRvIHdpdGhvdXQgY3J5cHRvIG9mZmxvYWQuIEkgd291bGQgYmUgaGFwcHkgdG8gZXhwbGFp
biBtb3JlIG9uIHRoaXMgZnJvbnQuIEkgdGhpbmsgd2Ugd2lsbCBleGhhdXN0IHNvZnR3YXJlIG9w
dGltaXphdGlvbnMgc29vbiBhbmQgdGhlbiBnZXQgYmxvY2tlZCBvbiBjcnlwdG8gb2ZmbG9hZC4N
Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMt
Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnRpbiBUaG9tc29uDQpTZW50OiBXZWRu
ZXNkYXksIEFwcmlsIDQsIDIwMTggOTozNiBQTQ0KVG86IEthenVobyBPa3UgPGthenVob29rdUBn
bWFpbC5jb20+DQpDYzogTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz47IE1hcmsgTm90dGlu
Z2hhbSA8bW5vdEBtbm90Lm5ldD47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IFBhdHJp
Y2sgTWNNYW51cyA8cG1jbWFudXNAbW96aWxsYS5jb20+DQpTdWJqZWN0OiBSZTogR2V0dGluZyB0
byBjb25zZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCk9uIFRodSwgQXByIDUs
IDIwMTggYXQgMTA6NTcgQU0sIEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+IHdyb3Rl
Og0KPiBJdCBpcyB0cnVlIHRoYXQgIzEwNzkgaGFzIGlzc3VlcyB3aXRoIGhhcmR3YXJlIGNyeXB0
byBvZmZsb2FkLiBJIGFtIA0KPiBoYXBweSB0byBzdXBwb3J0IHN3aXRjaGluZyB0byBhIGJldHRl
ciBlbmNyeXB0aW9uIHNjaGVtZSAoaWYgd2UgZmluZA0KPiBvbmUpIGF0IGFueSBtb21lbnQ7IGUu
Zy4sIGR1cmluZyB0aGUgc3RhbmRhcmRpemF0aW9uIG9mIFFVSUN2MSwgb3IgYXMgDQo+IGFuIGV4
dGVuc2lvbiB0byB2MSwgb3IgcGFydCBvZiB2WC4NCg0KVW50aWwgdGhpcyBjYW1lIHVwLCBJIGhh
ZG4ndCBjb25zaWRlcmVkIHRoZSB1c2Ugb2YgYW4gZXh0ZW5zaW9uL3RyYW5zcG9ydCBwYXJhbWV0
ZXIgdG8gbmVnb3RpYXRlIGEgbmV3IHNjaGVtZSwgYnV0IGl0J3Mgb2J2aW91cy4gIFRoaXMgZml0
cyBiZXN0IHdpdGggbXkgdmlldyBvZiB0aGluZ3MuDQoNCklmIHRoYXQgbWVhbnMgdGhhdCB3ZSBn
ZXQgdGhlIERDLVFVSUMgb3B0aW9uIHRoYXQgdHVybnMgdGhlIHBhY2tldCBudW1iZXIgZW5jcnlw
dGlvbiBmdW5jdGlvbiBpbnRvIGlkZW50aXR5IG9yIHNvbWUgY2hlYXBlciBmdW5jdGlvbiwgdGhl
biBJIHRoaW5rIHRoYXQncyBhbiBPSyBvdXRjb21lLiAgV2Ugc2hvdWxkIHN0b3AgcHJldGVuZGlu
ZyB0aGF0IG9uZSBzaXplIGZpdHMgYWxsIGlzIGFjaGlldmFibGU7IGl0J3Mgbm90IGJlZW4gdGhl
IGNhc2UgZm9yIHllYXJzIGFscmVhZHkuDQoNCkZXSVcsIHdoYXQgSSBnb3QgZnJvbSB0aGUgaW5m
byB0aGF0IFByYXZlZW4gYW5kIElhbiBoYXZlIHNoYXJlZCBpcyB0aGF0IHRoZXJlIGFyZSBlbm91
Z2ggcHJvYmxlbXMgdG8gc29sdmUgd2l0aCBVRFAgdGhhdCB3b3JyeWluZyBhYm91dCB0aGUgcGVy
Zm9ybWFuY2UgaGl0IGZyb20gZW5jcnlwdGlvbiBpcyBwcmVtYXR1cmUuDQoNCg==


From nobody Fri Apr  6 09:42:42 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DBC12025C for ; Fri,  6 Apr 2018 09:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523032960; bh=DNihmcXGH24m7oY01xyGDT6sUIZ8iwBPeIKbyOuNxno=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=He250+f6e+x4gGQm7nzlEoHnHU60ov9cFPLoOhU42Z7P4idUHzWGSl/X2v3oWtxC+ 89lz5j+2DIDIPZlEbNtz+vDqZLv0Vo8J6VdShDUEzBKRm2W/L2AA7E9T56DkltGU3e CSCElqRFeO7lw7NMmrKqiM1B5o/ssJWjyTPCbgAk=
X-Mailbox-Line: From pravb@microsoft.com  Fri Apr  6 09:42:40 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 157CF124D37 for ; Fri,  6 Apr 2018 09:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523032960; bh=DNihmcXGH24m7oY01xyGDT6sUIZ8iwBPeIKbyOuNxno=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=He250+f6e+x4gGQm7nzlEoHnHU60ov9cFPLoOhU42Z7P4idUHzWGSl/X2v3oWtxC+ 89lz5j+2DIDIPZlEbNtz+vDqZLv0Vo8J6VdShDUEzBKRm2W/L2AA7E9T56DkltGU3e CSCElqRFeO7lw7NMmrKqiM1B5o/ssJWjyTPCbgAk=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA28B12025C for ; Fri,  6 Apr 2018 09:42:39 -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 kpEdn4U_Zd-u for ; Fri,  6 Apr 2018 09:42:37 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E48124D37 for ; Fri,  6 Apr 2018 09:42:36 -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=DNihmcXGH24m7oY01xyGDT6sUIZ8iwBPeIKbyOuNxno=; b=k9GZBJd8MMq8RzcyGcGE7u9wexoxYj+hiSe1NXfkxWI0In5c5K79Df98NH5gVR7HTKIBw8PxUBKPPWnK8UnJ5iAQd5OHNJC1vCDm4Sj4rRv1LfKwLYazcyiH02AajX2Mo3kOXovkN38b93WqgjO+aH35cBLe0MrkLCB0Sg5sMmo=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0629.namprd21.prod.outlook.com (10.175.115.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Fri, 6 Apr 2018 16:42:35 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.005; Fri, 6 Apr 2018 16:42:35 +0000
From: Praveen Balasubramanian 
CC: IETF QUIC WG 
Subject: RE: Server's Preferred Address
Thread-Topic: Server's Preferred Address
Thread-Index: AdPM/yWWCvy2v59cR66uoZGAhfklJAABDakAADCsN6A=
Date: Fri, 6 Apr 2018 16:42:35 +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::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0629; 7:MvDty+kggXS3Lxj+H/Wvb3COFf5EkL6w8/QK69FS3p3W2s1WJ1AO/hm3WDauT0/FsK9pI7MKgyG5HZEVdnIhVRexiiGXhoueUjCd5yRI3Mo2mXVwR3iDJRNp4fj7YsO2keXsSPwF6SHJYLiTbmM4ZQI+4RLCrVtVBMimx4m9eX4rz0agERbZsss6NXR9BbNHqoFqEYtKn7r5kKYoWkNdBrxPx3SVbyq7lq485dnNn30SAEPAIZsjUwFSbFj6Dv7S; 20:+nipggyTNOUt1ebK4LepEOR3TsqI5R2/hx5hHwkjisH9SgF0eZOs/PLVZqetk7/Vl6+OZsGXmQjzVZK7wAGG7tZnGJ4Cl2ff4tsW+qUKq3qyhYMKRte/yKN/wvdAZ/u43g9dy8OTzQYZYnLwilSyqHEGxwsxqpWJj8DSNEZ6IKw=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 9f4d8cdc-4976-480a-d467-08d59bdd6679
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0629; 
x-ms-traffictypediagnostic: CY4PR21MB0629:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0629; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0629; 
x-forefront-prvs: 0634F37BFF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(376002)(366004)(346002)(396003)(189003)(199004)(316002)(86612001)(6116002)(76176011)(790700001)(97736004)(22452003)(33656002)(5250100002)(2900100001)(7696005)(99286004)(229853002)(3480700004)(105586002)(486006)(8936002)(5660300001)(53936002)(14454004)(3660700001)(54896002)(10090500001)(8990500004)(6306002)(236005)(6436002)(7736002)(9686003)(10290500003)(55016002)(68736007)(81166006)(8676002)(19609705001)(25786009)(74316002)(81156014)(478600001)(46003)(2906002)(86362001)(3280700002)(446003)(476003)(6506007)(110136005)(53546011)(6246003)(186003)(4326008)(102836004)(59450400001)(11346002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0629; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: EWteQnUcubyLh0Je2XitHihM3uFkgWaqw8pQaJYJOKrH2hYBA6TE8gRfMo/hEa7cflQ9dZwgcpO/AMIDDGd1k5yU4ONSo6we8evbtoYOfTpU6TUj14XXmibXjtJozHvaOA0z4DizYfTgGSKd/qnnhF+uTYcUjoEdvdBUpz25Am2nwgD8sw68xtBxjtgmKA7YANiVRewCjIvz0hdoRfdMeUzPwSdbjZXuKF2ey6BSdg4MIovPRDlY6RFi6+QZrDY0htZcn4NbMrjgc1AvJ6z3zqmR0CnQJ0KbMMs2z4A6MC5hMSQAft741uV3yv6xf3tJvXiFmpCa5ruCwBoj3YCu79/KgjuS7QwhD2K6/JOoEGIsEUzZnFmqG3OS+PJOMlx7D3YzAK7x3PBK4RKvRvN20NuMOVWyHS8hRm0VrsQsrZg=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630C0111186D33D21EA3FB6B6BA0CY4PR21MB0630namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f4d8cdc-4976-480a-d467-08d59bdd6679
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 16:42:35.0609 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0629
To: Ian Swett 
To: Mike Bishop 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 06 Apr 2018 16:42:40 -0000

--_000_CY4PR21MB0630C0111186D33D21EA3FB6B6BA0CY4PR21MB0630namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SWYgY29ubmVjdGlvbiBtaWdyYXRpb24gaXMgbmVnb3RpYXRlZCBhcyBzdWdnZXN0ZWQgaW4gaXNz
dWUgMTI3MSwgdGhlbiB3ZSBjYW4gbWFrZSB0aGUgU0hPVUxEIGEgTVVTVC4gVGhlIHNlcnZlciBj
YW5ub3Qgb2YgY291cnNlIHZhbGlkYXRlIHRoZSBhdHRlbXB0IGJ1dCB0aGUgY2xpZW50IG9ubHkg
ZW5kcyB1cCBsb3NpbmcgaXRzIG93biBjb25uZWN0aW9uIGFuZCBwb3NzaWJseSBmbGFnZ2VkIGZv
ciBhIERvUyBhdHRhY2sgcG9zdCBtaWdyYXRpb24uDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWlj
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJYW4gU3dldHQNClNlbnQ6IFRodXJzZGF5
LCBBcHJpbCA1LCAyMDE4IDEwOjI3IEFNDQpUbzogTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVl
Zm91LmJlPg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBT
ZXJ2ZXIncyBQcmVmZXJyZWQgQWRkcmVzcw0KDQpJIGFuZCB0aGUgdHJhZmZpYyBlbmdpbmVlcnMg
SSB3b3JrIHdpdGggd291bGQgUkVBTExZIGxpa2UgdG8gaGF2ZSB0aGlzIGZlYXR1cmUuICBBbHNv
LCBpbiBwcmFjdGljZSBpdCdzIHJlcXVpcmVkIHRvIG1ha2UgY29ubmVjdGlvbiBtaWdyYXRpb24g
d29yayB3aXRoIGFueWNhc3QuDQoNCkF0IEdvb2dsZSwgd2UndmUgc3RhcnRlZCBleHBlcmltZW50
aW5nIHdpdGggdGhpcyBhbHJlYWR5IGluIGdRVUlDLCBhbmQgaXQgd29ya3MgYXMgZXhwZWN0ZWQs
IHRob3VnaCB5b3UgZG8gbmVlZCB0byBwcm9iZSBiZWZvcmUganVtcGluZyB0byB0aGUgbmV3IHNl
cnZlciBJUChhcyBkZXNjcmliZWQgaW4gTWlrZSdzIFBSKSwgb3IgeW91IHJpc2sgYSBzbWFsbCBi
dXQgdmlzaWJsZSBudW1iZXIgb2YgY29ubmVjdGlvbiBmYWlsdXJlcyBwb3N0LWhhbmRzaGFrZS4N
Cg0KT24gVGh1LCBBcHIgNSwgMjAxOCBhdCAxOjE5IFBNIE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2
ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+PiB3cm90ZToNCkFzIHdlIHdh
bGsgYWxvbmcgdGhlIHNwZWN0cnVtIGZyb20gZml4ZWQgNC10dXBsZSBmb3IgdGhlIGxpZmUgb2Yg
YSBjb25uZWN0aW9uIHRvIGZ1bGwgbXVsdGlwYXRoLCAjNTYwIHJlcXVlc3RlZCBhIHNvbHV0aW9u
IHRvIHRoZSBwcm9ibGVtIG9mIEFueWNhc3QgSVAgYWRkcmVzc2VzLiAgVGhlcmUgYXJlIHNvbWUg
bGFyZ2Ugc2VydmVyIGRlcGxveW1lbnRzIHdoZXJlIHRoZSBmcm9udC1lbmQgYWRkcmVzc2VzIGFy
ZSBBbnljYXN0LWJhc2VkLiAgSG93ZXZlciwgZm9yIGEgY29ubmVjdGlvbi1vcmllbnRlZCBwcm90
b2NvbCwgeW91IHdhbnQgdG8gYmUg4oCcc3RpY2t54oCdIHRvIHRoZSBzZXJ2ZXIgZW5kcG9pbnQg
dGhhdCB5b3UgZGlkIHRoZSBoYW5kc2hha2Ugd2l0aC4gIEN1cnJlbnRseSwgdGhhdOKAmXMgYWRk
cmVzc2VkIHdpdGggc29tZSBhbW91bnQgb2YgcmUtZm9yd2FyZGluZyBpbnRlcm5hbGx5IGFuZCBz
b21lIGFtb3VudCBvZiB0b2xlcmF0ZWQgY29ubmVjdGlvbiBicmVha2FnZS4gIFRoaXMgZ2V0cyBt
b3JlIHBhaW5mdWwgaWYgd2Ugc3VwcG9ydCBjb25uZWN0aW9uIG1pZ3JhdGlvbiwgYXMgdGhlIHNh
bWUgQW55Y2FzdCBhZGRyZXNzIGxpa2VseSBoaXRzIGEgZGlmZmVyZW50IHNlcnZlciBmcm9tIHlv
dXIgbmV3IElQIGFkZHJlc3MuDQoNClBSIzEyNTEgYnVpbGRzIG9uIHRoZSBwYXRoIHZlcmlmaWNh
dGlvbiBhcHByb2FjaCB0byBlbmFibGUgc2VydmVycyB0byBoYW5kIG9mZiB0byBhIHVuaWNhc3Qg
SVAgYWRkcmVzcyBpZiBkZXNpcmVkLiAgSXQgYWRkcyBhIHRyYW5zcG9ydCBwYXJhbWV0ZXIgaW4g
d2hpY2ggdGhlIHNlcnZlciBzdXBwbGllczoNCg0KICAqICAgSVAgdmVyc2lvbg0KICAqICAgSVAg
YWRkcmVzcw0KICAqICAgVURQIHBvcnQNCiAgKiAgIENvbm5lY3Rpb24gSUQgKHBvc3NpYmx5IGVt
cHR5KQ0KICAqICAgU3RhdGVsZXNzIFJlc2V0IFRva2VuDQoNCkF0IHRoZSBlbmQgb2YgdGhlIGhh
bmRzaGFrZSwgdGhlIGNsaWVudCBTSE9VTEQgcGVyZm9ybSBwYXRoIHZhbGlkYXRpb24gb24gdGhl
IHN1cHBsaWVkIGFkZHJlc3M7IGlmIGl0IHN1Y2NlZWRzLCBpdCB0cmFuc2l0aW9ucyB0byB0aGUg
bmV3IGFkZHJlc3MuICBJZiBpdCBmYWlscywgaXQganVzdCBzdGF5cyBvbiB0aGUgb3JpZ2luYWwg
KHByZXN1bWFibHkgQW55Y2FzdCkgYWRkcmVzcyBhbmQgdGFrZXMgdGhlIHJpc2sgdGhhdCB0aGUg
Y29ubmVjdGlvbiB3aWxsIGZhaWwgd2hlbiByb3V0aW5nIGNoYW5nZXMuICAoVGhlIFNIT1VMRCBp
cyBhIG1hdHRlciBvZiBzb21lIGNvbnRlbnRpb24g4oCTIHNlcnZlcnMgd2FudCB0byBiZSBhYmxl
IHRvIHJlbHkgb24gdGhpcywgYnV0IGNhbuKAmXQgYWN0dWFsbHkgdGVsbCB3aGV0aGVyIHRoZSBj
bGllbnTigJlzIHBhdGggdmFsaWRhdGlvbiBmYWlsZWQgb3Igd2FzIG5ldmVyIGF0dGVtcHRlZC4p
DQoNCkl04oCZcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoaXMgaXNu4oCZdCBmdWxsIHNlcnZl
ciBtaWdyYXRpb24g4oCTIGl04oCZcyBhIHN0ZXAgaW4gdGhhdCBkaXJlY3Rpb24sIGJ1dCB0aGlz
IGlzIHNjb3BlZCBzdHJpY3RseSB0byB0aGUgc2VydmVyIG1ha2luZyBvbmUgY2hhbmdlIGF0dGVt
cHQgdG8gYW4gYWRkcmVzcyBpdCBwcm92aWRlcyBhdCBhIHNwZWNpZmllZCB0aW1lLiAgSG93ZXZl
ciwgdGhpcyBpc27igJl0IHNvbWV0aGluZyB0aGF0IGhhcyBzZWVuIGJyb2FkIGRpc2N1c3Npb24s
IHNvIEkgd2FudGVkIHRvIHJhaXNlIGl0IGZvciB0aGUgV0figJlzIGNvbnNpZGVyYXRpb24uDQoN
CihJZiB3ZSB3YW50IHRvIHRhY2tsZSBzZXJ2ZXIgbWlncmF0aW9uLCBJIHRoaW5rIHRoZSBuZXh0
IHBpZWNlIHdvdWxkIGJlIGEgZnJhbWUgdGhhdCBjYXJyaWVzIGVzc2VudGlhbGx5IHRoZSBzYW1l
IGluZm9ybWF0aW9uLCByZXF1ZXN0aW5nIHRoZSBjbGllbnQgdG8gbWFrZSBhIHByb2JlIGF0dGVt
cHQuICBUaGlzIGhlbHBzIGRlYWwgd2l0aCBOQVRzIGJ5IG1ha2luZyBjbGllbnRzIHNwZWFrIGZp
cnN0LCBidXQgaXQgYXNzdW1lcyB0aGF0IHRoZSBzZXJ2ZXIgYWx3YXlzIG1haW50YWlucyBjb250
cm9sIG9mIGJvdGggYWRkcmVzc2VzIGR1cmluZyBhIHRyYW5zaXRpb24uICBUbyBzdXBwb3J0IGZ1
bGwgUDJQLCB3aGVyZSBib3RoIHNpZGVzIGNvdWxkIGJlIG1ha2UtYWZ0ZXItYnJlYWssIHlvdSBi
YXNpY2FsbHkgbmVlZCBzb21ldGhpbmcgbGlrZSBJQ0UuKQ0K

--_000_CY4PR21MB0630C0111186D33D21EA3FB6B6BA0CY4PR21MB0630namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC
My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv
ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S
RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj
b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt
LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft
YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9
DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu
aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs
dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw
ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN
Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs
MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn
aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN
CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt
c28tbGlzdC1pZDo1OTc2NDQ5NTY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDIzMDE3MjAw
O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwy
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i
b2w7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu
c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2
ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT
eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6
bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6OTE5NzUxNDI5Ow0KCW1zby1saXN0
LXRlbXBsYXRlLWlkczoxNjQ0NzE2MTQ2O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT
eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6
bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg
bDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGlu
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp
c3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z
aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTow
aW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i
RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGNvbm5lY3Rpb24gbWlncmF0aW9uIGlzIG5l
Z290aWF0ZWQgYXMgc3VnZ2VzdGVkIGluIGlzc3VlIDEyNzEsIHRoZW4gd2UgY2FuIG1ha2UgdGhl
IFNIT1VMRCBhIE1VU1QuIFRoZSBzZXJ2ZXIgY2Fubm90IG9mIGNvdXJzZSB2YWxpZGF0ZSB0aGUg
YXR0ZW1wdCBidXQgdGhlIGNsaWVudCBvbmx5IGVuZHMgdXAgbG9zaW5nIGl0cyBvd24gY29ubmVj
dGlvbiBhbmQgcG9zc2libHkgZmxhZ2dlZCBmb3IgYSBEb1MNCiBhdHRhY2sgcG9zdCBtaWdyYXRp
b24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVp
Yy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5JYW4gU3dldHQ8YnI+DQo8
Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDUsIDIwMTggMTA6MjcgQU08YnI+DQo8Yj5Ubzo8
L2I+IE1pa2UgQmlzaG9wICZsdDttYmlzaG9wQGV2ZXF1ZWZvdS5iZSZndDs8YnI+DQo8Yj5DYzo8
L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUmU6IFNlcnZlcidzIFByZWZlcnJlZCBBZGRyZXNzPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSBhbmQgdGhlIHRyYWZmaWMgZW5naW5lZXJzIEkgd29yayB3aXRoIHdv
dWxkIFJFQUxMWSBsaWtlIHRvIGhhdmUgdGhpcyBmZWF0dXJlLiZuYnNwOyBBbHNvLCBpbiBwcmFj
dGljZSBpdCdzIHJlcXVpcmVkIHRvIG1ha2UgY29ubmVjdGlvbiBtaWdyYXRpb24gd29yayB3aXRo
IGFueWNhc3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
QXQgR29vZ2xlLCB3ZSd2ZSBzdGFydGVkIGV4cGVyaW1lbnRpbmcgd2l0aCB0aGlzIGFscmVhZHkg
aW4gZ1FVSUMsIGFuZCBpdCB3b3JrcyBhcyBleHBlY3RlZCwgdGhvdWdoIHlvdSBkbyBuZWVkIHRv
IHByb2JlIGJlZm9yZSBqdW1waW5nIHRvIHRoZSBuZXcgc2VydmVyIElQKGFzIGRlc2NyaWJlZCBp
biBNaWtlJ3MgUFIpLCBvciB5b3UgcmlzayBhIHNtYWxsIGJ1dCB2aXNpYmxlIG51bWJlciBvZiBj
b25uZWN0aW9uDQogZmFpbHVyZXMgcG9zdC1oYW5kc2hha2UuJm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEFwciA1LCAyMDE4IGF0IDE6
MTkgUE0gTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5i
ZSI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND
Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgd2Ugd2FsayBhbG9uZyB0aGUg
c3BlY3RydW0gZnJvbSBmaXhlZCA0LXR1cGxlIGZvciB0aGUgbGlmZSBvZiBhIGNvbm5lY3Rpb24g
dG8gZnVsbCBtdWx0aXBhdGgsICM1NjAgcmVxdWVzdGVkIGEgc29sdXRpb24gdG8gdGhlIHByb2Js
ZW0gb2YgQW55Y2FzdCBJUCBhZGRyZXNzZXMuJm5ic3A7IFRoZXJlIGFyZSBzb21lDQogbGFyZ2Ug
c2VydmVyIGRlcGxveW1lbnRzIHdoZXJlIHRoZSBmcm9udC1lbmQgYWRkcmVzc2VzIGFyZSBBbnlj
YXN0LWJhc2VkLiZuYnNwOyBIb3dldmVyLCBmb3IgYSBjb25uZWN0aW9uLW9yaWVudGVkIHByb3Rv
Y29sLCB5b3Ugd2FudCB0byBiZSDigJxzdGlja3nigJ0gdG8gdGhlIHNlcnZlciBlbmRwb2ludCB0
aGF0IHlvdSBkaWQgdGhlIGhhbmRzaGFrZSB3aXRoLiZuYnNwOyBDdXJyZW50bHksIHRoYXTigJlz
IGFkZHJlc3NlZCB3aXRoIHNvbWUgYW1vdW50IG9mIHJlLWZvcndhcmRpbmcNCiBpbnRlcm5hbGx5
IGFuZCBzb21lIGFtb3VudCBvZiB0b2xlcmF0ZWQgY29ubmVjdGlvbiBicmVha2FnZS4mbmJzcDsg
VGhpcyBnZXRzIG1vcmUgcGFpbmZ1bCBpZiB3ZSBzdXBwb3J0IGNvbm5lY3Rpb24gbWlncmF0aW9u
LCBhcyB0aGUgc2FtZSBBbnljYXN0IGFkZHJlc3MgbGlrZWx5IGhpdHMgYSBkaWZmZXJlbnQgc2Vy
dmVyIGZyb20geW91ciBuZXcgSVAgYWRkcmVzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PlBSIzEyNTEgYnVpbGRzIG9uIHRoZSBwYXRoIHZlcmlmaWNhdGlvbiBhcHByb2FjaCB0byBlbmFi
bGUgc2VydmVycyB0byBoYW5kIG9mZiB0byBhIHVuaWNhc3QgSVAgYWRkcmVzcyBpZiBkZXNpcmVk
LiZuYnNwOyBJdCBhZGRzIGEgdHJhbnNwb3J0IHBhcmFtZXRlciBpbiB3aGljaCB0aGUgc2VydmVy
IHN1cHBsaWVzOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQpJUCB2ZXJzaW9uPG86cD48L286
cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0K
SVAgYWRkcmVzczxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0
OmwwIGxldmVsMSBsZm8zIj4NClVEUCBwb3J0PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KQ29ubmVjdGlvbiBJRCAocG9zc2li
bHkgZW1wdHkpPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6
bDAgbGV2ZWwxIGxmbzMiPg0KU3RhdGVsZXNzIFJlc2V0IFRva2VuPG86cD48L286cD48L2xpPjwv
dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5BdCB0aGUgZW5kIG9mIHRoZSBoYW5kc2hha2UsIHRoZSBjbGllbnQg
U0hPVUxEIHBlcmZvcm0gcGF0aCB2YWxpZGF0aW9uIG9uIHRoZSBzdXBwbGllZCBhZGRyZXNzOyBp
ZiBpdCBzdWNjZWVkcywgaXQgdHJhbnNpdGlvbnMgdG8gdGhlIG5ldyBhZGRyZXNzLiZuYnNwOyBJ
ZiBpdCBmYWlscywgaXQganVzdCBzdGF5cyBvbg0KIHRoZSBvcmlnaW5hbCAocHJlc3VtYWJseSBB
bnljYXN0KSBhZGRyZXNzIGFuZCB0YWtlcyB0aGUgcmlzayB0aGF0IHRoZSBjb25uZWN0aW9uIHdp
bGwgZmFpbCB3aGVuIHJvdXRpbmcgY2hhbmdlcy4mbmJzcDsgKFRoZSBTSE9VTEQgaXMgYSBtYXR0
ZXIgb2Ygc29tZSBjb250ZW50aW9uIOKAkyBzZXJ2ZXJzIHdhbnQgdG8gYmUgYWJsZSB0byByZWx5
IG9uIHRoaXMsIGJ1dCBjYW7igJl0IGFjdHVhbGx5IHRlbGwgd2hldGhlciB0aGUgY2xpZW504oCZ
cyBwYXRoIHZhbGlkYXRpb24NCiBmYWlsZWQgb3Igd2FzIG5ldmVyIGF0dGVtcHRlZC4pPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdOKAmXMgaW1wb3J0YW50IHRvIG5vdGUgdGhhdCB0aGlz
IGlzbuKAmXQgZnVsbCBzZXJ2ZXIgbWlncmF0aW9uIOKAkyBpdOKAmXMgYSBzdGVwIGluIHRoYXQg
ZGlyZWN0aW9uLCBidXQgdGhpcyBpcyBzY29wZWQgc3RyaWN0bHkgdG8gdGhlIHNlcnZlciBtYWtp
bmcgb25lIGNoYW5nZSBhdHRlbXB0IHRvIGFuIGFkZHJlc3MgaXQNCiBwcm92aWRlcyBhdCBhIHNw
ZWNpZmllZCB0aW1lLiZuYnNwOyBIb3dldmVyLCB0aGlzIGlzbuKAmXQgc29tZXRoaW5nIHRoYXQg
aGFzIHNlZW4gYnJvYWQgZGlzY3Vzc2lvbiwgc28gSSB3YW50ZWQgdG8gcmFpc2UgaXQgZm9yIHRo
ZSBXR+KAmXMgY29uc2lkZXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPihJZiB3
ZSB3YW50IHRvIHRhY2tsZSBzZXJ2ZXIgbWlncmF0aW9uLCBJIHRoaW5rIHRoZSBuZXh0IHBpZWNl
IHdvdWxkIGJlIGEgZnJhbWUgdGhhdCBjYXJyaWVzIGVzc2VudGlhbGx5IHRoZSBzYW1lIGluZm9y
bWF0aW9uLCByZXF1ZXN0aW5nIHRoZSBjbGllbnQgdG8gbWFrZSBhIHByb2JlIGF0dGVtcHQuJm5i
c3A7IFRoaXMNCiBoZWxwcyBkZWFsIHdpdGggTkFUcyBieSBtYWtpbmcgY2xpZW50cyBzcGVhayBm
aXJzdCwgYnV0IGl0IGFzc3VtZXMgdGhhdCB0aGUgc2VydmVyIGFsd2F5cyBtYWludGFpbnMgY29u
dHJvbCBvZiBib3RoIGFkZHJlc3NlcyBkdXJpbmcgYSB0cmFuc2l0aW9uLiZuYnNwOyBUbyBzdXBw
b3J0IGZ1bGwgUDJQLCB3aGVyZSBib3RoIHNpZGVzIGNvdWxkIGJlIG1ha2UtYWZ0ZXItYnJlYWss
IHlvdSBiYXNpY2FsbHkgbmVlZCBzb21ldGhpbmcgbGlrZSBJQ0UuKTxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_CY4PR21MB0630C0111186D33D21EA3FB6B6BA0CY4PR21MB0630namp_--


From nobody Fri Apr  6 09:42:47 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7305E124D68 for ; Fri,  6 Apr 2018 09:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 YHK67_8j4630 for ; Fri,  6 Apr 2018 09:42:37 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0137.outbound.protection.outlook.com [104.47.40.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 CEA161200C5 for ; Fri,  6 Apr 2018 09:42:36 -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=DNihmcXGH24m7oY01xyGDT6sUIZ8iwBPeIKbyOuNxno=; b=k9GZBJd8MMq8RzcyGcGE7u9wexoxYj+hiSe1NXfkxWI0In5c5K79Df98NH5gVR7HTKIBw8PxUBKPPWnK8UnJ5iAQd5OHNJC1vCDm4Sj4rRv1LfKwLYazcyiH02AajX2Mo3kOXovkN38b93WqgjO+aH35cBLe0MrkLCB0Sg5sMmo=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0629.namprd21.prod.outlook.com (10.175.115.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Fri, 6 Apr 2018 16:42:35 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.005; Fri, 6 Apr 2018 16:42:35 +0000
From: Praveen Balasubramanian 
To: Ian Swett , Mike Bishop 
CC: IETF QUIC WG 
Subject: RE: Server's Preferred Address
Thread-Topic: Server's Preferred Address
Thread-Index: AdPM/yWWCvy2v59cR66uoZGAhfklJAABDakAADCsN6A=
Date: Fri, 6 Apr 2018 16:42:35 +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::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0629; 7:MvDty+kggXS3Lxj+H/Wvb3COFf5EkL6w8/QK69FS3p3W2s1WJ1AO/hm3WDauT0/FsK9pI7MKgyG5HZEVdnIhVRexiiGXhoueUjCd5yRI3Mo2mXVwR3iDJRNp4fj7YsO2keXsSPwF6SHJYLiTbmM4ZQI+4RLCrVtVBMimx4m9eX4rz0agERbZsss6NXR9BbNHqoFqEYtKn7r5kKYoWkNdBrxPx3SVbyq7lq485dnNn30SAEPAIZsjUwFSbFj6Dv7S; 20:+nipggyTNOUt1ebK4LepEOR3TsqI5R2/hx5hHwkjisH9SgF0eZOs/PLVZqetk7/Vl6+OZsGXmQjzVZK7wAGG7tZnGJ4Cl2ff4tsW+qUKq3qyhYMKRte/yKN/wvdAZ/u43g9dy8OTzQYZYnLwilSyqHEGxwsxqpWJj8DSNEZ6IKw=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 9f4d8cdc-4976-480a-d467-08d59bdd6679
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0629; 
x-ms-traffictypediagnostic: CY4PR21MB0629:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0629; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0629; 
x-forefront-prvs: 0634F37BFF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(376002)(366004)(346002)(396003)(189003)(199004)(316002)(86612001)(6116002)(76176011)(790700001)(97736004)(22452003)(33656002)(5250100002)(2900100001)(7696005)(99286004)(229853002)(3480700004)(105586002)(486006)(8936002)(5660300001)(53936002)(14454004)(3660700001)(54896002)(10090500001)(8990500004)(6306002)(236005)(6436002)(7736002)(9686003)(10290500003)(55016002)(68736007)(81166006)(8676002)(19609705001)(25786009)(74316002)(81156014)(478600001)(46003)(2906002)(86362001)(3280700002)(446003)(476003)(6506007)(110136005)(53546011)(6246003)(186003)(4326008)(102836004)(59450400001)(11346002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0629; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: EWteQnUcubyLh0Je2XitHihM3uFkgWaqw8pQaJYJOKrH2hYBA6TE8gRfMo/hEa7cflQ9dZwgcpO/AMIDDGd1k5yU4ONSo6we8evbtoYOfTpU6TUj14XXmibXjtJozHvaOA0z4DizYfTgGSKd/qnnhF+uTYcUjoEdvdBUpz25Am2nwgD8sw68xtBxjtgmKA7YANiVRewCjIvz0hdoRfdMeUzPwSdbjZXuKF2ey6BSdg4MIovPRDlY6RFi6+QZrDY0htZcn4NbMrjgc1AvJ6z3zqmR0CnQJ0KbMMs2z4A6MC5hMSQAft741uV3yv6xf3tJvXiFmpCa5ruCwBoj3YCu79/KgjuS7QwhD2K6/JOoEGIsEUzZnFmqG3OS+PJOMlx7D3YzAK7x3PBK4RKvRvN20NuMOVWyHS8hRm0VrsQsrZg=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630C0111186D33D21EA3FB6B6BA0CY4PR21MB0630namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f4d8cdc-4976-480a-d467-08d59bdd6679
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 16:42:35.0609 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0629
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 06 Apr 2018 16:42:40 -0000

--_000_CY4PR21MB0630C0111186D33D21EA3FB6B6BA0CY4PR21MB0630namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SWYgY29ubmVjdGlvbiBtaWdyYXRpb24gaXMgbmVnb3RpYXRlZCBhcyBzdWdnZXN0ZWQgaW4gaXNz
dWUgMTI3MSwgdGhlbiB3ZSBjYW4gbWFrZSB0aGUgU0hPVUxEIGEgTVVTVC4gVGhlIHNlcnZlciBj
YW5ub3Qgb2YgY291cnNlIHZhbGlkYXRlIHRoZSBhdHRlbXB0IGJ1dCB0aGUgY2xpZW50IG9ubHkg
ZW5kcyB1cCBsb3NpbmcgaXRzIG93biBjb25uZWN0aW9uIGFuZCBwb3NzaWJseSBmbGFnZ2VkIGZv
ciBhIERvUyBhdHRhY2sgcG9zdCBtaWdyYXRpb24uDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWlj
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJYW4gU3dldHQNClNlbnQ6IFRodXJzZGF5
LCBBcHJpbCA1LCAyMDE4IDEwOjI3IEFNDQpUbzogTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVl
Zm91LmJlPg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBT
ZXJ2ZXIncyBQcmVmZXJyZWQgQWRkcmVzcw0KDQpJIGFuZCB0aGUgdHJhZmZpYyBlbmdpbmVlcnMg
SSB3b3JrIHdpdGggd291bGQgUkVBTExZIGxpa2UgdG8gaGF2ZSB0aGlzIGZlYXR1cmUuICBBbHNv
LCBpbiBwcmFjdGljZSBpdCdzIHJlcXVpcmVkIHRvIG1ha2UgY29ubmVjdGlvbiBtaWdyYXRpb24g
d29yayB3aXRoIGFueWNhc3QuDQoNCkF0IEdvb2dsZSwgd2UndmUgc3RhcnRlZCBleHBlcmltZW50
aW5nIHdpdGggdGhpcyBhbHJlYWR5IGluIGdRVUlDLCBhbmQgaXQgd29ya3MgYXMgZXhwZWN0ZWQs
IHRob3VnaCB5b3UgZG8gbmVlZCB0byBwcm9iZSBiZWZvcmUganVtcGluZyB0byB0aGUgbmV3IHNl
cnZlciBJUChhcyBkZXNjcmliZWQgaW4gTWlrZSdzIFBSKSwgb3IgeW91IHJpc2sgYSBzbWFsbCBi
dXQgdmlzaWJsZSBudW1iZXIgb2YgY29ubmVjdGlvbiBmYWlsdXJlcyBwb3N0LWhhbmRzaGFrZS4N
Cg0KT24gVGh1LCBBcHIgNSwgMjAxOCBhdCAxOjE5IFBNIE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2
ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+PiB3cm90ZToNCkFzIHdlIHdh
bGsgYWxvbmcgdGhlIHNwZWN0cnVtIGZyb20gZml4ZWQgNC10dXBsZSBmb3IgdGhlIGxpZmUgb2Yg
YSBjb25uZWN0aW9uIHRvIGZ1bGwgbXVsdGlwYXRoLCAjNTYwIHJlcXVlc3RlZCBhIHNvbHV0aW9u
IHRvIHRoZSBwcm9ibGVtIG9mIEFueWNhc3QgSVAgYWRkcmVzc2VzLiAgVGhlcmUgYXJlIHNvbWUg
bGFyZ2Ugc2VydmVyIGRlcGxveW1lbnRzIHdoZXJlIHRoZSBmcm9udC1lbmQgYWRkcmVzc2VzIGFy
ZSBBbnljYXN0LWJhc2VkLiAgSG93ZXZlciwgZm9yIGEgY29ubmVjdGlvbi1vcmllbnRlZCBwcm90
b2NvbCwgeW91IHdhbnQgdG8gYmUg4oCcc3RpY2t54oCdIHRvIHRoZSBzZXJ2ZXIgZW5kcG9pbnQg
dGhhdCB5b3UgZGlkIHRoZSBoYW5kc2hha2Ugd2l0aC4gIEN1cnJlbnRseSwgdGhhdOKAmXMgYWRk
cmVzc2VkIHdpdGggc29tZSBhbW91bnQgb2YgcmUtZm9yd2FyZGluZyBpbnRlcm5hbGx5IGFuZCBz
b21lIGFtb3VudCBvZiB0b2xlcmF0ZWQgY29ubmVjdGlvbiBicmVha2FnZS4gIFRoaXMgZ2V0cyBt
b3JlIHBhaW5mdWwgaWYgd2Ugc3VwcG9ydCBjb25uZWN0aW9uIG1pZ3JhdGlvbiwgYXMgdGhlIHNh
bWUgQW55Y2FzdCBhZGRyZXNzIGxpa2VseSBoaXRzIGEgZGlmZmVyZW50IHNlcnZlciBmcm9tIHlv
dXIgbmV3IElQIGFkZHJlc3MuDQoNClBSIzEyNTEgYnVpbGRzIG9uIHRoZSBwYXRoIHZlcmlmaWNh
dGlvbiBhcHByb2FjaCB0byBlbmFibGUgc2VydmVycyB0byBoYW5kIG9mZiB0byBhIHVuaWNhc3Qg
SVAgYWRkcmVzcyBpZiBkZXNpcmVkLiAgSXQgYWRkcyBhIHRyYW5zcG9ydCBwYXJhbWV0ZXIgaW4g
d2hpY2ggdGhlIHNlcnZlciBzdXBwbGllczoNCg0KICAqICAgSVAgdmVyc2lvbg0KICAqICAgSVAg
YWRkcmVzcw0KICAqICAgVURQIHBvcnQNCiAgKiAgIENvbm5lY3Rpb24gSUQgKHBvc3NpYmx5IGVt
cHR5KQ0KICAqICAgU3RhdGVsZXNzIFJlc2V0IFRva2VuDQoNCkF0IHRoZSBlbmQgb2YgdGhlIGhh
bmRzaGFrZSwgdGhlIGNsaWVudCBTSE9VTEQgcGVyZm9ybSBwYXRoIHZhbGlkYXRpb24gb24gdGhl
IHN1cHBsaWVkIGFkZHJlc3M7IGlmIGl0IHN1Y2NlZWRzLCBpdCB0cmFuc2l0aW9ucyB0byB0aGUg
bmV3IGFkZHJlc3MuICBJZiBpdCBmYWlscywgaXQganVzdCBzdGF5cyBvbiB0aGUgb3JpZ2luYWwg
KHByZXN1bWFibHkgQW55Y2FzdCkgYWRkcmVzcyBhbmQgdGFrZXMgdGhlIHJpc2sgdGhhdCB0aGUg
Y29ubmVjdGlvbiB3aWxsIGZhaWwgd2hlbiByb3V0aW5nIGNoYW5nZXMuICAoVGhlIFNIT1VMRCBp
cyBhIG1hdHRlciBvZiBzb21lIGNvbnRlbnRpb24g4oCTIHNlcnZlcnMgd2FudCB0byBiZSBhYmxl
IHRvIHJlbHkgb24gdGhpcywgYnV0IGNhbuKAmXQgYWN0dWFsbHkgdGVsbCB3aGV0aGVyIHRoZSBj
bGllbnTigJlzIHBhdGggdmFsaWRhdGlvbiBmYWlsZWQgb3Igd2FzIG5ldmVyIGF0dGVtcHRlZC4p
DQoNCkl04oCZcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoaXMgaXNu4oCZdCBmdWxsIHNlcnZl
ciBtaWdyYXRpb24g4oCTIGl04oCZcyBhIHN0ZXAgaW4gdGhhdCBkaXJlY3Rpb24sIGJ1dCB0aGlz
IGlzIHNjb3BlZCBzdHJpY3RseSB0byB0aGUgc2VydmVyIG1ha2luZyBvbmUgY2hhbmdlIGF0dGVt
cHQgdG8gYW4gYWRkcmVzcyBpdCBwcm92aWRlcyBhdCBhIHNwZWNpZmllZCB0aW1lLiAgSG93ZXZl
ciwgdGhpcyBpc27igJl0IHNvbWV0aGluZyB0aGF0IGhhcyBzZWVuIGJyb2FkIGRpc2N1c3Npb24s
IHNvIEkgd2FudGVkIHRvIHJhaXNlIGl0IGZvciB0aGUgV0figJlzIGNvbnNpZGVyYXRpb24uDQoN
CihJZiB3ZSB3YW50IHRvIHRhY2tsZSBzZXJ2ZXIgbWlncmF0aW9uLCBJIHRoaW5rIHRoZSBuZXh0
IHBpZWNlIHdvdWxkIGJlIGEgZnJhbWUgdGhhdCBjYXJyaWVzIGVzc2VudGlhbGx5IHRoZSBzYW1l
IGluZm9ybWF0aW9uLCByZXF1ZXN0aW5nIHRoZSBjbGllbnQgdG8gbWFrZSBhIHByb2JlIGF0dGVt
cHQuICBUaGlzIGhlbHBzIGRlYWwgd2l0aCBOQVRzIGJ5IG1ha2luZyBjbGllbnRzIHNwZWFrIGZp
cnN0LCBidXQgaXQgYXNzdW1lcyB0aGF0IHRoZSBzZXJ2ZXIgYWx3YXlzIG1haW50YWlucyBjb250
cm9sIG9mIGJvdGggYWRkcmVzc2VzIGR1cmluZyBhIHRyYW5zaXRpb24uICBUbyBzdXBwb3J0IGZ1
bGwgUDJQLCB3aGVyZSBib3RoIHNpZGVzIGNvdWxkIGJlIG1ha2UtYWZ0ZXItYnJlYWssIHlvdSBi
YXNpY2FsbHkgbmVlZCBzb21ldGhpbmcgbGlrZSBJQ0UuKQ0K

--_000_CY4PR21MB0630C0111186D33D21EA3FB6B6BA0CY4PR21MB0630namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC
My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv
ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S
RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj
b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt
LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft
YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9
DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu
aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs
dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw
ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN
Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs
MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn
aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN
CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt
c28tbGlzdC1pZDo1OTc2NDQ5NTY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDIzMDE3MjAw
O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwy
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i
b2w7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu
c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2
ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT
eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6
bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6OTE5NzUxNDI5Ow0KCW1zby1saXN0
LXRlbXBsYXRlLWlkczoxNjQ0NzE2MTQ2O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT
eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6
bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg
bDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGlu
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp
c3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z
aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTow
aW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i
RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGNvbm5lY3Rpb24gbWlncmF0aW9uIGlzIG5l
Z290aWF0ZWQgYXMgc3VnZ2VzdGVkIGluIGlzc3VlIDEyNzEsIHRoZW4gd2UgY2FuIG1ha2UgdGhl
IFNIT1VMRCBhIE1VU1QuIFRoZSBzZXJ2ZXIgY2Fubm90IG9mIGNvdXJzZSB2YWxpZGF0ZSB0aGUg
YXR0ZW1wdCBidXQgdGhlIGNsaWVudCBvbmx5IGVuZHMgdXAgbG9zaW5nIGl0cyBvd24gY29ubmVj
dGlvbiBhbmQgcG9zc2libHkgZmxhZ2dlZCBmb3IgYSBEb1MNCiBhdHRhY2sgcG9zdCBtaWdyYXRp
b24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVp
Yy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5JYW4gU3dldHQ8YnI+DQo8
Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDUsIDIwMTggMTA6MjcgQU08YnI+DQo8Yj5Ubzo8
L2I+IE1pa2UgQmlzaG9wICZsdDttYmlzaG9wQGV2ZXF1ZWZvdS5iZSZndDs8YnI+DQo8Yj5DYzo8
L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUmU6IFNlcnZlcidzIFByZWZlcnJlZCBBZGRyZXNzPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSBhbmQgdGhlIHRyYWZmaWMgZW5naW5lZXJzIEkgd29yayB3aXRoIHdv
dWxkIFJFQUxMWSBsaWtlIHRvIGhhdmUgdGhpcyBmZWF0dXJlLiZuYnNwOyBBbHNvLCBpbiBwcmFj
dGljZSBpdCdzIHJlcXVpcmVkIHRvIG1ha2UgY29ubmVjdGlvbiBtaWdyYXRpb24gd29yayB3aXRo
IGFueWNhc3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
QXQgR29vZ2xlLCB3ZSd2ZSBzdGFydGVkIGV4cGVyaW1lbnRpbmcgd2l0aCB0aGlzIGFscmVhZHkg
aW4gZ1FVSUMsIGFuZCBpdCB3b3JrcyBhcyBleHBlY3RlZCwgdGhvdWdoIHlvdSBkbyBuZWVkIHRv
IHByb2JlIGJlZm9yZSBqdW1waW5nIHRvIHRoZSBuZXcgc2VydmVyIElQKGFzIGRlc2NyaWJlZCBp
biBNaWtlJ3MgUFIpLCBvciB5b3UgcmlzayBhIHNtYWxsIGJ1dCB2aXNpYmxlIG51bWJlciBvZiBj
b25uZWN0aW9uDQogZmFpbHVyZXMgcG9zdC1oYW5kc2hha2UuJm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEFwciA1LCAyMDE4IGF0IDE6
MTkgUE0gTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5i
ZSI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND
Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgd2Ugd2FsayBhbG9uZyB0aGUg
c3BlY3RydW0gZnJvbSBmaXhlZCA0LXR1cGxlIGZvciB0aGUgbGlmZSBvZiBhIGNvbm5lY3Rpb24g
dG8gZnVsbCBtdWx0aXBhdGgsICM1NjAgcmVxdWVzdGVkIGEgc29sdXRpb24gdG8gdGhlIHByb2Js
ZW0gb2YgQW55Y2FzdCBJUCBhZGRyZXNzZXMuJm5ic3A7IFRoZXJlIGFyZSBzb21lDQogbGFyZ2Ug
c2VydmVyIGRlcGxveW1lbnRzIHdoZXJlIHRoZSBmcm9udC1lbmQgYWRkcmVzc2VzIGFyZSBBbnlj
YXN0LWJhc2VkLiZuYnNwOyBIb3dldmVyLCBmb3IgYSBjb25uZWN0aW9uLW9yaWVudGVkIHByb3Rv
Y29sLCB5b3Ugd2FudCB0byBiZSDigJxzdGlja3nigJ0gdG8gdGhlIHNlcnZlciBlbmRwb2ludCB0
aGF0IHlvdSBkaWQgdGhlIGhhbmRzaGFrZSB3aXRoLiZuYnNwOyBDdXJyZW50bHksIHRoYXTigJlz
IGFkZHJlc3NlZCB3aXRoIHNvbWUgYW1vdW50IG9mIHJlLWZvcndhcmRpbmcNCiBpbnRlcm5hbGx5
IGFuZCBzb21lIGFtb3VudCBvZiB0b2xlcmF0ZWQgY29ubmVjdGlvbiBicmVha2FnZS4mbmJzcDsg
VGhpcyBnZXRzIG1vcmUgcGFpbmZ1bCBpZiB3ZSBzdXBwb3J0IGNvbm5lY3Rpb24gbWlncmF0aW9u
LCBhcyB0aGUgc2FtZSBBbnljYXN0IGFkZHJlc3MgbGlrZWx5IGhpdHMgYSBkaWZmZXJlbnQgc2Vy
dmVyIGZyb20geW91ciBuZXcgSVAgYWRkcmVzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PlBSIzEyNTEgYnVpbGRzIG9uIHRoZSBwYXRoIHZlcmlmaWNhdGlvbiBhcHByb2FjaCB0byBlbmFi
bGUgc2VydmVycyB0byBoYW5kIG9mZiB0byBhIHVuaWNhc3QgSVAgYWRkcmVzcyBpZiBkZXNpcmVk
LiZuYnNwOyBJdCBhZGRzIGEgdHJhbnNwb3J0IHBhcmFtZXRlciBpbiB3aGljaCB0aGUgc2VydmVy
IHN1cHBsaWVzOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQpJUCB2ZXJzaW9uPG86cD48L286
cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0K
SVAgYWRkcmVzczxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0
OmwwIGxldmVsMSBsZm8zIj4NClVEUCBwb3J0PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KQ29ubmVjdGlvbiBJRCAocG9zc2li
bHkgZW1wdHkpPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6
bDAgbGV2ZWwxIGxmbzMiPg0KU3RhdGVsZXNzIFJlc2V0IFRva2VuPG86cD48L286cD48L2xpPjwv
dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5BdCB0aGUgZW5kIG9mIHRoZSBoYW5kc2hha2UsIHRoZSBjbGllbnQg
U0hPVUxEIHBlcmZvcm0gcGF0aCB2YWxpZGF0aW9uIG9uIHRoZSBzdXBwbGllZCBhZGRyZXNzOyBp
ZiBpdCBzdWNjZWVkcywgaXQgdHJhbnNpdGlvbnMgdG8gdGhlIG5ldyBhZGRyZXNzLiZuYnNwOyBJ
ZiBpdCBmYWlscywgaXQganVzdCBzdGF5cyBvbg0KIHRoZSBvcmlnaW5hbCAocHJlc3VtYWJseSBB
bnljYXN0KSBhZGRyZXNzIGFuZCB0YWtlcyB0aGUgcmlzayB0aGF0IHRoZSBjb25uZWN0aW9uIHdp
bGwgZmFpbCB3aGVuIHJvdXRpbmcgY2hhbmdlcy4mbmJzcDsgKFRoZSBTSE9VTEQgaXMgYSBtYXR0
ZXIgb2Ygc29tZSBjb250ZW50aW9uIOKAkyBzZXJ2ZXJzIHdhbnQgdG8gYmUgYWJsZSB0byByZWx5
IG9uIHRoaXMsIGJ1dCBjYW7igJl0IGFjdHVhbGx5IHRlbGwgd2hldGhlciB0aGUgY2xpZW504oCZ
cyBwYXRoIHZhbGlkYXRpb24NCiBmYWlsZWQgb3Igd2FzIG5ldmVyIGF0dGVtcHRlZC4pPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdOKAmXMgaW1wb3J0YW50IHRvIG5vdGUgdGhhdCB0aGlz
IGlzbuKAmXQgZnVsbCBzZXJ2ZXIgbWlncmF0aW9uIOKAkyBpdOKAmXMgYSBzdGVwIGluIHRoYXQg
ZGlyZWN0aW9uLCBidXQgdGhpcyBpcyBzY29wZWQgc3RyaWN0bHkgdG8gdGhlIHNlcnZlciBtYWtp
bmcgb25lIGNoYW5nZSBhdHRlbXB0IHRvIGFuIGFkZHJlc3MgaXQNCiBwcm92aWRlcyBhdCBhIHNw
ZWNpZmllZCB0aW1lLiZuYnNwOyBIb3dldmVyLCB0aGlzIGlzbuKAmXQgc29tZXRoaW5nIHRoYXQg
aGFzIHNlZW4gYnJvYWQgZGlzY3Vzc2lvbiwgc28gSSB3YW50ZWQgdG8gcmFpc2UgaXQgZm9yIHRo
ZSBXR+KAmXMgY29uc2lkZXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPihJZiB3
ZSB3YW50IHRvIHRhY2tsZSBzZXJ2ZXIgbWlncmF0aW9uLCBJIHRoaW5rIHRoZSBuZXh0IHBpZWNl
IHdvdWxkIGJlIGEgZnJhbWUgdGhhdCBjYXJyaWVzIGVzc2VudGlhbGx5IHRoZSBzYW1lIGluZm9y
bWF0aW9uLCByZXF1ZXN0aW5nIHRoZSBjbGllbnQgdG8gbWFrZSBhIHByb2JlIGF0dGVtcHQuJm5i
c3A7IFRoaXMNCiBoZWxwcyBkZWFsIHdpdGggTkFUcyBieSBtYWtpbmcgY2xpZW50cyBzcGVhayBm
aXJzdCwgYnV0IGl0IGFzc3VtZXMgdGhhdCB0aGUgc2VydmVyIGFsd2F5cyBtYWludGFpbnMgY29u
dHJvbCBvZiBib3RoIGFkZHJlc3NlcyBkdXJpbmcgYSB0cmFuc2l0aW9uLiZuYnNwOyBUbyBzdXBw
b3J0IGZ1bGwgUDJQLCB3aGVyZSBib3RoIHNpZGVzIGNvdWxkIGJlIG1ha2UtYWZ0ZXItYnJlYWss
IHlvdSBiYXNpY2FsbHkgbmVlZCBzb21ldGhpbmcgbGlrZSBJQ0UuKTxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_CY4PR21MB0630C0111186D33D21EA3FB6B6BA0CY4PR21MB0630namp_--


From nobody Fri Apr  6 09:54:42 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9901F12025C for ; Fri,  6 Apr 2018 09:54:41 -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 (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 7fr335M9ctxZ for ; Fri,  6 Apr 2018 09:54:39 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0090.outbound.protection.outlook.com [104.47.37.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40D61200C5 for ; Fri,  6 Apr 2018 09:54:38 -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=YakkhD4dtXUmFKhiqDza25pnf1Og6xRN7Csul9xxhJo=; b=ljFIqUVngwO81KwhXw3NvgBmFTmifa0+lMYTQWI9AxKRWCVxKERaPpvXXbDH0B6vxbcLQAtQng5vRPiLb5UUDtILkvjtEy76MCstrN8D7ohOT+bpZdU7+dkvroJO5GKfEGbXX072W+UtWcjGD2LYsGa14MUDc4aicQueSeeM07g=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0789.namprd21.prod.outlook.com (10.175.121.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Fri, 6 Apr 2018 16:54:36 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.005; Fri, 6 Apr 2018 16:54:36 +0000
From: Praveen Balasubramanian 
To: Kazuho Oku , "Brian Trammell (IETF)" 
CC: huitema , QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Martin Thomson , Frederick Kautz 
Subject: RE: Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption))
Thread-Topic: Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption))
Thread-Index: AQHTzYsezaElZY5jPkWB++6/iJhOzKPzg/6AgAApqgCAADr0AIAACijQ
Date: Fri, 6 Apr 2018 16:54:36 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>    <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch>  <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch>    <8AAF21B8-5008-46EE-ACE1-FA2588DE9D20@trammell.ch> 
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::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0789; 7:WVXjHaPH+2eK9zKIxW9Jb1n30SELAzqRuTpgNG4gffHK81n7fQLxZ2DSqZaZVl2xuyte3J9Ludx7/+6B+as0HGL5IBTTuRJrb1HEz0N3/C3tdzZkzVD8YgNiGrC1MM56qZ5YcHVJ7z8X4cLuC4o58gQ7BNUBxbqq5Uo9ZUxX+eKN6qb2Qd1B2PJRtZvDi+HXQwx/1bw2h+1LRQ0LyJnDffuDYdorVv5OVW/wy105YRb8hBqFqBE6ArlVOrb3tsTN; 20:4fCvcPeGUWhF2n17DRZjuuL0iu1bsrxHN163VLiCoBh868DOLg8khLpnqwKV4OlRtjUzu6YDsZBBH2AUWYl7MANFrt5muKf8k2j2uM019g+5MTaX5ochqGr+M3HT6LV/opz3vGKIC6oh7dwnh8X34GRKqgMO8kjbWZVuQOYXaHc=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 153f6acf-a1b8-45ea-dad9-08d59bdf1498
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0789; 
x-ms-traffictypediagnostic: CY4PR21MB0789:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(100405760836317)(21532816269658); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(10201501046)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0789; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0789; 
x-forefront-prvs: 0634F37BFF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(396003)(376002)(39860400002)(39380400002)(13464003)(189003)(51444003)(199004)(377424004)(74316002)(7736002)(2900100001)(102836004)(22452003)(316002)(54906003)(110136005)(59450400001)(6436002)(186003)(4326008)(6246003)(53546011)(6506007)(106356001)(68736007)(46003)(9686003)(10090500001)(478600001)(11346002)(97736004)(476003)(8990500004)(14454004)(33656002)(93886005)(86362001)(55016002)(8936002)(10290500003)(5250100002)(3660700001)(229853002)(105586002)(81166006)(99286004)(2906002)(3280700002)(305945005)(446003)(6116002)(7696005)(76176011)(86612001)(81156014)(53936002)(5660300001)(8676002)(25786009)(39060400002)(345774005)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0789; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Co84ma5GWnp/NuSMQVQKVAQoCxGFFHVJEpce4a/OKOKXKdBIsf46kO53k97+DLwHk+um5VCwsoH90XOhHLK/o1B485BdMU2Wk9BZmrTOW/iTOXu7sHCYqkqBveMe9scjGpb0iWlDOyMyIb1UWDfyvCT4g3LtTV8MU24Qb2hgTV+nfPtIdUDNq/trq+lB4h4qRbMUcKo74uoJ2rbcYmpe5zw55btKuvgaEKNsDbbxEBslT4gqKNW0NT1V32Flcu7SbQ2xJBLcACjzNRheAP2q7DDNEmCsYrSvkk4kqJgLmxcJI0MHMnFQ4BUl6SggBjM3HunYebDutZwLLri/o4icQdLkr/jpBdhoW2sVChdH931Lxn8augn6JM88JZNNXu+U2uosaRfImoxBTn5BtNfjswRI2c3MvC8j3eCTsnvfVyU=
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-Network-Message-Id: 153f6acf-a1b8-45ea-dad9-08d59bdf1498
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 16:54:36.7146 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0789
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 06 Apr 2018 16:54:42 -0000

SSBhbSBhIHN1cHBvcnRlciBvZiB0aGUgZmxvdyBjbG9zdXJlIHNpZ25hbC4gSSB1bmRlcnN0YW5k
IHRoYXQgaXQgbWF5IG5vdCBiZSByZWxpYWJsZSBvbiB0aGUgbmV0d29yayBvciBub3QgYWxsIGVu
ZHBvaW50cyBtYXkgZ2VuZXJhdGUgaXQgKEthenVobydzIHBvaW50IGFib3V0IGJyaW5naW5nIHVw
IGJhdHRlcnkgdG8gc2VuZCB0aGUgIkZJTi9SU1QiKS4gQnV0IHdlIGhhdmUgYSBnZW51aW5lIHVz
ZSBjYXNlIGZvciB0aGlzIGluIHRoZSBjbG91ZC4gVGhlIHNvZnR3YXJlIHN3aXRjaGVzIGluIHB1
YmxpYyBjbG91ZCBob3N0cyB0eXBpY2FsbHkgZG8gc3RhdGVmdWwgcHJvY2Vzc2luZyAoZW5jYXAv
TkFUL290aGVyIHBhY2tldCB0cmFuc2Zvcm1zKSB0byBpbXBsZW1lbnQgU0ROIGZ1bmN0aW9uYWxp
dHkgbGlrZSBuZXR3b3JrIHZpcnR1YWxpemF0aW9uIGFuZCAgbG9hZCBiYWxhbmNpbmcuIFNpbmNl
IGZsb3cgc3RhdGUgdHJhY2tpbmcgaXMgZXhwZW5zaXZlLCB0b2RheSB0aGVzZSBzb2Z0d2FyZSBt
aWRkbGVib3hlcyB1c2UgVENQIHRlcm1pbmF0aW9uIHBhY2tldHMgdG8ga2VlcCBhIGxvbmdlciB0
aW1lb3V0IGZvciBUQ1AgYW5kIGEgbXVjaCBzaG9ydGVyIHRpbWVvdXQgZm9yIFVEUC4gSWYgdGhl
cmUgd2FzIGEgZXhwbGljaXQgY2xvc3VyZSBzaWduYWwgZm9yIFFVSUMsIHRoZW4gd2UgY291bGQg
aW5jcmVhc2UgdGhlIHRpbWVvdXRzIGFuZCB0aGVyZWJ5IHJlZHVjZSB0aGUga2VlcC1hbGl2ZSB0
cmFmZmljIG5lZWRlZCBieSBhIGxhcmdlIGZyYWN0aW9uLiANCg0KTm90IGV2ZXJ5IG1pZGRsZWJv
eCBpcyBvbiB0aGUgSW50ZXJuZXQgYW5kIG5vdCBldmVyeSBzY2VuYXJpbyBmb3IgUVVJQyBpcyB0
aGUgd2ViIGJyb3dzZXIvYXBwIGxvYWRpbmcgYSB3ZWIgcGFnZS4gV2hlbiBidWlsZGluZyBhIGdl
bmVyYWwgcHVycG9zZSB0cmFuc3BvcnQgd2Ugc2hvdWxkIGFpbSB0byBkZWZpbmUgbWVjaGFuaXNt
cyBsaWtlIGZsb3cgY2xvc3VyZSBzaWduYWwgYW5kIGxlYXZlIHRoZSBwb2xpY3kgb2Ygd2hldGhl
ciB0byBzZW5kIG9uZSB0byBlbmQgZGV2aWNlcy4gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgS2F6dWhvIE9rdQ0KU2VudDogRnJpZGF5LCBBcHJpbCA2LCAyMDE4IDk6MTEgQU0NClRvOiBC
cmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+DQpDYzogaHVpdGVtYSA8aHVp
dGVtYUBodWl0ZW1hLm5ldD47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNaXJqYSBLw7xobGV3
aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPjsgTWFydGluIFRob21zb24gPG1h
cnRpbi50aG9tc29uQGdtYWlsLmNvbT47IEZyZWRlcmljayBLYXV0eiA8ZmthdXR6QGFsdW1uaS5j
bXUuZWR1Pg0KU3ViamVjdDogUmU6IEdyaXBzIGluIHRoZSBXaXJlIEltYWdlIGZvciBJbi1OZXR3
b3JrIFN0YXRlICh3YXMgUmU6IFByaXZhY3kgaG9sZXMgKHdhcyBSZTogR2V0dGluZyB0byBjb25z
ZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uKSkNCg0KMjAxOC0wNC0wNiAyMTozOSBH
TVQrMDk6MDAgQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxpZXRmQHRyYW1tZWxsLmNoPjoNCj4gaGkg
S2F6dWhvLA0KPg0KPiBUaGFua3MgZm9yIHlvdXIgbWVzc2FnZSwgY29tbWVudHMgaW5saW5lLCBv
bWl0dGluZyBzb21lIGhpc3RvcnkgZm9yIGNsYXJpdHkuLi4NCj4NCj4+IE9uIDYgQXByIDIwMTgs
IGF0IDEyOjEwLCBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPiB3cm90ZToNCj4+DQo+
PiBIaSBCcmlhbiwNCj4+DQo+PiBNeSBjb21tZW50cyBpbmxpbmUuDQo+Pg0KPj4gMjAxOC0wNC0w
NiAxODozOCBHTVQrMDk6MDAgQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxpZXRmQHRyYW1tZWxsLmNo
PjoNCj4+Pg0KPj4+DQo+Pj4gSG93ZXZlciwgSSB3b3VsZCBzdWJtaXQgdGhhdCBpZiB3ZSB0aGlu
ayB3ZSBhcmUgaW4gYSBwb3NpdGlvbiB3aGVyZToNCj4+Pg0KPj4+IC0gdGhlcmUgaXMgYSBzdHJv
bmcgaW5jZW50aXZlIGZvciBmaXJld2FsbHMvTkFUcyB0byB3YW50IHRvIHNlZSANCj4+PiBzdGFy
dC0gKGFuZCBlbmQtKSBvZiBmbG93ICh3aGljaCBzZWVtcyB0byBtZSB0byBiZSB0aGUgdGhyZWF0
IG1vZGVsIA0KPj4+IHdlJ3JlIHRyeWluZyB0byBtaXRpZ2F0ZSB3aXRoIHRoaXMpOyBhbmQNCj4+
Pg0KPj4+IC0gd2UgZG8gbm90IHdhbnQgYXJiaXRyYXJ5IGluZm9ybWF0aW9uIGluIHRoZSBRVUlD
IHdpcmUgaW1hZ2UgdG8gYmUgDQo+Pj4gdXNlZCB0byBkZXRlY3QgdGhlc2UgY29uZGl0aW9ucywg
c2luY2UgdGhhdCBtaWdodCBjYXVzZSBiaXRzIG9mIHRoZSANCj4+PiB3aXJlIGltYWdlIHdlIGRv
bid0IHdhbnQgdG8gZW5kIHVwIGluIHRoZSBhY2NpZGVudGFsIGludmFyaWFudHM7DQo+Pj4NCj4+
PiB0aGVuIHdlIHJlYWxseSBzaG91bGQgY29uc2lkZXIgYWRkaW5nIGV4cGxpY2l0IGFkdmlzb3J5
IGZsb3cgc3RhdGUgc2lnbmFscywgYm90aCBmb3IgZXN0YWJsaXNobWVudCBhbmQgdGVhcmRvd24u
IFRoZSB0aGVvcnkgaGVyZSBpcyB0aGF0IGlmIHlvdSBnaXZlIGluLW5ldHdvcmsgZnVuY3Rpb25z
IGEgImdyaXAiIGluIHRoZSB3aXJlIGltYWdlIG9mIHRoZSBwcm90b2NvbCB0aGV5IGNhbiB1c2Ug
Zm9yIHN0YXRlIG1hbmFnZW1lbnQsIHRoZXkgd29uJ3QgdHJ5IHRvIGdyYWIgb24gdG8gdGhlIHNs
aXBwZXJ5IGJpdHMuIFRvZ2V0aGVyIHdpdGggcHJvYmFiaWxpc3RpYyBtaWdyYXRpb24sIHRoZXNl
IHNpZ25hbHMgd291bGQgZGl2b3JjZSAib24tcGF0aCBzdGF0ZSIgZnJvbSAidHJhbnNwb3J0IHNl
c3Npb24gc3RhdGUiLCByZWR1Y2luZyB0aGUgcHJpdmFjeSBpbXBhY3Qgd2l0aCByZXNwZWN0IHRv
IFNZTi9GSU4gaW4gVENQLg0KPj4NCj4+IEkgdGhpbmsgdGhhdCB0aGlzIGlzIGEgdmVyeSBpbnRl
cmVzdGluZyBxdWVzdGlvbiBhc2tpbmcgd2hhdCB0aGUgDQo+PiByZXF1aXJlbWVudHMgb2YgUVVJ
QyBhcyBhIHByb3RvY29sIGlzLiBUaGFuayB5b3UgZm9yIGJyaW5naW5nIHRoZSANCj4+IHRvcGlj
IHRvIHRhYmxlLg0KPj4NCj4+IE15IGFyZ3VtZW50IGFnYWluc3QgaGF2aW5nIGFuIGV4cGxpY2l0
IHNpZ25hbCBmb3IgZmxvdyBjcmVhdGlvbiBpcyANCj4+IHRoYXQgaXQgaXMgaW1wb3NzaWJsZSB0
byBoYXZlIHN1Y2ggc2lnbmFsIGluIGEgcmVsaWFibGUgd2F5LCBhbmQgdGhhdCANCj4+IHRyeWlu
ZyB0byBoYXZlIG5vIHNpZ25hbCBpcyBiZXR0ZXIgdGhhbiBoYXZpbmcgYW4gdW5yZWxpYWJsZSBz
aWduYWwuDQo+DQo+IEkgc2hvdWxkIHNheSBJJ20gbm90IGFsbCB0aGF0IGNvbnZpbmNlZCB0aGF0
IGFuIGFkdmlzb3J5ICJmbG93IHN0YXJ0IiBzaWduYWwgaXMgYSBnb29kIGlkZWEoKikgLS0gSSdt
IGp1c3Qgc2F5aW5nIHRoYXQgd2Ugc2VlbSB0byBiZSB0cnlpbmcgdmVyeSBoYXJkIHRvIGtlZXAg
YSBkZSBmYWN0byBhZHZpc29yeSBmbG93IHN0YXJ0IHNpZ25hbCBmcm9tIGZvcm1pbmcgKHdoaWNo
IEkgd291bGQgYWdyZWUgd291bGQgYmUgZXh0cmVtZWx5IHVuZGVzaXJhYmxlIGluZGVlZCkuLi4g
YW5kIHdlIHNob3VsZCBzdGVwIGJhY2sgYW5kIHRoaW5rIGFib3V0IHdoYXQgcHJvcGVydGllcyBm
bG93IHN0YXJ0IGFuZCBlbmQgc2hvdWxkIGhhdmUgaW4gUVVJQywgZXhwbGljaXRseSwgYXMgYSBm
dW5jdGlvbiBvZiByZXF1aXJlbWVudHMgYXMgb3Bwb3NlZCB0byBwaGlsb3NvcGh5Lg0KDQpUaGFu
ayB5b3UgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLg0KDQo+PiBMZXQgbWUgZXhwbGFpbiB3aHkgSSB0
aGluayB3ZSBjYW5ub3QgaGF2ZSBhIHJlbGlhYmxlIHNpZ25hbC4NCj4NCj4gPHNuaXA+IEFsbCB0
aGlzIG1ha2VzIHZlcnkgZ29vZCBzZW5zZSBhbmQgSSBhZ3JlZSB3aXRoIGl0OiB0aGUgc2lnbmFs
IGNhbm5vdCBwb3NzaWJseSBiZSByZWxpYWJsZSBpbiB0aGUgZ2VuZXJhbCBjYXNlLg0KPg0KPj4g
Rm9yIGZsb3cgY2xvc3VyZSwgSSB0aGluayBzYXZpbmcgdGhlIGJhdHRlcnkgYnkgbm90IHNlbmRp
bmcgYSBGSU4gDQo+PiBwYWNrZXQgYWZ0ZXIgcXVpZXNjZW5jZSBpcyBtb3JlIGltcG9ydGFudCB0
aGFuIHNlbmRpbmcgZ29vZCBzaWduYWwgdG8gDQo+PiBtaWRkbGVib3hlcw0KPg0KPiBUaGlzIGlz
IGEgaGFyZCBwcm9ibGVtLCBhbmQgaXQgY3V0cyBib3RoIHdheXM7IGlmIGEgc2VydmVyIHdhbnRz
IHRvIG1haW50YWluIHRoZSBhYmlsaXR5IHRvIGNvbm5lY3QgYSBjbGllbnQgYWZ0ZXIgbW9yZSB0
aGFuIHRoZSBzdGFuZGFyZCBVRFAgTkFUIHRpbWVvdXQgKDMwcyksIGl0IG5lZWRzIHRvIHNlbmQg
a2VlcGFsaXZlcyBtb3JlIG9mdGVuIHRoYW4gb25jZSBldmVyeSAzMHMgKHRoZXJlYnkgd2FraW5n
IHRoZSBjbGllbnQgaWYgaXQncyBvbiBiYXR0ZXJ5KS4gV2hpY2ggc2lkZSBvZiB0aGlzIGNvaW4g
d2FzdGVzIG1vcmUgcG93ZXIgaXMgZGlmZmljdWx0IHRvIGRldGVybWluZSwgc2luY2UgaXQncyBl
bnRpcmVseSBkZXBlbmRlbnQgb24gdGhlIHByZXZhbGVuY2Ugb2YgZWFjaCBraW5kIG9mIGFjdGl2
aXR5IGluIGEgZ2l2ZW4gbmV0d29yay4gV2UgY2FuIG1ha2UgcGxhdXNpYmxlIGd1ZXNzZXMgYm90
aCBpbiBmYXZvciBvZiAiZ2V0IHJpZCBvZiBGSU4sIGl0IHdhc3RlcyBlbmRwb2ludCBwb3dlciIg
b3IgIndlIHJlYWxseSBuZWVkIEZJTiB0byBrZWVwIGZyb20gd2FzdGluZyBlbmRwb2ludCBwb3dl
ciIuDQoNClRoZSBjYXNlIG9mIHNlcnZlciByZXZpdmluZyB0aGUgY29ubmVjdGlvbiBpcyBpbnRl
cmVzdGluZy4NCg0KSWYgd2UgYXJlIHRvIGhhdmUgc29tZSBzaWduYWwsIEkgdGhpbmsgdGhhdCBz
aG91bGQgYmUgInBhdGgtdmlzaWJsZSBpbmRpY2F0aW9uIG9mIGNvbnNlbnQgdG8gY29udGludWUg
Y29tbXVuaWNhdGluZyIgYXMgeW91IGRlc2NyaWJlLCBzcGVjaWZpY2FsbHksIGFzIGEgc2lnbmFs
IHRoYXQgY2FuIGJlIHNldCBvbiBldmVyeSBwYWNrZXQgZm9yIHdoaWNoLCBhdCB0aGUgbW9tZW50
IG9mIHNlbmRpbmcsIHRoZSBlbmRwb2ludCBpcyBzdXJlIHRoYXQgdGhlIHNlcnZlciB3aWxsIG5v
dCBzZW5kIGFueSBtb3JlIHBhY2tldHMgdW5sZXNzIGl0IHJlY2VpdmVzIGEgbmV3IHBhY2tldCBm
cm9tIHRoZSBjbGllbnQuDQoNCkEgTkFUIGF3YXJlIG9mIHRoZSBzaWduYWwgY2FuIGRyb3AgYW4g
aWRsZSBVRFAgZmxvdyBvbiB3aGljaCB0aGUgbGFzdCBwYWNrZXQgaGFkIHRoYXQgZmxhZyBzZXQs
IGFmdGVyIGNvdXBsZSBvZiByb3VuZC10cmlwcywgdGhlcmVieSBnaXZpbmcgb3RoZXIgZmxvd3Mg
YSBsb25nZXIgaWRsZSB0aW1lb3V0Lg0KDQpUaGUgYmVuZWZpdCBvZiBkZWZpbmluZyB0aGUgc2ln
bmFsIHRoaXMgd2F5IGlzIHRoYXQgdGhlcmUgd291bGQgYmUgbm8gbmVlZCB0byBzZW5kIEZJTiBh
ZnRlciBxdWllc2NlbmNlIHRvIHNodXQgZG93biB0aGUgaG9sZS4NCg0KVGhhdCBzYWlkLCBJIHdv
dWxkIHByZWZlciBub3QgZGlzY3Vzc2luZyB0aGlzIGFzIGEgZmVhdHVyZSBvZiBRVUlDdjEgZm9y
IHNldmVyYWwgcmVhc29uczogaSkgdGhpcyBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gdjIgaWkpIGhh
dmluZyBzdWNoIHNpZ25hbCBpcyBub3QgZ29pbmcgZ2l2ZSB1cyBiZW5lZml0IGluIHRoZSBzaG9y
dC10ZXJtLCBzbyBubyBuZWVkIHRvIGh1cnJ5IGlpaSkgbWFueSBvZiB1cyBhcmUgaW50ZXJlc3Rl
ZCBpbiBzaGlwcGluZyB2MSBhcyBlYXJseSBhcyBwb3NzaWJsZSBpdikgSFRUUCAod2hpY2ggaXMg
dGhlIGFwcGxpY2F0aW9uIHByb3RvY29sIGluIGZvY3VzIGZvciB2MSkgaXMgbm90IGdvaW5nIHRv
IHN1ZmZlciBhIGxvdCBmcm9tIHRoZSBzZXJ2ZXItcmV2aXZlcy1jb25uZWN0aW9uIHByb2JsZW0g
c2luY2UgSFRUUCBpcyBhIHJlcXVlc3QtcmVzcG9uc2UgcHJvdG9jb2wuDQoNCj4NCj4gU28gSSdt
IG1vcmUgY29udmluY2VkIG9mIHRoZSB2YWx1ZSBvZiBhZHZpc29yeS1lbmQgdGhhbiBhZHZpc29y
eS1zdGFydC4NCj4NCj4+PiAoVGhlIGFsdGVybmF0aXZlIGlzIHRvIG1ha2UgdGhlIHdpcmUgaW1h
Z2Ugc28gaW5zY3J1dGFibGUgdGhhdCANCj4+PiBvbi1wYXRoIHN0YXRlIHRyYWNraW5nIGJlY29t
ZXMgY29tcGxldGVseSBmdXRpbGUgYW5kIGdvZXMgYXdheS4gSSdtIA0KPj4+IG5vdCBzdXJlIHdl
J3JlIHRoYXQgZ29vZCBhdCBpbnNjcnV0YWJsZSB3aXJlIGltYWdlcy4pDQo+Pg0KPj4gSSB3b3Vs
ZCByYXRoZXIgYXJndWUgdGhhdCB0aGUgZ29hbCBvZiB0aGUgYWx0ZXJuYXRpdmUgYXBwcm9hY2gg
aXMgdG8gDQo+PiBtYWtlIHRoZSBpbnRlbnRpb25hbCBmbG93IGNyZWF0aW9uIG5vdCBlYXNpbHkg
ZGlzdGluZ3Vpc2hhYmxlIHRvIHRoZSANCj4+IGV4dGVudCB0aGF0IHRoZSBtaWRkbGVib3ggdmVu
ZG9ycyB3aWxsIHJlZmVyIHRvIHRoZSBSRkMuIFRoZW4sIHRoZXkgDQo+PiBjYW4gZGVjaWRlIGVp
dGhlciB0byBub3QgbGltaXQgUVVJQyBmbG93cyBzdGFydGluZyBmcm9tIGEgMS1SVFQgDQo+PiBw
YWNrZXQsIG9yIHRvIGRyb3AgUVVJQyBjb21wbGV0ZWx5LiBBbmQgdGhlIGlzc3VlIGlzIHNvbHZl
ZC4NCj4NCj4NCj4gTGV0IG1lIHRyeSB0byByZXBocmFzZSB0aGlzIGluIHdpbGRseSBkaWZmZXJl
bnQgdGVybWlub2xvZ3k6ICJ3ZSBjYW4ndCBjb21lIHVwIHdpdGggYSBncmlwIHRoYXQgd2UgdGhp
bmsgd2lsbCB3b3RrLCBzbyB3ZSBzaG91bGQgbWFrZSBmbG93IHN0YXJ0IGFzIHNsaXBwZXJ5IGFz
IHBvc3NpYmxlIjsgb3IgcmF0aGVyLCBhIG1pZGRsZWJveCB0aGF0IHRoaW5rcyBpdCdzIHNlZWlu
ZyBRVUlDIHNob3VsZCBtYWtlIGl0cyBkcm9wIGRlY2lzaW9uIGJhc2VkIG9uICJ0aGlzIGlzIFFV
SUMiIGFuZCBub3QgYW55dGhpbmcgYmFzZWQgb24gdGhlIHN0YXRlIG9mIHRoZSBjb25uZWN0aW9u
LiBUaGF0IGRlZmluaXRlbHkgaGFzIGRlc2lyYWJsZSBwcm9wZXJ0aWVzIHdpdGggcmVzcGVjdCB0
byBmdXR1cmUgZmxleGliaWxpdHkgLS0gdGhlIHN0YXJ0IGFuZCBlbmQgc2lnbmFsaW5nIHdvdWxk
IGVuZCB1cCBpbiB0aGUgaW52YXJpYW50cyByYXRoZXIgcXVpY2tseSB3aGV0aGVyIGludGVudGlv
bmFsIG9yIG5vdC4gQW5kIElTVE0gdGhhdCB0aGUgcHJvYmFiaWxpc3RpYyBtaWdyYXRpb24gYmVo
YXZpb3Igd291bGQgaGVscCB0byBhY2hpZXZlIGl0Lg0KPg0KPiBDaGVlcnMsDQo+DQo+IEJyaWFu
DQo+DQo+DQo+ICgqKTogIkFkdmlzb3J5IGZsb3cgc3RhcnQiIGlzIHNvbWV3aGF0IGRpZmZlcmVu
dCB0aGFuICJwYXRoLXZpc2libGUgcHJvb2Ygb2YgcmV0dXJuIHJvdXRhYmlsaXR5IiBhbmQgInBh
dGgtdmlzaWJsZSBpbmRpY2F0aW9uIG9mIGNvbnNlbnQgdG8gY29udGludWUgY29tbXVuaWNhdGlu
ZyIuIFRoZSBsYXR0ZXIsIElNTywgaGFzIG1vcmUgdmFsdWUgYXMgcGFydCBvZiBhIGRlc2lnbiB0
byBzdXBwb3J0IGluLW5ldHdvcmsgcmVqZWN0aW9uIG9mIFVEUCBnYXJiYWdlLiBCdXQgaXQncyBh
IG1vcmUgY29tcGxleCBzaWduYWwsIHNpbmNlIGl0IGludm9sdmVzIHJldmVhbGluZyB0aGluZ3Mg
dGhhdCBhcmUgaGFyZCB0byBmYWtlIGF0IGZsb3cgZXN0YWJsaXNobWVudCB0aW1lLCBhbmQgaXMg
b2YgY291cnNlIHN1YmplY3QgdG8gdGhlIHBoaWxvc29waGljYWwgcXVlc3Rpb24gb2Ygd2hldGhl
ciB0aGF0J3MgYSBnb29kIGlkZWEuDQo+DQoNCg0KDQotLQ0KS2F6dWhvIE9rdQ0KDQo=


From nobody Fri Apr  6 13:37:46 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06136126C0F for ; Fri,  6 Apr 2018 13:37:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUF0PeMTOGpc for ; Fri,  6 Apr 2018 13:37:40 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0110.outbound.protection.outlook.com [104.47.34.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A581200C1 for ; Fri,  6 Apr 2018 13:37:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/uQ6+bvR3+cUHKmI2qG/7qOaLHAiyFQR4TodZSUaM0A=; b=EBWqQEsWSQ60fgKUS8g+til07x10oafonsfU4G0TUESYjB1JLKXQnDXnupa8arzjnllI4ke8zmr/prS3cWZ1ol6gfUCwEG4nJuyV0syx1Wwd2Q7SMsOeM9uD/AVV8+c/GLCzavMIHCvFw0Wa4R+1CV/5fGI0EJ7AP9eB6Fz5REo=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1693.namprd08.prod.outlook.com (10.162.133.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Fri, 6 Apr 2018 20:37:37 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0653.013; Fri, 6 Apr 2018 20:37:37 +0000
From: Mike Bishop 
To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Ian Swett" 
CC: Praveen Balasubramanian , IETF QUIC WG 
Subject: RE: Impact of hardware offloads on network stack performance
Thread-Topic: Impact of hardware offloads on network stack performance
Thread-Index: AdPMUbL7T8nZAW2ySiO289IPTC0ttgAApm4AADSbFZAACUWYgAAFkLQAACA3b/A=
Date: Fri, 6 Apr 2018 20:37:37 +0000
Message-ID: 
References:   ,  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; 
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1693; 7:R0c0dvJvUjUuMfwl9dmvBN0vowiLWUiF8I4Qoj3MD8dqGUXnSW/QwLHip9B7tV9w605SHcbaAN8iQtw2YtfE2sJlMErSHhrxnr73TwWT2k/9/4zWZNrgVZ+LfEFOJcdmfpbmlw4IdYKTH+tmWQ5LDG9o03i9sFr3NrqDcbCKwDVOmHYe5nnHBWIbugQ+Jnx8h6AJugbKaxilIqme/PL/mk7YWFDmb1ZPK8lRDn391GtW8qwGyS/qFETxRFN6LVv/
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 39780d65-579f-4ccb-1188-08d59bfe3c2b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1693; 
x-ms-traffictypediagnostic: SN1PR08MB1693:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(85827821059158)(211936372134217)(153496737603132)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(3002001)(10201501046)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(2016111802025)(6043046)(6072148)(201708071742011); SRVR:SN1PR08MB1693; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1693; 
x-forefront-prvs: 0634F37BFF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39830400003)(366004)(39380400002)(51914003)(199004)(189003)(476003)(2906002)(606006)(68736007)(81156014)(81166006)(53936002)(33656002)(66066001)(8666007)(55016002)(8936002)(2900100001)(5250100002)(6436002)(478600001)(19609705001)(105586002)(236005)(9686003)(6116002)(3846002)(54896002)(6306002)(8676002)(790700001)(316002)(7736002)(7696005)(26005)(106356001)(5660300001)(74316002)(186003)(11346002)(76176011)(446003)(14454004)(86362001)(102836004)(53546011)(97736004)(110136005)(54906003)(3280700002)(45080400002)(6246003)(486006)(3660700001)(93886005)(99286004)(39060400002)(59450400001)(229853002)(25786009)(6506007)(74482002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1693; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: m8uQEyqV/A7jIsbO9XU4K1HVAojgt4Sz8nTeNmmzdC34it0s69D4c9hz2gF69vTLeuECHEtEt6+YGHxODXjzN8XD1VDHcgexoMoxGHb0SHXxB+e+W5O940LhGG8zi+8J6ZdK8EjeckqZ0537Qfg7JYoxkjV6T03Clg+9RpEwraM5nr6p5YR76gIf3Dwaf8ovf686cumChbTCZFHBI0Jozp4w9UxQLZV+82aQ0MXTc5coLWiMdQmlvgMELOOiJ70pvpfi4dijDDlCxkPTefeoU/opyvVNUrsmx1IK1eXg69gAv0qisdc+9m8WyeQoXo5gxpeiQ2XPPYvAQOyGQeW2OgCbGyh2DCdCRQOd52xQuTO8Syguq4CuhIVlGmpuk4cQQBb99l/9kFCL+M5ppsNYXyVixsi8iK5GCTnaPBZsXyA=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR08MB18548155722C665FFD45CC4DDABA0SN1PR08MB1854namp_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 39780d65-579f-4ccb-1188-08d59bfe3c2b
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 20:37:37.4215 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1693
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 06 Apr 2018 20:37:44 -0000

--_000_SN1PR08MB18548155722C665FFD45CC4DDABA0SN1PR08MB1854namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gIEkgZ3Vlc3Mgd2hhdCBJ4oCZbSByZWFsbHkg
Z2V0dGluZyBkb3duIHRvIGlzIGhvdyBkbyB3ZSBxdWFudGlmeSB0aGUgYWN0dWFsIGNvc3Qgb2Yg
UE5FPyAgQXJlIHdlIHN1YnN0YW50aWFsbHkgaW5jcmVhc2luZyB0aGUgY3J5cHRvIGNvc3RzPyAg
SWYgSWFuIGlzIHNheWluZyB0aGF0IGNyeXB0byBpcyBjb21wYXJhdGl2ZWx5IGNoZWFwIGFuZCB0
aGUgY29zdCBpcyB0aGF0IGl04oCZcyBoYXJkZXIgdG8gb2ZmbG9hZCBzb21ldGhpbmcgdGhhdOKA
mXMgY29tcGFyYXRpdmVseSBjaGVhcCwgd2hhdCBoYXZlIHdlIGxvc3Q/ICBJ4oCZZCB0aGluayB3
ZSB3YW50IHRvIG9mZmxvYWQgdGhlIG1vc3QgaW50ZW5zaXZlIHBpZWNlIHdlIGNhbiwgYW5kIGl0
IHNlZW1zIGxpa2Ugd2XigJlyZSB0YWxraW5nIGFib3V0IGNyeXB0byBvZmZsb2Fkcy4uLi4gIE9y
IGFyZSB3ZSBzYXlpbmcgaW5zdGVhZCB0aGF0IHRoZSBjcnlwdG8gbWFrZXMgaXQgaGFyZGVyIHRv
IG9mZmxvYWQgb3RoZXIgdGhpbmdzIGluIHRoZSBmdXR1cmUsIGxpa2UgYSBRVUlDIGVxdWl2YWxl
bnQgdG8gTFJPL0xTTz8NCg0KRnJvbTogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRv
Om1pa2tlbGZqQGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCA1LCAyMDE4IDk6NDUg
UE0NClRvOiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBNaWtlIEJpc2hvcCA8bWJp
c2hvcEBldmVxdWVmb3UuYmU+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1p
Y3Jvc29mdC5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog
SW1wYWN0IG9mIGhhcmR3YXJlIG9mZmxvYWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVyZm9ybWFuY2UN
Cg0KVG8gYmUgY2xlYXIgLSBJIGRvbuKAmXQgdGhpbmsgY3J5cHRvIGlzIG92ZXJzaGFkb3dpbmcg
b3RoZXIgaXNzdWVzIGFzIE1pa2UgcmVhZCBteSBwb3N0LiBJdCBjZXJ0YWlubHkgY29tZXMgYXQg
YSBjb3N0LCBidXQgZWl0aGVyIG11bHRpcGxlIGNvcmVzIG9yIGNvLXByb2Nlc3NvcnMgd2lsbCBk
ZWFsIHdpdGggdGhpcy4gMTAwMG5zIGlzIDEwR2JwcyBjcnlwdG8gc3BlZWQgb24gb25lIGNvcmUg
YW5kIGl0IGlzIGhpZ2x5IHBhcmFsbGVsaXNhYmxlIGFuZCBjYWNoZSBmcmllbmRseS4NCg0KQnV0
IGlmIHlvdSBoYXZlIHRvIGRyaXAgeW91ciBwYWNrZXRzIHRocm91Z2ggYSB0cmFkaXRpb25hbCBz
ZW5kIGludGVyZmFjZSB0aGF0IGlzIGNvcHlpbmcsIGJ1ZmZlcmluZyBvciBibG9ja2luZywgYW5k
IGNlcnRhaW5seSBzeW5j4oCZaW5nIHdpdGggdGhlIGtlcm5lbCAtIGl0IGlzIGdvaW5nIHRvIGJl
IHRvdWdoLg0KDQpGb3IgcmVjZWl2ZSB5b3UgcmlzayBoaWdoIGxhdGVuY3kgb3IgdG9wIG11Y2gg
c2NoZWR1bGluZyBpbiByZWNlaXZlIGJ1ZmZlcnMuDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpGcm9tOiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlh
bnN3ZXR0QGdvb2dsZS5jb20+Pg0KU2VudDogRnJpZGF5LCBBcHJpbCA2LCAyMDE4IDQ6MDY6MDEg
QU0NClRvOiBNaWtlIEJpc2hvcA0KQ2M6IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW47IFByYXZl
ZW4gQmFsYXN1YnJhbWFuaWFuOyBJRVRGIFFVSUMgV0cNClN1YmplY3Q6IFJlOiBJbXBhY3Qgb2Yg
aGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZQ0KDQoNCk9uIFRo
dSwgQXByIDUsIDIwMTggYXQgNTo1NyBQTSBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3Uu
YmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj4gd3JvdGU6DQpUaGF04oCZcyBpbnRlcmVz
dGluZyBkYXRhLCBQcmF2ZWVuIOKAkyB0aGFua3MuICBUaGVyZSBpcyBvbmUgY2F2ZWF0IHRoZXJl
LCB3aGljaCBpcyB0aGF0IChJSVVDLCBvbiBjdXJyZW50IGhhcmR3YXJlKSB5b3UgY2Fu4oCZdCBk
byBwYWNrZXQgcGFjaW5nIHdpdGggTFNPLCBhbmQgc28gbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0
IGV2ZW4gZm9yIFRDUCBtYW55IHByb3ZpZGVycyBkaXNhYmxlIHRoaXMgaW4gcHVyc3VpdCBvZiBi
ZXR0ZXIgZWdyZXNzIG1hbmFnZW1lbnQuICBTbyB3aGF0IHdl4oCZcmUgcmVhbGx5IHNheWluZyBp
cyB0aGF0Og0KDQogICogICBPbiBjdXJyZW50IGhhcmR3YXJlIGFuZCBPUyBzZXR1cHMsIFVEUCBy
dW5zIGxlc3MgdGhhbiBoYWxmIGFzIG11Y2ggdGhyb3VnaHB1dCBhcyBUQ1A7IHRoYXQgbmVlZHMg
c29tZSBvcHRpbWl6YXRpb24sIGFzIHdl4oCZdmUgYWxyZWFkeSBkaXNjdXNzZWQNCiAgKiAgIFRD
UCB3aWxsIGRyYW1hdGljYWxseSBnYWluIHBlcmZvcm1hbmNlIG9uY2UgaGFyZHdhcmUgb2ZmbG9h
ZCBjYXRjaGVzIHVwIGFuZCBhbGxvd3MgcGFjZWQgTFNPIPCfmIoNCg0KSG93ZXZlciwgYXMgTWlr
a2VsIHBvaW50cyBvdXQsIHRoZSBjcnlwdG8gY29zdHMgYXJlIGxpa2VseSB0byBvdmVyd2hlbG0g
dGhlIE9TIHRocm91Z2hwdXQgLyBzY2hlZHVsaW5nIGlzc3VlcyBpbiByZWFsIGRlcGxveW1lbnRz
LiAgU28gSSB0aGluayB0aGUgb3RoZXIgcmVsZXZhbnQgcGllY2UgdG8gdW5kZXJzdGFuZGluZyB0
aGUgY29zdCBoZXJlIGlzIHRoaXM6DQoNCkkgaGF2ZSBhIGZldyBjYXNlcyhib3RoIGNsaWVudCBh
bmQgc2VydmVyKSB3aGVyZSBteSBVRFAgc2VuZCBjb3N0cyBhcmUgbW9yZSB0aGFuIDMwJShpbiBz
b21lIGNhc2VzIDUwJSkgb2YgQ1BVIGNvbnN1bXB0aW9uLCBhbmQgY3J5cHRvIGlzIGxlc3MgdGhh
biAxMCUuICBTbyBjdXJyZW50bHksIEkgYXNzdW1lIGNyeXB0byBpcyBjaGVhcChlc3BlY2lhbGx5
IEFFUy1HQ00gd2hlbiBoYXJkd2FyZSBhY2NlbGVyYXRpb24gaXMgYXZhaWxhYmxlKSBhbmQgZWdy
ZXNzIGlzIGV4cGVuc2l2ZS4gIFVEUCBpbmdyZXMgaXMgbm90IHRoYXQgZXhwZW5zaXZlLCBidXQg
Y291bGQgdXNlIGEgYml0IG9mIG9wdGltaXphdGlvbiBhcyB3ZWxsLg0KDQpUaGUgb25seSAnZmFu
Y3knIHRoaW5nIG91ciBjdXJyZW50IGNvZGUgaXMgZG9pbmcgZm9yIGNyeXB0byBpcyBlbmNyeXB0
aW5nIGluIHBsYWNlLCB3aGljaCB3YXMgYSB+MiUgd2luLiAgTmljZSwgYnV0IG5vdCB0cmFuc2Zv
cm1hdGl2ZS4gIFNlZSBFbmNyeXB0SW5QbGFjZTxodHRwczovL2NzLmNocm9taXVtLm9yZy9jaHJv
bWl1bS9zcmMvbmV0L3F1aWMvY29yZS9xdWljX2ZyYW1lci5jYz9zcT1wYWNrYWdlOmNocm9taXVt
Jmw9MTg5Mz4NCg0KSSBoYXZlbid0IGRvbmUgbXVjaCB3b3JrIGJlbmNobWFya2luZyBXaW5kb3dz
LCBzbyBwb3NzaWJseSB0aGUgV2luZG93cyBVRFAgc3RhY2sgaXMgcmVhbGx5IGZhc3QsIGFuZCBz
byBjcnlwdG8gc2VlbXMgcmVhbGx5IHNsb3cgaW4gY29tcGFyaXNvbj8NCg0KDQogICogICBXaGF0
IGlzIHRoZSB0aHJvdWdocHV0IGFuZCByZWxhdGl2ZSBjb3N0IG9mIFRMUy9UQ1AgdmVyc3VzIFFV
SUMgKGkuZS4gaG93IG11Y2ggYXJlIHRoZSBzbWFsbGVyIHVuaXRzIG9mIGVuY3J5cHRpb24gaHVy
dGluZyB1cyB2ZXJzdXMsIHNheSwgMTZLQiBUTFMgcmVjb3Jkcyk/DQoNCiAgICAgKiAgIFRMUyBp
bXBsZW1lbnRhdGlvbnMgYWxyZWFkeSB2YXJ5IGhlcmU6ICBTb21lIGltcGxlbWVudGF0aW9ucyBj
aG9vc2UgbGFyZ2UgcmVjb3JkIHNpemVzLCBzb21lIHZhcnkgcmVjb3JkIHNpemVzIHRvIHJlZHVj
ZSBkZWxheSAvIEhvTEIsIHNvIHRoaXMgcHJvYmFibHkgaXNu4oCZdCBhIHNpbmdsZSBudW1iZXIu
DQoNCiAgKiAgIEhvdyBtdWNoIGFkZGl0aW9uYWwgbG9hZCBkb2VzIFBORSBhZGQgdG8gdGhpcyBk
aWZmZXJlbmNlPw0KICAqICAgVG8gd2hhdCBleHRlbnQgd291bGQgUE5FIG1ha2UgZnV0dXJlIGNy
eXB0byBvZmZsb2FkcyBpbXBvc3NpYmxlIHZlcnN1cyByZXF1aXJlcyBtb3JlIFImRCB0byBkZXZl
bG9wPw0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpx
dWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTWlra2VsIEZhaG7DuGUgSsO4cmdl
bnNlbg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDE4IDE6MzQgUE0NClRvOiBQcmF2ZWVu
IEJhbGFzdWJyYW1hbmlhbiA8cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1h
aWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+PjsgSUVURiBRVUlDIFdHIDxxdWlj
QGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBJbXBhY3Qgb2Yg
aGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZQ0KDQpUaGFua3Mg
Zm9yIHNoYXJpbmcgdGhlc2UgbnVtYmVycy4NCg0KTXkgZ3Vlc3MgaXMgdGhhdCB0aGVzZSBvZmZs
b2FkcyBkZWFsIHdpdGgga2VybmVsIHNjaGVkdWxpbmcsIG1lbW9yeSBjYWNoZSBpc3N1ZXMsIGFu
ZCBpbnRlcnJ1cHQgc2NoZWR1bGluZy4NCg0KSXQgcHJvYmFibHkgaGFzIHZlcnkgbGl0dGxlIHRv
IGRvIHdpdGggY3J5cHRvLCBUQ1AgaGVhZGVycywgYW5kIGFueSBvdGhlciBjcHUgc2Vuc2l0aXZl
IHByb2Nlc3NpbmcuDQoNClRoaXMgaXMgd2hlcmUgbmV0bWFwIGVudGVyczogeW91IGNhbiB0cmFu
c3BhcmVudGx5IGZlZWQgdGhlIGRhdGEgYXMgaXQgYmVjb21lcyBhdmFpbGFibGUgd2l0aCB2ZXJ5
IGxpdHRsZSBzeW5jIHdvcmsgYW5kIHlvdSBjYW4gYWxzbyBlZmZpY2llbnRseSBwaXBlbGluZSBz
byB5b3UgcGFzcyBkYXRhIHRvIGRlY3J5cHRvciwgdGhlbiB0byBhcHAsIHdpdGggYXMgbGl0dGxl
IGJ1cyB0cmFmZmljIGFzIHBvc3NpYmxlLiBObyBuZWVkIHRvIGNvcHkgZGF0YSBvciBzeW5jaHJv
bml6ZSBrZXJuZWwgc3BhY2UuDQoNCkZvciAxSyBwYWNrZXRzIHlvdSB3b3VsZCB1c2UgYWJvdXQg
MTAwMG5zICgzIGN5Y2xlcy9ieXRlKSBvbiBjcnlwdG8gYW5kIHRoaXMgd291bGQgaGFwcGVuIGlu
IEwxIGNhY2hlLiBJdCB3b3VsZCBvZiBjb3Vyc2UgY29uc3VtZSBhIGNvcmUgd2hpY2ggYSBjcnlw
dG8gb2ZmbG9hZCB3b3VsZCBub3QsIGJ1dCB0aGF0IGNhbiBiZSBkZWJhdGVkIGJlY2F1c2Ugd2l0
aCAxOCBjb3JlIHN5c3RlbXMsIHlvdXIgcHJvYmxlbSBpcyBtZW1vcnkgYW5kIG5ldHdvcmsgbW9y
ZSB0aGFuIENQVS4NCg0KTXkgY29uY2VybiB3aXRoIFBORSBpcyBmb3Igc21hbGwgcGFja2V0cyBh
bmQgbG93IGxhdGVuY3kgd2hlcmUNCjEpIGFuIGVzdGltYXRlZCAyNG5zIGZvciBQTiBlbmNyeXB0
aW9uIGFuZCBkZWNyeXB0aW9uIGJlY29tZXMgbWVhc3VyYWJsZSBpZiB5b3VyIG5ldHdvcmsgaXMg
ZmFzdCBlbm91Z2guDQoyKSBhbnkgZGFtYWdlIHRvIHRoZSBwYWNrZXQgYnVmZmVyIGNhdXNlIGFs
bCBzb3J0cyBvZiBtZW1vcnkgYW5kIGNwdSBidXMgdHJhZmZpYyBpc3N1ZXMuDQoNCjEpIGlzIGFu
bm95aW5nLiAyKSBpcyBiYWQsIGNvbXBsZXRlbHkgYXZvaWRhYmxlIGJ1dCBub3QgYXMgUFIgMTA3
OSBpcyBmb3JtdWxhdGVkIGN1cnJlbnRseS4NCg0KMikgaXMgYWxzbyBsaWtlbHkgYmFkIGZvciBo
YXJkd2FyZSBvZmZsb2FkIHVuaXRzIGFzIHdlbGwuDQoNCkFzIHRvIFNSVi1JTyAtIEnigJltIG5v
dCBmYW1pbGlhciB3aXRoIGl0LCBidXQgb2J2aW91c2x5IHRoZXJlIGlzIHNvbWUgSU8gYWJzdHJh
Y3Rpb24gbGF5ZXIgLSB0aGUgcXVlc3Rpb24gaXMgaG93IHlvdSBtYWtlIGl0IGFjY2Vzc2libGUg
dG8gYXBwcyBhcyBvcHBvc2VkIHRvIGRldmljZSBkcml2ZXJzIHRoYXQgZG9lcyBub3Igd29yayB3
aXRoIHlvdSBRVUlDIGN1c3RvbSBzdGFjaywgYW5kIG5ldG1hcCBpcyBvbmUgb3B0aW9uIGhlcmUu
DQoNCktpbmQgUmVnYXJkcywNCk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCg0KDQpPbiA0IEFw
cmlsIDIwMTggYXQgMjIuMTUuNTIsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIChwcmF2Yj00MG1p
Y3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnByYXZiPTQwbWljcm9zb2Z0LmNvbUBk
bWFyYy5pZXRmLm9yZz4pIHdyb3RlOg0KU29tZSBjb21wYXJhdGl2ZSBudW1iZXJzIGZyb20gYW4g
b3V0IG9mIGJveCBkZWZhdWx0IHNldHRpbmdzIFdpbmRvd3MgU2VydmVyIDIwMTYgKHJlbGVhc2Vk
IHZlcnNpb24pIGZvciBhIHNpbmdsZSBjb25uZWN0aW9uIHdpdGggYSBtaWNyb2JlbmNobWFyayB0
b29sOg0KDQpPZmZsb2FkcyBlbmFibGVkDQoNClRDUCBnYnBzDQoNClVEUCBnYnBzDQoNCkxTTyAr
IExSTyArIGNoZWNrc3VtDQoNCjI0DQoNCjMuNg0KDQpDaGVja3N1bSBvbmx5DQoNCjcuNg0KDQoz
LjYNCg0KTm9uZQ0KDQo1LjYNCg0KMi4zDQoNCg0KVGhpcyBpcyBmb3IgYSBmdWxseSBib3R0bGVu
ZWNrZWQgQ1BVIGNvcmUgLS0gaWYgeW91IHJ1biBsb3dlciBkYXRhIHJhdGVzIHRoZXJlIGlzIHN0
aWxsIGEgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZSBpbiBDeWNsZXMvYnl0ZSBjb3N0LiBTYW1lIGlu
Y3JlYXNlZCBDUFUgY29zdCBhcHBsaWVzIGZvciBjbGllbnQgc3lzdGVtcyBnb2luZyBvdmVyIGhp
Z2ggZGF0YSByYXRlIFdpZmkgYW5kIGNlbGx1bGFyLg0KDQpUaGlzIGlzIHdpdGhvdXQgYW55IGNy
eXB0by4gT25jZSB5b3UgYWRkIGNyeXB0byB0aGUgbnVtYmVycyBiZWNvbWUgbXVjaCB3b3JzZSB3
aXRoIGNyeXB0byBjb3N0IGJlY29taW5nIGRvbWluYW50LiBBZGRpbmcgYW5vdGhlciBjcnlwdG8g
c3RlcCBmdXJ0aGVyIGV4YWNlcmJhdGVzIHRoZSBwcm9ibGVtLiBIZW5jZSBjcnlwdG8gb2ZmbG9h
ZCBnYWlucyBpbiBpbXBvcnRhbmNlIGZvbGxvd2VkIGJ5IHRoZXNlIGJhdGNoIG9mZmxvYWRzLg0K
DQpJZiBmb2xrcyBuZWVkIGFueSBtb3JlIG51bWJlcnMgSeKAmWQgYmUgaGFwcHkgdG8gcHJvdmlk
ZSB0aGVtLg0KDQpUaGFua3MNCg0K

--_000_SN1PR08MB18548155722C665FFD45CC4DDABA0SN1PR08MB1854namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6IlNlZ29lIFVJIEVtb2ppIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9
DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu
aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs
dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw
ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN
Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs
MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn
aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tLTkwMDQ5MTcxNDk0MDU1OTQxNDNhaXJt
YWlsb24sIGxpLm0tOTAwNDkxNzE0OTQwNTU5NDE0M2Fpcm1haWxvbiwgZGl2Lm0tOTAwNDkxNzE0
OTQwNTU5NDE0M2Fpcm1haWxvbg0KCXttc28tc3R5bGUtbmFtZTptXy05MDA0OTE3MTQ5NDA1NTk0
MTQzYWlybWFpbG9uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow
aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv
bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh
bi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5
bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN
Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn
ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu
IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K
LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjgxMzAyNjA4
Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjI4NDUwOTg0O30NCkBsaXN0IGwwOmxldmVsMQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K
CW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm
b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w
OjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7
fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw0
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i
b2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu
c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2
ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT
eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEN
Cgl7bXNvLWxpc3QtaWQ6MTkzOTQ4NjI2NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4MzAy
NTgwMDY7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t
YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps
ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU
aW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox
LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N
CkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K
CW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv
cDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s
O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs
OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3
Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt
c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt
Ym9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U
aGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLiZuYnNwOyBJIGd1ZXNzIHdoYXQgSeKAmW0gcmVh
bGx5IGdldHRpbmcgZG93biB0byBpcyBob3cgZG8gd2UgcXVhbnRpZnkgdGhlIGFjdHVhbA0KPGk+
Y29zdDwvaT4gb2YgUE5FPyZuYnNwOyBBcmUgd2Ugc3Vic3RhbnRpYWxseSBpbmNyZWFzaW5nIHRo
ZSBjcnlwdG8gY29zdHM/Jm5ic3A7IElmIElhbiBpcyBzYXlpbmcgdGhhdCBjcnlwdG8gaXMgY29t
cGFyYXRpdmVseSBjaGVhcCBhbmQgdGhlIGNvc3QgaXMgdGhhdCBpdOKAmXMgaGFyZGVyIHRvIG9m
ZmxvYWQgc29tZXRoaW5nIHRoYXTigJlzIGNvbXBhcmF0aXZlbHkgY2hlYXAsIHdoYXQgaGF2ZSB3
ZSBsb3N0PyZuYnNwOyBJ4oCZZCB0aGluayB3ZSB3YW50IHRvIG9mZmxvYWQgdGhlDQogbW9zdCBp
bnRlbnNpdmUgcGllY2Ugd2UgY2FuLCBhbmQgaXQgc2VlbXMgbGlrZSB3ZeKAmXJlIHRhbGtpbmcg
YWJvdXQgY3J5cHRvIG9mZmxvYWRzLi4uLiZuYnNwOyBPciBhcmUgd2Ugc2F5aW5nIGluc3RlYWQg
dGhhdCB0aGUgY3J5cHRvIG1ha2VzIGl0IGhhcmRlciB0byBvZmZsb2FkIG90aGVyIHRoaW5ncyBp
biB0aGUgZnV0dXJlLCBsaWtlIGEgUVVJQyBlcXVpdmFsZW50IHRvIExSTy9MU08/PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t
OjwvYj4gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNv
bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgNSwgMjAxOCA5OjQ1IFBNPGJy
Pg0KPGI+VG86PC9iPiBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7OyBNaWtl
IEJpc2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBQcmF2
ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZndDs7IElFVEYgUVVJ
QyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEltcGFj
dCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2IGlkPSJjb21wb3NlLWNvbnRhaW5lciI+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBiZSBjbGVhciAtIEkgZG9u4oCZdCB0aGlu
ayBjcnlwdG8gaXMgb3ZlcnNoYWRvd2luZyBvdGhlciBpc3N1ZXMgYXMgTWlrZSByZWFkIG15IHBv
c3QuIEl0IGNlcnRhaW5seSBjb21lcyBhdCBhIGNvc3QsIGJ1dCBlaXRoZXIgbXVsdGlwbGUgY29y
ZXMgb3IgY28tcHJvY2Vzc29ycyB3aWxsIGRlYWwgd2l0aCB0aGlzLiAxMDAwbnMgaXMgMTBHYnBz
IGNyeXB0byBzcGVlZCBvbiBvbmUgY29yZSBhbmQgaXQgaXMgaGlnbHkNCiBwYXJhbGxlbGlzYWJs
ZSBhbmQgY2FjaGUgZnJpZW5kbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBpZiB5b3UgaGF2ZSB0byBkcmlwIHlvdXIgcGFja2V0cyB0
aHJvdWdoIGEgdHJhZGl0aW9uYWwgc2VuZCBpbnRlcmZhY2UgdGhhdCBpcyBjb3B5aW5nLCBidWZm
ZXJpbmcgb3IgYmxvY2tpbmcsIGFuZCBjZXJ0YWlubHkgc3luY+KAmWluZyB3aXRoIHRoZSBrZXJu
ZWwgLSBpdCBpcyBnb2luZyB0byBiZSB0b3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHJlY2VpdmUgeW91IHJpc2sgaGlnaCBsYXRl
bmN5IG9yIHRvcCBtdWNoIHNjaGVkdWxpbmcgaW4gcmVjZWl2ZSBidWZmZXJzLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05v
cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXpl
PSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdiBpZD0iZGl2UnBs
eUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiBJYW4gU3dldHQg
Jmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIj5pYW5zd2V0dEBnb29nbGUu
Y29tPC9hPiZndDs8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCA2LCAyMDE4IDQ6MDY6
MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgQmlzaG9wPGJyPg0KPGI+Q2M6PC9iPiBNaWtrZWwg
RmFobsO4ZSBKw7hyZ2Vuc2VuOyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbjsgSUVURiBRVUlDIFdH
PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMgb24g
bmV0d29yayBzdGFjayBwZXJmb3JtYW5jZTwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0
b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+T24gVGh1LCBBcHIgNSwgMjAxOCBhdCA1OjU3IFBNIE1pa2UgQmlzaG9wICZs
dDs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiPm1iaXNob3BAZXZlcXVlZm91
LmJlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6
MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhdOKAmXMgaW50ZXJlc3Rpbmcg
ZGF0YSwgUHJhdmVlbiDigJMgdGhhbmtzLiZuYnNwOyBUaGVyZSBpcyBvbmUgY2F2ZWF0IHRoZXJl
LCB3aGljaCBpcyB0aGF0IChJSVVDLCBvbiBjdXJyZW50IGhhcmR3YXJlKSB5b3UgY2Fu4oCZdCBk
byBwYWNrZXQgcGFjaW5nIHdpdGggTFNPLCBhbmQgc28gbXkgdW5kZXJzdGFuZGluZyBpcw0KIHRo
YXQgZXZlbiBmb3IgVENQIG1hbnkgcHJvdmlkZXJzIGRpc2FibGUgdGhpcyBpbiBwdXJzdWl0IG9m
IGJldHRlciBlZ3Jlc3MgbWFuYWdlbWVudC4mbmJzcDsgU28gd2hhdCB3ZeKAmXJlIHJlYWxseSBz
YXlpbmcgaXMgdGhhdDo8bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KT24gY3VycmVudCBoYXJk
d2FyZSBhbmQgT1Mgc2V0dXBzLCBVRFAgcnVucyBsZXNzIHRoYW4gaGFsZiBhcyBtdWNoIHRocm91
Z2hwdXQgYXMgVENQOyB0aGF0IG5lZWRzIHNvbWUgb3B0aW1pemF0aW9uLCBhcyB3ZeKAmXZlIGFs
cmVhZHkgZGlzY3Vzc2VkPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv
LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVENQIHdpbGwgZHJhbWF0aWNhbGx5IGdhaW4gcGVyZm9y
bWFuY2Ugb25jZSBoYXJkd2FyZSBvZmZsb2FkIGNhdGNoZXMgdXAgYW5kIGFsbG93cw0KPHU+cGFj
ZWQ8L3U+IExTTyA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkm
cXVvdDssc2Fucy1zZXJpZiI+JiMxMjg1MjI7PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+SG93ZXZlciwgYXMgTWlra2VsIHBvaW50cyBvdXQsIHRoZSBjcnlwdG8gY29z
dHMgYXJlIGxpa2VseSB0byBvdmVyd2hlbG0gdGhlIE9TIHRocm91Z2hwdXQgLyBzY2hlZHVsaW5n
IGlzc3VlcyBpbiByZWFsIGRlcGxveW1lbnRzLiZuYnNwOyBTbyBJIHRoaW5rIHRoZSBvdGhlciBy
ZWxldmFudCBwaWVjZSB0byB1bmRlcnN0YW5kaW5nDQogdGhlIGNvc3QgaGVyZSBpcyB0aGlzOjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhIGZldyBjYXNlcyhib3RoIGNsaWVudCBhbmQgc2Vy
dmVyKSB3aGVyZSBteSBVRFAgc2VuZCBjb3N0cyBhcmUgbW9yZSB0aGFuIDMwJShpbiBzb21lIGNh
c2VzIDUwJSkgb2YgQ1BVIGNvbnN1bXB0aW9uLCBhbmQgY3J5cHRvIGlzIGxlc3MgdGhhbiAxMCUu
Jm5ic3A7IFNvIGN1cnJlbnRseSwgSSBhc3N1bWUgY3J5cHRvIGlzIGNoZWFwKGVzcGVjaWFsbHkg
QUVTLUdDTSB3aGVuIGhhcmR3YXJlIGFjY2VsZXJhdGlvbg0KIGlzIGF2YWlsYWJsZSkgYW5kIGVn
cmVzcyBpcyBleHBlbnNpdmUuJm5ic3A7IFVEUCBpbmdyZXMgaXMgbm90IHRoYXQgZXhwZW5zaXZl
LCBidXQgY291bGQgdXNlIGEgYml0IG9mIG9wdGltaXphdGlvbiBhcyB3ZWxsLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb25seSAnZmFu
Y3knIHRoaW5nIG91ciBjdXJyZW50IGNvZGUgaXMgZG9pbmcgZm9yIGNyeXB0byBpcyBlbmNyeXB0
aW5nIGluIHBsYWNlLCB3aGljaCB3YXMgYSB+MiUgd2luLiZuYnNwOyBOaWNlLCBidXQgbm90IHRy
YW5zZm9ybWF0aXZlLiZuYnNwOyBTZWUNCjxhIGhyZWY9Imh0dHBzOi8vY3MuY2hyb21pdW0ub3Jn
L2Nocm9taXVtL3NyYy9uZXQvcXVpYy9jb3JlL3F1aWNfZnJhbWVyLmNjP3NxPXBhY2thZ2U6Y2hy
b21pdW0mYW1wO2w9MTg5MyI+DQpFbmNyeXB0SW5QbGFjZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlbid0IGRvbmUgbXVjaCB3
b3JrIGJlbmNobWFya2luZyBXaW5kb3dzLCBzbyBwb3NzaWJseSB0aGUgV2luZG93cyBVRFAgc3Rh
Y2sgaXMgcmVhbGx5IGZhc3QsIGFuZCBzbyBjcnlwdG8gc2VlbXMgcmVhbGx5IHNsb3cgaW4gY29t
cGFyaXNvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g
MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk
aXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omwx
IGxldmVsMSBsZm8yIj4NCldoYXQgaXMgdGhlIHRocm91Z2hwdXQgYW5kIHJlbGF0aXZlIGNvc3Qg
b2YgVExTL1RDUCB2ZXJzdXMgUVVJQyAoaS5lLiBob3cgbXVjaCBhcmUgdGhlIHNtYWxsZXIgdW5p
dHMgb2YgZW5jcnlwdGlvbiBodXJ0aW5nIHVzIHZlcnN1cywgc2F5LCAxNktCIFRMUyByZWNvcmRz
KT8NCjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNp
cmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMiBsZm8yIj4N
ClRMUyBpbXBsZW1lbnRhdGlvbnMgYWxyZWFkeSB2YXJ5IGhlcmU6Jm5ic3A7IFNvbWUgaW1wbGVt
ZW50YXRpb25zIGNob29zZSBsYXJnZSByZWNvcmQgc2l6ZXMsIHNvbWUgdmFyeSByZWNvcmQgc2l6
ZXMgdG8gcmVkdWNlIGRlbGF5IC8gSG9MQiwgc28gdGhpcyBwcm9iYWJseSBpc27igJl0IGEgc2lu
Z2xlIG51bWJlci48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+
DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCkhvdyBt
dWNoIGFkZGl0aW9uYWwgbG9hZCBkb2VzIFBORSBhZGQgdG8gdGhpcyBkaWZmZXJlbmNlPzxvOnA+
PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8y
Ij4NClRvIHdoYXQgZXh0ZW50IHdvdWxkIFBORSBtYWtlIGZ1dHVyZSBjcnlwdG8gb2ZmbG9hZHMg
PGk+aW1wb3NzaWJsZTwvaT4gdmVyc3VzIDxpPg0KcmVxdWlyZXMgbW9yZSBSJmFtcDtEIHRvIGRl
dmVsb3A8L2k+PzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86PGEgaHJlZj0i
bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNl
c0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1pa2tlbCBGYWhuw7hlIErDuHJn
ZW5zZW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDE4IDE6MzQgUE08
YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2Yj08YSBocmVm
PSJtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs7IElFVEYgUVVJQyBXRyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYu
b3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEltcGFjdCBvZiBoYXJkd2FyZSBv
ZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxkaXYgaWQ9Im1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3Igc2hhcmluZyB0
aGVzZSBudW1iZXJzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8t
OTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2IGlkPSJtXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NeSBndWVzcyBpcyB0aGF0
IHRoZXNlIG9mZmxvYWRzIGRlYWwgd2l0aCBrZXJuZWwgc2NoZWR1bGluZywgbWVtb3J5IGNhY2hl
IGlzc3VlcywgYW5kIGludGVycnVwdCBzY2hlZHVsaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0ibV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy05MDA0OTE3MTQ5NDA1NTk0MTQz
Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj5JdCBwcm9iYWJseSBoYXMgdmVyeSBsaXR0bGUgdG8gZG8gd2l0aCBjcnlwdG8sIFRDUCBo
ZWFkZXJzLCBhbmQgYW55IG90aGVyIGNwdSBzZW5zaXRpdmUgcHJvY2Vzc2luZy48L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9v
cF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tOTAwNDkx
NzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+VGhpcyBpcyB3aGVyZSBuZXRtYXAgZW50ZXJzOiB5b3UgY2FuIHRy
YW5zcGFyZW50bHkgZmVlZCB0aGUgZGF0YSBhcyBpdCBiZWNvbWVzIGF2YWlsYWJsZSB3aXRoIHZl
cnkgbGl0dGxlIHN5bmMNCiB3b3JrIGFuZCB5b3UgY2FuIGFsc28gZWZmaWNpZW50bHkgcGlwZWxp
bmUgc28geW91IHBhc3MgZGF0YSB0byBkZWNyeXB0b3IsIHRoZW4gdG8gYXBwLCB3aXRoIGFzIGxp
dHRsZSBidXMgdHJhZmZpYyBhcyBwb3NzaWJsZS4gTm8gbmVlZCB0byBjb3B5IGRhdGEgb3Igc3lu
Y2hyb25pemUga2VybmVsIHNwYWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
diBpZD0ibV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9t
Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgMUsg
cGFja2V0cyB5b3Ugd291bGQgdXNlIGFib3V0IDEwMDBucyAoMyBjeWNsZXMvYnl0ZSkgb24gY3J5
cHRvIGFuZCB0aGlzIHdvdWxkIGhhcHBlbiBpbiBMMSBjYWNoZS4gSXQgd291bGQNCiBvZiBjb3Vy
c2UgY29uc3VtZSBhIGNvcmUgd2hpY2ggYSBjcnlwdG8gb2ZmbG9hZCB3b3VsZCBub3QsIGJ1dCB0
aGF0IGNhbiBiZSBkZWJhdGVkIGJlY2F1c2Ugd2l0aCAxOCBjb3JlIHN5c3RlbXMsIHlvdXIgcHJv
YmxlbSBpcyBtZW1vcnkgYW5kIG5ldHdvcmsgbW9yZSB0aGFuIENQVS48L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0
b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tOTAwNDkxNzE0OTQw
NTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+TXkgY29uY2VybiB3aXRoIFBORSBpcyBmb3Igc21hbGwgcGFja2V0cyBhbmQg
bG93IGxhdGVuY3kgd2hlcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9
Im1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjEpIGFuIGVzdGltYXRlZCAyNG5zIGZvciBQTiBl
bmNyeXB0aW9uIGFuZCBkZWNyeXB0aW9uIGJlY29tZXMgbWVhc3VyYWJsZSBpZiB5b3VyIG5ldHdv
cmsgaXMgZmFzdCBlbm91Z2guPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk
PSJtXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yKSBhbnkgZGFtYWdlIHRvIHRoZSBwYWNrZXQg
YnVmZmVyIGNhdXNlIGFsbCBzb3J0cyBvZiBtZW1vcnkgYW5kIGNwdSBidXMgdHJhZmZpYyBpc3N1
ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy05MDA0OTE3MTQ5
NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg
aWQ9Im1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjEpIGlzIGFubm95aW5nLiAyKSBpcyBiYWQs
IGNvbXBsZXRlbHkgYXZvaWRhYmxlIGJ1dCBub3QgYXMgUFIgMTA3OSBpcyBmb3JtdWxhdGVkIGN1
cnJlbnRseS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTkwMDQ5
MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdiBpZD0ibV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+MikgaXMgYWxzbyBsaWtlbHkgYmFk
IGZvciBoYXJkd2FyZSBvZmZsb2FkIHVuaXRzIGFzIHdlbGwuPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9u
dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPkFzIHRvIFNSVi1JTyAtIEnigJltIG5vdCBmYW1pbGlhciB3aXRoIGl0LCBi
dXQgb2J2aW91c2x5IHRoZXJlIGlzIHNvbWUgSU8gYWJzdHJhY3Rpb24gbGF5ZXIgLSB0aGUgcXVl
c3Rpb24gaXMgaG93DQogeW91IG1ha2UgaXQgYWNjZXNzaWJsZSB0byBhcHBzIGFzIG9wcG9zZWQg
dG8gZGV2aWNlIGRyaXZlcnMgdGhhdCBkb2VzIG5vciB3b3JrIHdpdGggeW91IFFVSUMgY3VzdG9t
IHN0YWNrLCBhbmQgbmV0bWFwIGlzIG9uZSBvcHRpb24gaGVyZS48L3NwYW4+PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0ibV8tOTAwNDkxNzE0OTQwNTU5NDE0
M2Jsb29wX3NpZ25fMTUyMjg3MzM1MDQxNTEyMDEyOCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+S2luZCBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
Pk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tOTAwNDkxNzE0OTQwNTU5NDE0M2Fp
cm1haWxvbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDQgQXByaWwgMjAxOCBhdCAyMi4xNS41Miwg
UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gKDxhIGhyZWY9Im1haWx0bzpwcmF2Yj00MG1pY3Jvc29m
dC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wcmF2Yj00MG1pY3Jvc29mdC5j
b21AZG1hcmMuaWV0Zi5vcmc8L2E+KQ0KIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+U29tZSBjb21wYXJhdGl2ZSBudW1iZXJzIGZyb20gYW4gb3V0IG9mIGJveCBkZWZhdWx0
IHNldHRpbmdzIFdpbmRvd3MgU2VydmVyIDIwMTYgKHJlbGVhc2VkIHZlcnNpb24pIGZvciBhIHNp
bmdsZQ0KIGNvbm5lY3Rpb24gd2l0aCBhIG1pY3JvYmVuY2htYXJrIHRvb2w6PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIg
Ym9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJib3JkZXIt
Y29sbGFwc2U6Y29sbGFwc2UiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGln
bj0idG9wIiBzdHlsZT0id2lkdGg6MTE2Ljg1cHQ7Ym9yZGVyOnNvbGlkICM5OTk5OTkgMS4wcHQ7
Ym9yZGVyLWJvdHRvbTpzb2xpZCAjNjY2NjY2IDEuNXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1
LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PZmZs
b2FkcyBlbmFibGVkPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9
IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6c29saWQg
Izk5OTk5OSAxLjBwdDtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgIzY2NjY2
NiAxLjVwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBpbiA1LjRw
dCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+VENQIGdicHM8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0i
MTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7Ym9yZGVyLXRvcDpzb2xpZCAj
OTk5OTk5IDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjNjY2NjY2
IDEuNXB0O2JvcmRlci1yaWdodDpzb2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0
IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij5VRFAgZ2Jwczwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4N
Cjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi44NXB0O2JvcmRl
cjpzb2xpZCAjOTk5OTk5IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBpbiA1LjRwdCAw
aW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
TFNPICYjNDM7IExSTyAmIzQzOyBjaGVja3N1bTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8
L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2LjlwdDti
b3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICM5OTk5
OTkgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7cGFkZGluZzowaW4gNS40
cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PjI0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249
InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5v
bmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjOTk5OTk5IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCAj
OTk5OTk5IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4zLjY8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5bGU9Indp
ZHRoOjExNi44NXB0O2JvcmRlcjpzb2xpZCAjOTk5OTk5IDEuMHB0O2JvcmRlci10b3A6bm9uZTtw
YWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+Q2hlY2tzdW0gb25seTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+
DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2Ljlw
dDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICM5
OTk5OTkgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7cGFkZGluZzowaW4g
NS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPjcuNjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFs
aWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVm
dDpub25lO2JvcmRlci1ib3R0b206c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29s
aWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+My42PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxl
PSJ3aWR0aDoxMTYuODVwdDtib3JkZXI6c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItdG9wOm5v
bmU7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk5vbmU8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90
ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7Ym9y
ZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjOTk5OTk5
IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0
IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj41
LjY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0i
dG9wIiBzdHlsZT0id2lkdGg6MTE2LjlwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9u
ZTtib3JkZXItYm90dG9tOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5
OTk5OTkgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjIuMzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
dGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIGZvciBhIGZ1bGx5IGJvdHRs
ZW5lY2tlZCBDUFUgY29yZSAtLQ0KPGk+aWYgeW91IHJ1biBsb3dlciBkYXRhIHJhdGVzIHRoZXJl
IGlzIHN0aWxsIGEgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZSBpbiBDeWNsZXMvYnl0ZSBjb3N0PC9p
Pi4gU2FtZSBpbmNyZWFzZWQgQ1BVIGNvc3QgYXBwbGllcyBmb3IgY2xpZW50IHN5c3RlbXMgZ29p
bmcgb3ZlciBoaWdoIGRhdGEgcmF0ZSBXaWZpIGFuZCBjZWxsdWxhci4NCjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPlRoaXMgaXMgd2l0aG91dCBhbnkgY3J5cHRvLiBPbmNlIHlvdSBhZGQgY3J5cHRv
IHRoZSBudW1iZXJzIGJlY29tZSBtdWNoIHdvcnNlDQo8aT53aXRoIGNyeXB0byBjb3N0IGJlY29t
aW5nIGRvbWluYW50PC9pPi4gQWRkaW5nIGFub3RoZXIgY3J5cHRvIHN0ZXAgZnVydGhlciBleGFj
ZXJiYXRlcyB0aGUgcHJvYmxlbS4gSGVuY2UgY3J5cHRvIG9mZmxvYWQgZ2FpbnMgaW4gaW1wb3J0
YW5jZSBmb2xsb3dlZCBieSB0aGVzZSBiYXRjaCBvZmZsb2Fkcy48L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj5JZiBmb2xrcyBuZWVkIGFueSBtb3JlIG51bWJlcnMgSeKAmWQgYmUgaGFwcHkgdG8gcHJv
dmlkZSB0aGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rczwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_SN1PR08MB18548155722C665FFD45CC4DDABA0SN1PR08MB1854namp_--


From nobody Fri Apr  6 13:55:38 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E00120721 for ; Fri,  6 Apr 2018 13:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-NRMldYFLYI for ; Fri,  6 Apr 2018 13:55:34 -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 1FCCE1201F8 for ; Fri,  6 Apr 2018 13:55:34 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id v194-v6so3318702itb.0 for ; Fri, 06 Apr 2018 13:55:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9nddmN8IPCl1KxN58mGCcGwECG6+9G1+O3SgTBmU6s8=; b=TMHU5zoRnQ1hkvj/86/Tr7xNqoRJ+k5Yhmlv4d9aiadpMnSs320ZyWoHOUgp1kyjF1 sxra21NMYy3EImUFQxkR7OZ0ccTvlrQz5CLFVZHAz6VS54vnIIEQKgjEOgUNOP8tmw4k 38nrJg8yL4GfIiqaa4A8eRW+0hs2Lk1Li5mc2s0bNHTN22iW6fmGn26D61bb4+9k/9BK Owfux0T9XHVhQi6M2AVqf70SVqi9n3kgRaHwsLJkqOd3X/xIn3feMvCDQnWY7Pe8mYW2 y5d7vuKRhUTPuiqw9a2oKnqhypVN98Nt8CtYlcCi7oM7cmVnle8nhseq7p1v8cwTsuRM CkWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9nddmN8IPCl1KxN58mGCcGwECG6+9G1+O3SgTBmU6s8=; b=md0RmVjzUgubGQzL9tvgnWILkygE9PyByOlqY5htZGiT6sVpWVSf9dYVKpPOmr+RUb QohM7JyaoUX02q1htY4Avr2DPynQ9qwvWtZ7GChWakvpVBnnQZz8BBDqS3lfptxWgIBe Y1pj4hFPuSfknj48SNpW74YDjFfh7FvCI4OJTcaaNpCv/ESeAOB011vRGYbC2tSKeOAx CYBBG6dY/cqE1d9WGC63iJ3x99QhKNZNh+0vEj4yuyRberh/cMjhX6fVfygNn4nIhH+j v06V5lYIsT3/SMz+R7As6z7JtSit8veMqPtQbbR+W4qnBEAtXlvZ9kTwjlIhiEbsNp3U wfAQ==
X-Gm-Message-State: ALQs6tB5gax+2rdOzEQwJepsWxHZCMgy77miBZWBMJ6vA6mFuO1hquOu rPGwOA8nEXR1FGF20x+qQ64CkGWLiRtR7btTAGkH2w==
X-Google-Smtp-Source: AIpwx4+qytsBlGPlmTDrQMrDUDxEyNEwpyysNgBhE4ABqDX6kIIyYzn5NtTrl3Xf2dhoamERCZ6pQiPk6vaeGy+ffPM=
X-Received: by 2002:a24:5a49:: with SMTP id v70-v6mr6896397ita.54.1523048133021;  Fri, 06 Apr 2018 13:55:33 -0700 (PDT)
MIME-Version: 1.0
References:      
In-Reply-To: 
From: Ian Swett 
Date: Fri, 06 Apr 2018 20:55:21 +0000
Message-ID: 
Subject: Re: Impact of hardware offloads on network stack performance
To: Mike Bishop 
Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= ,  Praveen Balasubramanian , IETF QUIC WG 
Content-Type: multipart/alternative; boundary="000000000000f27cbd056934468b"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 06 Apr 2018 20:55:37 -0000

--000000000000f27cbd056934468b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

PNE doesn't preclude UDP LRO or pacing offload.

However, in a highly optimized stack(ie: The Disk|Crypt|Net paper from
SIGCOMM 2017) not touching(ie: bringing into memory or cache) the content
to be sent until the last possible moment is critical.  PNE likely means
touching that content much earlier.

But personally I consider the actual crypto we're talking about(2 AES
instructions?) adding basically free.

On Fri, Apr 6, 2018 at 4:37 PM Mike Bishop  wrote:

> Thanks for the clarification.  I guess what I=E2=80=99m really getting do=
wn to is
> how do we quantify the actual *cost* of PNE?  Are we substantially
> increasing the crypto costs?  If Ian is saying that crypto is comparative=
ly
> cheap and the cost is that it=E2=80=99s harder to offload something that=
=E2=80=99s
> comparatively cheap, what have we lost?  I=E2=80=99d think we want to off=
load the
> most intensive piece we can, and it seems like we=E2=80=99re talking abou=
t crypto
> offloads....  Or are we saying instead that the crypto makes it harder to
> offload other things in the future, like a QUIC equivalent to LRO/LSO?
>
>
>
> *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]
> *Sent:* Thursday, April 5, 2018 9:45 PM
> *To:* Ian Swett ; Mike Bishop 
> *Cc:* Praveen Balasubramanian ; IETF QUIC WG <
> quic@ietf.org>
> *Subject:* Re: Impact of hardware offloads on network stack performance
>
>
>
> To be clear - I don=E2=80=99t think crypto is overshadowing other issues =
as Mike
> read my post. It certainly comes at a cost, but either multiple cores or
> co-processors will deal with this. 1000ns is 10Gbps crypto speed on one
> core and it is higly parallelisable and cache friendly.
>
>
>
> But if you have to drip your packets through a traditional send interface
> that is copying, buffering or blocking, and certainly sync=E2=80=99ing wi=
th the
> kernel - it is going to be tough.
>
>
>
> For receive you risk high latency or top much scheduling in receive
> buffers.
>
>
> ------------------------------
>
> *From:* Ian Swett 
> *Sent:* Friday, April 6, 2018 4:06:01 AM
> *To:* Mike Bishop
> *Cc:* Mikkel Fahn=C3=B8e J=C3=B8rgensen; Praveen Balasubramanian; IETF QU=
IC WG
> *Subject:* Re: Impact of hardware offloads on network stack performance
>
>
>
>
>
> On Thu, Apr 5, 2018 at 5:57 PM Mike Bishop  wrote:
>
> That=E2=80=99s interesting data, Praveen =E2=80=93 thanks.  There is one =
caveat there,
> which is that (IIUC, on current hardware) you can=E2=80=99t do packet pac=
ing with
> LSO, and so my understanding is that even for TCP many providers disable
> this in pursuit of better egress management.  So what we=E2=80=99re reall=
y saying
> is that:
>
>    - On current hardware and OS setups, UDP runs less than half as much
>    throughput as TCP; that needs some optimization, as we=E2=80=99ve alre=
ady discussed
>    - TCP will dramatically gain performance once hardware offload catches
>    up and allows *paced* LSO =F0=9F=98=8A
>
>
>
> However, as Mikkel points out, the crypto costs are likely to overwhelm
> the OS throughput / scheduling issues in real deployments.  So I think th=
e
> other relevant piece to understanding the cost here is this:
>
>
>
> I have a few cases(both client and server) where my UDP send costs are
> more than 30%(in some cases 50%) of CPU consumption, and crypto is less
> than 10%.  So currently, I assume crypto is cheap(especially AES-GCM when
> hardware acceleration is available) and egress is expensive.  UDP ingres =
is
> not that expensive, but could use a bit of optimization as well.
>
>
>
> The only 'fancy' thing our current code is doing for crypto is encrypting
> in place, which was a ~2% win.  Nice, but not transformative.  See
> EncryptInPlace
> 
>
>
>
> I haven't done much work benchmarking Windows, so possibly the Windows UD=
P
> stack is really fast, and so crypto seems really slow in comparison?
>
>
>
>
>    - What is the throughput and relative cost of TLS/TCP versus QUIC
>    (i.e. how much are the smaller units of encryption hurting us versus, =
say,
>    16KB TLS records)?
>
>
>    - TLS implementations already vary here:  Some implementations choose
>       large record sizes, some vary record sizes to reduce delay / HoLB, =
so this
>       probably isn=E2=80=99t a single number.
>
>
>    - How much additional load does PNE add to this difference?
>    - To what extent would PNE make future crypto offloads *impossible*
>    versus * requires more R&D to develop*?
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahn=C3=
=B8e
> J=C3=B8rgensen
> *Sent:* Wednesday, April 4, 2018 1:34 PM
> *To:* Praveen Balasubramanian ;
> IETF QUIC WG 
> *Subject:* Re: Impact of hardware offloads on network stack performance
>
>
>
> Thanks for sharing these numbers.
>
>
>
> My guess is that these offloads deal with kernel scheduling, memory cache
> issues, and interrupt scheduling.
>
>
>
> It probably has very little to do with crypto, TCP headers, and any other
> cpu sensitive processing.
>
>
>
> This is where netmap enters: you can transparently feed the data as it
> becomes available with very little sync work and you can also efficiently
> pipeline so you pass data to decryptor, then to app, with as little bus
> traffic as possible. No need to copy data or synchronize kernel space.
>
>
>
> For 1K packets you would use about 1000ns (3 cycles/byte) on crypto and
> this would happen in L1 cache. It would of course consume a core which a
> crypto offload would not, but that can be debated because with 18 core
> systems, your problem is memory and network more than CPU.
>
>
>
> My concern with PNE is for small packets and low latency where
>
> 1) an estimated 24ns for PN encryption and decryption becomes measurable
> if your network is fast enough.
>
> 2) any damage to the packet buffer cause all sorts of memory and cpu bus
> traffic issues.
>
>
>
> 1) is annoying. 2) is bad, completely avoidable but not as PR 1079 is
> formulated currently.
>
>
>
> 2) is also likely bad for hardware offload units as well.
>
>
>
> As to SRV-IO - I=E2=80=99m not familiar with it, but obviously there is s=
ome IO
> abstraction layer - the question is how you make it accessible to apps as
> opposed to device drivers that does nor work with you QUIC custom stack,
> and netmap is one option here.
>
>
>
> Kind Regards,
>
> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>
>
>
> On 4 April 2018 at 22.15.52, Praveen Balasubramanian (
> pravb=3D40microsoft.com@dmarc.ietf.org) wrote:
>
> Some comparative numbers from an out of box default settings Windows
> Server 2016 (released version) for a single connection with a
> microbenchmark tool:
>
>
>
> *Offloads enabled*
>
> *TCP gbps*
>
> *UDP gbps*
>
> *LSO + LRO + checksum*
>
> 24
>
> 3.6
>
> *Checksum only*
>
> 7.6
>
> 3.6
>
> *None*
>
> 5.6
>
> 2.3
>
>
>
> This is for a fully bottlenecked CPU core -- *if you run lower data rates
> there is still a significant difference in Cycles/byte cost*. Same
> increased CPU cost applies for client systems going over high data rate
> Wifi and cellular.
>
>
>
> This is without any crypto. Once you add crypto the numbers become much
> worse *with crypto cost becoming dominant*. Adding another crypto step
> further exacerbates the problem. Hence crypto offload gains in importance
> followed by these batch offloads.
>
>
>
> If folks need any more numbers I=E2=80=99d be happy to provide them.
>
>
>
> Thanks
>
>
>
>

--000000000000f27cbd056934468b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


PNE doesn't preclude UDP LRO or pacing offload.
However, in a highly optimized stack(ie: The Disk|Crypt|Net pa=
per from SIGCOMM 2017) not touching(ie: bringing into memory or cache) the =
content to be sent until the last possible moment is critical.=C2=A0 PNE li=
kely means touching that content much earlier.

But=
 personally I consider the actual crypto we're talking about(2 AES inst=
ructions?) adding basically free.=C2=A0=C2=A0

On Fri, Apr 6, 2018 at 4:37 PM Mike Bishop &l=
t;mbishop@evequefou.be> wrot=
e:











Thanks for the clarification.=C2=A0 I guess what I=
=E2=80=99m really getting down to is how do we quantify the actual
cost of PNE?=C2=A0 Are we substantially increasing the crypto costs?=
=C2=A0 If Ian is saying that crypto is comparatively cheap and the cost is =
that it=E2=80=99s harder to offload something that=E2=80=99s comparatively =
cheap, what have we lost?=C2=A0 I=E2=80=99d think we want to offload the
 most intensive piece we can, and it seems like we=E2=80=99re talking about=
 crypto offloads....=C2=A0 Or are we saying instead that the crypto makes i=
t harder to offload other things in the future, like a QUIC equivalent to L=
RO/LSO?


=C2=A0






From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mail=
to:mikkelfj@gmail.c=
om]


Sent: Thursday, April 5, 2018 9:45 PM

To: Ian Swett <ianswett@google.com>; Mike Bishop <mbishop@evequefou.be>

Cc: Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>

Subject: Re: Impact of hardware offloads on network stack performanc=
e






=C2=A0










To be clear - I don=E2=80=99t think crypto is oversh=
adowing other issues as Mike read my post. It certainly comes at a cost, bu=
t either multiple cores or co-processors will deal with this. 1000ns is 10G=
bps crypto speed on one core and it is higly
 parallelisable and cache friendly.






=C2=A0






But if you have to drip your packets through a tradi=
tional send interface that is copying, buffering or blocking, and certainly=
 sync=E2=80=99ing with the kernel - it is going to be tough.<=
/p>





=C2=A0






For receive you risk high latency or top much schedu=
ling in receive buffers.








=C2=A0
















From: Ian Swett <ianswett@google.com>

Sent: Friday, April 6, 2018 4:06:01 AM

To: Mike Bishop

Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen; Praveen Balasubramanian; IETF=
 QUIC WG

Subject: Re: Impact of hardware offloads on network stack performanc=
e





=C2=A0










=C2=A0<=
/p>





On Thu, Apr 5, 2018 at 5:57 PM Mike Bishop <mbishop@evequefou.be> wrote:










That=E2=80=99s interesting data, Praveen =E2=80=93 t=
hanks.=C2=A0 There is one caveat there, which is that (IIUC, on current har=
dware) you can=E2=80=99t do packet pacing with LSO, and so my understanding=
 is
 that even for TCP many providers disable this in pursuit of better egress =
management.=C2=A0 So what we=E2=80=99re really saying is that:


    

  • 
On current hardware and OS setups, UDP runs less than half as much throughp=
ut as TCP; that needs some optimization, as we=E2=80=99ve already discussed=

  • 
TCP will dramatically gain performance once hardware offload catches up and=
 allows
paced LSO =F0=9F=98=8A


=C2=A0


However, as Mikkel points out, the crypto costs are =
likely to overwhelm the OS throughput / scheduling issues in real deploymen=
ts.=C2=A0 So I think the other relevant piece to understanding
 the cost here is this:










=C2=A0






I have a few cases(both client and server) where my =
UDP send costs are more than 30%(in some cases 50%) of CPU consumption, and=
 crypto is less than 10%.=C2=A0 So currently, I assume crypto is cheap(espe=
cially AES-GCM when hardware acceleration
 is available) and egress is expensive.=C2=A0 UDP ingres is not that expens=
ive, but could use a bit of optimization as well.






=C2=A0







=C2=A0






I haven't done much work benchmarking Windows, s=
o possibly the Windows UDP stack is really fast, and so crypto seems really=
 slow in comparison?






=C2=A0










    

  • 
What is the throughput and relative cost of TLS/TCP versus QUIC (i.e. how m=
uch are the smaller units of encryption hurting us versus, say, 16KB TLS re=
cords)?



    

      

    • 
TLS implementations already vary here:=C2=A0 Some implementations choose la=
rge record sizes, some vary record sizes to reduce delay / HoLB, so this pr=
obably isn=E2=80=99t a single number.
    



    

  • 
How much additional load does PNE add to this difference?
  • 
To what extent would PNE make future crypto offloads impossible vers=
us 
requires more R&D to develop?


=C2=A0






From: QUIC [mailto:quic-bounces@ietf.org]
On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen

Sent: Wednesday, April 4, 2018 1:34 PM

To: Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org&=
gt;; IETF QUIC WG <qu=
ic@ietf.org>

Subject: Re: Impact of hardware offloads on network stack performanc=
e






=C2=A0




Thanks for sharing these numbers.






=C2=A0






My guess is that these offloads deal with kernel =
scheduling, memory cache issues, and interrupt scheduling.=







=C2=A0






It probably has very little to do with crypto, TC=
P headers, and any other cpu sensitive processing.






=C2=A0






This is where netmap enters: you can transparentl=
y feed the data as it becomes available with very little sync
 work and you can also efficiently pipeline so you pass data to decryptor, =
then to app, with as little bus traffic as possible. No need to copy data o=
r synchronize kernel space.






=C2=A0






For 1K packets you would use about 1000ns (3 cycl=
es/byte) on crypto and this would happen in L1 cache. It would
 of course consume a core which a crypto offload would not, but that can be=
 debated because with 18 core systems, your problem is memory and network m=
ore than CPU.






=C2=A0






My concern with PNE is for small packets and low =
latency where






1) an estimated 24ns for PN encryption and decryp=
tion becomes measurable if your network is fast enough.






2) any damage to the packet buffer cause all sort=
s of memory and cpu bus traffic issues.






=C2=A0






1) is annoying. 2) is bad, completely avoidable b=
ut not as PR 1079 is formulated currently.






=C2=A0






2) is also likely bad for hardware offload units =
as well.






=C2=A0




As to SRV-IO - I=E2=80=99m not familiar with it, =
but obviously there is some IO abstraction layer - the question is how
 you make it accessible to apps as opposed to device drivers that does nor =
work with you QUIC custom stack, and netmap is one option here.




=C2=A0






Kind Regards,






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






=C2=A0


On 4 A=
pril 2018 at 22.15.52, Praveen Balasubramanian (pravb=3D40microsoft.com@dm=
arc.ietf.org)
 wrote:










Some comparative numbers from an out of box defau=
lt settings Windows Server 2016 (released version) for a single
 connection with a microbenchmark tool:


=C2=A0








Offloads enabled




TCP gbps




UDP gbps








LSO + LRO + checksum<=
/p>




24




3.6








Checksum only




7.6




3.6








None




5.6




2.3








=C2=A0


This is for a fully bottlenecked CPU core --
if you run lower data rates there is still a significant difference in C=
ycles/byte cost. Same increased CPU cost applies for client systems goi=
ng over high data rate Wifi and cellular.



=C2=A0


This is without any crypto. Once you add crypto t=
he numbers become much worse
with crypto cost becoming dominant. Adding another crypto step furth=
er exacerbates the problem. Hence crypto offload gains in importance follow=
ed by these batch offloads.


=C2=A0


If folks need any more numbers I=E2=80=99d be hap=
py to provide them.


=C2=A0


Thanks


=C2=A0































--000000000000f27cbd056934468b--


From nobody Fri Apr  6 14:20:19 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649C9120721 for ; Fri,  6 Apr 2018 14:20:17 -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 BiZh7A034Uab for ; Fri,  6 Apr 2018 14:20:13 -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 585FE1201F8 for ; Fri,  6 Apr 2018 14:20:13 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id e79so3248571ioi.7 for ; Fri, 06 Apr 2018 14:20:13 -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=WvrASTbKRR+ViHK2yn1yBx8iHpT75IKPKQ2LcrzCo/Y=; b=GUmypH5yJjrOrOgvRLjNcx2gIgosgfWEYK0sRVeFVSLhliPclJ9IIXi/87iojAJFLB R0yVylKBRnFJkLFAb262X6+Lxq+M+1mzSA7UqB8lj2ydZbQ5XHBMDAEc8sj2jKx5VEj9 VncTDjOPYtDJvc6KjiAlPECVJyOx1Gk/Zy9xsAI4piBf3O9WDc/DEB/DjBfQ7aeLXpst 6ACWPGQKEHgG4tZDHxxoaRffWCcgIVY67LPlSwF2N4bmR5TFdban+b3s5XOVCLy8VHOS /JKzTP5nSXd8//jNnqZ0fD6w8QWRRW7jUebWvZVKelPr/LOwjI+tGwFEtJGyZMT1rKgp 4teg==
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=WvrASTbKRR+ViHK2yn1yBx8iHpT75IKPKQ2LcrzCo/Y=; b=lUzx+ah46LtLcJ5QxzoU94H5f4QGt33RDQzy+230wixCNgTd2x123AGry4oNee4nbN juSbs/vcKKzZQNXCxuwmEpD3f93AVhpaNrwTPj12BJHAXVAks/eazi4mgfz8GVEzeIbD 7lo4o1q55d4Y8PLsGtGpQ01grBGvs5NOEYzaMX61WmxFdfuJXt9j2l0Hwx+B5q3l4mci m3PLaKse9wLt6CRGJndPeGQApzQPdbLimjAEXHB6Dkdi3rQ6mK2QOAU3z+J0KFRaeycl pM+wxPybhDvdUIZ7JBPyJomXKohPrOfHeOhUojrfgp1uiZNkFQtonOuVQoq9KWiT/zbq HE3Q==
X-Gm-Message-State: ALQs6tD68QgncVIgWkhMtiuHWgzlTUEwrPeEFhpI/nGHGxndTn0tjRx1 hhpRi/YrJGU7twWJ5WqX6GH/D9kjtNoLLm38Qqs=
X-Google-Smtp-Source: AIpwx48UgxSd3WaXbppU1tnuagH0pdGCMATQifJgD41QA0X500ZngjnmWFyd2p4bC2bTisbgghihxGyYRPZdy2Yv2KA=
X-Received: by 10.107.103.14 with SMTP id b14mr18285375ioc.70.1523049612538; Fri, 06 Apr 2018 14:20:12 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 6 Apr 2018 17:20:11 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:       
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 6 Apr 2018 17:20:11 -0400
Message-ID: 
Subject: Re: Impact of hardware offloads on network stack performance
To: Mike Bishop , Ian Swett 
Cc: IETF QUIC WG , Praveen Balasubramanian 
Content-Type: multipart/alternative; boundary="089e08e54afb2177610569349f7e"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 06 Apr 2018 21:20:17 -0000

--089e08e54afb2177610569349f7e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, it is touching the memory that is the big problem.

24ns is measurable time in my world where a 500 byte structured message is
easily handled, but in reality it is the same latency as a 7 meter longer
ethernet cable due to c (the speed of light).

CPU cores work by cache coherency and prefetching. As long as data is only
written once, data can funnel into the different CPU cache systems but if
data is later touched the message bus between CPU=E2=80=99s must invalidate=
 a lot
of assumptions and start over.

In the current form of PR 1079, the packet number is encrypted by writing
over data in the buffer, so in order to decrypt it, or just to verify it,
it is necessary to either copy the buffer - which means that all other
interested CPU=E2=80=99s must fetch new data, or the data is modified meani=
ng cache
invalidation.

Fortunately this part of the problem is not so hard to solve: remove the
packet number from the AEAD protected data - there is no benefit in having
it there. Store and encrypt it separately. This is a problem because an AES
block is 16 bytes and smaller encryption schemes are hard to make secure.
By overwriting packet data PR 1079 places some of block size over existing
non-packet number data which saves space but hurts cache.

My unverified assumption is that this can be improved: the packet number
can be encrypted indirectly by first encrypting arbitrary content (say the
tag) of the existing already encrypted packet. The encrypted data is NOT
stored  but xor=E2=80=99ed with the packet number. The packet number is now
appended after the tag, or anywhere else, just not inside AEAD data.

So how to decrypt? When the packet is received you encrypt the same data as
before and get 16 bytes out. You locate the encrypted packet number and xor
to get the clear text of the packet number.

Now you can start to decrypt and/or verify the AEAD packet content because
the decrypted packet number is the IV used in that crypto process. Notice
that in this process we only operate with a 16-byte temporary block that we
do NOT store in he packet buffer. We get a decoded packet number that we do
NOT store in the packet buffer. We can store it anywhere else, as long as
it is in a memory area with its own cache line boundary.

This is still not ideal because the latency is not only the 24ns decryption
but also writing the decrypted packet number somewhere and communicate it
to a process that operate on packet data. For example, if we have two cores
- one for verification, and one for decryption, then one must necessarily
send data to the other, or they most both do the same packet number
decryption (which probably is the better idea, but now it costs 48ns total)=
.



On 6 April 2018 at 22.55.33, Ian Swett (ianswett@google.com) wrote:

PNE doesn't preclude UDP LRO or pacing offload.

However, in a highly optimized stack(ie: The Disk|Crypt|Net paper from
SIGCOMM 2017) not touching(ie: bringing into memory or cache) the content
to be sent until the last possible moment is critical.  PNE likely means
touching that content much earlier.

But personally I consider the actual crypto we're talking about(2 AES
instructions?) adding basically free.

On Fri, Apr 6, 2018 at 4:37 PM Mike Bishop  wrote:

> Thanks for the clarification.  I guess what I=E2=80=99m really getting do=
wn to is
> how do we quantify the actual *cost* of PNE?  Are we substantially
> increasing the crypto costs?  If Ian is saying that crypto is comparative=
ly
> cheap and the cost is that it=E2=80=99s harder to offload something that=
=E2=80=99s
> comparatively cheap, what have we lost?  I=E2=80=99d think we want to off=
load the
> most intensive piece we can, and it seems like we=E2=80=99re talking abou=
t crypto
> offloads....  Or are we saying instead that the crypto makes it harder to
> offload other things in the future, like a QUIC equivalent to LRO/LSO?
>
>
>
> *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]
> *Sent:* Thursday, April 5, 2018 9:45 PM
> *To:* Ian Swett ; Mike Bishop 
> *Cc:* Praveen Balasubramanian ; IETF QUIC WG <
> quic@ietf.org>
> *Subject:* Re: Impact of hardware offloads on network stack performance
>
>
>
> To be clear - I don=E2=80=99t think crypto is overshadowing other issues =
as Mike
> read my post. It certainly comes at a cost, but either multiple cores or
> co-processors will deal with this. 1000ns is 10Gbps crypto speed on one
> core and it is higly parallelisable and cache friendly.
>
>
>
> But if you have to drip your packets through a traditional send interface
> that is copying, buffering or blocking, and certainly sync=E2=80=99ing wi=
th the
> kernel - it is going to be tough.
>
>
>
> For receive you risk high latency or top much scheduling in receive
> buffers.
>
>
> ------------------------------
>
> *From:* Ian Swett 
> *Sent:* Friday, April 6, 2018 4:06:01 AM
> *To:* Mike Bishop
> *Cc:* Mikkel Fahn=C3=B8e J=C3=B8rgensen; Praveen Balasubramanian; IETF QU=
IC WG
> *Subject:* Re: Impact of hardware offloads on network stack performance
>
>
>
>
>
> On Thu, Apr 5, 2018 at 5:57 PM Mike Bishop  wrote:
>
> That=E2=80=99s interesting data, Praveen =E2=80=93 thanks.  There is one =
caveat there,
> which is that (IIUC, on current hardware) you can=E2=80=99t do packet pac=
ing with
> LSO, and so my understanding is that even for TCP many providers disable
> this in pursuit of better egress management.  So what we=E2=80=99re reall=
y saying
> is that:
>
>    - On current hardware and OS setups, UDP runs less than half as much
>    throughput as TCP; that needs some optimization, as we=E2=80=99ve alre=
ady discussed
>    - TCP will dramatically gain performance once hardware offload catches
>    up and allows *paced* LSO =F0=9F=98=8A
>
>
>
> However, as Mikkel points out, the crypto costs are likely to overwhelm
> the OS throughput / scheduling issues in real deployments.  So I think th=
e
> other relevant piece to understanding the cost here is this:
>
>
>
> I have a few cases(both client and server) where my UDP send costs are
> more than 30%(in some cases 50%) of CPU consumption, and crypto is less
> than 10%.  So currently, I assume crypto is cheap(especially AES-GCM when
> hardware acceleration is available) and egress is expensive.  UDP ingres =
is
> not that expensive, but could use a bit of optimization as well.
>
>
>
> The only 'fancy' thing our current code is doing for crypto is encrypting
> in place, which was a ~2% win.  Nice, but not transformative.  See
> EncryptInPlace
> 
>
>
>
> I haven't done much work benchmarking Windows, so possibly the Windows UD=
P
> stack is really fast, and so crypto seems really slow in comparison?
>
>
>
>
>    - What is the throughput and relative cost of TLS/TCP versus QUIC
>    (i.e. how much are the smaller units of encryption hurting us versus, =
say,
>    16KB TLS records)?
>
>
>    - TLS implementations already vary here:  Some implementations choose
>    large record sizes, some vary record sizes to reduce delay / HoLB, so =
this
>    probably isn=E2=80=99t a single number.
>
>
>    - How much additional load does PNE add to this difference?
>    - To what extent would PNE make future crypto offloads *impossible*
>    versus *requires more R&D to develop*?
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of* Mikkel Fahn=C3=
=B8e
> J=C3=B8rgensen
> *Sent:* Wednesday, April 4, 2018 1:34 PM
> *To:* Praveen Balasubramanian ;
> IETF QUIC WG 
> *Subject:* Re: Impact of hardware offloads on network stack performance
>
>
>
> Thanks for sharing these numbers.
>
>
>
> My guess is that these offloads deal with kernel scheduling, memory cache
> issues, and interrupt scheduling.
>
>
>
> It probably has very little to do with crypto, TCP headers, and any other
> cpu sensitive processing.
>
>
>
> This is where netmap enters: you can transparently feed the data as it
> becomes available with very little sync work and you can also efficiently
> pipeline so you pass data to decryptor, then to app, with as little bus
> traffic as possible. No need to copy data or synchronize kernel space.
>
>
>
> For 1K packets you would use about 1000ns (3 cycles/byte) on crypto and
> this would happen in L1 cache. It would of course consume a core which a
> crypto offload would not, but that can be debated because with 18 core
> systems, your problem is memory and network more than CPU.
>
>
>
> My concern with PNE is for small packets and low latency where
>
> 1) an estimated 24ns for PN encryption and decryption becomes measurable
> if your network is fast enough.
>
> 2) any damage to the packet buffer cause all sorts of memory and cpu bus
> traffic issues.
>
>
>
> 1) is annoying. 2) is bad, completely avoidable but not as PR 1079 is
> formulated currently.
>
>
>
> 2) is also likely bad for hardware offload units as well.
>
>
>
> As to SRV-IO - I=E2=80=99m not familiar with it, but obviously there is s=
ome IO
> abstraction layer - the question is how you make it accessible to apps as
> opposed to device drivers that does nor work with you QUIC custom stack,
> and netmap is one option here.
>
>
>
> Kind Regards,
>
> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>
>
>
> On 4 April 2018 at 22.15.52, Praveen Balasubramanian (
> pravb=3D40microsoft.com@dmarc.ietf.org) wrote:
>
> Some comparative numbers from an out of box default settings Windows
> Server 2016 (released version) for a single connection with a
> microbenchmark tool:
>
>
>
> *Offloads enabled*
>
> *TCP gbps*
>
> *UDP gbps*
>
> *LSO + LRO + checksum*
>
> 24
>
> 3.6
>
> *Checksum only*
>
> 7.6
>
> 3.6
>
> *None*
>
> 5.6
>
> 2.3
>
>
>
> This is for a fully bottlenecked CPU core -- *if you run lower data rates
> there is still a significant difference in Cycles/byte cost*. Same
> increased CPU cost applies for client systems going over high data rate
> Wifi and cellular.
>
>
>
> This is without any crypto. Once you add crypto the numbers become much
> worse *with crypto cost becoming dominant*. Adding another crypto step
> further exacerbates the problem. Hence crypto offload gains in importance
> followed by these batch offloads.
>
>
>
> If folks need any more numbers I=E2=80=99d be happy to provide them.
>
>
>
> Thanks
>
>
>
>

--089e08e54afb2177610569349f7e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
Yes, it is touching =
the memory that is the big problem.

24ns is measurable time in my world where a 500 byte structu=
red message is easily handled, but in reality it is the same latency as a 7=
 meter longer ethernet cable due to c (the speed of light).

CPU cores work by cache coherency an=
d prefetching. As long as data is only written once, data can funnel into t=
he different CPU cache systems but if data is later touched the message bus=
 between CPU=E2=80=99s must invalidate a lot of assumptions and start over.=


In the current form =
of PR 1079, the packet number is encrypted by writing over data in the buff=
er, so in order to decrypt it, or just to verify it, it is necessary to eit=
her copy the buffer - which means that all other interested CPU=E2=80=99s m=
ust fetch new data, or the data is modified meaning cache invalidation.

Fortunately this part of=
 the problem is not so hard to solve: remove the packet number from the AEA=
D protected data - there is no benefit in having it there. Store and encryp=
t it separately. This is a problem because an AES block is 16 bytes and sma=
ller encryption schemes are hard to make secure. By overwriting packet data=
 PR 1079 places some of block size over existing non-packet number data whi=
ch saves space but hurts cache.

My unverified assumption is that this can be improved: the packe=
t number can be encrypted indirectly by first encrypting arbitrary content =
(say the tag) of the existing already encrypted packet. The encrypted data =
is NOT stored =C2=A0but xor=E2=80=99ed with the packet number. The packet n=
umber is now appended after the tag, or anywhere else, just not inside AEAD=
 data.

So how to decr=
ypt? When the packet is received you encrypt the same data as before and ge=
t 16 bytes out. You locate the encrypted packet number and xor to get the c=
lear text of the packet number.

Now you can start to decrypt and/or verify the AEAD packet conte=
nt because the decrypted packet number is the IV used in that crypto proces=
s. Notice that in this process we only operate with a 16-byte temporary blo=
ck that we do NOT store in he packet buffer. We get a decoded packet number=
 that we do NOT store in the packet buffer. We can store it anywhere else, =
as long as it is in a memory area with its own cache line boundary.

This is still not ideal beca=
use the latency is not only the 24ns decryption but also writing the decryp=
ted packet number somewhere and communicate it to a process that operate on=
 packet data. For example, if we have two cores - one for verification, and=
 one for decryption, then one must necessarily send data to the other, or t=
hey most both do the same packet number decryption (which probably is the b=
etter idea, but now it costs 48ns total).


 
On 6 April 20=
18 at 22.55.33, Ian Swett (ianswett@=
google.com) wrote:
 







PNE doesn't preclude UDP LRO or pacing offload.




However, in a highly optimized stack(ie: The Disk|Crypt|Net
paper from SIGCOMM 2017) not touching(ie: bringing into memory or
cache) the content to be sent until the last possible moment is
critical.=C2=A0 PNE likely means touching that content much
earlier.





But personally I consider the actual crypto we're talking
about(2 AES instructions?) adding basically free.=C2=A0=C2=A0








On Fri, Apr 6, 2018 at 4:37 PM Mike Bishop
<mbishop@evequefou.be>
wrote:








Thanks for the clarification.=C2=A0 I guess
what I=E2=80=99m really getting down to is how do we quantify the actual
cost of PNE?=C2=A0 Are we substantially increasing the
crypto costs?=C2=A0 If Ian is saying that crypto is comparatively
cheap and the cost is that it=E2=80=99s harder to offload something that=E2=
=80=99s
comparatively cheap, what have we lost?=C2=A0 I=E2=80=99d think we want to
offload the most intensive piece we can, and it seems like we=E2=80=99re
talking about crypto offloads....=C2=A0 Or are we saying instead
that the crypto makes it harder to offload other things in the
future, like a QUIC equivalent to LRO/LSO?


=C2=A0






From: Mikkel Fahn=C3=B8e J=C3=B8rgensen
[mailto:mikkelfj@gm=
ail.com]

Sent: Thursday, April 5, 2018 9:45 PM

To: Ian Swett <ianswett@google.com>; Mike Bishop
<mbishop@evequ=
efou.be>

Cc: Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>

Subject: Re: Impact of hardware offloads on network stack
performance






=C2=A0










To be clear - I don=E2=80=99t think crypto is
overshadowing other issues as Mike read my post. It certainly comes
at a cost, but either multiple cores or co-processors will deal
with this. 1000ns is 10Gbps crypto speed on one core and it is
higly parallelisable and cache friendly.






=C2=A0






But if you have to drip your packets through a
traditional send interface that is copying, buffering or blocking,
and certainly sync=E2=80=99ing with the kernel - it is going to be
tough.






=C2=A0






For receive you risk high latency or top much
scheduling in receive buffers.








=C2=A0














From:
Ian Swett <ianswett@google.com>

Sent: Friday, April 6, 2018 4:06:01 AM

To: Mike Bishop

Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen; Praveen Balasubramanian; IETF
QUIC WG

Subject: Re: Impact of hardware offloads on network stack
performance




=C2=A0










=C2=A0






On Thu, Apr 5, 2018 at 5:57 PM Mike Bishop
<mbishop@evequ=
efou.be> wrote:










That=E2=80=99s interesting data, Praveen =E2=80=93
thanks.=C2=A0 There is one caveat there, which is that (IIUC, on
current hardware) you can=E2=80=99t do packet pacing with LSO, and so my
understanding is that even for TCP many providers disable this in
pursuit of better egress management.=C2=A0 So what we=E2=80=99re really
saying is that:


    

  • On current hardware and OS setups, UDP runs
less than half as much throughput as TCP; that needs some
optimization, as we=E2=80=99ve already discussed
    • 

  • TCP will dramatically gain performance once
hardware offload catches up and allows paced LSO
=F0=9F=98=
=8A
    • 



=C2=A0


However, as Mikkel points out, the crypto
costs are likely to overwhelm the OS throughput / scheduling issues
in real deployments.=C2=A0 So I think the other relevant piece to
understanding the cost here is this:










=C2=A0






I have a few cases(both client and server)
where my UDP send costs are more than 30%(in some cases 50%) of CPU
consumption, and crypto is less than 10%.=C2=A0 So currently, I
assume crypto is cheap(especially AES-GCM when hardware
acceleration is available) and egress is expensive.=C2=A0 UDP
ingres is not that expensive, but could use a bit of optimization
as well.






=C2=A0






The only 'fancy' thing our current code is
doing for crypto is encrypting in place, which was a ~2% win.=C2=A0
Nice, but not transformative.=C2=A0 See EncryptInPlace






=C2=A0






I haven't done much work benchmarking Windows,
so possibly the Windows UDP stack is really fast, and so crypto
seems really slow in comparison?






=C2=A0










    

  • What is the throughput and relative cost of
TLS/TCP versus QUIC (i.e. how much are the smaller units of
encryption hurting us versus, say, 16KB TLS records)?
    • 





    

  • TLS implementations already vary here:=C2=A0
Some implementations choose large record sizes, some vary record
sizes to reduce delay / HoLB, so this probably isn=E2=80=99t a single
number.
    • 





    

  • How much additional load does PNE add to this
difference?
    • 

  • To what extent would PNE make future crypto
offloads impossible versus requires more R&D to
develop?
    • 



=C2=A0






From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of=
 Mikkel
Fahn=C3=B8e J=C3=B8rgensen

Sent: Wednesday, April 4, 2018 1:34 PM

To: Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org&=
gt;; IETF QUIC WG
<quic@ietf.org>=
;

Subject: Re: Impact of hardware offloads on network stack
performance






=C2=A0




Thanks
for sharing these numbers.






=C2=A0






My
guess is that these offloads deal with kernel scheduling, memory
cache issues, and interrupt scheduling.






=C2=A0






It
probably has very little to do with crypto, TCP headers, and any
other cpu sensitive processing.






=C2=A0






This
is where netmap enters: you can transparently feed the data as it
becomes available with very little sync work and you can also
efficiently pipeline so you pass data to decryptor, then to app,
with as little bus traffic as possible. No need to copy data or
synchronize kernel space.






=C2=A0






For
1K packets you would use about 1000ns (3 cycles/byte) on crypto and
this would happen in L1 cache. It would of course consume a core
which a crypto offload would not, but that can be debated because
with 18 core systems, your problem is memory and network more than
CPU.






=C2=A0






My
concern with PNE is for small packets and low latency
where






1)
an estimated 24ns for PN encryption and decryption becomes
measurable if your network is fast enough.






2)
any damage to the packet buffer cause all sorts of memory and cpu
bus traffic issues.






=C2=A0






1)
is annoying. 2) is bad, completely avoidable but not as PR 1079 is
formulated currently.






=C2=A0






2)
is also likely bad for hardware offload units as well.






=C2=A0




As
to SRV-IO - I=E2=80=99m not familiar with it, but obviously there is some
IO abstraction layer - the question is how you make it accessible
to apps as opposed to device drivers that does nor work with you
QUIC custom stack, and netmap is one option here.




=C2=A0






Kind
Regards,






Mikkel
Fahn=C3=B8e J=C3=B8rgensen






=C2=A0



On
4 April 2018 at 22.15.52, Praveen Balasubramanian (pravb=3D40microsoft.co=
m@dmarc.ietf.org)
wrote:










Some
comparative numbers from an out of box default settings Windows
Server 2016 (released version) for a single connection with a
microbenchmark tool:


=C2=A0








Offloads
enabled




TCP
gbps




UDP
gbps








LSO
+ LRO + checksum




24




3.6








Checksum
only




7.6




3.6








None




5.6




2.3








=C2=A0


This
is for a fully bottlenecked CPU core -- if you run lower data
rates there is still a significant difference in Cycles/byte
cost. Same increased CPU cost applies for client systems going
over high data rate Wifi and cellular.


=C2=A0


This
is without any crypto. Once you add crypto the numbers become much
worse with crypto cost becoming dominant. Adding another
crypto step further exacerbates the problem. Hence crypto offload
gains in importance followed by these batch offloads.


=C2=A0


If
folks need any more numbers I=E2=80=99d be happy to provide
them.


=C2=A0


Thanks


=C2=A0




































--089e08e54afb2177610569349f7e--


From nobody Fri Apr  6 15:58:01 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0255B126CD6 for ; Fri,  6 Apr 2018 15:58:00 -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 ncpiCpt8Onvm for ; Fri,  6 Apr 2018 15:57:56 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on072f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8106F126C3D for ; Fri,  6 Apr 2018 15:57:56 -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=K+7CmUKbS5Zp0jkCS6KPoF51t/FgSMvyJEhgLAliawc=; b=RukFnN5SDJtc3CtdcPVqCyYZz4SQEY0PR8TrNiqLddoCGOXQMX2kYhBj8JLtNZulnquVCot50nR/gcTEv7rAvDVJpHuLWKUCrP2qbqvfFXKARN23Ab8GRTNpQswC8P2Kb7xTjbtn4uQ1zwJGBAl1iOp1MXGre9+hevq7ewzBFoY=
Received: from DM5PR21MB0636.namprd21.prod.outlook.com (10.175.111.143) by DM5PR21MB0282.namprd21.prod.outlook.com (10.173.174.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Fri, 6 Apr 2018 22:57:54 +0000
Received: from DM5PR21MB0636.namprd21.prod.outlook.com ([fe80::2043:e91f:2585:3121]) by DM5PR21MB0636.namprd21.prod.outlook.com ([fe80::2043:e91f:2585:3121%10]) with mapi id 15.20.0675.005; Fri, 6 Apr 2018 22:57:54 +0000
From: Praveen Balasubramanian 
To: Mike Bishop , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , IETF QUIC WG 
Subject: RE: Impact of hardware offloads on network stack performance
Thread-Topic: Impact of hardware offloads on network stack performance
Thread-Index: AdPMUbL7T8nZAW2ySiO289IPTC0ttgAApm4AADSbFZAANIcgoA==
Date: Fri, 6 Apr 2018 22:57:54 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:9::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR21MB0282; 7:t5lIpIQdRwGSYYITUvaToGd5N7G2TkBNVPmnKDiitFLJJnYTmHZzCMFHAZCBudLTthiIxlcXx7fQ26KaAdw/6qLdkCyPwTav1qcNzTf1l5SLfb3QHqrXkVbTkRryS32XotzezQ4Lxpw1MLZL8ux0OarVpIOPdtsensM7WP3MoOAvPVxtNFnxn1asMugXlQ+0ROQdjBz+IBGhMEO1GygIddJrhvZtqGAmyloNAN5PIIJR8mlPx43glrpeG9t+ExWN; 20:GFf/K60n0gRXKS3zqgIMTyqyasWhVQV4TsjWIRGjXXAcPtmtWunmkl4dybXrHSUd/JBDtU6QxfMhPWOzJNBhWF+j9GezfQgoJCMIDxXqoAfDcETboYMLX/qwP7v/MDVG8NJnL8DyZKA1yTsAuhVutLLGoLjuQcaxwEv0Xt/iIGQ=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 65400d41-9833-4ce2-2627-08d59c11d4ca
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR21MB0282; 
x-ms-traffictypediagnostic: DM5PR21MB0282:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(85827821059158)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR21MB0282; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0282; 
x-forefront-prvs: 0634F37BFF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(346002)(366004)(396003)(376002)(199004)(189003)(9686003)(54896002)(81166006)(10290500003)(478600001)(3660700001)(46003)(81156014)(74316002)(19609705001)(25786009)(8676002)(68736007)(14454004)(6306002)(7736002)(10090500001)(8990500004)(53936002)(5660300001)(55016002)(6436002)(236005)(476003)(11346002)(102836004)(110136005)(53546011)(186003)(6506007)(3280700002)(2906002)(86362001)(446003)(106356001)(97736004)(316002)(486006)(76176011)(790700001)(6116002)(229853002)(6246003)(39060400002)(86612001)(8936002)(33656002)(105586002)(2900100001)(5250100002)(7696005)(22452003)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0282; H:DM5PR21MB0636.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 0DUkLkFp42dcVMV2BZMR9RMsPzp6MpxOFNBJQui+12ttGpJ2m33o7VP+1dIECFhIAay0uHxRMGXlDMHfepcSe10spQDXvDGg7ujP9hyonkC9kDLtgqdrIfsregy22cRr6Fxw5lqe0rgGChY2PPykVkNzm7JG+rFpUtTQERb5khm90Fu02HCO0ChWxw9UNcF4+8GLtpOtavSEjw3YxWJvCht+JQerbzqInIcN+2cbEBu1gVkQBJh3j0Gtps5BdWM+nf0dwHVKzidvFvYiAu3oy5Sfo0MPLU0O5OiuRkLTVe/NUEx444NlHhRkKxbmb9yRJF8Sb6VLMg2i1jEX/wZ/cT0qFyy/9iZt3o1DjQr3kjJY8Io9f8xiTX/5MJIJrZI557u61Q99jwcAOZOeg+dWA7brRFUjqX2mlaDUC4t9E1w=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR21MB0636B1E2B4E5B96CC49F6742B6BA0DM5PR21MB0636namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 65400d41-9833-4ce2-2627-08d59c11d4ca
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 22:57:54.0847 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0282
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 06 Apr 2018 22:58:00 -0000

--_000_DM5PR21MB0636B1E2B4E5B96CC49F6742B6BA0DM5PR21MB0636namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Pj4uICBUaGVyZSBpcyBvbmUgY2F2ZWF0IHRoZXJlLCB3aGljaCBpcyB0aGF0IChJSVVDLCBvbiBj
dXJyZW50IGhhcmR3YXJlKSB5b3UgY2Fu4oCZdCBkbyBwYWNrZXQgcGFjaW5nIHdpdGggTFNPLCBh
bmQgc28gbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGV2ZW4gZm9yIFRDUCBtYW55IHByb3ZpZGVy
cyBkaXNhYmxlIHRoaXMgaW4gcHVyc3VpdCBvZiBiZXR0ZXIgZWdyZXNzIG1hbmFnZW1lbnQNClNv
bWUgZG8gc29tZSBkb27igJl0LiBXaW5kb3dzIGhhc27igJl0IGRvbmUgcGFja2V0IHBhY2luZyBm
b3IgVENQIHNvIGZhciBhbmQgaXMgcXVpdGUgd2lkZWx5IGRlcGxveWVkIGFjcm9zcyBzZXJ2ZXJz
IGFuZCBjbGllbnRzLiBFdmVuIHdpdGggcGFjaW5nIHlvdSBjYW4gY29tZSB1cCB3aXRoIHByb3Bl
ciBzaXppbmcgc28geW91IGRvbuKAmXQgbG9zZSB0aGUgYWR2YW50YWdlcyBvZiBMU08uIEFzIHlv
dSBjYW4gc2VlIGluIHRoZSBudW1iZXJzIExTTyBoYXMgYSBwcmV0dHkgc2l6ZWFibGUgaW1wYWN0
IG9uIHBlcmYuDQoNCj4+IFRDUCB3aWxsIGRyYW1hdGljYWxseSBnYWluIHBlcmZvcm1hbmNlIG9u
Y2UgaGFyZHdhcmUgb2ZmbG9hZCBjYXRjaGVzIHVwIGFuZCBhbGxvd3MgcGFjZWQgTFNPDQpUQ1Ag
YXMgZGVwbG95ZWQgdG9kYXkgb24gV2luZG93cyB1c2VzIGhhcmR3YXJlIG9mZmxvYWQgKExTTywg
TFJPLCBjaGVja3N1bSkgYnkgZGVmYXVsdCBvbiBhbGwgc3lzdGVtcyB3aGVuIGF2YWlsYWJsZSBh
bmQgc3VwcG9ydCBpcyBhbG1vc3QgdW5pdmVyc2FsIGV4Y2VwdCBmb3Igc29tZSBjbGllbnQgTklD
cy4gVGhlcmUgaXMgbm8gc3RyaWN0IHJlcXVpcmVtZW50IGZvciBwYWNpbmcgdG8gZG8gTFNPIHNp
bmNlIHdlIGhhdmUgYmVlbiBzdWNjZXNzZnVsbHkgZGVwbG95ZWQgdGhpcyB3YXkgZm9yIDEwKyB5
ZWFycy4gVENQIGFscmVhZHkgaGFzIGRyYW1hdGljYWxseSBiZXR0ZXIgcGVyZiB0aGFuIFVEUCBv
biBhbGwgcHVibGljIGNsb3VkcyBhY3Jvc3MgYWxsIFZNIHNpemVzLg0KDQpBcyB0byBvdmVyaGVh
ZCBkdWUgdG8gUE5FLCB3ZSBkaWQgYW4gZXhwZXJpbWVudCBmb3IgdGhhdCByaWdodCB3aGVuIHRo
ZSBQTkUgZGlzY3Vzc2lvbiBzdGF0ZWQuIFdpdGggb3VyIGN1cnJlbnQgUVVJQyBpbXBsZW1lbnRh
dGlvbiBvdmVyIHRoZSAodW5vcHRpbWl6ZWQpIFVEUCBzdGFjayBhbmQgdGhlcmUgd2FzIDEgdG8g
MS4yNSUgb3ZlcmhlYWQuIE9uY2UgdGhlIFVEUCBhbmQgUVVJQyBpbXBsZW1lbnRhdGlvbnMgYXJl
IG9wdGltaXplZCwgdGhpcyBudW1iZXIgd2lsbCBpbmNyZWFzZS4gSGFwcHkgdG8gZG8gdGhlIG1l
YXN1cmVtZW50IGFnYWluLg0KDQpBcyB0byB3aGF0IGV4dGVudCBoYXJkd2FyZSBpcyBpbXBhY3Rl
ZCwgaGFyZHdhcmUgdmVuZG9ycyB3aWxsIGhhdmUgdG8gY2hpbWUgaW4uIFNldmVyYWwgZm9sa3Mg
aGFkIGNoaW1lZCBpbiBvbiB0aGUgb3JpZ2luYWwgdGhyZWFkLiBTaW5jZSB3ZSBoYXZlIGEgbGFj
ayBvZiBwYXJ0aWNpcGF0aW9uIGZyb20gaGFyZHdhcmUgdmVuZG9ycywgSSBhbSB0cnlpbmcgdG8g
cmVhY2ggb3V0IHRvIG1vcmUgZm9sa3MgdG8gam9pbiB0aGUgZ3JvdXAgYW5kIHBhcnRpY2lwYXRl
Lg0KDQpGcm9tOiBNaWtlIEJpc2hvcCBbbWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlXQ0KU2Vu
dDogVGh1cnNkYXksIEFwcmlsIDUsIDIwMTggMjo1NyBQTQ0KVG86IE1pa2tlbCBGYWhuw7hlIErD
uHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxw
cmF2YkBtaWNyb3NvZnQuY29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVj
dDogUkU6IEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZv
cm1hbmNlDQoNClRoYXTigJlzIGludGVyZXN0aW5nIGRhdGEsIFByYXZlZW4g4oCTIHRoYW5rcy4g
IFRoZXJlIGlzIG9uZSBjYXZlYXQgdGhlcmUsIHdoaWNoIGlzIHRoYXQgKElJVUMsIG9uIGN1cnJl
bnQgaGFyZHdhcmUpIHlvdSBjYW7igJl0IGRvIHBhY2tldCBwYWNpbmcgd2l0aCBMU08sIGFuZCBz
byBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgZXZlbiBmb3IgVENQIG1hbnkgcHJvdmlkZXJzIGRp
c2FibGUgdGhpcyBpbiBwdXJzdWl0IG9mIGJldHRlciBlZ3Jlc3MgbWFuYWdlbWVudC4gIFNvIHdo
YXQgd2XigJlyZSByZWFsbHkgc2F5aW5nIGlzIHRoYXQ6DQoNCiAgKiAgIE9uIGN1cnJlbnQgaGFy
ZHdhcmUgYW5kIE9TIHNldHVwcywgVURQIHJ1bnMgbGVzcyB0aGFuIGhhbGYgYXMgbXVjaCB0aHJv
dWdocHV0IGFzIFRDUDsgdGhhdCBuZWVkcyBzb21lIG9wdGltaXphdGlvbiwgYXMgd2XigJl2ZSBh
bHJlYWR5IGRpc2N1c3NlZA0KICAqICAg8J+Yig0KDQpIb3dldmVyLCBhcyBNaWtrZWwgcG9pbnRz
IG91dCwgdGhlIGNyeXB0byBjb3N0cyBhcmUgbGlrZWx5IHRvIG92ZXJ3aGVsbSB0aGUgT1MgdGhy
b3VnaHB1dCAvIHNjaGVkdWxpbmcgaXNzdWVzIGluIHJlYWwgZGVwbG95bWVudHMuICBTbyBJIHRo
aW5rIHRoZSBvdGhlciByZWxldmFudCBwaWVjZSB0byB1bmRlcnN0YW5kaW5nIHRoZSBjb3N0IGhl
cmUgaXMgdGhpczoNCg0KICAqICAgV2hhdCBpcyB0aGUgdGhyb3VnaHB1dCBhbmQgcmVsYXRpdmUg
Y29zdCBvZiBUTFMvVENQIHZlcnN1cyBRVUlDIChpLmUuIGhvdyBtdWNoIGFyZSB0aGUgc21hbGxl
ciB1bml0cyBvZiBlbmNyeXB0aW9uIGh1cnRpbmcgdXMgdmVyc3VzLCBzYXksIDE2S0IgVExTIHJl
Y29yZHMpPw0KICAgICAqICAgVExTIGltcGxlbWVudGF0aW9ucyBhbHJlYWR5IHZhcnkgaGVyZTog
IFNvbWUgaW1wbGVtZW50YXRpb25zIGNob29zZSBsYXJnZSByZWNvcmQgc2l6ZXMsIHNvbWUgdmFy
eSByZWNvcmQgc2l6ZXMgdG8gcmVkdWNlIGRlbGF5IC8gSG9MQiwgc28gdGhpcyBwcm9iYWJseSBp
c27igJl0IGEgc2luZ2xlIG51bWJlci4NCiAgKiAgIEhvdyBtdWNoIGFkZGl0aW9uYWwgbG9hZCBk
b2VzIFBORSBhZGQgdG8gdGhpcyBkaWZmZXJlbmNlPw0KICAqICAgVG8gd2hhdCBleHRlbnQgd291
bGQgUE5FIG1ha2UgZnV0dXJlIGNyeXB0byBvZmZsb2FkcyBpbXBvc3NpYmxlIHZlcnN1cyByZXF1
aXJlcyBtb3JlIFImRCB0byBkZXZlbG9wPw0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KU2Vu
dDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDE4IDE6MzQgUE0NClRvOiBQcmF2ZWVuIEJhbGFzdWJy
YW1hbmlhbiA8cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpwcmF2
Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+PjsgSUVURiBRVUlDIFdHIDxxdWljQGll
dGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBJbXBhY3Qgb2YgaGFy
ZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZQ0KDQpUaGFua3MgZm9y
IHNoYXJpbmcgdGhlc2UgbnVtYmVycy4NCg0KTXkgZ3Vlc3MgaXMgdGhhdCB0aGVzZSBvZmZsb2Fk
cyBkZWFsIHdpdGgga2VybmVsIHNjaGVkdWxpbmcsIG1lbW9yeSBjYWNoZSBpc3N1ZXMsIGFuZCBp
bnRlcnJ1cHQgc2NoZWR1bGluZy4NCg0KSXQgcHJvYmFibHkgaGFzIHZlcnkgbGl0dGxlIHRvIGRv
IHdpdGggY3J5cHRvLCBUQ1AgaGVhZGVycywgYW5kIGFueSBvdGhlciBjcHUgc2Vuc2l0aXZlIHBy
b2Nlc3NpbmcuDQoNClRoaXMgaXMgd2hlcmUgbmV0bWFwIGVudGVyczogeW91IGNhbiB0cmFuc3Bh
cmVudGx5IGZlZWQgdGhlIGRhdGEgYXMgaXQgYmVjb21lcyBhdmFpbGFibGUgd2l0aCB2ZXJ5IGxp
dHRsZSBzeW5jIHdvcmsgYW5kIHlvdSBjYW4gYWxzbyBlZmZpY2llbnRseSBwaXBlbGluZSBzbyB5
b3UgcGFzcyBkYXRhIHRvIGRlY3J5cHRvciwgdGhlbiB0byBhcHAsIHdpdGggYXMgbGl0dGxlIGJ1
cyB0cmFmZmljIGFzIHBvc3NpYmxlLiBObyBuZWVkIHRvIGNvcHkgZGF0YSBvciBzeW5jaHJvbml6
ZSBrZXJuZWwgc3BhY2UuDQoNCkZvciAxSyBwYWNrZXRzIHlvdSB3b3VsZCB1c2UgYWJvdXQgMTAw
MG5zICgzIGN5Y2xlcy9ieXRlKSBvbiBjcnlwdG8gYW5kIHRoaXMgd291bGQgaGFwcGVuIGluIEwx
IGNhY2hlLiBJdCB3b3VsZCBvZiBjb3Vyc2UgY29uc3VtZSBhIGNvcmUgd2hpY2ggYSBjcnlwdG8g
b2ZmbG9hZCB3b3VsZCBub3QsIGJ1dCB0aGF0IGNhbiBiZSBkZWJhdGVkIGJlY2F1c2Ugd2l0aCAx
OCBjb3JlIHN5c3RlbXMsIHlvdXIgcHJvYmxlbSBpcyBtZW1vcnkgYW5kIG5ldHdvcmsgbW9yZSB0
aGFuIENQVS4NCg0KTXkgY29uY2VybiB3aXRoIFBORSBpcyBmb3Igc21hbGwgcGFja2V0cyBhbmQg
bG93IGxhdGVuY3kgd2hlcmUNCjEpIGFuIGVzdGltYXRlZCAyNG5zIGZvciBQTiBlbmNyeXB0aW9u
IGFuZCBkZWNyeXB0aW9uIGJlY29tZXMgbWVhc3VyYWJsZSBpZiB5b3VyIG5ldHdvcmsgaXMgZmFz
dCBlbm91Z2guDQoyKSBhbnkgZGFtYWdlIHRvIHRoZSBwYWNrZXQgYnVmZmVyIGNhdXNlIGFsbCBz
b3J0cyBvZiBtZW1vcnkgYW5kIGNwdSBidXMgdHJhZmZpYyBpc3N1ZXMuDQoNCjEpIGlzIGFubm95
aW5nLiAyKSBpcyBiYWQsIGNvbXBsZXRlbHkgYXZvaWRhYmxlIGJ1dCBub3QgYXMgUFIgMTA3OSBp
cyBmb3JtdWxhdGVkIGN1cnJlbnRseS4NCg0KMikgaXMgYWxzbyBsaWtlbHkgYmFkIGZvciBoYXJk
d2FyZSBvZmZsb2FkIHVuaXRzIGFzIHdlbGwuDQoNCkFzIHRvIFNSVi1JTyAtIEnigJltIG5vdCBm
YW1pbGlhciB3aXRoIGl0LCBidXQgb2J2aW91c2x5IHRoZXJlIGlzIHNvbWUgSU8gYWJzdHJhY3Rp
b24gbGF5ZXIgLSB0aGUgcXVlc3Rpb24gaXMgaG93IHlvdSBtYWtlIGl0IGFjY2Vzc2libGUgdG8g
YXBwcyBhcyBvcHBvc2VkIHRvIGRldmljZSBkcml2ZXJzIHRoYXQgZG9lcyBub3Igd29yayB3aXRo
IHlvdSBRVUlDIGN1c3RvbSBzdGFjaywgYW5kIG5ldG1hcCBpcyBvbmUgb3B0aW9uIGhlcmUuDQoN
CktpbmQgUmVnYXJkcywNCk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCg0KDQpPbiA0IEFwcmls
IDIwMTggYXQgMjIuMTUuNTIsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIChwcmF2Yj00MG1pY3Jv
c29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFy
Yy5pZXRmLm9yZz4pIHdyb3RlOg0KU29tZSBjb21wYXJhdGl2ZSBudW1iZXJzIGZyb20gYW4gb3V0
IG9mIGJveCBkZWZhdWx0IHNldHRpbmdzIFdpbmRvd3MgU2VydmVyIDIwMTYgKHJlbGVhc2VkIHZl
cnNpb24pIGZvciBhIHNpbmdsZSBjb25uZWN0aW9uIHdpdGggYSBtaWNyb2JlbmNobWFyayB0b29s
Og0KDQpPZmZsb2FkcyBlbmFibGVkDQoNClRDUCBnYnBzDQoNClVEUCBnYnBzDQoNCkxTTyArIExS
TyArIGNoZWNrc3VtDQoNCjI0DQoNCjMuNg0KDQpDaGVja3N1bSBvbmx5DQoNCjcuNg0KDQozLjYN
Cg0KTm9uZQ0KDQo1LjYNCg0KMi4zDQoNCg0KVGhpcyBpcyBmb3IgYSBmdWxseSBib3R0bGVuZWNr
ZWQgQ1BVIGNvcmUgLS0gaWYgeW91IHJ1biBsb3dlciBkYXRhIHJhdGVzIHRoZXJlIGlzIHN0aWxs
IGEgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZSBpbiBDeWNsZXMvYnl0ZSBjb3N0LiBTYW1lIGluY3Jl
YXNlZCBDUFUgY29zdCBhcHBsaWVzIGZvciBjbGllbnQgc3lzdGVtcyBnb2luZyBvdmVyIGhpZ2gg
ZGF0YSByYXRlIFdpZmkgYW5kIGNlbGx1bGFyLg0KDQpUaGlzIGlzIHdpdGhvdXQgYW55IGNyeXB0
by4gT25jZSB5b3UgYWRkIGNyeXB0byB0aGUgbnVtYmVycyBiZWNvbWUgbXVjaCB3b3JzZSB3aXRo
IGNyeXB0byBjb3N0IGJlY29taW5nIGRvbWluYW50LiBBZGRpbmcgYW5vdGhlciBjcnlwdG8gc3Rl
cCBmdXJ0aGVyIGV4YWNlcmJhdGVzIHRoZSBwcm9ibGVtLiBIZW5jZSBjcnlwdG8gb2ZmbG9hZCBn
YWlucyBpbiBpbXBvcnRhbmNlIGZvbGxvd2VkIGJ5IHRoZXNlIGJhdGNoIG9mZmxvYWRzLg0KDQpJ
ZiBmb2xrcyBuZWVkIGFueSBtb3JlIG51bWJlcnMgSeKAmWQgYmUgaGFwcHkgdG8gcHJvdmlkZSB0
aGVtLg0KDQpUaGFua3MNCg0K

--_000_DM5PR21MB0636B1E2B4E5B96CC49F6742B6BA0DM5PR21MB0636namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC
My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv
ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S
RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj
b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt
LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2
ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1
IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh
bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IlNlZ29lIFVJIEVtb2ppIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBT
dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v
cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh
bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ
dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r
Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBh
cmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K
CW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47
DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl
OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1h
bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v
cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6
MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFpbG9u
LCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9v
bjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEu
MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHls
ZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3
aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu
ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN
Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx
LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u
MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs
MA0KCXttc28tbGlzdC1pZDo2ODU3ODczNzk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv
LWxpc3QtdGVtcGxhdGUtaWRzOi0xMjUxODY4MTEyIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz
IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N
CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6
U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt
ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2
ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv
Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5
OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w
Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u
MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z
by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx
DQoJe21zby1saXN0LWlkOjczNjgyNjEwMDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwNjcy
NjIwMTI7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t
YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps
ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU
aW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox
LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N
CkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K
CW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv
cDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s
O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs
OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3
Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt
c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt
Ym9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjk1Nzk1MzYyOTsNCgltc28tbGlzdC10ZW1w
bGF0ZS1pZHM6MjE0MTg1NjI2ODt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s
O30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVs
Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3
Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt
c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt
Ym9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxl
dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6
U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy
OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjEx
Mzc5ODg1OTA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz
Ojk0Mjk3NjIwMCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2
NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMzpsZXZlbDENCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzps
ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci
O30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p
bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg
bDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7
fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1
bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv
eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg
djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh
cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg
bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsuJm5ic3A7IFRoZXJlIGlzIG9uZSBjYXZlYXQg
dGhlcmUsIHdoaWNoIGlzIHRoYXQgKElJVUMsIG9uIGN1cnJlbnQgaGFyZHdhcmUpIHlvdSBjYW7i
gJl0IGRvIHBhY2tldCBwYWNpbmcgd2l0aCBMU08sIGFuZCBzbyBteSB1bmRlcnN0YW5kaW5nIGlz
IHRoYXQgZXZlbiBmb3IgVENQIG1hbnkgcHJvdmlkZXJzIGRpc2FibGUgdGhpcyBpbiBwdXJzdWl0
IG9mIGJldHRlciBlZ3Jlc3MgbWFuYWdlbWVudDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+U29tZSBkbyBzb21lIGRvbuKAmXQuIFdpbmRvd3MgaGFzbuKAmXQgZG9uZSBwYWNr
ZXQgcGFjaW5nIGZvciBUQ1Agc28gZmFyIGFuZCBpcyBxdWl0ZSB3aWRlbHkgZGVwbG95ZWQgYWNy
b3NzIHNlcnZlcnMgYW5kIGNsaWVudHMuIEV2ZW4gd2l0aCBwYWNpbmcgeW91IGNhbiBjb21lIHVw
IHdpdGggcHJvcGVyIHNpemluZyBzbyB5b3UgZG9u4oCZdCBsb3NlIHRoZSBhZHZhbnRhZ2VzIG9m
IExTTy4gQXMgeW91IGNhbiBzZWUgaW4NCiB0aGUgbnVtYmVycyBMU08gaGFzIGEgcHJldHR5IHNp
emVhYmxlIGltcGFjdCBvbiBwZXJmLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsg
VENQIHdpbGwgZHJhbWF0aWNhbGx5IGdhaW4gcGVyZm9ybWFuY2Ugb25jZSBoYXJkd2FyZSBvZmZs
b2FkIGNhdGNoZXMgdXAgYW5kIGFsbG93cw0KPHU+cGFjZWQ8L3U+IExTTzxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VENQIGFzIGRlcGxveWVkIHRvZGF5IG9uIFdpbmRvd3Mg
dXNlcyBoYXJkd2FyZSBvZmZsb2FkIChMU08sIExSTywgY2hlY2tzdW0pIGJ5IGRlZmF1bHQgb24g
YWxsIHN5c3RlbXMgd2hlbiBhdmFpbGFibGUgYW5kIHN1cHBvcnQgaXMgYWxtb3N0IHVuaXZlcnNh
bCBleGNlcHQgZm9yIHNvbWUgY2xpZW50IE5JQ3MuIFRoZXJlIGlzIG5vIHN0cmljdCByZXF1aXJl
bWVudCBmb3IgcGFjaW5nIHRvIGRvIExTTyBzaW5jZQ0KIHdlIGhhdmUgYmVlbiBzdWNjZXNzZnVs
bHkgZGVwbG95ZWQgdGhpcyB3YXkgZm9yIDEwJiM0MzsgeWVhcnMuIFRDUCBhbHJlYWR5IGhhcyBk
cmFtYXRpY2FsbHkgYmV0dGVyIHBlcmYgdGhhbiBVRFAgb24gYWxsIHB1YmxpYyBjbG91ZHMgYWNy
b3NzIGFsbCBWTSBzaXplcy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyB0byBvdmVyaGVh
ZCBkdWUgdG8gUE5FLCB3ZSBkaWQgYW4gZXhwZXJpbWVudCBmb3IgdGhhdCByaWdodCB3aGVuIHRo
ZSBQTkUgZGlzY3Vzc2lvbiBzdGF0ZWQuIFdpdGggb3VyIGN1cnJlbnQgUVVJQyBpbXBsZW1lbnRh
dGlvbiBvdmVyIHRoZSAodW5vcHRpbWl6ZWQpIFVEUCBzdGFjayBhbmQgdGhlcmUgd2FzIDEgdG8g
MS4yNSUgb3ZlcmhlYWQuIE9uY2UgdGhlIFVEUCBhbmQgUVVJQyBpbXBsZW1lbnRhdGlvbnMNCiBh
cmUgb3B0aW1pemVkLCB0aGlzIG51bWJlciB3aWxsIGluY3JlYXNlLiBIYXBweSB0byBkbyB0aGUg
bWVhc3VyZW1lbnQgYWdhaW4uIDxvOnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIHRvIHdoYXQg
ZXh0ZW50IGhhcmR3YXJlIGlzIGltcGFjdGVkLCBoYXJkd2FyZSB2ZW5kb3JzIHdpbGwgaGF2ZSB0
byBjaGltZSBpbi4gU2V2ZXJhbCBmb2xrcyBoYWQgY2hpbWVkIGluIG9uIHRoZSBvcmlnaW5hbCB0
aHJlYWQuIFNpbmNlIHdlIGhhdmUgYSBsYWNrIG9mIHBhcnRpY2lwYXRpb24gZnJvbSBoYXJkd2Fy
ZSB2ZW5kb3JzLCBJIGFtIHRyeWluZyB0byByZWFjaCBvdXQgdG8gbW9yZSBmb2xrcyB0byBqb2lu
DQogdGhlIGdyb3VwIGFuZCBwYXJ0aWNpcGF0ZS4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g
MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWlrZSBCaXNob3Ag
W21haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZV0gPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5
LCBBcHJpbCA1LCAyMDE4IDI6NTcgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2tlbCBGYWhuw7hlIErD
uHJnZW5zZW4gJmx0O21pa2tlbGZqQGdtYWlsLmNvbSZndDs7IFByYXZlZW4gQmFsYXN1YnJhbWFu
aWFuICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGll
dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogSW1wYWN0IG9mIGhhcmR3YXJlIG9m
ZmxvYWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVyZm9ybWFuY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlRoYXTigJlzIGludGVyZXN0aW5nIGRhdGEsIFByYXZlZW4g4oCT
IHRoYW5rcy4mbmJzcDsgVGhlcmUgaXMgb25lIGNhdmVhdCB0aGVyZSwgd2hpY2ggaXMgdGhhdCAo
SUlVQywgb24gY3VycmVudCBoYXJkd2FyZSkgeW91IGNhbuKAmXQgZG8gcGFja2V0IHBhY2luZyB3
aXRoIExTTywgYW5kIHNvIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBldmVuIGZvciBUQ1AgbWFu
eSBwcm92aWRlcnMgZGlzYWJsZSB0aGlzIGluIHB1cnN1aXQgb2YNCiBiZXR0ZXIgZWdyZXNzIG1h
bmFnZW1lbnQuJm5ic3A7IFNvIHdoYXQgd2XigJlyZSByZWFsbHkgc2F5aW5nIGlzIHRoYXQ6PG86
cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxs
aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzMiPk9uIGN1
cnJlbnQgaGFyZHdhcmUgYW5kIE9TIHNldHVwcywgVURQIHJ1bnMgbGVzcyB0aGFuIGhhbGYgYXMg
bXVjaCB0aHJvdWdocHV0IGFzIFRDUDsgdGhhdCBuZWVkcyBzb21lIG9wdGltaXphdGlvbiwgYXMg
d2XigJl2ZSBhbHJlYWR5IGRpc2N1c3NlZDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1saXN0OmwzIGxldmVsMSBsZm8zIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZiI+JiMxMjg1MjI7PC9z
cGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyLCBhcyBNaWtrZWwgcG9p
bnRzIG91dCwgdGhlIGNyeXB0byBjb3N0cyBhcmUgbGlrZWx5IHRvIG92ZXJ3aGVsbSB0aGUgT1Mg
dGhyb3VnaHB1dCAvIHNjaGVkdWxpbmcgaXNzdWVzIGluIHJlYWwgZGVwbG95bWVudHMuJm5ic3A7
IFNvIEkgdGhpbmsgdGhlIG90aGVyIHJlbGV2YW50IHBpZWNlIHRvIHVuZGVyc3RhbmRpbmcgdGhl
IGNvc3QgaGVyZSBpcyB0aGlzOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9w
OjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0
OmwwIGxldmVsMSBsZm82Ij5XaGF0IGlzIHRoZSB0aHJvdWdocHV0IGFuZCByZWxhdGl2ZSBjb3N0
IG9mIFRMUy9UQ1AgdmVyc3VzIFFVSUMgKGkuZS4gaG93IG11Y2ggYXJlIHRoZSBzbWFsbGVyIHVu
aXRzIG9mIGVuY3J5cHRpb24gaHVydGluZyB1cyB2ZXJzdXMsIHNheSwgMTZLQiBUTFMgcmVjb3Jk
cyk/DQo8bzpwPjwvbzpwPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iY2lyY2xl
Ij4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzYi
PlRMUyBpbXBsZW1lbnRhdGlvbnMgYWxyZWFkeSB2YXJ5IGhlcmU6Jm5ic3A7IFNvbWUgaW1wbGVt
ZW50YXRpb25zIGNob29zZSBsYXJnZSByZWNvcmQgc2l6ZXMsIHNvbWUgdmFyeSByZWNvcmQgc2l6
ZXMgdG8gcmVkdWNlIGRlbGF5IC8gSG9MQiwgc28gdGhpcyBwcm9iYWJseSBpc27igJl0IGEgc2lu
Z2xlIG51bWJlci48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvNiI+SG93IG11Y2ggYWRkaXRpb25hbCBs
b2FkIGRvZXMgUE5FIGFkZCB0byB0aGlzIGRpZmZlcmVuY2U/PG86cD48L286cD48L2xpPjxsaSBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzYiPlRvIHdoYXQg
ZXh0ZW50IHdvdWxkIFBORSBtYWtlIGZ1dHVyZSBjcnlwdG8gb2ZmbG9hZHMNCjxpPmltcG9zc2li
bGU8L2k+IHZlcnN1cyA8aT5yZXF1aXJlcyBtb3JlIFImYW1wO0QgdG8gZGV2ZWxvcDwvaT4/PG86
cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF
MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbPGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm
Lm9yZyI+bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg
PC9iPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5
LCBBcHJpbCA0LCAyMDE4IDE6MzQgUE08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJh
bWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmll
dGYub3JnIj5wcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzsgSUVU
RiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9y
ZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2Zm
bG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
diBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+VGhhbmtzIGZvciBzaGFyaW5nIHRoZXNlIG51bWJlcnMuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk15IGd1ZXNzIGlzIHRoYXQgdGhlc2Ugb2ZmbG9hZHMgZGVh
bCB3aXRoIGtlcm5lbCBzY2hlZHVsaW5nLCBtZW1vcnkgY2FjaGUgaXNzdWVzLCBhbmQgaW50ZXJy
dXB0IHNjaGVkdWxpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJi
bG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1
c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkl0IHBy
b2JhYmx5IGhhcyB2ZXJ5IGxpdHRsZSB0byBkbyB3aXRoIGNyeXB0bywgVENQIGhlYWRlcnMsIGFu
ZCBhbnkgb3RoZXIgY3B1IHNlbnNpdGl2ZSBwcm9jZXNzaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIHdoZXJlIG5ldG1hcCBlbnRlcnM6IHlvdSBjYW4gdHJh
bnNwYXJlbnRseSBmZWVkIHRoZSBkYXRhIGFzIGl0IGJlY29tZXMgYXZhaWxhYmxlIHdpdGggdmVy
eSBsaXR0bGUgc3luYyB3b3JrIGFuZCB5b3UgY2FuIGFsc28gZWZmaWNpZW50bHkgcGlwZWxpbmUg
c28geW91IHBhc3MgZGF0YQ0KIHRvIGRlY3J5cHRvciwgdGhlbiB0byBhcHAsIHdpdGggYXMgbGl0
dGxlIGJ1cyB0cmFmZmljIGFzIHBvc3NpYmxlLiBObyBuZWVkIHRvIGNvcHkgZGF0YSBvciBzeW5j
aHJvbml6ZSBrZXJuZWwgc3BhY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJs
b29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PkZvciAxSyBwYWNrZXRzIHlvdSB3b3VsZCB1c2UgYWJvdXQgMTAwMG5zICgzIGN5Y2xlcy9ieXRl
KSBvbiBjcnlwdG8gYW5kIHRoaXMgd291bGQgaGFwcGVuIGluIEwxIGNhY2hlLiBJdCB3b3VsZCBv
ZiBjb3Vyc2UgY29uc3VtZSBhIGNvcmUgd2hpY2ggYSBjcnlwdG8gb2ZmbG9hZCB3b3VsZCBub3Qs
DQogYnV0IHRoYXQgY2FuIGJlIGRlYmF0ZWQgYmVjYXVzZSB3aXRoIDE4IGNvcmUgc3lzdGVtcywg
eW91ciBwcm9ibGVtIGlzIG1lbW9yeSBhbmQgbmV0d29yayBtb3JlIHRoYW4gQ1BVLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NeSBjb25jZXJuIHdpdGggUE5FIGlzIGZvciBz
bWFsbCBwYWNrZXRzIGFuZCBsb3cgbGF0ZW5jeSB3aGVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+MSkgYW4gZXN0aW1hdGVkIDI0bnMgZm9yIFBOIGVuY3J5cHRp
b24gYW5kIGRlY3J5cHRpb24gYmVjb21lcyBtZWFzdXJhYmxlIGlmIHlvdXIgbmV0d29yayBpcyBm
YXN0IGVub3VnaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29w
X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjIp
IGFueSBkYW1hZ2UgdG8gdGhlIHBhY2tldCBidWZmZXIgY2F1c2UgYWxsIHNvcnRzIG9mIG1lbW9y
eSBhbmQgY3B1IGJ1cyB0cmFmZmljIGlzc3Vlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
diBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+MSkgaXMgYW5ub3lpbmcuIDIpIGlzIGJhZCwgY29tcGxldGVseSBhdm9pZGFibGUg
YnV0IG5vdCBhcyBQUiAxMDc5IGlzIGZvcm11bGF0ZWQgY3VycmVudGx5LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj4yKSBpcyBhbHNvIGxpa2VseSBiYWQgZm9yIGhhcmR3YXJl
IG9mZmxvYWQgdW5pdHMgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFzIHRvIFNSVi1JTyAtIEnigJltIG5vdCBm
YW1pbGlhciB3aXRoIGl0LCBidXQgb2J2aW91c2x5IHRoZXJlIGlzIHNvbWUgSU8gYWJzdHJhY3Rp
b24gbGF5ZXIgLSB0aGUgcXVlc3Rpb24gaXMgaG93IHlvdSBtYWtlIGl0IGFjY2Vzc2libGUgdG8g
YXBwcyBhcyBvcHBvc2VkIHRvIGRldmljZSBkcml2ZXJzDQogdGhhdCBkb2VzIG5vciB3b3JrIHdp
dGggeW91IFFVSUMgY3VzdG9tIHN0YWNrLCBhbmQgbmV0bWFwIGlzIG9uZSBvcHRpb24gaGVyZS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9ImJsb29w
X3NpZ25fMTUyMjg3MzM1MDQxNTEyMDEyOCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox
Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
YWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gNCBBcHJpbCAyMDE4IGF0IDIyLjE1LjUy
LCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAoPGEgaHJlZj0ibWFpbHRvOnByYXZiPTQwbWljcm9z
b2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyI+cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu
b3JnPC9hPikgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Tb21lIGNvbXBh
cmF0aXZlIG51bWJlcnMgZnJvbSBhbiBvdXQgb2YgYm94IGRlZmF1bHQgc2V0dGluZ3MgV2luZG93
cyBTZXJ2ZXIgMjAxNiAocmVsZWFzZWQgdmVyc2lvbikgZm9yIGEgc2luZ2xlDQogY29ubmVjdGlv
biB3aXRoIGEgbWljcm9iZW5jaG1hcmsgdG9vbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxz
cGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpjb2xsYXBz
ZSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3
aWR0aDoxMTYuODVwdDtib3JkZXI6c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItYm90dG9tOnNv
bGlkICM2NjY2NjYgMS41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9mZmxvYWRzIGVuYWJsZWQ8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K
PHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2LjlwdDtib3JkZXIt
dG9wOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNv
bGlkICM2NjY2NjYgMS41cHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7cGFkZGlu
ZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPlRDUCBnYnBzPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48
L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5
bGU9IndpZHRoOjExNi45cHQ7Ym9yZGVyLXRvcDpzb2xpZCAjOTk5OTk5IDEuMHB0O2JvcmRlci1s
ZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjNjY2NjY2IDEuNXB0O2JvcmRlci1yaWdodDpz
b2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5VRFAgZ2Jwczwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0K
PHRyPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2Ljg1cHQ7
Ym9yZGVyOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGluIDUu
NHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj5MU08gJiM0MzsgTFJPICYjNDM7IGNoZWNrc3VtPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxp
Z249InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0
Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjOTk5OTk5IDEuMHB0O2JvcmRlci1yaWdodDpzb2xp
ZCAjOTk5OTk5IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0
O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgIzk5
OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBpbiA1
LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+My42PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgd2lk
dGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuODVwdDtib3JkZXI6c29saWQg
Izk5OTk5OSAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWNrc3Vt
IG9ubHk8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2Ljlw
dDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICM5
OTk5OTkgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7cGFkZGluZzowaW4g
NS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPjcuNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFs
aWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVm
dDpub25lO2JvcmRlci1ib3R0b206c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29s
aWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+My42PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxl
PSJ3aWR0aDoxMTYuODVwdDtib3JkZXI6c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItdG9wOm5v
bmU7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk5vbmU8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9w
IiBzdHlsZT0id2lkdGg6MTE2LjlwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTti
b3JkZXItYm90dG9tOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5
OTkgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjUuNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+
DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRl
ci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgIzk5OTk5OSAx
LjBwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAw
aW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Mi4z
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PlRoaXMgaXMgZm9yIGEgZnVsbHkgYm90dGxlbmVja2VkIENQVSBjb3JlIC0tDQo8aT5pZiB5b3Ug
cnVuIGxvd2VyIGRhdGEgcmF0ZXMgdGhlcmUgaXMgc3RpbGwgYSBzaWduaWZpY2FudCBkaWZmZXJl
bmNlIGluIEN5Y2xlcy9ieXRlIGNvc3Q8L2k+LiBTYW1lIGluY3JlYXNlZCBDUFUgY29zdCBhcHBs
aWVzIGZvciBjbGllbnQgc3lzdGVtcyBnb2luZyBvdmVyIGhpZ2ggZGF0YSByYXRlIFdpZmkgYW5k
IGNlbGx1bGFyLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBpcyB3aXRob3V0IGFueSBj
cnlwdG8uIE9uY2UgeW91IGFkZCBjcnlwdG8gdGhlIG51bWJlcnMgYmVjb21lIG11Y2ggd29yc2UN
CjxpPndpdGggY3J5cHRvIGNvc3QgYmVjb21pbmcgZG9taW5hbnQ8L2k+LiBBZGRpbmcgYW5vdGhl
ciBjcnlwdG8gc3RlcCBmdXJ0aGVyIGV4YWNlcmJhdGVzIHRoZSBwcm9ibGVtLiBIZW5jZSBjcnlw
dG8gb2ZmbG9hZCBnYWlucyBpbiBpbXBvcnRhbmNlIGZvbGxvd2VkIGJ5IHRoZXNlIGJhdGNoIG9m
ZmxvYWRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklmIGZvbGtzIG5lZWQgYW55IG1vcmUgbnVt
YmVycyBJ4oCZZCBiZSBoYXBweSB0byBwcm92aWRlIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_DM5PR21MB0636B1E2B4E5B96CC49F6742B6BA0DM5PR21MB0636namp_--


From nobody Sat Apr  7 17:45:21 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F85A124D68 for ; Sat,  7 Apr 2018 17:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=nWvb2x9T; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XT6ERMsC
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_Bid_MP_iPD for ; Sat,  7 Apr 2018 17:45:17 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F785126D45 for ; Sat,  7 Apr 2018 17:45:17 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id F051020D31 for ; Sat,  7 Apr 2018 20:45:16 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 07 Apr 2018 20:45:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ekESaLSwpu8sx/3dC +1rhQdMHE38sWJsqvCblya/8vs=; b=nWvb2x9TRBvsSuFmytdNm38ecyqIK8HLY nHs9KcXI6DBgQKR7IgkhT0rF+z1+hFCF8WrfMgqtVakTz2QmakYj3EwhkEoJm5lW HoTJfYKL5AtEyTbBWnf+M9McVLLPtFiG/O+7jbhXh5z2WFPZVsFU0qHU5AOuzNKS OTMKlm6C1SVakvbaoBN0LOnGLLx0TyuwOaXYtp/tZf+LGBNn4RyNINhvkOL3CN45 Xyh9kQHq6kFNpP9Dyq6FFUhchN+lrI3PV2uD3TXIpfybKgJzcmqcur0NC0C3E9AD OLFBzp3scZ8nPjIeRpGW2chIlzpoBrVbQ+snkxaWWbS/ExNKMYv1g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=ekESaLSwpu8sx/3dC+1rhQdMHE38sWJsqvCblya/8vs=; b=XT6ERMsC uVGM5E3F9dq70V9zMtbY3tih+21Mu5Pln6NcUXXLSzHWScQoU8cvEbE97z10T4pv 5xq6QGjZuvIXkv7vmTsIP74QdPA2CvbikvnzTaZBpkVs3YyrV7Tfw1Hi1M306MXP +EgGWtM9d0f/3OUO3u+ywlwHpe/Yicd6ME7ejfrh2FA+pAtGb6sBVt8u/XCmPJOY XYLTudklFIaVR8zRdWT09UW+FuW9AEkPavE18InEsFcMh4JDj9ogYrICdpQXdECM 0DTYAayDRSIuoq1ufDCT5snU7m2eZgT5MDuJO+36xCSKItaWYwigQwKdnz624966 5VRrjZCU5vmPcw==
X-ME-Sender: 
Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 4061A10253 for ; Sat,  7 Apr 2018 20:45:16 -0400 (EDT)
Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 52B4CC2AED for ; Sun,  8 Apr 2018 00:45:13 +0000 (UTC)
Content-Type: multipart/alternative; boundary="===============2780299072982636778=="
MIME-Version: 1.0
From: =?utf-8?q?Github_Notifications?= 
To: quic@ietf.org
Subject: Weekly github digest (QUIC Working Group Specifications)
Message-Id: <20180408004513.52B4CC2AED@cloud.mnot.net>
Date: Sun,  8 Apr 2018 00:45:13 +0000 (UTC)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 08 Apr 2018 00:45:20 -0000

--===============2780299072982636778==
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; format="flowed"




Events without label "editorial"

Issues
------
* quicwg/base-drafts (+7/-3/=F0=9F=92=AC38)
  7 issues created:
  - Connection migration must be negotiated (by pravb)
    https://github.com/quicwg/base-drafts/issues/1271 =

  - CONNECTION_CLOSE missing from handshake packet (by kevin-kp)
    https://github.com/quicwg/base-drafts/issues/1270 =

  - Packet protection keys not CID-based (by MikeBishop)
    https://github.com/quicwg/base-drafts/issues/1267 [-tls] [design] =

  - error handling for path_response (by mcmanus)
    https://github.com/quicwg/base-drafts/issues/1265 =

  - Adding more information about the computation of RTO (by scw00)
    https://github.com/quicwg/base-drafts/issues/1261 =

  - Invariants extensbility (by pravb)
    https://github.com/quicwg/base-drafts/issues/1260 =

  - Stateless Reset during Path Migration (by MikeBishop)
    https://github.com/quicwg/base-drafts/issues/1258 [-transport] [design] =


  9 issues received 38 new comments:
  - #1271 Connection migration must be negotiated (15 by nibanks, pravb, ia=
nswett, MikeBishop, RyanAtGoogle, ekr, tfpauly)
    https://github.com/quicwg/base-drafts/issues/1271 =

  - #1260 Invariants extensbility (5 by ianswett, pravb, MikeBishop)
    https://github.com/quicwg/base-drafts/issues/1260 =

  - #1250 UDP-like, not exclusively UDP (4 by martinthomson, MikeBishop, pr=
avb, mikkelfj)
    https://github.com/quicwg/base-drafts/issues/1250 [-invariants] [design=
] =

  - #1252 Stream Flow Control on Stream 0 (4 by siyengar, pravb, martinduke)
    https://github.com/quicwg/base-drafts/issues/1252 [-transport] [design] =

  - #1255 Gratuitous change of QHKDF-Expand in draft 10 (3 by kazuho, tatsu=
hiro-t)
    https://github.com/quicwg/base-drafts/issues/1255 [-tls] [design] =

  - #1265 error handling for path_response (3 by martinthomson, mcmanus)
    https://github.com/quicwg/base-drafts/issues/1265 [-transport] [design] =

  - #1261 Adding more information about the computation of RTO (2 by scw00,=
 ianswett)
    https://github.com/quicwg/base-drafts/issues/1261 =

  - #1230 Stateless Reset needs "on-path" proof (1 by MikeBishop)
    https://github.com/quicwg/base-drafts/issues/1230 [-transport] [design] =

  - #1267 Packet protection keys not CID-based (1 by martinthomson)
    https://github.com/quicwg/base-drafts/issues/1267 [-tls] [design] =


  3 issues closed:
  - Adding more information about the computation of RTO https://github.com=
/quicwg/base-drafts/issues/1261 =

  - Recommend simulating migration after quiescence https://github.com/quic=
wg/base-drafts/issues/1087 [-transport] [design] =

  - UDP-like, not exclusively UDP https://github.com/quicwg/base-drafts/iss=
ues/1250 [-invariants] [design] =




Pull requests
-------------
* quicwg/base-drafts (+4/-2/=F0=9F=92=AC20)
  4 pull requests submitted:
  - Change the UDP port sometimes too (by martinthomson)
    https://github.com/quicwg/base-drafts/pull/1269 =

  - Provide a linkage between key and _pp__ (by martinthom=
son)
    https://github.com/quicwg/base-drafts/pull/1268 =

  - Avoid failure from spoofed/delayed PATH_RESPONSE (by martinduke)
    https://github.com/quicwg/base-drafts/pull/1263 =

  - define compound packets (by kazuho)
    https://github.com/quicwg/base-drafts/pull/1262 =


  6 pull requests received 20 new comments:
  - #1068 Extension frames (11 by rpaulo, kazuho, martinthomson, huitema, e=
kr)
    https://github.com/quicwg/base-drafts/pull/1068 [-transport] =

  - #1269 Change the UDP port sometimes too (4 by mirjak, britram, mikkelfj=
, chris-wood)
    https://github.com/quicwg/base-drafts/pull/1269 =

  - #1256 Tls restore compat (2 by kazuho, ekr)
    https://github.com/quicwg/base-drafts/pull/1256 =

  - #1249 A more complete connection migration (1 by ekr)
    https://github.com/quicwg/base-drafts/pull/1249 =

  - #1251 Server's preferred address (1 by MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1251 [-transport] =

  - #1254 Remove unnecessary text from #1253 (1 by MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1254 [-transport] =


  2 pull requests merged:
  - Remove unnecessary text from #1253
    https://github.com/quicwg/base-drafts/pull/1254 [-transport] =

  - Change CID after inactivity
    https://github.com/quicwg/base-drafts/pull/1214 [-transport] =



Repositories tracked by this digest:
-----------------------------------
* https://github.com/quicwg/base-drafts

--===============2780299072982636778==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable





Weekly github digest (QUIC Working Group Specifications)





Sunday April 08, 2018



Events without label "editorial"



Issues



quicwg/base-drafts (+7/-3/=F0=9F=92=AC38)

  
7 issues created:

  

  
9 issues received 38 new comments:

  

  
3 issues closed:

  




Pull requests


quicwg/base-drafts (+4/-2/=F0=9F=92=AC20)

  
4 pull requests submitted:

  

  
6 pull requests received 20 new comments:

  

  
2 pull requests merged:

  



Repositories tracked by this digest:





--===============2780299072982636778==--


From nobody Sun Apr  8 11:02:07 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A5D129C6E for ; Sun,  8 Apr 2018 11:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6U5Wtb4hGnG for ; Sun,  8 Apr 2018 11:02:01 -0700 (PDT)
Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 88932129C59 for ; Sun,  8 Apr 2018 11:02:00 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,424,1517871600";  d="scan'208";a="7892914"
Received: from thorgal.eurecom.fr ([10.3.2.220]) by drago2i.eurecom.fr with ESMTP; 08 Apr 2018 20:01:59 +0200
Received: (from apache@localhost) by thorgal.eurecom.fr (8.14.4+Sun/8.14.4/Submit) id w38I1wbn020716; Sun, 8 Apr 2018 20:01:58 +0200 (CEST)
X-Authentication-Warning: thorgal.eurecom.fr: apache set sender to otilibil@eurecom.fr using -f
Received: from lam06-2-82-234-168-183.fbx.proxad.net (lam06-2-82-234-168-183.fbx.proxad.net [82.234.168.183]) by webmail.eurecom.fr (Horde MIME library) with HTTP; Sun, 08 Apr 2018 20:01:58 +0200
Message-ID: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>
Date: Sun, 08 Apr 2018 20:01:58 +0200
From: Ariel Otilibili Anieli 
To: jri.ietf@gmail.com, martin.thomson@gmail.com
Cc: quic@ietf.org
Subject: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_5z25ylmdey88"
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)
X-Originating-IP: 82.234.168.183
X-Remote-Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 08 Apr 2018 18:02:05 -0000

This message is in MIME format.

--=_5z25ylmdey88
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Jana, Hi Martin,

Here is my review of the draft:

1. The document defines QUIC, but nowhere have I come across the =20
definition of its acronym: it would help readers to get it from the =20
abstract, or no later than the introduction.

2. Section 2 lays out the Conventions and Definitions, but does not =20
state the meaning of frames (though they are used many times). Section =20
2 should also define what is a frame, and how it relates with a =20
streams and a packet.

3. Some typos; the text contains abbreviations (e.g, "isn't" for "is =20
not", "don't" for "do not"), and also considers technical terms as =20
legal persons ("QUIC's ACK frames", "TCP's retransmission"). See them =20
in the attachment.

Finally, on the QUIC version numbering: I think it would ease readers =20
to have a human-friendly representation, as IPv4 and IPv6 do; I =20
propose to follow the example of MAC and IPv6 addresses:

     * 00:00:00:00 for 0x00000000
     * 00:00:00:01 for 0x00000001
     * ff:00:00:00D for 0xff00000D

And allow double-dotted notation as in IPv6 (so sequence of zeros be grouped=
):

     * ::0 for 0x00000000
     * ::1 for 0x00000001
     * ff::0D for 0xff00000D

What do you think?

Regards,
Ariel

----------------------------------------------------------------------------=
---
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


--=_5z25ylmdey88
Content-Type: text/plain; charset=UTF-8;
 name="typos.draft-ietf-quic-transport-10"
Content-Disposition: attachment; filename="typos.draft-ietf-quic-transport-10"
Content-Transfer-Encoding: quoted-printable

# curl -sL https://tools.ietf.org/id/draft-ietf-quic-transport-10.txt | grep=
 -Pn "n't|'s"
66:   This document is subject to BCP 78 and the IETF Trust's Legal
177:   10. Streams: QUIC's Data Structuring Abstraction  . . . . . . . .  66
254:   Accompanying documents describe QUIC's loss detection and congestion
315:   This section briefly describes QUIC's key mechanisms and benefits.
359:   application multiplexes many streams atop TCP's single-bytestream
369:   QUIC's packet framing and acknowledgments carry rich information that
374:   those for original transmissions, avoiding TCP's retransmission
379:   QUIC's ACK frames support multiple ACK blocks, so QUIC is more
430:   number randomly generated by the server.  QUIC's consistent
431:   connection ID allows connections to survive changes to the client's
439:   client's and the server's network addresses.
514:   We first describe QUIC's packet types and their formats, since some
657:   [[Editor's Note: this section should be removed and the bit
662:   [[Editor's Note: this section should be removed and the bit
868:   stream 0 with offset 0 containing the server's cryptographic
974:   Server's Version Negotiation (Section 5.3) and Retry (Section 5.4.2)
1046:   the first packet sent by an endpoint isn't necessarily the first
1168:   endpoints.  QUIC's connection establishment intertwines version
1245:   If a server isn't currently accepting any new connections, it SHOULD
1321:   client's chosen version.
1944:   QUIC's consistent connection ID allows connections to survive change=
s
1945:   to the client's IP and/or port, such as those caused by client or
2087:   so that it can associate the peer's response with the causative
2280:   The time at which an idle timeout takes effect won't be perfectly
2611:   If there are open streams that haven't been explicitly closed, they
3377:   A stream frame's Stream Data MUST NOT be empty, unless the FIN bit i=
s
3628:   o  Set the IPv4 Don't Fragment (DF) bit on a small proportion of
3646:      is provisional until QUIC's loss detection algorithm determines
3669:10.  Streams: QUIC's Data Structuring Abstraction
3821:      states aren't intended to constrain implementations.  An
3962:   doesn't track states on the send stream that cannot be observed, suc=
h
4272:   encapsulating STREAM frame's offset field to the stream offset of th=
e
4279:   violation of the receiver's flow control limits.
4288:   regardless of the server's flow control state.  This rule applies
4354:   describes QUIC's flow-control mechanisms.
4356:   QUIC employs a credit-based flow-control scheme similar to HTTP/2's
4361:   receiver's buffer capacity for the connection, and (ii) Stream flow
4491:   message on stream 0 than would ordinarily be permitted by the peer's
4499:   complete, endpoints MUST NOT send additional data beyond the peer's
4501:   exceeds the peer's maximum offset, the endpoint cannot send
4771:   and initiate a 0-RTT connection with a server on the victim's behalf=
.
5202:      *RFC Editor's Note:* Please remove this section prior to
5250:   o  Reserved versions don't need to be generated deterministically
5253:   o  You don't always need the draining period (#871)
5368:   o  Version validation fields can't move or change (#121)
5512:   o  Don't require retransmission of old timestamps for lost ACK frame=
s


--=_5z25ylmdey88--


From nobody Sun Apr  8 11:16:13 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC3F12D77D for ; Sun,  8 Apr 2018 11:16:12 -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 J5KtrfU2WgSM for ; Sun,  8 Apr 2018 11:16:10 -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 77D1C129C59 for ; Sun,  8 Apr 2018 11:16:08 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id q80so7048234ioi.13 for ; Sun, 08 Apr 2018 11:16:08 -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=v3tLgrZYGYJkJ39A4QiKC3DeYighzJ+snrGdjzfTLx0=; b=qpz+LwjBoLbKM0z731WGZbKF48xKJdx30MSmTpuOURdjqOopnEaJ9+BXW7bi0BdtZt WsWKtGoYIJVEDz7KGExA2ewvyNTgyjXJOidPb/l9Swengugv/rxrSyGDbIE73I36sEAr Xko44qJuQXToyKcjB1Obx2oImRTtZ/M/I7t0xRuMqXgSdHLFakzl0gr1GrioTA0nrRWL ABW6yqIQKugoe03NkbZkDqvuQbknt8xHtMkTRYV1VvNogXuBO2uGRvmAPBHmxShaOgl7 w2ciJ2Gp0inSiP/PauEoQWSRL2NMaAQbeua166pYS0FDZs87IBGCJ8JQHR6mFV/wKzt9 YCow==
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=v3tLgrZYGYJkJ39A4QiKC3DeYighzJ+snrGdjzfTLx0=; b=OVgGKixjfXsNE53oh7fKvaeqHstrJr+FinVq/KTnXhLQ3x6puxJW3oSt+XCHSzzS5l XrCllQpCiUQwH6UoODo8J78V+PpQUjeirKf3j8D5DdjVOmTEGzc21IiQfO5dnhsJopEb fm31uRcqS/oZGbOY9ZL9Z8ZLjfQ+HgDp0lZ4fnb8gV01s5ZzPjj5kOJmC2pyDy4MWniu 5epa7Z2oqv46wAQblaOprVtzAPyZTflKuDukdLc/sEsOWFvgZ6sePPs1LK4SPCv5Mykj iTFmjqC3oCyv9x+vTKYmLRat2bnudkZfqpJKoLx9pYxEeW7p8FMDpxDRs8x6WZq9cK2A 3dkA==
X-Gm-Message-State: AElRT7GY8+eSGkFt1AqEml/CPpFKg9uAtW3IEecj34x8O3w9WndWrYPk 9RGA33Ncn77J+aysyTzgAmL/Mv70LIKO8PHQvzA=
X-Google-Smtp-Source: AIpwx4/3sH04AeEu+OVOSAmCMvz0ShKUgQl1xL7qIi2NuPpeirbOq3jHWflHJVtiHHYhMDkAjZIbvowhUQFf2sH8iUM=
X-Received: by 10.107.17.6 with SMTP id z6mr32088020ioi.274.1523211367742; Sun, 08 Apr 2018 11:16:07 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 8 Apr 2018 11:16:06 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Sun, 8 Apr 2018 11:16:06 -0700
Message-ID: 
Subject: Re: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
To: jri.ietf@gmail.com, Ariel Otilibili Anieli , martin.thomson@gmail.com
Cc: quic@ietf.org
Content-Type: multipart/alternative; boundary="001a113eda327e0d4205695a48f7"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 08 Apr 2018 18:16:12 -0000

--001a113eda327e0d4205695a48f7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ariel,

on the proposed dotted QUIC version numbers - I think it would be to easy
to confuse with an IP number.
There are many internal hex codes such as frame header types in a QUIC
implementation and the
supported version list would fit naturally in plain hex.

For public / human communication I believe some informal name would be
associated with each version - current QUIC v1 and QUIC v2 similar to IPV4
and IPv6. Also custom versions like gQUICxx are being used informally.
Perhaps this could be more formalized, at least for v1 and v2?

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


On 8 April 2018 at 20.02.12, Ariel Otilibili Anieli (otilibil@eurecom.fr)
wrote:

Hi Jana, Hi Martin,

Here is my review of the draft:

1. The document defines QUIC, but nowhere have I come across the
definition of its acronym: it would help readers to get it from the
abstract, or no later than the introduction.

2. Section 2 lays out the Conventions and Definitions, but does not
state the meaning of frames (though they are used many times). Section
2 should also define what is a frame, and how it relates with a
streams and a packet.

3. Some typos; the text contains abbreviations (e.g, "isn't" for "is
not", "don't" for "do not"), and also considers technical terms as
legal persons ("QUIC's ACK frames", "TCP's retransmission"). See them
in the attachment.

Finally, on the QUIC version numbering: I think it would ease readers
to have a human-friendly representation, as IPv4 and IPv6 do; I
propose to follow the example of MAC and IPv6 addresses:

* 00:00:00:00 for 0x00000000
* 00:00:00:01 for 0x00000001
* ff:00:00:00D for 0xff00000D

And allow double-dotted notation as in IPv6 (so sequence of zeros be
grouped):

* ::0 for 0x00000000
* ::1 for 0x00000001
* ff::0D for 0xff00000D

What do you think?

Regards,
Ariel

---------------------------------------------------------------------------=
----

This message was sent using EURECOM Webmail: http://webmail.eurecom.fr

--001a113eda327e0d4205695a48f7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
Hi Ariel,

on the proposed dotted QUIC ver=
sion numbers - I think it would be to easy to confuse with an IP number.
There are many =
internal hex codes such as frame header types in a QUIC implementation and =
the
supported=
 version list would fit naturally in plain hex.

For public / human communication I believe some =
informal name would be associated with each version - current QUIC v1 and Q=
UIC v2 similar to IPV4 and IPv6. Also custom versions like gQUICxx are bein=
g used informally.=C2=A0 Perhaps this could be more formalized, at least fo=
r v1 and v2?
=

 
=

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

 
On 8 Ap=
ril 2018 at 20.02.12, Ariel Otilibili Anieli (otilibil@eurecom.fr) wrote:
 
Hi Jana, Hi Martin,



Here is my review of the draft:



1. The document defines QUIC, but nowhere have I come across the  =20

definition of its acronym: it would help readers to get it from the  =
=20

abstract, or no later than the introduction.



2. Section 2 lays out the Conventions and Definitions, but does not  =
=20

state the meaning of frames (though they are used many times). Section =
 =20

2 should also define what is a frame, and how it relates with a  =20

streams and a packet.



3. Some typos; the text contains abbreviations (e.g, "isn't&qu=
ot; for "is  =20

not", "don't" for "do not"), and also cons=
iders technical terms as  =20

legal persons ("QUIC's ACK frames", "TCP's retra=
nsmission"). See them  =20

in the attachment.



Finally, on the QUIC version numbering: I think it would ease readers  =
=20

to have a human-friendly representation, as IPv4 and IPv6 do; I  =20

propose to follow the example of MAC and IPv6 addresses:



     * 00:00:00:00 for 0x00000000

     * 00:00:00:01 for 0x00000001

     * ff:00:00:00D for 0xff00000D



And allow double-dotted notation as in IPv6 (so sequence of zeros be gr=
ouped):



     * ::0 for 0x00000000

     * ::1 for 0x00000001

     * ff::0D for 0xff00000D



What do you think?



Regards,

Ariel



-----------------------------------------------------------------------=
--------

This message was sent using EURECOM Webmail: http://webmail.eurecom.fr





--001a113eda327e0d4205695a48f7--


From nobody Sun Apr  8 11:27:22 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737B112D77D for ; Sun,  8 Apr 2018 11:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JacV7o5Pxc-E for ; Sun,  8 Apr 2018 11:27:19 -0700 (PDT)
Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 6F36C12422F for ; Sun,  8 Apr 2018 11:27:19 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,424,1517871600";  d="scan'208";a="7892932"
Received: from thorgal.eurecom.fr ([10.3.2.220]) by drago2i.eurecom.fr with ESMTP; 08 Apr 2018 20:27:18 +0200
Received: (from apache@localhost) by thorgal.eurecom.fr (8.14.4+Sun/8.14.4/Submit) id w38IRIDU020727; Sun, 8 Apr 2018 20:27:18 +0200 (CEST)
X-Authentication-Warning: thorgal.eurecom.fr: apache set sender to otilibil@eurecom.fr using -f
Received: from lam06-2-82-234-168-183.fbx.proxad.net (lam06-2-82-234-168-183.fbx.proxad.net [82.234.168.183]) by webmail.eurecom.fr (Horde MIME library) with HTTP; Sun, 08 Apr 2018 20:27:18 +0200
Message-ID: <20180408202718.f24rua6h44w840kg@webmail.eurecom.fr>
Date: Sun, 08 Apr 2018 20:27:18 +0200
From: Ariel Otilibili Anieli 
To: Mikkel =?utf-8?b?RmFobsO4ZSA=?= =?utf-8?b?SsO4cmdlbnNlbg==?= 
Cc: jri.ietf@gmail.com, martin.thomson@gmail.com, quic@ietf.org
Subject: Re: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)
X-Originating-IP: 82.234.168.183
X-Remote-Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 08 Apr 2018 18:27:21 -0000

Hi Mikkel,

My comments in line.

Regards,
Ariel

Quoting Mikkel Fahn=C3=B8e J=C3=B8rgensen :

> Hi Ariel,
>
> on the proposed dotted QUIC version numbers - I think it would be to easy
> to confuse with an IP number.
> There are many internal hex codes such as frame header types in a QUIC
> implementation and the
> supported version list would fit naturally in plain hex.
>
> For public / human communication I believe some informal name would be
> associated with each version - current QUIC v1 and QUIC v2 similar to IPV4
> and IPv6. Also custom versions like gQUICxx are being used informally.
> Perhaps this could be more formalized, at least for v1 and v2?
I go for your proposal; the document should declare a formal, =20
human-friendly name (QUICv1 for instance), or explicitly says =20
somewhere "0x00000001 corresponds to the version 1 of QUIC".
>
> Kind Regards,
> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>
>
> On 8 April 2018 at 20.02.12, Ariel Otilibili Anieli (otilibil@eurecom.fr)
> wrote:
>
> Hi Jana, Hi Martin,
>
> Here is my review of the draft:
>
> 1. The document defines QUIC, but nowhere have I come across the
> definition of its acronym: it would help readers to get it from the
> abstract, or no later than the introduction.
>
> 2. Section 2 lays out the Conventions and Definitions, but does not
> state the meaning of frames (though they are used many times). Section
> 2 should also define what is a frame, and how it relates with a
> streams and a packet.
>
> 3. Some typos; the text contains abbreviations (e.g, "isn't" for "is
> not", "don't" for "do not"), and also considers technical terms as
> legal persons ("QUIC's ACK frames", "TCP's retransmission"). See them
> in the attachment.
>
> Finally, on the QUIC version numbering: I think it would ease readers
> to have a human-friendly representation, as IPv4 and IPv6 do; I
> propose to follow the example of MAC and IPv6 addresses:
>
> * 00:00:00:00 for 0x00000000
> * 00:00:00:01 for 0x00000001
> * ff:00:00:00D for 0xff00000D
>
> And allow double-dotted notation as in IPv6 (so sequence of zeros be
> grouped):
>
> * ::0 for 0x00000000
> * ::1 for 0x00000001
> * ff::0D for 0xff00000D
>
> What do you think?
>
> Regards,
> Ariel
>
> --------------------------------------------------------------------------=
-----
>
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>



----------------------------------------------------------------------------=
---
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


From nobody Sun Apr  8 18:18:55 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FD6126C83 for ; Sun,  8 Apr 2018 18:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1FgFcv355Kh for ; Sun,  8 Apr 2018 18:18:52 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77ADA126BF0 for ; Sun,  8 Apr 2018 18:18:52 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id l190-v6so6083463oig.9 for ; Sun, 08 Apr 2018 18:18: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=7dWvoGIXXgbTqyCjm0a3ny0i6OUzFZfkEDdDPNWoUUc=; b=Mwno16gUeisss05vhfxc8U8V2ZVSbfIfVHycWEP3aGf8Qyv+l3anz2avqf5K3RCjZ/ RGGR3t5HrZzZXUnvpO0D2txFedrGL0EESSZwVwlDrvXFRNXu7tphtU770pmID4LWLCVh Flp8ffE4FTW54Rj+cdL8e+dbkR0QgIxatkZ4AE3+KMU+hz2EFjnQq56ZiXg7zYg3q8Fv vc16IzHeyD1SXIq5IzgNJsIiRkRHS/cbNUObyvEBXSouI5ax3fRyRGwcHF+u8gFtOqGl bVbbzVVzSWdyO+9XPEg7eZACTEmZoDLIUeyiEkUBb7f0qN6RYFQXlnjmLOFczGh4JXOZ OxIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=7dWvoGIXXgbTqyCjm0a3ny0i6OUzFZfkEDdDPNWoUUc=; b=Vd8RK4lUlXI+CJywl7yV1Ga463X7BmiNCMfTKxxhTf3cpZQAOJ5NY5/3Ifd8sj00AH hOLDkv/lxYlYlzOWBXivxc/f6d7BTj/Pf76ZtpVo92qg2oTgXbn9FldnUJF9HpDCid+Q hmX7KXNcMzuskT22lVPPMc1LWj6qEZdPsuqBHMZ3i7n3jt8jcjd8Tuzr/0EeHhhrGbEH mby2mYg7s/qCA+g5f7G3tKxzwCboOLESfWvC82Qrh1TFPEf9owL4Ll6VLzLnQvVMB1P2 9vJDoxD+bb/rQ+6cFlbodTPkC7wGDEk9xBa80yT+jhF4gzv6klS5FT1NWhDpAr/DblHc Ii6w==
X-Gm-Message-State: ALQs6tCoJtmZ0zCbMxMSKhiC7tkIrtx3T0iTDuL3gOdL2ZWNAH2JzIn4 soAGYHzVWamVOuFMkfTlys0oQ1rbVPB9UogJ8/I=
X-Google-Smtp-Source: AIpwx4/c4MJDuJ+NzjrZkxcuvkGubB9MVI62TYeGp2ttNjNEWhHhlWRPes4Hjn6L+JGwdfxYC7rc0iXFlIEd+mZa+Fg=
X-Received: by 2002:aca:524c:: with SMTP id g73-v6mr19934409oib.144.1523236731717;  Sun, 08 Apr 2018 18:18:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Sun, 8 Apr 2018 18:18:51 -0700 (PDT)
In-Reply-To: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>
From: Martin Thomson 
Date: Mon, 9 Apr 2018 11:18:51 +1000
Message-ID: 
Subject: Re: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
To: Ariel Otilibili Anieli 
Cc: Jana Iyengar , 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, 09 Apr 2018 01:18:54 -0000

Hi Ariel,

Thanks for the input.

On Mon, Apr 9, 2018 at 4:01 AM, Ariel Otilibili Anieli
 wrote:
> 1. The document defines QUIC, but nowhere have I come across the definition
> of its acronym: it would help readers to get it from the abstract, or no
> later than the introduction.

QUIC is not an acronym.  You are expected to shout it ;)

> 2. Section 2 lays out the Conventions and Definitions, but does not state
> the meaning of frames (though they are used many times). Section 2 should
> also define what is a frame, and how it relates with a streams and a packet.

A pull request would be welcome.

> 3. Some typos; the text contains abbreviations (e.g, "isn't" for "is not",
> "don't" for "do not"), and also considers technical terms as legal persons
> ("QUIC's ACK frames", "TCP's retransmission"). See them in the attachment.

I don't consider use of contractions to be typos.  I do try to avoid
the possessive form, but I suspect that I or other contributors slip
on occasion.  Again, a pull request is the best way to make this
contribution.

> Finally, on the QUIC version numbering: I think it would ease readers to
> have a human-friendly representation

I think that "1" is perfectly human friendly.  It's just a number.  We
use the full, unambiguous form in a specification because we believe
our audience is capable of handling that.  Feel free to use whatever
numerical representation you feel suits you best.

Unambiguous textual representations are not a goal here, as it is
(unfortunately) for addresses.  If the number is presented to a human,
I sincerely hope that they are an engineer and therefore capable of
coping.


From nobody Sun Apr  8 19:54:54 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB12127337 for ; Sun,  8 Apr 2018 19:54:53 -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=WoZzMd3X; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BJEjqrEV
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJAhjTfJwgu6 for ; Sun,  8 Apr 2018 19:54:50 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17AAA126E64 for ; Sun,  8 Apr 2018 19:54:50 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4358020CBC; Sun,  8 Apr 2018 22:54:49 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 08 Apr 2018 22:54:49 -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; s=fm2; bh=3xxRlXl5RZ8vjP8PuM5kYRhx4BdOb NZZEihhoJpdU3k=; b=WoZzMd3XIXh8VFgkDSJKoh+j5pPGccnphB8NLrVW8744V BvT8M3JA+RSeqtHHn9/49eer1/otd/2V/IJgbkTeC5n4HKjGvpNZmTdqaUfKKiiS yL29/S1Ed/3Babo3AoHp2yQpXiRPfrAdncoCMJ3AkYY0eJZ747asX2SmuIpb8oNu wDcx4EmR+sHpHyRNyZgix15ep/6l04UqxGBbK6VufpodO7BjH0qgq/CbgD3sSH6x c1JJp/VfiuF4BLzTAK6WuHGO2JWcLyEzfnz1yUiApcFQUg3f/WYhJtpqIXeOvvXy S7SEKS7fS20+JUj54GcoeC66jWpGHiKBO9CuJBTrw==
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; s=fm2; bh=3xxRlX l5RZ8vjP8PuM5kYRhx4BdObNZZEihhoJpdU3k=; b=BJEjqrEV4l9Jm6his1TS73 +CmCJgzx0bJ1aZRgAuT2x/BLXql87S/JjCKwJ75Xqud87rUW1jcBe3bQ3uJ9zLmU z0STLtLFbh0ftRF4X4YNmrXOLyHh8Ai3z470rrFPFK4b+pKH69TveH5FEXCi41kO u0BgTAn4PjcgPjeg9UaPyL6D9zSkggW7FX+J7L4oZqiNO55BqI6sKy/plkHCou70 mHrlxWR1sqvoMIJAqioUVTiQRu02oL33LWVYZUzym2isdbp9oH97NXB5x1njz+HK FQ1DK+yDtCqelY1Oibjw9wZSdUEq3HtpqCb1iKvuAuBhliAfi0cZRFDM3ChH0cRw ==
X-ME-Sender: 
Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 5B7BC10253; Sun,  8 Apr 2018 22:54:46 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Getting to consensus on packet number encryption
From: Mark Nottingham 
In-Reply-To: 
Date: Mon, 9 Apr 2018 12:54:43 +1000
Cc: Martin Thomson , Kazuho Oku , Lars Eggert , IETF QUIC WG , Patrick McManus 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BCB9BA5-A282-445A-B7A1-8F7C539C28F9@mnot.net>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>     <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net>    
To: Praveen Balasubramanian 
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 02:54:53 -0000

Praveen,

In previous discussions, there's been strong interest in including =
connection migration -- in a limited form (for the "parking lot" use =
case) -- in QUICv1 (discussed in Melbourne in some detail; see =
).=20

It looks like the discussion in =
 about making it =
optional and how that gets indicated / negotiated is going nicely. =
Thanks for opening an issue.

AFAICT, (at least) two assumptions need to be proven to have that help =
the PNE issue:

a) There isn't a linkability issue during NAT rebinding

b) Having two packet number schemes is acceptable to implementers (given =
the probable popularity of migration)

I haven't yet seen much discussion of either of these specific aspects.

As an aside -- the other threads about modifications to PNE to make them =
single-pass seem extremely promising; I'd encourage folks there to =
continue discussions and make a PR.

Cheers,



> On 6 Apr 2018, at 2:41 am, Praveen Balasubramanian =
 wrote:
>=20
> Love this idea. Expanding it a bit further I don=E2=80=99t think we =
need to make PN transform a transport parameter but rather connection =
migration itself. We could also simply use QUIC versioning for this.=20
>=20
> 1. Ship QUIC v1 with no support for connection migration. Servers =
behind load balancers that are not QUIC aware will only advertise this =
version. I expect this to be a large fraction of servers especially =
those hosted in AWS, Azure, GCP. *This is important - I want the group =
to acknowledge that servers needs to be able to advertise support for =
connection migration*.
> 2. Ship QUIC v2 with support for connection migration. If a client and =
server use this version they MUST do PNE as per #1079. If we find a more =
efficient scheme before November then we use that instead.=20
>=20
> Eventually we will ship QUIV vN which has support for multi-path and =
we can revisit if PNE is needed or multiple PN spaces will work. Until =
then I can live with higher CPU cost for the fraction of connections =
that will migrate.=20
>=20
> Now there is the ossification problem in QUIC v1 as referred to above. =
We already require a random starting PN. The next problem is one that =
Kazuho brought up where middleboxes will start seeing strict increasing =
PN and try to reorder. I was thinking about short random jumps to fix =
this problem but the monotonic increase will remain. While I think sane =
middleboxes will not do any reordering, there might be a few crazy =
outliers like with TCP. I think we can solve this by making the in clear =
PN jump both forward and back within a "reordering degree". I am =
thinking about some ideas here and will reply back if I find a simple =
scheme.
>=20
>>> FWIW, what I got from the info that Praveen and Ian have shared is =
that there are enough problems to solve with UDP that worrying about the =
performance hit from encryption is premature
> Martin, we have plans to make UDP screaming fast in software. But the =
real advantage for TCP comes from the batch offloads (see email with =
subject " Impact of hardware offloads on network stack performance"). =
Batch offloads for QUIC are impossible to do without crypto offload. I =
would be happy to explain more on this front. I think we will exhaust =
software optimizations soon and then get blocked on crypto offload.
>=20
>=20
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson
> Sent: Wednesday, April 4, 2018 9:36 PM
> To: Kazuho Oku 
> Cc: Lars Eggert ; Mark Nottingham ; =
IETF QUIC WG ; Patrick McManus 
> Subject: Re: Getting to consensus on packet number encryption
>=20
> On Thu, Apr 5, 2018 at 10:57 AM, Kazuho Oku  =
wrote:
>> It is true that #1079 has issues with hardware crypto offload. I am=20=

>> happy to support switching to a better encryption scheme (if we find
>> one) at any moment; e.g., during the standardization of QUICv1, or as=20=

>> an extension to v1, or part of vX.
>=20
> Until this came up, I hadn't considered the use of an =
extension/transport parameter to negotiate a new scheme, but it's =
obvious.  This fits best with my view of things.
>=20
> If that means that we get the DC-QUIC option that turns the packet =
number encryption function into identity or some cheaper function, then =
I think that's an OK outcome.  We should stop pretending that one size =
fits all is achievable; it's not been the case for years already.
>=20
> FWIW, what I got from the info that Praveen and Ian have shared is =
that there are enough problems to solve with UDP that worrying about the =
performance hit from encryption is premature.
>=20

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


From nobody Sun Apr  8 19:55:00 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6611D12D87F for ; Sun,  8 Apr 2018 19:54:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523242494; bh=R5F/vnTzS6Y8nniRUwoutGiLR8/i6+sJ/1RL57iNqPM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=q+8V2mI31wo15SO4jl0Y5IqYwaVNTXttxB3qoYMzbeKUnnob+pCh3HHzy0Js493F+ i1oY4RQkwzRX9FuyLFUUG+003f9z9kIbjFPqAO6CjZoKu29Xc3/Nb4DYvsir/RvmI+ mfpyO5ZCZkmbOrXPGyA+sMJwEwlA4VxyHXBChSnk=
X-Mailbox-Line: From mnot@mnot.net  Sun Apr  8 19:54:54 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DA6127337; Sun,  8 Apr 2018 19:54:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523242494; bh=R5F/vnTzS6Y8nniRUwoutGiLR8/i6+sJ/1RL57iNqPM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=q+8V2mI31wo15SO4jl0Y5IqYwaVNTXttxB3qoYMzbeKUnnob+pCh3HHzy0Js493F+ i1oY4RQkwzRX9FuyLFUUG+003f9z9kIbjFPqAO6CjZoKu29Xc3/Nb4DYvsir/RvmI+ mfpyO5ZCZkmbOrXPGyA+sMJwEwlA4VxyHXBChSnk=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6857126E64 for ; Sun,  8 Apr 2018 19:54:53 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=WoZzMd3X; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BJEjqrEV
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ4YBqBJPjNA for ; Sun,  8 Apr 2018 19:54:50 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7EB128896 for ; Sun,  8 Apr 2018 19:54:50 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4358020CBC; Sun,  8 Apr 2018 22:54:49 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 08 Apr 2018 22:54:49 -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; s=fm2; bh=3xxRlXl5RZ8vjP8PuM5kYRhx4BdOb NZZEihhoJpdU3k=; b=WoZzMd3XIXh8VFgkDSJKoh+j5pPGccnphB8NLrVW8744V BvT8M3JA+RSeqtHHn9/49eer1/otd/2V/IJgbkTeC5n4HKjGvpNZmTdqaUfKKiiS yL29/S1Ed/3Babo3AoHp2yQpXiRPfrAdncoCMJ3AkYY0eJZ747asX2SmuIpb8oNu wDcx4EmR+sHpHyRNyZgix15ep/6l04UqxGBbK6VufpodO7BjH0qgq/CbgD3sSH6x c1JJp/VfiuF4BLzTAK6WuHGO2JWcLyEzfnz1yUiApcFQUg3f/WYhJtpqIXeOvvXy S7SEKS7fS20+JUj54GcoeC66jWpGHiKBO9CuJBTrw==
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; s=fm2; bh=3xxRlX l5RZ8vjP8PuM5kYRhx4BdObNZZEihhoJpdU3k=; b=BJEjqrEV4l9Jm6his1TS73 +CmCJgzx0bJ1aZRgAuT2x/BLXql87S/JjCKwJ75Xqud87rUW1jcBe3bQ3uJ9zLmU z0STLtLFbh0ftRF4X4YNmrXOLyHh8Ai3z470rrFPFK4b+pKH69TveH5FEXCi41kO u0BgTAn4PjcgPjeg9UaPyL6D9zSkggW7FX+J7L4oZqiNO55BqI6sKy/plkHCou70 mHrlxWR1sqvoMIJAqioUVTiQRu02oL33LWVYZUzym2isdbp9oH97NXB5x1njz+HK FQ1DK+yDtCqelY1Oibjw9wZSdUEq3HtpqCb1iKvuAuBhliAfi0cZRFDM3ChH0cRw ==
X-ME-Sender: 
Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 5B7BC10253; Sun,  8 Apr 2018 22:54:46 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Getting to consensus on packet number encryption
From: Mark Nottingham 
In-Reply-To: 
Date: Mon, 9 Apr 2018 12:54:43 +1000
Cc: Martin Thomson , Kazuho Oku , Lars Eggert , IETF QUIC WG , Patrick McManus 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BCB9BA5-A282-445A-B7A1-8F7C539C28F9@mnot.net>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>     <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net>    
X-Mailer: Apple Mail (2.3445.6.18)
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 02:54:55 -0000

Praveen,

In previous discussions, there's been strong interest in including =
connection migration -- in a limited form (for the "parking lot" use =
case) -- in QUICv1 (discussed in Melbourne in some detail; see =
).=20

It looks like the discussion in =
 about making it =
optional and how that gets indicated / negotiated is going nicely. =
Thanks for opening an issue.

AFAICT, (at least) two assumptions need to be proven to have that help =
the PNE issue:

a) There isn't a linkability issue during NAT rebinding

b) Having two packet number schemes is acceptable to implementers (given =
the probable popularity of migration)

I haven't yet seen much discussion of either of these specific aspects.

As an aside -- the other threads about modifications to PNE to make them =
single-pass seem extremely promising; I'd encourage folks there to =
continue discussions and make a PR.

Cheers,



> On 6 Apr 2018, at 2:41 am, Praveen Balasubramanian =
 wrote:
>=20
> Love this idea. Expanding it a bit further I don=E2=80=99t think we =
need to make PN transform a transport parameter but rather connection =
migration itself. We could also simply use QUIC versioning for this.=20
>=20
> 1. Ship QUIC v1 with no support for connection migration. Servers =
behind load balancers that are not QUIC aware will only advertise this =
version. I expect this to be a large fraction of servers especially =
those hosted in AWS, Azure, GCP. *This is important - I want the group =
to acknowledge that servers needs to be able to advertise support for =
connection migration*.
> 2. Ship QUIC v2 with support for connection migration. If a client and =
server use this version they MUST do PNE as per #1079. If we find a more =
efficient scheme before November then we use that instead.=20
>=20
> Eventually we will ship QUIV vN which has support for multi-path and =
we can revisit if PNE is needed or multiple PN spaces will work. Until =
then I can live with higher CPU cost for the fraction of connections =
that will migrate.=20
>=20
> Now there is the ossification problem in QUIC v1 as referred to above. =
We already require a random starting PN. The next problem is one that =
Kazuho brought up where middleboxes will start seeing strict increasing =
PN and try to reorder. I was thinking about short random jumps to fix =
this problem but the monotonic increase will remain. While I think sane =
middleboxes will not do any reordering, there might be a few crazy =
outliers like with TCP. I think we can solve this by making the in clear =
PN jump both forward and back within a "reordering degree". I am =
thinking about some ideas here and will reply back if I find a simple =
scheme.
>=20
>>> FWIW, what I got from the info that Praveen and Ian have shared is =
that there are enough problems to solve with UDP that worrying about the =
performance hit from encryption is premature
> Martin, we have plans to make UDP screaming fast in software. But the =
real advantage for TCP comes from the batch offloads (see email with =
subject " Impact of hardware offloads on network stack performance"). =
Batch offloads for QUIC are impossible to do without crypto offload. I =
would be happy to explain more on this front. I think we will exhaust =
software optimizations soon and then get blocked on crypto offload.
>=20
>=20
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson
> Sent: Wednesday, April 4, 2018 9:36 PM
> To: Kazuho Oku 
> Cc: Lars Eggert ; Mark Nottingham ; =
IETF QUIC WG ; Patrick McManus 
> Subject: Re: Getting to consensus on packet number encryption
>=20
> On Thu, Apr 5, 2018 at 10:57 AM, Kazuho Oku  =
wrote:
>> It is true that #1079 has issues with hardware crypto offload. I am=20=

>> happy to support switching to a better encryption scheme (if we find
>> one) at any moment; e.g., during the standardization of QUICv1, or as=20=

>> an extension to v1, or part of vX.
>=20
> Until this came up, I hadn't considered the use of an =
extension/transport parameter to negotiate a new scheme, but it's =
obvious.  This fits best with my view of things.
>=20
> If that means that we get the DC-QUIC option that turns the packet =
number encryption function into identity or some cheaper function, then =
I think that's an OK outcome.  We should stop pretending that one size =
fits all is achievable; it's not been the case for years already.
>=20
> FWIW, what I got from the info that Praveen and Ian have shared is =
that there are enough problems to solve with UDP that worrying about the =
performance hit from encryption is premature.
>=20

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


From nobody Sun Apr  8 22:52:24 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3795B124F57 for ; Sun,  8 Apr 2018 22:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (1024-bit key) header.d=itaoyama.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 z8VktnN1fZLf for ; Sun,  8 Apr 2018 22:52:20 -0700 (PDT)
Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0120.outbound.protection.outlook.com [104.47.92.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F69B1242EA for ; Sun,  8 Apr 2018 22:52:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hYIS1dHN4pV4c3zHS09Hl3siswE0Kt/i7cbRSpFvuto=; b=t5n6LYHBdyJWA4CTbu8rn3MseooZGZefeRUOt5F5EbjZUaHimIZ4BuBY6z4zFa6YyObsTsyJGW6KlepfegZGSUs9kMixTvF9gp0pxyj9zb7MJ3RkCGjluNHym9K2++SDiiIUqrmqs7kAtsVG4SZzLX17kNETgIu9giJcUzS2Ol0=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; 
Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB1547.jpnprd01.prod.outlook.com (2603:1096:403:4::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.631.10; Mon, 9 Apr 2018 05:52:17 +0000
Subject: Re: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
To: Martin Thomson , Ariel Otilibili Anieli 
Cc: Jana Iyengar , QUIC WG 
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr> 
From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: <0c2bbb1f-af3c-e196-3605-db9458936a42@it.aoyama.ac.jp>
Date: Mon, 9 Apr 2018 14:52:18 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.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
X-Originating-IP: [133.2.210.64]
X-ClientProxiedBy: KAXPR01CA0001.jpnprd01.prod.outlook.com (2603:1096:402:19::11) To TY1PR01MB1547.jpnprd01.prod.outlook.com (2603:1096:403:4::14)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 50273011-5db5-46a9-8e10-08d59dde0d8b
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:TY1PR01MB1547; 
X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB1547; 3:ErxEKKRkdut3GgDRkyL7WRci7X9wd8oODuqCzOAQTcrvj3Osj3YrZrOjbJnTqnW9HB4bXVO0a8xi8AWD2Y5JvOhpWB4SuvImec52cAS9OhFQYLl35lXKe1C+34qiD6U3LbQ0knmGxWfb3v9AY/XmcaLFB4Juyg9xojNKjWg9vfRaTS94PDGXAVuQsKgco+w7+dUKLUi9N0KEMallh0NLOcFjapRQUGAS5hrnn+0ZHigwo13MZMfK5GIPx0GieMyg; 25:reRlITxPPrfLQp3CWufF0wzj9kSUeNn649ws7MVsoWTs8UjooIApo+SQpOKDHoU4jMNX79pbqyHZ5FEdNpX34zyNMsp1+L2oY5FJiwFziio9db5nBRpR4R/noIGLA7ukPHoTzkrybNzDuNRL89CiKvyUl6SlTrUQK3PHowd1jACQknMihkbVG6YUD0sMJy/0TrVIWoXBI5Ked8zPQ6LOIDmwjnR+N4K3Mxq/BX9V2P41OQz2dAKAXSHMlHFuHAMrgfC3I9dKfDT+pID3QbCSYZZmpH3+PBADw09Kvm3/NMOMKQsp6Tb4d4FyATq387KW2L+zsum1DziRsLgYecFeQg==; 31:kmY2DwlHb9Xtiqzjp/JZDbqsqx3AdkAXjl/8VcfQ+78O/1kJ/LmPRjvOsQuByxdnzL9D7EXk1M+5cRPcO2gKlckEcqhcts2J1d1g7ip5lqVK6l/tBvZaubLXsJLkuo96UeZtedSivTq6T1TCFilYxLfRxuRzNDKOgJ/FPil/CAM8QYe0cBE6vGyduZq7jaFN0CJpDvibcc02VYvQTqCq705kbwYS2fYVSt3GHV3LXJU=
X-MS-TrafficTypeDiagnostic: TY1PR01MB1547:
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(93006095)(93001095)(10201501046)(6041310)(20161123558120)(20161123560045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:TY1PR01MB1547; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB1547; 
X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB1547; 4:C9osAT/tcSnqyi1AnZmNFfXmnh2QCnbF2iK6o1gcybQkwANHcopWC49KnumQMOMYgPJVZR3Hm+720WUK9O4/na8re0aMgdlekdTMkAAJCAs1CueXA2OMo3yopTM47reuXIwvVL9oYkbsWxODwNcG5fAAstkUxwDOOd5MHlZLUbCI5rYqFoChIKCEUqluWwFJ1EmpiVLjhDevNjrc7NTO3jaXrGZ5oLCWaw47SDeFRRKsJDlLTMp7f1dkzr53Q3VDL1cnn9SzLchaNoikNcXILQ==
X-Forefront-PRVS: 0637FCE711
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(39380400002)(346002)(366004)(376002)(396003)(39840400004)(199004)(189003)(66066001)(7736002)(229853002)(65956001)(16526019)(64126003)(6486002)(5660300001)(186003)(39060400002)(50466002)(76176011)(58126008)(65826007)(53936002)(486006)(26005)(97736004)(65806001)(110136005)(16576012)(956004)(23676004)(2906002)(305945005)(74482002)(68736007)(54906003)(316002)(105586002)(476003)(81156014)(6116002)(8676002)(47776003)(3846002)(786003)(25786009)(52116002)(81166006)(31686004)(6246003)(106356001)(478600001)(4326008)(8936002)(49976009)(2616005)(52146003)(446003)(230700001)(53546011)(386003)(36916002)(31696002)(86362001)(67846002)(2486003)(11346002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB1547; H:[133.2.210.64]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIxNTQ3OzIzOmJ3N25iNG9ZZlVLTEFTMUhvYkM4WGxHeFc1?= =?utf-8?B?VlpyVGo4YUlpU3UxYkg4REl5U2dUZ3Zhd2J6T1Q2UlY2K1R2MEFGOUlIZ3gy?= =?utf-8?B?c3VvN2owQm5iSW1iT0tVc3o4OVNCRmxqR0ptNnRSWkhKM1JidUJCZ3NoaUcv?= =?utf-8?B?L0IxSlpNMjFZcWxnTGJ1WU1SRlZNWjBvMUlQTmRnYVJrU25TRVY0dmtleitX?= =?utf-8?B?bEJaREFOMmp6YzVOYzVnQ3E5VGlEbnNKSlprcE5zTGtsdEdMSGluZ2d4SXpE?= =?utf-8?B?OFhyT2t4SkpQTWRmL3YyNitVU3hwOHFtcjJOTnpXc2g2cU50bEppSmptemNx?= =?utf-8?B?aEZkRzJidnhxMWtRUGU3ZEhheFB4ejFsbTloQk5tTTFvN3poNEtEbWUwWDZS?= =?utf-8?B?KzBNZ2FlWGViZU5hTk56dTB5RFpUOXNoczJUM1F5cEtONVFmckpEdDBVajI1?= =?utf-8?B?bjlqMVltbk52aHM3eFdhcCtrNmV0REtmbnFFQlljWS81Q0VqQTdIaHd3RkZt?= =?utf-8?B?blN2amplbEtQZ09EeUM5cW15bnd3eVZ6dVJSbDhKLytXd2JQdnNTUUd1UGZR?= =?utf-8?B?VC92eE05WENsaUlha0E5dW1jb29IdHVWSFJNK1Q0Tldub3g4VXpmbUg3WDZ5?= =?utf-8?B?aWU3alBvWDlRSW9BQTM0VTJYSWRSc0ZBUktLbXVBTnZlME94TVBDc0tDT0lj?= =?utf-8?B?WnJtNDBCRjFzN0VIeGVoZmdvWXdFeGt6cFd5V0FSYVVpZHJHZTJDUlhnekNZ?= =?utf-8?B?UzNvdlVrbHZ3WkhlNXpSYzN6d0ZjVlAxTHV1dXVUZXh0T1pDektXL0xmYStr?= =?utf-8?B?eXBlRE9MT3UxSFMydkdtL2RVbVdrdGFOeFRhMEg0cTNOR0tVQVpEVVlXSFc3?= =?utf-8?B?akp2V2kzeUhubG1hVVdNUDBuTHJCWlZDbUdIMWE4SmxlSXVGRmdSbFROcVgy?= =?utf-8?B?c1JsU0tSUjFURlZhaXVwb1p1NW5PRjQ0aEZDNzN6NXorVFhvMkRkZDAvQ0ZD?= =?utf-8?B?N0hlYm9nL05neDQweEpkUzNicEcwU2hnRzBDZUxybUFHNWFrOUh4eW9wdGV5?= =?utf-8?B?S2w3Vkpwc2VESndibDRESEpFNllodm9sSHd4bFZic2Z2SlhXQnYyN2lQK25o?= =?utf-8?B?V1Rqd0NUTmkyclIzaTZWNmQzZFc2UXhlbXlJdmxVaEhmNGg4SGtoa1FKMUF1?= =?utf-8?B?cjZLRTJ2ZTV6NFZCMzd0OGVlV3dKcEhTZUU5Yzc0dVZMUjcwakNoWVlYelJW?= =?utf-8?B?V0VGNmcwWkNyYlE5QjBXVmZXL0NHT2tCU2JXeVppTzBSWUdpMFhEWVhLL1ZS?= =?utf-8?B?TEVkVlRTT2docUI0OG9ZVEg2T3V3bndJY0E3cWZpQk9vT1A5UCtkZ05TeWhV?= =?utf-8?B?ZXMybHdVMWVtMWI3S1g0aC91T1RrV2QzMWlIbDVpTi9NUEc2TThHV1F5RDZY?= =?utf-8?B?dWdIUEhHekJmT2c3bVBZaGZzcjFBdng0NVViMklUVThMTFk1YW0yNThldHFZ?= =?utf-8?B?ajlwcUxacTBRMUlkTjRGNHRVUVpGUHdqYk16SGdBZ21LWDRxV05CYXYzNzdm?= =?utf-8?B?dzM5TlJBUlJNdGkvVmozWENmMHgwK3dQWTNWTkFyOEVaaDBFdEZYMXJrTTJG?= =?utf-8?B?Wjc2TjNISjAzRXViWFFWenBkdUExckpaUFEzdG9LMFV6blozcWZ2N1Z4ZzA1?= =?utf-8?B?b25mSTN6bk9QUW8zVFZ0VnJRSXFlbFg0UTlkZVRkSGliL0NJRksrQkF1SDUz?= =?utf-8?B?ekdSRzRPdHVWUnlRQm1VTEI0Q1ROVTg2Q2E3QmIyVlJDUzlCbkw4cUNPWUpw?= =?utf-8?B?blVib2wxTjQrV1B5V3RkVlNCZnY1V0NPekR4dS9xQjRDby9ZRFlhbVNSWmNx?= =?utf-8?B?RFRrN0VLZnN5YnE0MUxqWTJKdFBNR1U3SG1NYThzeVVsUGlheXRXR1JIV25R?= =?utf-8?B?SkQrb1dERDRFTE1iYjdSSmJmQUFoYjlub1lkWGxJZ3lRZU9ROExIdytqSzRm?= =?utf-8?B?SFdRRVAyOW90TWtXb3RtWjZQdHY5NkR5S3NmTEhWRlhmVWt0bWRqRmJnSGRU?= =?utf-8?Q?zOfiMuOfG2gyrkb7oF3awrQzk?=
X-Microsoft-Antispam-Message-Info: LRNuKD19hlQx3bDxn95pL4iRKYLhf76OujB0HPziEipqbaWWOQBN4ozA3fkEcysebZjpyyrftLyc88dbQS7KFuSJ3fJOdwZFkziBNHU11wraqkWJk688PruOp7PIYHewlBRzDCUhJIToqoChBIYfJ6r4KCO12k8uffjmIIkHWdi9dVYgsqHPbSSwcoEpZdTT
X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB1547; 6:M18oQFJeidV56wVV4d8KDdrx8tnthik/W1Sdpp1o2vygDeY6oFcAsskq3USqnEg8XkKn5KFeaOTjeE7MxabW/k7k6enhr3wry8iKV5C5YDx3SBImt92ta0MhXoM88mUE1N2CEbrSbZ7jh9U0djn96fbptU3TLp2kLij7Nx2t9Pu3rx4gbfIA8VV+cVz1AfyuQO9V51CEDzByB5I936Od6yMGA6X5jTh3nPQkqRvx1WnJsBW3R/ggdUPA9wQEYs/Px8zV5PAXG3qaH/t7LFuRVDCb/IRi7jrwdYJHQB+Vl/Z5/gSdmBxIjsrbc/vdGdEsEPZD1eU343aNGKhS9G3UpzjYfPw+HHyDRH485Cnz3WUgRrpW1TTfvUDh8hhb7iWQ3XtyGjNxZpioR8ln/dAPx9NABxVmNBARHzd/onPfRtBnUz0xPy0OdmRJW7XdNlRd8OGMvE/feQsZI+x1cN0iqQ==; 5:IJFsb4sAddPkXrKSFNveHxqhjANHN56RuveQRYphwSLjns4+smKD9tuAyIBWLAmpkIFYLnJ/u3hEy3ZK7Ix2ufu0XUeSEssnhRLtj5s+3AzslGVTLfncD/wPRXUI7JODh27nVAYs1N/vgx58UxnTE0nNJ55f28YPKhQ/VCXFauk=; 24:C9FuY7UvPgRMUzer1TyzCKuHA5UO0WL3Ka3pT6j5NtLiAQOYHH2YveUy9pNLltRAmUWIbchXz6uFgRWf1d9f9snQ/PZSNFuVHpFiGshLpFY=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB1547; 7:gHRCGMSl5cC7YhwRCzaZ1N8CWYMnPeO24HLhhDoSt8Wwf/60TO9mVLjdFVa07p1qMGj4jDABuLByzmuUEI5ZtK2O8IZEYSKqJcVcB9LRmMUH0RIous9Rd3hIv8eiT0xLoPq8JcjYuO5Kb/Xfgp1mPQZSsm0zngKeF+3bianjrVE/GX/mGy7E6/lwhjH2wQ9pp1N+zTWhO7YaHf7ZX1HoeKEQTT8yjyQSa50wZb0x5J0qBGKBtjCZVDIB6CHauKEb
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2018 05:52:17.4437 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 50273011-5db5-46a9-8e10-08d59dde0d8b
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB1547
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 05:52:23 -0000

On 2018/04/09 10:18, Martin Thomson wrote:

> On Mon, Apr 9, 2018 at 4:01 AM, Ariel Otilibili Anieli
>  wrote:
>> 1. The document defines QUIC, but nowhere have I come across the definition
>> of its acronym: it would help readers to get it from the abstract, or no
>> later than the introduction.
> 
> QUIC is not an acronym.  You are expected to shout it ;)

Good to know. Maybe the text (introduction) could say so?

Regards,   Martin.


From nobody Mon Apr  9 00:02:41 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004BC126FB3 for ; Mon,  9 Apr 2018 00:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J45W2Hn6GWQZ for ; Mon,  9 Apr 2018 00:02:36 -0700 (PDT)
Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6DB126579 for ; Mon,  9 Apr 2018 00:02:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,426,1517871600";  d="scan'208";a="7893818"
Received: from thorgal.eurecom.fr ([10.3.2.220]) by drago2i.eurecom.fr with ESMTP; 09 Apr 2018 09:02:34 +0200
Received: (from apache@localhost) by thorgal.eurecom.fr (8.14.4+Sun/8.14.4/Submit) id w3972Xxv021172; Mon, 9 Apr 2018 09:02:33 +0200 (CEST)
X-Authentication-Warning: thorgal.eurecom.fr: apache set sender to otilibil@eurecom.fr using -f
Received: from reverse.completel.net (reverse.completel.net [92.103.89.82]) by webmail.eurecom.fr (Horde MIME library) with HTTP; Mon, 09 Apr 2018 09:02:33 +0200
Message-ID: <20180409090233.hxlqgu1wqo0o04c0@webmail.eurecom.fr>
Date: Mon, 09 Apr 2018 09:02:33 +0200
From: Ariel Otilibili Anieli 
To: "Martin J. =?utf-8?b?RMO8cnN0?=" 
Cc: Martin Thomson , Jana Iyengar , QUIC WG 
Subject: Re: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>  <0c2bbb1f-af3c-e196-3605-db9458936a42@it.aoyama.ac.jp>
In-Reply-To: <0c2bbb1f-af3c-e196-3605-db9458936a42@it.aoyama.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)
X-Originating-IP: 92.103.89.82
X-Remote-Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 07:02:39 -0000

Hi Martin, hi Martin,

A comment in line.

Regards,
Ariel

Quoting "Martin J. D=C3=BCrst" :

> On 2018/04/09 10:18, Martin Thomson wrote:
>
>> On Mon, Apr 9, 2018 at 4:01 AM, Ariel Otilibili Anieli
>>  wrote:
>>> 1. The document defines QUIC, but nowhere have I come across the definit=
ion
>>> of its acronym: it would help readers to get it from the abstract, or no
>>> later than the introduction.
>>
>> QUIC is not an acronym.  You are expected to shout it ;)
>
> Good to know. Maybe the text (introduction) could say so?
"QUIC (Quick UDP Internet Connections, pronounced quick) is an =20
experimental transport layer" says Wikipedia, =20
https://en.wikipedia.org/wiki/QUIC
>
> Regards,   Martin.



----------------------------------------------------------------------------=
---
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


From nobody Mon Apr  9 00:05:12 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6B312704A for ; Mon,  9 Apr 2018 00:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol7zoGs62cxp for ; Mon,  9 Apr 2018 00:05:08 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49C5126FB3 for ; Mon,  9 Apr 2018 00:05:07 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id u141-v6so6631910oif.1 for ; Mon, 09 Apr 2018 00:05: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=rTbpEuzgrGUaMclruF17pCsV2blSREMzsIn/szrSw9E=; b=gKi7tsqUxqeSktLbYz5B0DxnlCmBHBeZwrrP+pI+ApFNcy8XAvxoiJwN0CbyiI7r3D oX8EDIqPmlOU6KC7AP1C99DG3RsobNfspMmtSCwwb2CknigTUDtxFa4YdyXwsjITemua bcMny6wpuSTWHdOO7DVVF/PjuKqwuPStSa6mz0J1la/vidfDodpvOWTun3tYYjtWaAgE ClCiYqsdRpg/AXdHOlQ2Ps+hs3rX8KtyIfhVmR+FYGG/dwOS0AKlyBSyeL0Xbb2DpDdQ fXekD+fkAAFbK2BU9wJNEVebmDvJWMKrP+E0pDQWu934fUo9cdJ7/mSTn3cCFhgDtzbO GAng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=rTbpEuzgrGUaMclruF17pCsV2blSREMzsIn/szrSw9E=; b=cUsVGRSW4kWL/FS6Vbjibb3stQ2Ot22Qxqh23ZbnZ8o3tofMyT7ZZUQL/HzW8c3owM 4TAHDxuaqr2N2rZKWNHQEuWEkdPxS7NgLw+C6MAmM7WDhEQ3uW/bxO8/mjM2eCgmZZC5 dXvAJXh0pUB8PBEo5LPo1gKemp/lkD8tulpph7ecGJUUOsiNDLLdJRSqZvP7iSpuy44S 4wHbFjL1NU9cVLLBvyvMlAZc58GT+8MaOFIStZaVpjDpjuVMQ8lTMgzhJwEFzl9QewfD GUdaUcA4cb4PNBuUgDOa/S4l+4PuvGcEl2TPJ/PmVvrnUFZEI1HtO8qKv18+fJFV7t8R xbNQ==
X-Gm-Message-State: ALQs6tCBmyxcyUIDeW2Zc3qACwzp1CzgtCZwE8oYPKrTU9SwmrCub2hQ wvFMY0SECCd8rh/QxXL8aorYuAIGPmp1xuZIHUJwpQ==
X-Google-Smtp-Source: AIpwx48c5PgPfJfhPPQ7k+flpdkG32JFVNfZtoaxzuPqDlo8DmSlTQPG0L/fSzLk9gnipYjQ1OvL0q+DP+kaD/kQf9Q=
X-Received: by 2002:aca:ab44:: with SMTP id u65-v6mr21901744oie.272.1523257507018;  Mon, 09 Apr 2018 00:05:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 9 Apr 2018 00:05:06 -0700 (PDT)
In-Reply-To: <20180409090233.hxlqgu1wqo0o04c0@webmail.eurecom.fr>
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>  <0c2bbb1f-af3c-e196-3605-db9458936a42@it.aoyama.ac.jp> <20180409090233.hxlqgu1wqo0o04c0@webmail.eurecom.fr>
From: Martin Thomson 
Date: Mon, 9 Apr 2018 17:05:06 +1000
Message-ID: 
Subject: Re: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
To: Ariel Otilibili Anieli 
Cc: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= ,  Jana Iyengar , 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, 09 Apr 2018 07:05:10 -0000

On Mon, Apr 9, 2018 at 5:02 PM, Ariel Otilibili Anieli
 wrote:
> "QUIC (Quick UDP Internet Connections, pronounced quick) is an experimental
> transport layer" says Wikipedia, https://en.wikipedia.org/wiki/QUIC

Yes.  That is an expansion that has been used.  We explicitly decided
not to use that.


From nobody Mon Apr  9 01:26:17 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7511242F7 for ; Mon,  9 Apr 2018 01:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-om2F8AhzPm for ; Mon,  9 Apr 2018 01:26:13 -0700 (PDT)
Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20DC126C19 for ; Mon,  9 Apr 2018 01:26:12 -0700 (PDT)
Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk [10.161.14.16]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w398Q9vS002575; Mon, 9 Apr 2018 09:26:09 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1012.national.core.bbc.co.uk ([10.161.14.16]) with mapi id 14.03.0361.001; Mon, 9 Apr 2018 09:26:09 +0100
From: Lucas Pardue 
To: Martin Thomson , Ariel Otilibili Anieli 
CC: Jana Iyengar , =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= , QUIC WG 
Subject: RE: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
Thread-Topic: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
Thread-Index: AQHTz2O5y8Wvf6t3b066iKl2ZkPu+6P3keSAgABMZwCAABOhgIAAALYAgAAmgeQ=
Date: Mon, 9 Apr 2018 08:26:09 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB22349@bgb01xud1012>
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>  <0c2bbb1f-af3c-e196-3605-db9458936a42@it.aoyama.ac.jp> <20180409090233.hxlqgu1wqo0o04c0@webmail.eurecom.fr>, 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.161.212]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23772.005
x-tm-as-result: No--4.267000-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Apr 2018 08:26:15 -0000

In day to day talk I tell people that QUIC is the KFC of transport protocol=
s, and has similar levels of GREASE.

Lucas
________________________________________
From: QUIC [quic-bounces@ietf.org] on behalf of Martin Thomson [martin.thom=
son@gmail.com]
Sent: 09 April 2018 08:05
To: Ariel Otilibili Anieli
Cc: Jana Iyengar; Martin J. D=FCrst; QUIC WG
Subject: Re: Review of draft-ietf-quic-transport-10, and a proposal for a h=
uman-friendly QUIC version numbering

On Mon, Apr 9, 2018 at 5:02 PM, Ariel Otilibili Anieli
 wrote:
> "QUIC (Quick UDP Internet Connections, pronounced quick) is an experiment=
al
> transport layer" says Wikipedia, https://en.wikipedia.org/wiki/QUIC

Yes.  That is an expansion that has been used.  We explicitly decided
not to use that.


From nobody Mon Apr  9 01:31:17 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDC1127601 for ; Mon,  9 Apr 2018 01:31:15 -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 VbLdWm5kUFju for ; Mon,  9 Apr 2018 01:31: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 13782126C19 for ; Mon,  9 Apr 2018 01:31:13 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id v194-v6so9225184itb.0 for ; Mon, 09 Apr 2018 01:31:13 -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=d68NKZ0ikWb70xY+7TAbHuuq+SUvqmR/jI22rnnlJdA=; b=rFFsWT8nwPC1+g0LFyj6b/8hl3N5IEAgFI8lpOlz7Thcei+HPpHB/selFU/WuNqt9e vdg/5vsE19m/Vjg69mlBQ7fBG40o/P+rjcQ5dU57BuERB1LA2B3sXPHwZkHdtJ86bHBt Zhf5uG4p5Bk5aiESMnjyOAy2M4AkpwmhWlkuBBGrQTSo/C05eI1xNLn9gcvUr/Do7EeN 4ndGOGZq0H0BZjU1YseBlekoQzKvs0ZNweMzizQIGwVKhDMc1AoYNiN+nYnzteRl31jZ n170D1R3zyn3bbblshiSkxMNl0U4+vyUzLVs3hkb3gW1g8o8c5LOckIE+6lShiPP0UOq t1UA==
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=d68NKZ0ikWb70xY+7TAbHuuq+SUvqmR/jI22rnnlJdA=; b=pA33f8SgA+jeGGx8dEohHT4JX/w/QVJvLVa3XlJLJheHX3dQCiaOTgt16CIYhpsVID oUioOFYtbM9ypw14RXfkDJFn/+lZhEu/BOR5PDp4efZQE4Vtk901xdZIWRAPPju61yda ZhW+7NmYpy7pzg+VIgbvhxGAnq7EX1iE6UjTrcRiKZcWoOObhzPNlMi7rDhjn0cj+zFs +0u805vI4NPD2cX4KmODZleyZohTRX9TuZSeZ70C6vA54weUtFT4eKjYjL3aXHz5gqL9 DUuzgUCEHmK81ur9amb8kbKwFBgR5+dwB6JvdNaeKc+WBZ7VVlrb+iLzCCxh8oeunv59 6kSA==
X-Gm-Message-State: ALQs6tDXHtczZ1rZ+nERb0dMoUinIJrW8CPZje6HR+a5ihFfvc4pi/aS OQuahrkMADFn4WR7sqWtJQSqeGZ8LR9uPHNCm0U=
X-Google-Smtp-Source: AIpwx48CQAcoimRtDc+58IBTrIMxfm1NudDl4kS5Xq72LVsv01fzhlvyc7m5VnxYSqyG9+L/oznZHHmHc+grJXlcA3Q=
X-Received: by 2002:a24:5085:: with SMTP id m127-v6mr4191343itb.118.1523262671800;  Mon, 09 Apr 2018 01:31:11 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 9 Apr 2018 04:31:11 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB22349@bgb01xud1012>
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>  <0c2bbb1f-af3c-e196-3605-db9458936a42@it.aoyama.ac.jp> <20180409090233.hxlqgu1wqo0o04c0@webmail.eurecom.fr>  <7CF7F94CB496BF4FAB1676F375F9666A3BB22349@bgb01xud1012>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 9 Apr 2018 04:31:11 -0400
Message-ID: 
Subject: RE: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
To: Lucas Pardue , Martin Thomson ,  Ariel Otilibili Anieli 
Cc: Jana Iyengar , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= ,  QUIC WG 
Content-Type: multipart/alternative; boundary="00000000000073d8560569663ab2"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 08:31:15 -0000

--00000000000073d8560569663ab2
Content-Type: text/plain; charset="UTF-8"

http://fortune.com/2018/02/23/kfc-chicken-shortage-apology/

I guess the equivalent would be to write ICUQ when running out of UDP
packets.

Mikkel

On 9 April 2018 at 10.26.22, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote:

In day to day talk I tell people that QUIC is the KFC of transport
protocols, and has similar levels of GREASE.

Lucas

--00000000000073d8560569663ab2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=


I guess the equivalent woul=
d be to write ICUQ when running out of UDP packets.

 
Mikkel
 
On 9 =
April 2018 at 10.26.22, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote:
 
In day to =
day talk I tell people that QUIC is the KFC of transport protocols, and has=
 similar levels of GREASE.=C2=A0

Lucas=C2=A0
<=
/body>

--00000000000073d8560569663ab2--


From nobody Mon Apr  9 01:36:29 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9DA127419 for ; Mon,  9 Apr 2018 01:36:27 -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 79J-Me9A7Env for ; Mon,  9 Apr 2018 01:36:24 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9978E126C19 for ; Mon,  9 Apr 2018 01:36:24 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 89512340D44; Mon,  9 Apr 2018 10:36:22 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.16195);  Mon,  9 Apr 2018 10:36:22 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Mon,  9 Apr 2018 10:36:22 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 51048847; Mon, 09 Apr 2018 10:36:22 +0200
From: "Brian Trammell (IETF)" 
Message-Id: <37129F6C-71C2-437D-A6F4-7AC651FDFBE3@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_95AE2A92-59EC-47D4-93A8-C9921FA33760"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Getting to consensus on packet number encryption
Date: Mon, 9 Apr 2018 10:36:21 +0200
In-Reply-To: <9BCB9BA5-A282-445A-B7A1-8F7C539C28F9@mnot.net>
Cc: Praveen Balasubramanian , Lars Eggert , IETF QUIC WG , Martin Thomson , Patrick McManus , Kazuho Oku 
To: Mark Nottingham 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>     <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net>     <9BCB9BA5-A282-445A-B7A1-8F7C539C28F9@mnot.net>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 08:36:27 -0000

--Apple-Mail=_95AE2A92-59EC-47D4-93A8-C9921FA33760
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

hi Mark, all,

> On 9 Apr 2018, at 04:54, Mark Nottingham  wrote:
>=20
> Praveen,
>=20
> In previous discussions, there's been strong interest in including =
connection migration -- in a limited form (for the "parking lot" use =
case) -- in QUICv1 (discussed in Melbourne in some detail; see =
).
>=20
> It looks like the discussion in =
 about making it =
optional and how that gets indicated / negotiated is going nicely. =
Thanks for opening an issue.
>=20
> AFAICT, (at least) two assumptions need to be proven to have that help =
the PNE issue:
>=20
> a) There isn't a linkability issue during NAT rebinding

Isn't the question we should be asking here "does QUIC with connection =
migration disabled (and no PNE) have similar linkability characteristics =
to QUIC with connection migration enabled (and PNE)?"?

I'm still confused as to how PNE is supposed to mitigate linkability =
across a NAT rebinding that occurs without client knowledge in the =
presence of a server-supplied CID, which seems to me to be the most =
common NAT rebinding event type. If it indeed does not, then the =
linkability characteristics seem identical to me.

>=20
> b) Having two packet number schemes is acceptable to implementers =
(given the probable popularity of migration)
>=20
> I haven't yet seen much discussion of either of these specific =
aspects.
>=20
> As an aside -- the other threads about modifications to PNE to make =
them single-pass seem extremely promising; I'd encourage folks there to =
continue discussions and make a PR.

+1. Making the design of PNE less problematic for offload and other =
future optimizations won't solve the underlying requirements problem =
(i.e. we are both treating linkability among 5-tuple flows by a specific =
on-path device, the LB, as a requirement to support via CID, as well as =
a requirement to mitigate linkability among 5-tuple flows by a all =
generic on-path devices via PNE, which is inherently contradictory  =
without a very precise definition of under which circumstances which =
requirement takes precedence). But it will reduce the cost from =
"probably mostly harmless" to "almost definitely mostly harmless", which =
should make the decision easier.

Cheers,

Brian


>=20
> Cheers,
>=20
>=20
>=20
>> On 6 Apr 2018, at 2:41 am, Praveen Balasubramanian =
 wrote:
>>=20
>> Love this idea. Expanding it a bit further I don=E2=80=99t think we =
need to make PN transform a transport parameter but rather connection =
migration itself. We could also simply use QUIC versioning for this.
>>=20
>> 1. Ship QUIC v1 with no support for connection migration. Servers =
behind load balancers that are not QUIC aware will only advertise this =
version. I expect this to be a large fraction of servers especially =
those hosted in AWS, Azure, GCP. *This is important - I want the group =
to acknowledge that servers needs to be able to advertise support for =
connection migration*.
>> 2. Ship QUIC v2 with support for connection migration. If a client =
and server use this version they MUST do PNE as per #1079. If we find a =
more efficient scheme before November then we use that instead.
>>=20
>> Eventually we will ship QUIV vN which has support for multi-path and =
we can revisit if PNE is needed or multiple PN spaces will work. Until =
then I can live with higher CPU cost for the fraction of connections =
that will migrate.
>>=20
>> Now there is the ossification problem in QUIC v1 as referred to =
above. We already require a random starting PN. The next problem is one =
that Kazuho brought up where middleboxes will start seeing strict =
increasing PN and try to reorder. I was thinking about short random =
jumps to fix this problem but the monotonic increase will remain. While =
I think sane middleboxes will not do any reordering, there might be a =
few crazy outliers like with TCP. I think we can solve this by making =
the in clear PN jump both forward and back within a "reordering degree". =
I am thinking about some ideas here and will reply back if I find a =
simple scheme.
>>=20
>>>> FWIW, what I got from the info that Praveen and Ian have shared is =
that there are enough problems to solve with UDP that worrying about the =
performance hit from encryption is premature
>> Martin, we have plans to make UDP screaming fast in software. But the =
real advantage for TCP comes from the batch offloads (see email with =
subject " Impact of hardware offloads on network stack performance"). =
Batch offloads for QUIC are impossible to do without crypto offload. I =
would be happy to explain more on this front. I think we will exhaust =
software optimizations soon and then get blocked on crypto offload.
>>=20
>>=20
>> -----Original Message-----
>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson
>> Sent: Wednesday, April 4, 2018 9:36 PM
>> To: Kazuho Oku 
>> Cc: Lars Eggert ; Mark Nottingham ; =
IETF QUIC WG ; Patrick McManus 
>> Subject: Re: Getting to consensus on packet number encryption
>>=20
>> On Thu, Apr 5, 2018 at 10:57 AM, Kazuho Oku  =
wrote:
>>> It is true that #1079 has issues with hardware crypto offload. I am
>>> happy to support switching to a better encryption scheme (if we find
>>> one) at any moment; e.g., during the standardization of QUICv1, or =
as
>>> an extension to v1, or part of vX.
>>=20
>> Until this came up, I hadn't considered the use of an =
extension/transport parameter to negotiate a new scheme, but it's =
obvious.  This fits best with my view of things.
>>=20
>> If that means that we get the DC-QUIC option that turns the packet =
number encryption function into identity or some cheaper function, then =
I think that's an OK outcome.  We should stop pretending that one size =
fits all is achievable; it's not been the case for years already.
>>=20
>> FWIW, what I got from the info that Praveen and Ian have shared is =
that there are enough problems to solve with UDP that worrying about the =
performance hit from encryption is premature.
>>=20
>=20
> --
> Mark Nottingham   https://www.mnot.net/
>=20


--Apple-Mail=_95AE2A92-59EC-47D4-93A8-C9921FA33760
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-----

iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlrLJgUACgkQihK3vwvq
RqPaHQ/8DUoRDmsdWsDl5NtXg2LfVgz034ssaYzhypoTEmKyn9etQgB7HBvDuOxU
6rBj9x/Wq0aFQomg7+bP3YYDQmmsfc4/3mq0/38gfPIv8S3EovhzyJulK0CrzZku
G6bdHw18x/k8i6k0vRg0RXizAQnfZlxLS82P6Od65MHDF+p/6g2wLx2ASLs4k1pE
eOJuHQ/XkAMSHk46IQd+JA35r4d12Eaf/WPkeBsvWWOHwvZ+NM1Mle87BFE3T3z6
h6JWdyez3PU9Crll3Lxvm68dSCT9R/IeERXCOTF+gqg2o5OKbEch1NgmM1BUkxlB
ehHqp170gPCcVp99yQj6fg/e89o5YJibFOgXzjqICzsMq572LrM5ZWyPWmP9lKh2
C/arZPHSowimsVaZ8r85lfb9qw8GU1qgad5mdLy1ylXaMBVCZh+rofyrzLs/Ymb2
haUcZgQH0H9kcSmRPkzVno9STDiOVF2kW2gl9+H01c440D0Z3j85kIybTCicMeIh
qixZaPBwNBR1MGnNsPXjr7c3gjGmymAIUa+wUepwqo02mOUeYCHuy8z9J90gi5VF
IJZRVTOg9dOW7HiAUY4yHwEDdqARmUjzcxMFdDCmvFkf6TRCgriajkoG202zCc/4
ojVdWCfy2NMuSrB9Pp39DD2MHrkYMidlyc4YdfqhtIohMtYwAF0=
=dk3/
-----END PGP SIGNATURE-----

--Apple-Mail=_95AE2A92-59EC-47D4-93A8-C9921FA33760--


From nobody Mon Apr  9 01:42:15 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6936D127419 for ; Mon,  9 Apr 2018 01:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgYrfxPkecyJ for ; Mon,  9 Apr 2018 01:42:10 -0700 (PDT)
Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 8445D126C19 for ; Mon,  9 Apr 2018 01:42:10 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,426,1517871600";  d="scan'208";a="7894410"
Received: from thorgal.eurecom.fr ([10.3.2.220]) by drago2i.eurecom.fr with ESMTP; 09 Apr 2018 10:42:09 +0200
Received: (from apache@localhost) by thorgal.eurecom.fr (8.14.4+Sun/8.14.4/Submit) id w398g8H1021679; Mon, 9 Apr 2018 10:42:08 +0200 (CEST)
X-Authentication-Warning: thorgal.eurecom.fr: apache set sender to otilibil@eurecom.fr using -f
Received: from reverse.completel.net (reverse.completel.net [92.103.89.82]) by webmail.eurecom.fr (Horde MIME library) with HTTP; Mon, 09 Apr 2018 10:42:08 +0200
Message-ID: <20180409104208.qwe4ab3s8woowgsc@webmail.eurecom.fr>
Date: Mon, 09 Apr 2018 10:42:08 +0200
From: Ariel Otilibili Anieli 
To: Mikkel =?utf-8?b?RmFobsO4ZSA=?= =?utf-8?b?SsO4cmdlbnNlbg==?= , Lucas Pardue , Martin Thomson , Jana Iyengar , "Martin J. =?utf-8?b?RMO8cnN0?=" 
Cc: QUIC WG 
Subject: RE: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>  <0c2bbb1f-af3c-e196-3605-db9458936a42@it.aoyama.ac.jp> <20180409090233.hxlqgu1wqo0o04c0@webmail.eurecom.fr>  <7CF7F94CB496BF4FAB1676F375F9666A3BB22349@bgb01xud1012> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)
X-Originating-IP: 92.103.89.82
X-Remote-Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 08:42:13 -0000

Hi,

My comments inline.

Regards,
Ariel

Quoting Mikkel Fahn=C3=B8e J=C3=B8rgensen :

> http://fortune.com/2018/02/23/kfc-chicken-shortage-apology/
>
> I guess the equivalent would be to write ICUQ when running out of UDP
> packets.
>
> Mikkel
>
> On 9 April 2018 at 10.26.22, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote:
>
> In day to day talk I tell people that QUIC is the KFC of transport
> protocols, and has similar levels of GREASE.
I will propose a pull request: "QUIC used to be known as 'Quick UDP =20
Internet Connections', but the present RFC advises it be used no more: =20
QUIC does not stand for an acronym".

What do you think?
>
> Lucas
>



----------------------------------------------------------------------------=
---
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


From nobody Mon Apr  9 02:11:59 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DFA12783A for ; Mon,  9 Apr 2018 02:11:57 -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 (1024-bit key) header.d=itaoyama.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 AlT_dMdFBs4W for ; Mon,  9 Apr 2018 02:11:52 -0700 (PDT)
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0105.outbound.protection.outlook.com [104.47.93.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF8A127775 for ; Mon,  9 Apr 2018 02:11:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FBSo8bRUXEHk5i2PhRIuW/11qs8idzMQlmviBP0020w=; b=E/GfRgx7nOSWQkuWlpzsP2bLNBgZ8DKgN6aSOibRJtHernjETmwdArZfJqjdcQXRzuQHB7IsReKdChVZaDTl1hxSQYMTOeOG2FazCYJiA+L1OdnH1A9eL6uj/s12jwPBeRgsUmwBHhOyc3LZ0rFh/2hTSPPwh6gmwPQz5FtkGTg=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; 
Received: from [133.2.210.64] (133.2.210.64) by OSBPR01MB1541.jpnprd01.prod.outlook.com (2603:1096:603:3::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Mon, 9 Apr 2018 09:11:46 +0000
Subject: Re: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
To: Ariel Otilibili Anieli , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , Lucas Pardue , Martin Thomson , Jana Iyengar 
Cc: QUIC WG 
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>  <0c2bbb1f-af3c-e196-3605-db9458936a42@it.aoyama.ac.jp> <20180409090233.hxlqgu1wqo0o04c0@webmail.eurecom.fr>  <7CF7F94CB496BF4FAB1676F375F9666A3BB22349@bgb01xud1012>  <20180409104208.qwe4ab3s8woowgsc@webmail.eurecom.fr>
From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: <49c3e44b-4e61-b2d8-0059-ab4310bd474a@it.aoyama.ac.jp>
Date: Mon, 9 Apr 2018 18:11:46 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180409104208.qwe4ab3s8woowgsc@webmail.eurecom.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [133.2.210.64]
X-ClientProxiedBy: OSAPR01CA0013.jpnprd01.prod.outlook.com (2603:1096:603:2a::25) To OSBPR01MB1541.jpnprd01.prod.outlook.com (2603:1096:603:3::16)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: cbe2e2a1-c2fd-43d5-e421-08d59df9eb92
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB1541; 
X-Microsoft-Exchange-Diagnostics: 1; OSBPR01MB1541; 3:fOoQKjoDlQ7h/WW33kJ9rNyWSJ8PXkdXHYMRSvUXGeEmZpdE9Tf6vFpR7TQ19iuyxi/WBNDOSns+mPNr5/85/woIFdqe+HQ/f6oSTUtBMOy0D6C/gdii1SV1DUk49aopJskiBwlVhMoYmy/A9EoX9vMNnMlB7k0ahMOlpwKJrSrHOKGm8s2ZDvoyuO+AvoFNn2SCvri4pc0F/sIBNi4mZTl2dD4sM8Yd9YpQVtOJyyMOGqBewIz1QxT84L4qjytK; 25:8+9UKK3yuOUt8IIxFRtsL6lxNM4i3pobD9I/LueO/jRv3NPH3C1ByN73gcy3NngsDDk2H/II/Z73Q/UFJgs4ahPG4BlnNTWKuW5jCvM8tcfhwvBXd6asJEYO0TumMQeGJA9q3/iP+2OHdRja6AYaQu21iQaSYa5PeZOW0osnN/Dndz6Q3E2X5UTRaI0pYcwaEX5yHZTELkv8Uqu0/9+W2HBQRVZ679P3y3J85kVAu1eCn9tdpAy87ipO2EeLLEvoxD0nvognNV/aBXlTNlRxGBBYUVcpT5bKoBHHbs/aG9cKv+HhFo40HWvn+U3tbrRwDu7veCfaV2b37XxMqFxUAQ==; 31:Xeoa1c5mQTK7cS2aeoIeju40BLPMqC5BTuMgfYEI7U+GwZ9f1Vk2DZhhYCdzSouapK6GM+7Exxpkc7gUDGnoEed0uceCBtiEeL8vYWPrKLDGP1ZXfoy0r5+MOirB3KaZzSRJn68ACwqLp0HXVn7Qa4kh8TXdJung5noBx+BmvEQfpH+QpXNtAetHXnjBW0cUoP5iSy0WTsPOe2yLU/q2HIXYEEg+2O1LD5YQgkq0VR8=
X-MS-TrafficTypeDiagnostic: OSBPR01MB1541:
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231221)(944501327)(52105095)(10201501046)(6041310)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:OSBPR01MB1541; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB1541; 
X-Microsoft-Exchange-Diagnostics: 1; OSBPR01MB1541; 4:CUP8KnExTyahic/WDTtQ+oQ1di8Txt8KCkMnTp8Fp1dmfXHtoQV7Ww3uIXZR4ANy9ASh2uJqLe3pdQ0ybGyq9ZtohxBJ4iv3w7VDueImRuqPxuBTM/65sZIbqrdOAwtJtH+s6hGpylOGi7+CB7jCiC4DTr7o/yFqMKvcf27gPBz3HyQfxdI4/5wwJtkFFy65umWMIlHyNeagqaPmRgtRdGC3NzmlzTDWPRU0BQrol9BIRaGFHY7yzOhMGCI7kAvYYq1Ov4Fj0cLlUBywMlXREQ==
X-Forefront-PRVS: 0637FCE711
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(396003)(39380400002)(346002)(376002)(366004)(39840400004)(199004)(189003)(64126003)(5660300001)(229853002)(65826007)(26005)(478600001)(68736007)(8676002)(8936002)(86362001)(31686004)(3846002)(81166006)(81156014)(31696002)(305945005)(786003)(93886005)(186003)(16576012)(25786009)(4326008)(110136005)(7736002)(316002)(446003)(2616005)(956004)(11346002)(476003)(6246003)(36916002)(2486003)(52146003)(23676004)(97736004)(39060400002)(486006)(59450400001)(49976009)(67846002)(230700001)(2906002)(53936002)(76176011)(58126008)(6486002)(16526019)(6116002)(50466002)(105586002)(106356001)(47776003)(386003)(52116002)(66066001)(53546011)(74482002)(65956001)(65806001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OSBPR01MB1541; H:[133.2.210.64]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU0JQUjAxTUIxNTQxOzIzOkhVUXBRaWUwb2pSSzdSd0h3ajdaTk14NmlO?= =?utf-8?B?K2RpWk1EZkpXWlNHL01OdXQ1VEZlL0I5cVQ5S1N3U2pyMGhOZWRGQTFKM2V3?= =?utf-8?B?aG8wR2NOeVhUY2hPazNRUld2dmFaWUt0SFV3ZkFta2hXUDNibHhKcUdjODBj?= =?utf-8?B?b2ZSZnNEL3hNOUE4a2xqdGd4bURESUdUK1M0Vmd1c1B3SHA3b3JqaXAwZ2R1?= =?utf-8?B?MWc2ZmNGa0dFNDNvck1mVm92Y3luR3E2SnBQYUVsSzJGVmNLeml2QTN0RDVT?= =?utf-8?B?dXRYVzRIT0UrNFBLbno4Q2hhTWJNMGdKZDFvQWxKOVA2M3RzWlZuZ3YrQ25G?= =?utf-8?B?YkpzMkxCOVRmTGJ5TExhdm1SVVQ0RXk5ZEZCQzhnTDBrWjY5VUI1bGVRdlY5?= =?utf-8?B?WHlrWG9uOUZBbFcwVDJ2bFRLNzZWdStvSDZ6TVJQY2tqeWxFVWc3LzhQbDdk?= =?utf-8?B?SGJlem5nQk9pU1laQmgydGJiRFFxTkpOdDJJN1dFaUx3NmZLWUdKT0V3VXNM?= =?utf-8?B?U3pKR0RDZ29leTd6TGVjSEpjSXVMUldmVHZqaXVCckxzWmtJVHM5UzdwTkpa?= =?utf-8?B?YVlBOEhqTzlldlZ1SHU0NTRvWk5NazNNWmsrSHBXMU5WcTUzS0U3THJkL3c4?= =?utf-8?B?anZQWndDNmpMcjJVY3ZpL25PTnhWS0k3bzh2V3VCU2xMeENQWUNzb3AyMXF6?= =?utf-8?B?NzZIak1rSldVMWxOS1NFM3o0VThVNHBIcXB4Z3h4RzlJbVhSMjhmaFR5OUVF?= =?utf-8?B?Y0ZiRzI2WVJaekZ2T09TQUN0VG1CNEx5TkZyaC92UFMrZUFINFFBdEdxdTdw?= =?utf-8?B?VGJ4ejRyYXZxUjBab3pMb0RkZlY4ODY5bU4xYS9OWHgxNVRHUm1BYVByL0dz?= =?utf-8?B?OElTRG8zZGdPVFpzZnA5M3pyVHZlaFRpS1pRV0tNbDIxRlJ3UlgrU3FZRFo2?= =?utf-8?B?L0ppemtkUmY2ZDBaRFVzUVV0cSs1T2ZzV0c5UWxBWElWVGdZSCtES2lieFJy?= =?utf-8?B?L3ROK0RWTlVjb2xHck4ya1N0TkZuNGt5ZkgyczdtQ3dlWWNuQk5GczE2NG8z?= =?utf-8?B?MmJqSWhVQk1acFp1cko3aUtVT2hReXEyOWFoNW15VmltSHV4NGtlVk1JeC9C?= =?utf-8?B?UkR3c3J1L21rdlRSNmJPVVdZT0pNUk5JSDFCRUVLQ3BTTHVDWFE3U0hSNlpU?= =?utf-8?B?dC8ybEpPQ0s3ZG1RZ1ZsV2hZZGcxUU9XenJUUnlKTi9udm90RUFCWWRjYjN1?= =?utf-8?B?LzFKZVdZekJxVTRlYVdjQWdCWGQzMDB5VUFRWkJKdWNoNnVGaWxmWXczZU9L?= =?utf-8?B?dklmWXovQ01wNEJLZ3pyWUcwR3Nmb2hhN2VURjRCOGdQQld2SlN0UDBGTEVD?= =?utf-8?B?OUMyYjVEbnBpTUMyeUMyT3pmL2h5YWNlRVZmSWFuMG5JSXk0ZHFQZXNuUlc0?= =?utf-8?B?U0RuQUVLakJLbktpSERnRTMyb3Fjclh3MUVTK1BXM1NIaHNrVjZZS09XT3gv?= =?utf-8?B?MmJIc0RhK0ZKU3VIZDNmbXZnZHVLWXJ1TEtINHIvUHVsK0xUQitOUStUTGxQ?= =?utf-8?B?d0xtZG8rbHNvcWlQeXFsNFc3UHJYcGltYjdIRzA2VUFIYWJ4VUU5TnpTYm9X?= =?utf-8?B?V2grdU9SMHJmM1NLek1qdXFPdU0ycm1EVVVOSmNxT0duQjBoOXJwRU5XbXp6?= =?utf-8?B?dEJKVFErWUlDdklrTVVGYjg4Q3luSjdhdVdnejZiT0ZZQjBVQXVuVzFoL0JE?= =?utf-8?B?T1NjeFRuY29HeXc0allRWlFXQk12b2NyaDhDTEhpTVNDVXV2T2xhUkI0Q1RF?= =?utf-8?B?Tk9ocHA4SnhzRjVRYzYza25HQmVSQk1hSXdkUHBxNm9reEdsYS9rdWdMQ0NN?= =?utf-8?B?bDR0S1M3enVvaCtxRldRZ2s3dU8yMXlkbFVlbmYrY0VVNnhYVk9MUkFhMVBo?= =?utf-8?B?aDl0SXhxSmtaangzeE9qcnVGdm4vVmVlR0pHYUwrT0JVbXl6YmozWGVMdWtw?= =?utf-8?B?YkhsZkgvWHB1MzNtMFlISmdqcEp3YVZRdHdiNVFoc05oVWkwR3ZXalpiSS9U?= =?utf-8?B?YXVudjhDczdNNEFYUTBxUEFjT3h0THFQV0IxZlh6WjlKMEpudy9Zd25BdzdR?= =?utf-8?B?bVE9PQ==?=
X-Microsoft-Antispam-Message-Info: fp+kTM/wt0DUP7l2xiNu9q9YdqpdzwPbqYCnF2DN2GhnOAifxi+Cng1SUTUpjVP/l8CK1tU0sxfCpL+CzBB64qW9NSc8nIFcKlUeQPO7HZFC7HgD9hDxAjRpyJ07GYKZGmIQBCuX031estmhF7vNVt7dsUGLSZL7SCbs6yX107UpDsvGpvfPot7LkPg2P3jO
X-Microsoft-Exchange-Diagnostics: 1; OSBPR01MB1541; 6:uXBrDP5TRea/S6LFmXgtyAdMOPZwdB9npO1JGTAdRNCD5yDhctW8tbWXuS6UbGIAjIpmFavK4Wn7s4aODhkIeaGeVqaXwDMrHjm9U8n9bgn+ENPrvp6FkwXg2g7MG1JTOqjnHtrlqB9G3Ex/lFHmalcDDWXJmslmDiRwW66Xl+NHQ0qKtdNBSvuPmamAxOzXpfCRmWw7WJxPrHWgi+xA03NZusbHppp18+dkvgA5pGPZ4C6qWuNt5WnjqoryM3f4UDrj6tyUVQaLtMlaH3BKJpqZgQKigtx5QSl+A2HnSudPXGQ1Psc/y5i+lxavltGMijjU71PUMfUgMJuHTrmenz7XWgVMRb/Tr/qZWBtVsrJe0gIhh6wYkDWhlza8AqrjjlZ3Fuz68LOc5I7dN0k/wmbCqDhAu+p+ogzvomkrj5PRHP5eJJown/wNzwupXY4BDRh6lu1TB9/jgMDlFQ/6Fg==; 5:Yh0r2fFylp2kaUDeTzRBPfDdlMNjxJaUKL+bQkPVrvYDc9Y6tCGjavyFS53vZmkglnLpRtfr2kEOhIrbkgV6FH263/Y/yoFPEZwUDhc2WC8lnc2BR3ZoyC6tKffSMfn0EYHUONX3RHHaDCs5vyjKC+gseqIW3gXwzXqoB/dkltA=; 24:mCcpyR2uB02qFQLvf6DZDHxhkMw3H6ROJJ0YxOpq3wmTJJKwXuT2T6jb6rpv8nlQpc7/gDyG5TboOjjYJ8a5chhiS7T7b9DPKtJlhWDySdY=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; OSBPR01MB1541; 7:0eCXttUtGgFH+gNqNds8W2oDTYz0FphP4MTNcwXURlDpIJLpINNbjXGKx5g6SOH4K5pF3Wwj6m/d4CqsrUZs5plKaa/e363B/uXCjgLtu13CMXbfh4sfNI1XdqXwt8+7zwluztKxcI8Fw1XRiZBUBJhZD9zyxbyfr/Q9MRsR+vL02mc4ognZy/WTL0/UfWdaZIVz9iQhgsENcu7Hlb8JW7snw2nTJ7ZYd4dAcsbJ3geVAiV+R9q2lVof/Su17i38
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2018 09:11:46.5451 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cbe2e2a1-c2fd-43d5-e421-08d59df9eb92
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB1541
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 09:11:57 -0000

On 2018/04/09 17:42, Ariel Otilibili Anieli wrote:

> I will propose a pull request: "QUIC used to be known as 'Quick UDP 
> Internet Connections', but the present RFC advises it be used no more: 
> QUIC does not stand for an acronym".

"QUIC does not stand for an acronym" -> "QUIC is not an acronym" and/or 
"QUIC does not stand for anything".

Regards,   Martin.


From nobody Mon Apr  9 02:24:11 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C291276AF for ; Mon,  9 Apr 2018 02:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWDF66BPheZm for ; Mon,  9 Apr 2018 02:24:07 -0700 (PDT)
Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1D346124234 for ; Mon,  9 Apr 2018 02:24:06 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,426,1517871600";  d="scan'208";a="7894603"
Received: from thorgal.eurecom.fr ([10.3.2.220]) by drago2i.eurecom.fr with ESMTP; 09 Apr 2018 11:24:06 +0200
Received: (from apache@localhost) by thorgal.eurecom.fr (8.14.4+Sun/8.14.4/Submit) id w399O5rw021867; Mon, 9 Apr 2018 11:24:05 +0200 (CEST)
X-Authentication-Warning: thorgal.eurecom.fr: apache set sender to otilibil@eurecom.fr using -f
Received: from reverse.completel.net (reverse.completel.net [92.103.89.82]) by webmail.eurecom.fr (Horde MIME library) with HTTP; Mon, 09 Apr 2018 11:24:05 +0200
Message-ID: <20180409112405.ba37t74psgw8840w@webmail.eurecom.fr>
Date: Mon, 09 Apr 2018 11:24:05 +0200
From: Ariel Otilibili Anieli 
To: "Martin J. =?utf-8?b?RMO8cnN0?=" , Mikkel =?utf-8?b?RmFobsO4ZSA=?= =?utf-8?b?SsO4cmdlbnNlbg==?= , Lucas Pardue , Martin Thomson , Jana Iyengar 
Cc: QUIC WG 
Subject: Re: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>  <0c2bbb1f-af3c-e196-3605-db9458936a42@it.aoyama.ac.jp> <20180409090233.hxlqgu1wqo0o04c0@webmail.eurecom.fr>  <7CF7F94CB496BF4FAB1676F375F9666A3BB22349@bgb01xud1012>  <20180409104208.qwe4ab3s8woowgsc@webmail.eurecom.fr> <49c3e44b-4e61-b2d8-0059-ab4310bd474a@it.aoyama.ac.jp>
In-Reply-To: <49c3e44b-4e61-b2d8-0059-ab4310bd474a@it.aoyama.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)
X-Originating-IP: 92.103.89.82
X-Remote-Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 09:24:09 -0000

Hi all,

Inline the pull request I will propose in the Introduction. Does =20
everyone agree with it?

Regards,
Ariel

Quoting "Martin J. D=C3=BCrst" :

> On 2018/04/09 17:42, Ariel Otilibili Anieli wrote:
>
>> I will propose a pull request: "QUIC used to be known as 'Quick UDP =20
>>  Internet Connections', but the present RFC advises it be used no  =20
>> more: QUIC does not stand for an acronym".
>
> "QUIC does not stand for an acronym" -> "QUIC is not an acronym" and/or
> "QUIC does not stand for anything".
Fixed: "QUIC is not an acronym: it does not stand for anything."
>
> Regards,   Martin.



----------------------------------------------------------------------------=
---
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


From nobody Mon Apr  9 09:43:55 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662A212D77A for ; Mon,  9 Apr 2018 09:43: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=[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 jBUshUtGDLDT for ; Mon,  9 Apr 2018 09:43: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 3768012D777 for ; Mon,  9 Apr 2018 09:43:52 -0700 (PDT)
Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx60.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1f5ZtU-000FlW-3D for quic@ietf.org; Mon, 09 Apr 2018 18:43:50 +0200
Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1f5ZtQ-0001rt-JR for quic@ietf.org; Mon, 09 Apr 2018 12:43:45 -0400
Received: (qmail 21677 invoked from network); 9 Apr 2018 16:43:40 -0000
Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.61]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Apr 2018 16:43:40 -0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Christian Huitema 
X-Mailer: iPhone Mail (15D100)
In-Reply-To: <20180409112405.ba37t74psgw8840w@webmail.eurecom.fr>
Date: Mon, 9 Apr 2018 09:43:38 -0700
Cc: =?utf-8?Q?"Martin_J._D=C3=BCrst"?= , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Lucas Pardue , Martin Thomson , Jana Iyengar , QUIC WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <20ED4DA3-F688-42BE-ABD8-FDC97FC1D26D@huitema.net>
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>  <0c2bbb1f-af3c-e196-3605-db9458936a42@it.aoyama.ac.jp> <20180409090233.hxlqgu1wqo0o04c0@webmail.eurecom.fr>  <7CF7F94CB496BF4FAB1676F375F9666A3BB22349@bgb01xud1012>  <20180409104208.qwe4ab3s8woowgsc@webmail.eurecom.fr> <49c3e44b-4e61-b2d8-0059-ab4310bd474a@it.aoyama.ac.jp> <20180409112405.ba37t74psgw8840w@webmail.eurecom.fr>
To: Ariel Otilibili Anieli 
Subject: Re: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
X-Originating-IP: 168.144.250.234
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.18)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5hyqkp4a8DvguduhhF4ZeJN602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVio1HEuyN83VD1ujmZV0zqCs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB6b6XZpNC1wnpsGpZepb/px/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpX8nIu6prlMU9qLY4Lxa6TDEUDpzUh97nbRBafHFU0M5cJ9Mzv+g54q kQltgJYTLEiO98fck6astPPFccqiLCixm7xl+RQ3vIZqfBpLwZArl3I1g+tBSv0B+cgW7VoPEiDI +8QkA7WZKXURE/tHtZ/u0KOJrIKT6Yz+kw/sINDgmVhNqyux1yaQvYroLJ1yFFq84+OHMz/cWp3h cOTrnvEhQZs4iXA/pTuddAL2KCGOjKaoYeoLX/yEBEWAApw66Tq3t9PKqfIkYUDuwnGn3d4uZhUF HKbUZMv7c3cOU/0VErE2BJ6+Ocmt1JPBpwCeIwTbMcctPzMPLiqwr8e+aie3zxvdN0leIxaNIjs7 cbPZdZnckpWaLvahyBjmQxBKOztcoEJy5JI/WnEUTEvEJGtKRioNM4YdAO5dQww9T9HjAWtJl6pO HngTL5HKgxzCo5M=
X-Report-Abuse-To: spam@quarantine6.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, 09 Apr 2018 16:43:54 -0000

I would drop the part about past backronym. If you repeat it, you perpetuate=
 it. If you want history, you have to explain the lineage from FAST    to QU=
IC, and an RFC is not the place to do that.

-- Christian Huitema=20

> On Apr 9, 2018, at 2:24 AM, Ariel Otilibili Anieli  w=
rote:
>=20
> Hi all,
>=20
> Inline the pull request I will propose in the Introduction. Does everyone a=
gree with it?
>=20
> Regards,
> Ariel
>=20
> Quoting "Martin J. D=C3=BCrst" :
>=20
>>> On 2018/04/09 17:42, Ariel Otilibili Anieli wrote:
>>>=20
>>> I will propose a pull request: "QUIC used to be known as 'Quick UDP  Int=
ernet Connections', but the present RFC advises it be used no  more: QUIC do=
es not stand for an acronym".
>>=20
>> "QUIC does not stand for an acronym" -> "QUIC is not an acronym" and/or
>> "QUIC does not stand for anything".
> Fixed: "QUIC is not an acronym: it does not stand for anything."
>>=20
>> Regards,   Martin.
>=20
>=20
>=20
> --------------------------------------------------------------------------=
-----
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>=20


From nobody Mon Apr  9 13:20:26 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797DE124D37 for ; Mon,  9 Apr 2018 13:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.81
X-Spam-Level: 
X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNBEEK1tgN9R for ; Mon,  9 Apr 2018 13:20:22 -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 3CC7A12422F for ; Mon,  9 Apr 2018 13:20:22 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id b20so11149805iof.5 for ; Mon, 09 Apr 2018 13:20:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sZ7yrpGvLPBZKe/m93WCvRlaFe8bDqPPNDWSYvVFOVE=; b=QZHkPDaylZDi9RLmSJqWOaYCGRCHnpSYCYuAHVE6MtwXC43nBOx8ydudNQFZ7jMZR8 xQKeKTUoc+EK9DVUesPJ5fGcRLnh63hXzudk/B6oZvaATXhELywgv87w7L4cK3DKeTRr UuVhavR8UvMX4MsOrpnhdo+JsKW5GHBG2e2RLsNmLU6AbNDICF8p2ZlTB7vU7vG9CF4e tDW8sVOfo8SHV6AwO205PNZ99qLhbs6FH1UyhuNlGu5l3GagIillYVJ+gW7fjNit8XR8 wuNFXvBCuqZWD8PErL+1veK516rNMCutUsXI+z/cRxRA3PwH1Bd5LPJ7VO9EU8DcwYJp mnPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sZ7yrpGvLPBZKe/m93WCvRlaFe8bDqPPNDWSYvVFOVE=; b=SguqNtA26wxUA5mOWNShKpb4yU0GmFxW7bTQFXoc0QQKlyY/o6QHcS3mWvwxOI1PzU Ym3ol0zk0VJsZYopqm2W9fAMApcS/uWJDzJTdH+MeXlkNxwPpwqKzPtDtQAHUMmc6ABF 2QArHFyJT7FmL7y8Z8d0xEVCHxVWTRJpWFXaCghr5sdSC/JTRDqdRqcCL/MhUl3IE7hc zA4vA8LJFVNGeZpaRbFKpDkFBaVTKVOS9DHbJ97/9icw/n/eWdpccDiCsXD6FfM1wm9E xbsNHIOT/ZGNUrTfb7tnePwOPFqIJUHlxnuk9xXdcAZju0+YTCehDPhLAmXbA3XDUKbA Mv4Q==
X-Gm-Message-State: ALQs6tD3kFJQwQmhpVg7hVfh4WM/4Oyl4jmNpP2BNgja2yTmUQUc+7kO RSB0P3knDdHEpV8hirghRxpjW3fs2kNUXo4FYYfCxQ==
X-Google-Smtp-Source: AIpwx4+7vew9dwtEPcBfeEN9hpZnISQuZuVRvt4aNLJkDBEq1gDW7qCHoL7SVMbjoimbuafqhw6Ap3B/xRJ5qd64SJQ=
X-Received: by 10.107.131.83 with SMTP id f80mr476330iod.102.1523305221127; Mon, 09 Apr 2018 13:20:21 -0700 (PDT)
MIME-Version: 1.0
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>     <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net>     <9BCB9BA5-A282-445A-B7A1-8F7C539C28F9@mnot.net> <37129F6C-71C2-437D-A6F4-7AC651FDFBE3@trammell.ch>
In-Reply-To: <37129F6C-71C2-437D-A6F4-7AC651FDFBE3@trammell.ch>
From: Ian Swett 
Date: Mon, 09 Apr 2018 20:20:09 +0000
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Brian Trammell 
Cc: Mark Nottingham , Praveen Balasubramanian ,  Patrick McManus , Lars Eggert , IETF QUIC WG ,  Martin Thomson , Kazuho Oku 
Content-Type: multipart/alternative; boundary="001a113f998a97cddf0569702273"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 20:20:25 -0000

--001a113f998a97cddf0569702273
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 9, 2018 at 4:36 AM Brian Trammell (IETF) 
wrote:

> hi Mark, all,
>
> > On 9 Apr 2018, at 04:54, Mark Nottingham  wrote:
> >
> > Praveen,
> >
> > In previous discussions, there's been strong interest in including
> connection migration -- in a limited form (for the "parking lot" use case=
)
> -- in QUICv1 (discussed in Melbourne in some detail; see <
> https://github.com/quicwg/wg-materials/blob/master/interim-18-01/minutes.=
md#connection-migration
> >).
> >
> > It looks like the discussion in <
> https://github.com/quicwg/base-drafts/issues/1271> about making it
> optional and how that gets indicated / negotiated is going nicely. Thanks
> for opening an issue.
> >
> > AFAICT, (at least) two assumptions need to be proven to have that help
> the PNE issue:
> >
> > a) There isn't a linkability issue during NAT rebinding
>
> Isn't the question we should be asking here "does QUIC with connection
> migration disabled (and no PNE) have similar linkability characteristics =
to
> QUIC with connection migration enabled (and PNE)?"?
>
> I'm still confused as to how PNE is supposed to mitigate linkability
> across a NAT rebinding that occurs without client knowledge in the presen=
ce
> of a server-supplied CID, which seems to me to be the most common NAT
> rebinding event type. If it indeed does not, then the linkability
> characteristics seem identical to me.
>

Agreed.  It would only be non-identical in the case of 0 byte connection
IDs, which I don't believe anyone expects to be common from client to
server.

>
> >
> > b) Having two packet number schemes is acceptable to implementers (give=
n
> the probable popularity of migration)
> >
> > I haven't yet seen much discussion of either of these specific aspects.
> >
> > As an aside -- the other threads about modifications to PNE to make the=
m
> single-pass seem extremely promising; I'd encourage folks there to contin=
ue
> discussions and make a PR.
>
> +1. Making the design of PNE less problematic for offload and other futur=
e
> optimizations won't solve the underlying requirements problem (i.e. we ar=
e
> both treating linkability among 5-tuple flows by a specific on-path devic=
e,
> the LB, as a requirement to support via CID, as well as a requirement to
> mitigate linkability among 5-tuple flows by a all generic on-path devices
> via PNE, which is inherently contradictory  without a very precise
> definition of under which circumstances which requirement takes
> precedence). But it will reduce the cost from "probably mostly harmless" =
to
> "almost definitely mostly harmless", which should make the decision easie=
r.
>
> Cheers,
>
> Brian
>
>
> >
> > Cheers,
> >
> >
> >
> >> On 6 Apr 2018, at 2:41 am, Praveen Balasubramanian  40microsoft.com@dmarc.ietf.org> wrote:
> >>
> >> Love this idea. Expanding it a bit further I don=E2=80=99t think we ne=
ed to
> make PN transform a transport parameter but rather connection migration
> itself. We could also simply use QUIC versioning for this.
> >>
> >> 1. Ship QUIC v1 with no support for connection migration. Servers
> behind load balancers that are not QUIC aware will only advertise this
> version. I expect this to be a large fraction of servers especially those
> hosted in AWS, Azure, GCP. *This is important - I want the group to
> acknowledge that servers needs to be able to advertise support for
> connection migration*.
> >> 2. Ship QUIC v2 with support for connection migration. If a client and
> server use this version they MUST do PNE as per #1079. If we find a more
> efficient scheme before November then we use that instead.
> >>
> >> Eventually we will ship QUIV vN which has support for multi-path and w=
e
> can revisit if PNE is needed or multiple PN spaces will work. Until then =
I
> can live with higher CPU cost for the fraction of connections that will
> migrate.
> >>
> >> Now there is the ossification problem in QUIC v1 as referred to above.
> We already require a random starting PN. The next problem is one that
> Kazuho brought up where middleboxes will start seeing strict increasing P=
N
> and try to reorder. I was thinking about short random jumps to fix this
> problem but the monotonic increase will remain. While I think sane
> middleboxes will not do any reordering, there might be a few crazy outlie=
rs
> like with TCP. I think we can solve this by making the in clear PN jump
> both forward and back within a "reordering degree". I am thinking about
> some ideas here and will reply back if I find a simple scheme.
> >>
> >>>> FWIW, what I got from the info that Praveen and Ian have shared is
> that there are enough problems to solve with UDP that worrying about the
> performance hit from encryption is premature
> >> Martin, we have plans to make UDP screaming fast in software. But the
> real advantage for TCP comes from the batch offloads (see email with
> subject " Impact of hardware offloads on network stack performance"). Bat=
ch
> offloads for QUIC are impossible to do without crypto offload. I would be
> happy to explain more on this front. I think we will exhaust software
> optimizations soon and then get blocked on crypto offload.
> >>
> >>
> >> -----Original Message-----
> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson
> >> Sent: Wednesday, April 4, 2018 9:36 PM
> >> To: Kazuho Oku 
> >> Cc: Lars Eggert ; Mark Nottingham ;
> IETF QUIC WG ; Patrick McManus 
> >> Subject: Re: Getting to consensus on packet number encryption
> >>
> >> On Thu, Apr 5, 2018 at 10:57 AM, Kazuho Oku 
> wrote:
> >>> It is true that #1079 has issues with hardware crypto offload. I am
> >>> happy to support switching to a better encryption scheme (if we find
> >>> one) at any moment; e.g., during the standardization of QUICv1, or as
> >>> an extension to v1, or part of vX.
> >>
> >> Until this came up, I hadn't considered the use of an
> extension/transport parameter to negotiate a new scheme, but it's obvious=
.
> This fits best with my view of things.
> >>
> >> If that means that we get the DC-QUIC option that turns the packet
> number encryption function into identity or some cheaper function, then I
> think that's an OK outcome.  We should stop pretending that one size fits
> all is achievable; it's not been the case for years already.
> >>
> >> FWIW, what I got from the info that Praveen and Ian have shared is tha=
t
> there are enough problems to solve with UDP that worrying about the
> performance hit from encryption is premature.
> >>
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
>
>

--001a113f998a97cddf0569702273
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon=
, Apr 9, 2018 at 4:36 AM Brian Trammell (IETF) <ietf@trammell.ch> wrote:
hi Mark, all,



> On 9 Apr 2018, at 04:54, Mark Nottingham <mnot@mnot.net> wrote:

>

> Praveen,

>

> In previous discussions, there's been strong interest in including=
 connection migration -- in a limited form (for the "parking lot"=
 use case) -- in QUICv1 (discussed in Melbourne in some detail; see <https:/=
/github.com/quicwg/wg-materials/blob/master/interim-18-01/minutes.md#connec=
tion-migration>).

>

> It looks like the discussion in <https://gi=
thub.com/quicwg/base-drafts/issues/1271> about making it optional an=
d how that gets indicated / negotiated is going nicely. Thanks for opening =
an issue.

>

> AFAICT, (at least) two assumptions need to be proven to have that help=
 the PNE issue:

>

> a) There isn't a linkability issue during NAT rebinding



Isn't the question we should be asking here "does QUIC with connec=
tion migration disabled (and no PNE) have similar linkability characteristi=
cs to QUIC with connection migration enabled (and PNE)?"?



I'm still confused as to how PNE is supposed to mitigate linkability ac=
ross a NAT rebinding that occurs without client knowledge in the presence o=
f a server-supplied CID, which seems to me to be the most common NAT rebind=
ing event type. If it indeed does not, then the linkability characteristics=
 seem identical to me.

Agreed.=C2=A0 It=
 would only be non-identical in the case of 0 byte connection IDs, which I =
don't believe anyone expects to be common from client to server.=C2=A0<=
/div>



>

> b) Having two packet number schemes is acceptable to implementers (giv=
en the probable popularity of migration)

>

> I haven't yet seen much discussion of either of these specific asp=
ects.

>

> As an aside -- the other threads about modifications to PNE to make th=
em single-pass seem extremely promising; I'd encourage folks there to c=
ontinue discussions and make a PR.



+1. Making the design of PNE less problematic for offload and other future =
optimizations won't solve the underlying requirements problem (i.e. we =
are both treating linkability among 5-tuple flows by a specific on-path dev=
ice, the LB, as a requirement to support via CID, as well as a requirement =
to mitigate linkability among 5-tuple flows by a all generic on-path device=
s via PNE, which is inherently contradictory=C2=A0 without a very precise d=
efinition of under which circumstances which requirement takes precedence).=
 But it will reduce the cost from "probably mostly harmless" to &=
quot;almost definitely mostly harmless", which should make the decisio=
n easier.



Cheers,



Brian





>

> Cheers,

>

>

>

>> On 6 Apr 2018, at 2:41 am, Praveen Balasubramanian <pravb=3D40microsof=
t.com@dmarc.ietf.org> wrote:

>>

>> Love this idea. Expanding it a bit further I don=E2=80=99t think w=
e need to make PN transform a transport parameter but rather connection mig=
ration itself. We could also simply use QUIC versioning for this.

>>

>> 1. Ship QUIC v1 with no support for connection migration. Servers =
behind load balancers that are not QUIC aware will only advertise this vers=
ion. I expect this to be a large fraction of servers especially those hoste=
d in AWS, Azure, GCP. *This is important - I want the group to acknowledge =
that servers needs to be able to advertise support for connection migration=
*.

>> 2. Ship QUIC v2 with support for connection migration. If a client=
 and server use this version they MUST do PNE as per #1079. If we find a mo=
re efficient scheme before November then we use that instead.

>>

>> Eventually we will ship QUIV vN which has support for multi-path a=
nd we can revisit if PNE is needed or multiple PN spaces will work. Until t=
hen I can live with higher CPU cost for the fraction of connections that wi=
ll migrate.

>>

>> Now there is the ossification problem in QUIC v1 as referred to ab=
ove. We already require a random starting PN. The next problem is one that =
Kazuho brought up where middleboxes will start seeing strict increasing PN =
and try to reorder. I was thinking about short random jumps to fix this pro=
blem but the monotonic increase will remain. While I think sane middleboxes=
 will not do any reordering, there might be a few crazy outliers like with =
TCP. I think we can solve this by making the in clear PN jump both forward =
and back within a "reordering degree". I am thinking about some i=
deas here and will reply back if I find a simple scheme.

>>

>>>> FWIW, what I got from the info that Praveen and Ian have s=
hared is that there are enough problems to solve with UDP that worrying abo=
ut the performance hit from encryption is premature

>> Martin, we have plans to make UDP screaming fast in software. But =
the real advantage for TCP comes from the batch offloads (see email with su=
bject " Impact of hardware offloads on network stack performance"=
). Batch offloads for QUIC are impossible to do without crypto offload. I w=
ould be happy to explain more on this front. I think we will exhaust softwa=
re optimizations soon and then get blocked on crypto offload.

>>

>>

>> -----Original Message-----

>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson

>> Sent: Wednesday, April 4, 2018 9:36 PM

>> To: Kazuho Oku <kazuhooku@gmail.com>

>> Cc: Lars Eggert <lars@eggert.org>; Mark Nottingham <mnot@mnot.net>; IETF QUIC WG <quic@ietf.org>; Patrick =
McManus <pmcma=
nus@mozilla.com>

>> Subject: Re: Getting to consensus on packet number encryption

>>

>> On Thu, Apr 5, 2018 at 10:57 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>> It is true that #1079 has issues with hardware crypto offload.=
 I am

>>> happy to support switching to a better encryption scheme (if w=
e find

>>> one) at any moment; e.g., during the standardization of QUICv1=
, or as

>>> an extension to v1, or part of vX.

>>

>> Until this came up, I hadn't considered the use of an extensio=
n/transport parameter to negotiate a new scheme, but it's obvious.=C2=
=A0 This fits best with my view of things.

>>

>> If that means that we get the DC-QUIC option that turns the packet=
 number encryption function into identity or some cheaper function, then I =
think that's an OK outcome.=C2=A0 We should stop pretending that one si=
ze fits all is achievable; it's not been the case for years already.
>>

>> FWIW, what I got from the info that Praveen and Ian have shared is=
 that there are enough problems to solve with UDP that worrying about the p=
erformance hit from encryption is premature.

>>

>

> --

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

>






--001a113f998a97cddf0569702273--


From nobody Mon Apr  9 13:48:43 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB17412D7EC for ; Mon,  9 Apr 2018 13:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.11
X-Spam-Level: 
X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vksLhItlc89Q for ; Mon,  9 Apr 2018 13:48:39 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0126.outbound.protection.outlook.com [104.47.42.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142371204DA for ; Mon,  9 Apr 2018 13:48:39 -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=osCPzH58IYpU5i6YsQ1kFDftCvvEUIVD3lPpMajrYpk=; b=AnGJwVqfpEkrACZh2dawsXmY5z4LETgMSJ1iVdwLtRB3X3zkqfAZrZHBISEEx/QDa6Z6gWBE6KM9hk1HlLk8yMu4SgjOzUWxWgmH3hYs1qMwJi5QsBm72GSSE9RrpDwZD0TXd99U8i4rn4kh97EYv9xsarjoqUdFbPwckpoQBp4=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0118.namprd21.prod.outlook.com (10.173.189.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Mon, 9 Apr 2018 20:48:38 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Mon, 9 Apr 2018 20:48:37 +0000
From: Praveen Balasubramanian 
To: IETF QUIC WG 
Subject: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bw==
Date: Mon, 9 Apr 2018 20:48:37 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:9::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0118; 7:Cp8K4wxXHds3u6R3e0Z1yITSA43c16AF0JdyLRa/ppTLZA2vqMthuOcEZaI2dKJRIMmuWSzK9YjR7NJEPZP7I/o7qUtyNZstnxqmfhcFZM7g3xKqNMD3fvp30+gyu8d8cYccOu57sTUPIaob1dO/kOmCXq+pJNsG61nI+6eK12+y+ZZWsie5gWA4/0+MdChP6UPRABieSARDtIMPcg2xTa9sUcaRy2nMCGlahaYgbSzJ9BuGwOlun6Ep8FT9HV0C; 20:ycK5qmH1pghEqQhTSD6hW4rcegRdHWJr+J1gXFjMMVwEeVFWrhNgmwrvDbpBvaz3IaD3YLvgN1kegZPQ3+PaVXPP2bZkYm6QPUfUvM1iB82HXWjH+SIZFrQO56XCbIGaIeXEJ/YeuZV67RsPHjD7po5akKASyh2g141XPSfC2jU=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
X-MS-Office365-Filtering-Correlation-Id: d522d3f2-2f5e-48c2-8758-08d59e5b44d2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0118; 
x-ms-traffictypediagnostic: CY4PR21MB0118:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155)(15185016700835); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0118; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0118; 
x-forefront-prvs: 0637FCE711
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(396003)(366004)(376002)(39380400002)(199004)(189003)(2906002)(59450400001)(5250100002)(102836004)(6116002)(790700001)(106356001)(6506007)(10290500003)(3280700002)(6436002)(186003)(33656002)(8990500004)(68736007)(561944003)(486006)(97736004)(606006)(476003)(478600001)(2900100001)(7696005)(22452003)(86362001)(86612001)(14454004)(99286004)(966005)(7736002)(8676002)(81156014)(81166006)(8936002)(55016002)(236005)(3660700001)(9686003)(74316002)(10090500001)(6916009)(54896002)(6306002)(46003)(105586002)(53936002)(5660300001)(25786009)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0118; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: cA7iT6iY8cYVv8cZUyheaLjsNrZ2JtFsUEeTfB/vjVhrwffl0hj/OoUBKmXDDeS6nWk3ug5BR2vT5XI7f2LLcg4zIHQ8YO4Uo52+9K8q+JX+7lHUBAtAYtKRRk9WgKRUXCEaiBQNahYJBLiY2PdDlybtjP9B3hjX2OCwBcqgtkT2KWxEBch5XVyYTDPG9seoWkrYlKp8SbH31kev0nm74eeeQKr1OcVOlEAA6Q/CCaORG77cQQY9J2iVEFY4nLeHnSmrzuXxZOShh/ecJztUhNKjBMuy0D1cPxV38rmA0xVoEhBz8Dagr2QkdylGrpK6OU5jYGbNP6TRVg57HnOmcAeJLyeZmV92QAmRjONrI9ZEzOkMEHQnJ8PtESEr7YXA2nGtijMt+iX2ZprvoI8qpGjQwKA3I8SFuVvUvRibjRk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB063025EF8B5F228BB242920AB6BF0CY4PR21MB0630namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d522d3f2-2f5e-48c2-8758-08d59e5b44d2
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 20:48:37.4934 (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: Mon, 09 Apr 2018 20:48:42 -0000

--_000_CY4PR21MB063025EF8B5F228BB242920AB6BF0CY4PR21MB0630namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The current approach in the draft for preventing PN ossification is to use =
a random starting PN. Kazuho pointed out a problem with this approach where=
 middleboxes could interpret the PN as a sequence number. And in an attempt=
 to be "helpful", they could reorder the packets exacerbating the HoL block=
ing problem and may cause issues for unreliable semantics.

If the PN in the clear (the nonce value) didn't always monotonically increa=
se then it will preclude such bad behavior by the middleboxes. Hence we nee=
d to find a simple transform that is not monotonically increasing and also =
not repeating.

Requirements for any PN transform in the single path case:

  1.  The actual PN must always increment by 1 and will be used for generat=
ing ACKs in ACK frames.
  2.  The transformed PN in the clear is a nonce and must not repeat over t=
he connection lifetime.
  3.  Middleboxes must not be able to determine the actual PN. Only the QUI=
C receiver should be able to do so.

PNE is one possible transform that meets all these requirements but it is e=
xpensive CPU cost wise and has implications for hardware implementations.

Following is a proposal for an alternative simple transform with low CPU ov=
erhead which satisfies these three requirements. The goal is to produce a n=
on-repeating shuffle of the original set of numbers. Since the PN space is =
very big and efficient shuffle algorithms have O(n) space requirement, we n=
eed to define a "reorder degree" or a "batch size" within which we will shu=
ffle the packet numbers.

As an example consider that the starting random PN is 100. Per the current =
draft the actual PN increments as follows:
    100, 101, 102, 103, 104,    105, 106, 107, 108, 109, ... and so forth

Let's assume a "batch size" of 5. Then using one possible outcome of the sh=
uffles we can generate the following as the cleartext nonces:
|  102, 104, 103, 101, 100, |  107, 105, 109, 108, 106 |   ,... and so fort=
h
The bars | indicate batch boundaries.

Of course since we need the QUIC receiver to get the actual PN from the cle=
artext value, we need to communicate the offsets in the encrypted portion o=
f the packet, which for this example would be:
|  +2,    +3,   +1,   -2,   -4,    |    -2,   +1,   -2,    0,     +3    |, =
 ....
Middleboxes will not be able to see the offset values in the clear. QUIC re=
ceiver will need to do a simple add of a signed number to get the original =
PN. This is very cheap operation CPU cost wise.

A QUIC sender implementation can pick any size for the reorder degree, the =
trade-off is the space complexity and packet space needed to communicate th=
e offsets. A reorder degree within 128 numbers will need at most an extra b=
yte in the encrypted header to communicate the signed offset values. The 12=
8 batch size i.e. a 1 byte offset size should be more than enough entropy t=
o discourage a middle box from "fixing reordering" and in practice we may n=
eed less.

One possible algorithm for the shuffle is the Fisher-Yates (Knuth) shuffle =
as documented here: https://en.wikipedia.org/wiki/Fisher-Yates_shuffle . Pl=
ease see the "Modern method" section which is in-place. The random number g=
enerator doesn't have to be a secure variant.

One advantage of such a scheme is that packet loss can still be inferred by=
 looking at each batch sized set of the nonce (packet numbers). For example=
 if the batch size is 128, then missing numbers in this batch size (or a mu=
ltiple) will show the extent of packet loss. The other advantage is that a =
QUIC diagnostic connection can trivially detect a bad middlebox that tries =
to reorder the nonce in sequence as it will be easily distinguishable from =
a random network reorder.



--_000_CY4PR21MB063025EF8B5F228BB242920AB6BF0CY4PR21MB0630namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











The current approach in the draft for preventing PN =
ossification is to use a random starting PN. Kazuho pointed out a problem w=
ith this approach where middleboxes could interpret the PN as a sequence nu=
mber. And in an attempt to be “helpful”,
 they could reorder the packets exacerbating the HoL blocking problem and m=
ay cause issues for unreliable semantics.



 


If the PN in the clear (the nonce value) didn=
’t always monotonically increase then it will preclude such bad behav=
ior by the middleboxes. Hence we need to find a simple transform that is no=
t monotonically increasing and also not
 repeating. 


 


Requirements for any PN transform in the single path=
 case:


    

  1. The actual PN mus=
t always increment by 1 and will be used for generating ACKs in ACK frames.

  2. T=
he transformed PN in the clear is a nonce and must not repeat over the conn=
ection lifetime.
  3. Middleboxes must not be able to determine the actual PN. Onl=
y the QUIC receiver should be able to do so.


 


PNE is one possible transform that meets all these r=
equirements but it is expensive CPU cost wise and has implications for hard=
ware implementations.



 


Following is a proposal for an alternative simple tr=
ansform with low CPU overhead which satisfies these three requirements. The=
 goal is to produce a non-repeating shuffle of the original set of numbers.=
 Since the PN space is very big and
 efficient shuffle algorithms have O(n) space requirement, we need to defin=
e a “reorder degree” or a “batch size” within which=
 we will shuffle the packet numbers.


 


As an example consider that the starting random PN i=
s 100. Per the current draft the actual PN increments as follows:


    100, 101, 102, 103, 104,  &n=
bsp; 105, 106, 107, 108, 109, … and so forth


 


Let’s assume a “batch size” of 5. =
Then using one possible outcome of the shuffles we can generate the followi=
ng as the cleartext nonces:


|  102, 104, 103, 101, 100, |  107, 105, 1=
09, 108, 106 |   ,… and so forth


The bars | indicate batch boundaries.


 


Of course since we need the QUIC receiver to get the=
 actual PN from the cleartext value, we need to communicate the offsets in =
the encrypted portion of the packet, which for this example would be:<=
/o:p>


|  +2,    +3,  &nbs=
p;+1,   -2,   -4,    |  &n=
bsp; -2,   +1,   -2,    0,  &nb=
sp;  +3    |,  ….


Middleboxes will not be able to see the offset value=
s in the clear. QUIC receiver will need to do a simple add of a signed numb=
er to get the original PN. This is very cheap operation CPU cost wise.



 


A QUIC sender implementation can pick any size for t=
he reorder degree, the trade-off is the space complexity and packet space n=
eeded to communicate the offsets. A reorder degree within 128 numbers will =
need at most an extra byte in the
 encrypted header to communicate the signed offset values. The 128 batch si=
ze i.e. a 1 byte offset size should be more than enough entropy to discoura=
ge a middle box from “fixing reordering” and in practice we may=
 need less.


 


One possible algorithm for the shuffle is the Fisher=
–Yates (Knuth) shuffle as documented here:
https:=
//en.wikipedia.org/wiki/Fisher–Yates_shuffle . Please see the =
220;Modern method” section which is in-place. The random number gener=
ator doesn’t have to be a secure variant.


 


One advantage of such a scheme is that packet loss c=
an still be inferred by looking at each batch sized set of the nonce (packe=
t numbers). For example if the batch size is 128, then missing numbers in t=
his batch size (or a multiple) will
 show the extent of packet loss. The other advantage is that a QUIC diagnos=
tic connection can trivially detect a bad middlebox that tries to reorder t=
he nonce in sequence as it will be easily distinguishable from a random net=
work reorder.



 


 






--_000_CY4PR21MB063025EF8B5F228BB242920AB6BF0CY4PR21MB0630namp_--


From nobody Mon Apr  9 14:20:12 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80C12D7EF for ; Mon,  9 Apr 2018 14:20:11 -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 N2n0IkkF3keP for ; Mon,  9 Apr 2018 14:20:08 -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 82A9C126CBF for ; Mon,  9 Apr 2018 14:20:08 -0700 (PDT)
Received: by mail-it0-x22f.google.com with SMTP id v194-v6so12154363itb.0 for ; Mon, 09 Apr 2018 14:20:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to;  bh=FbWAQ6/Jzp85dN8DsS9NQ+3OF1IemOU5TG2kkM6xsyg=; b=e3JCJaPS2A55w9rwfhrRWHw0Ap910P3p6+Ry1Ksp/R6LZYA/XntBbFuFZLtL+WDP+G ByHZl1CWeQn2zeV9y5L3qVHbjHiDcCsCVPpNUV53Vt92HphnhJa8Aclbe4OK/+qqXDLO nnjq2F9RD03l1RN/M21rw2FSkYuwBlNQ0moMHJxq52TBm4WFUqQsj3w2akZ+hIT73dQy HOgQpvqb6xFzz4QGPh4gfsNpxO6siHQzvpprD/YY93BIsWEofvZ692EtJq0sUR6afcY+ wpp+hohW7IkE1lJd0rVnkkbRW0vIwzQeVgzsKrmxEXllR+FRA4Qz6yyxSR9JduQUnzjx RwGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=FbWAQ6/Jzp85dN8DsS9NQ+3OF1IemOU5TG2kkM6xsyg=; b=pR5s1rF2xZwRZVY92YLZRIbhjzpFXzM1lTG+hDmqw9Qes7ENKKJ/1rU0gJXy7mJ2+f OHxZTqPhobJ/xXSH646pqt/LZpzc7ssFGl79N1Tgv3NbPEhx5vnk/J243J0oKwFzZtAR xV7kYCi7LKWKhG67S7WRiwWuHpjF/9ahoeYDFs/FWe4WspOO7NsCgoZbKtEEVlIJH36o N9IMr7KFvWUvikLvHhWQl/jGR5SXp+vrF9MGGaFbmb53xxojki49/PK6kvTbFaX3b1DL eP4JFueYZMOBbyMwUVI5Ni5nI63bahSx7kg4qhou7NEbVO4TbVANVUTSf0Tf5RYG7lNV B3lQ==
X-Gm-Message-State: ALQs6tCr5KEZbxaP72Z4/qH9SLpRv937R5XCXCx+Iy7WFF6xz8221lJP CF5FIBuMEef5POvE1Ide1jEX5Df8nNC4EYsE/4miUA==
X-Google-Smtp-Source: AIpwx4/6DzkjkTSMLCt+U5ij8JL3qGCWjDxnvVkPOgNDfroStzPqHz2mfduPVeabz+jZv81cPIC3NVVfj6A+MTu1fhE=
X-Received: by 2002:a24:4922:: with SMTP id z34-v6mr1857762ita.150.1523308807806;  Mon, 09 Apr 2018 14:20:07 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 9 Apr 2018 17:20:06 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References: 
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 9 Apr 2018 17:20:06 -0400
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Praveen Balasubramanian , IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000005f6ac3056970f89a"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 21:20:11 -0000

--0000000000005f6ac3056970f89a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I incidentally implemented Fisher-Yates a few days ago=E2=80=A6

But if you permit a window, you can also encrypt packet numbers using an
internal precomputed AES driven PRNG stream - this is about 16x faster than
direct encryption because one block covers 4 packets, and encryption can be
done in a parallel pipeline with current AES-NI hardware. You need to map
the window in a hash table, and it must be small or cache effects makes it
too expensive.

However, big packet loss would make this scheme either ineffective, or
complicated with fallback search.

I assume your proposed shuffle is fully deterministic and precomputed.
Aside from the problems with a window size vs loss, this looks like a very
good way to correlate packets because they now exhibit a distinct pattern
for each connection. So I don=E2=80=99t see this as being worthwhile, if I
understand the scheme correctly.

The shuffle can also be seen as a clever way to create a perfect hash table
for the above mentioned PRNG scheme, but I don't think it would be
effective for large enough windows.

Furthermore, all of these schemes require extra memory per connection and
this can be expensive if there are 10K+ idle connections sitting.

/*
 * Given an uninitialized `index` of `n` uint64_t slots:
 * Place a unique value in the range 0 .. n - 1 inclusive in each slot
 * unbiased randomly (within the prng limits).
 *
 * Based on Fisher-Yates shuffle - inside out variant.
 */
static inline void rand64_init_shuffle_below(uint64_t *state, uint64_t
*index, uint64_t n)
{
    uint64_t i, x;

    for (i =3D 0; i < n; ++i) {
        x =3D rand64_below(state, i + 1); /* unsigned random value (0 .. i)=
 */
        index[i] =3D index[x]; /* Uninitialized if i =3D=3D x, which is ok.=
 */
        index[x] =3D i;
    }
}


Mikkel


On 9 April 2018 at 22.48.48, Praveen Balasubramanian (
pravb=3D40microsoft.com@dmarc.ietf.org) wrote:

The current approach in the draft for preventing PN ossification is to use
a random starting PN. Kazuho pointed out a problem with this approach where
middleboxes could interpret the PN as a sequence number. And in an attempt
to be =E2=80=9Chelpful=E2=80=9D, they could reorder the packets exacerbatin=
g the HoL
blocking problem and may cause issues for unreliable semantics.



If the PN *in the clear* (the nonce value) didn=E2=80=99t always monotonica=
lly
increase then it will preclude such bad behavior by the middleboxes. Hence
we need to find a simple transform that is not monotonically increasing and
also not repeating.



Requirements for any PN transform in the single path case:

   1. The actual PN must always increment by 1 and will be used for
   generating ACKs in ACK frames.
   2. The transformed PN in the clear is a nonce and must not repeat over
   the connection lifetime.
   3. Middleboxes must not be able to determine the actual PN. Only the
   QUIC receiver should be able to do so.



PNE is one possible transform that meets all these requirements but it is
expensive CPU cost wise and has implications for hardware implementations.



Following is a proposal for an alternative simple transform with low CPU
overhead which satisfies these three requirements. The goal is to produce a
non-repeating shuffle of the original set of numbers. Since the PN space is
very big and efficient shuffle algorithms have O(n) space requirement, we
need to define a =E2=80=9Creorder degree=E2=80=9D or a =E2=80=9Cbatch size=
=E2=80=9D within which we will
shuffle the packet numbers.



As an example consider that the starting random PN is 100. Per the current
draft the actual PN increments as follows:

    100, 101, 102, 103, 104,    105, 106, 107, 108, 109, =E2=80=A6 and so f=
orth



Let=E2=80=99s assume a =E2=80=9Cbatch size=E2=80=9D of 5. Then using one po=
ssible outcome of the
shuffles we can generate the following as the cleartext nonces:

|  102, 104, 103, 101, 100, |  107, 105, 109, 108, 106 |   ,=E2=80=A6 and s=
o forth

The bars | indicate batch boundaries.



Of course since we need the QUIC receiver to get the actual PN from the
cleartext value, we need to communicate the offsets in the encrypted
portion of the packet, which for this example would be:

|  +2,    +3,   +1,   -2,   -4,    |    -2,   +1,   -2,    0,     +3    |,
 =E2=80=A6.

Middleboxes will not be able to see the offset values in the clear. QUIC
receiver will need to do a simple add of a signed number to get the
original PN. This is very cheap operation CPU cost wise.



A QUIC sender implementation can pick any size for the reorder degree, the
trade-off is the space complexity and packet space needed to communicate
the offsets. A reorder degree within 128 numbers will need at most an extra
byte in the encrypted header to communicate the signed offset values. The
128 batch size i.e. a 1 byte offset size should be more than enough entropy
to discourage a middle box from =E2=80=9Cfixing reordering=E2=80=9D and in =
practice we may
need less.



One possible algorithm for the shuffle is the Fisher=E2=80=93Yates (Knuth) =
shuffle
as documented here: https://en.wikipedia.org/wiki/Fisher=E2=80=93Yates_shuf=
fle .
Please see the =E2=80=9CModern method=E2=80=9D section which is in-place. T=
he random number
generator doesn=E2=80=99t have to be a secure variant.



One advantage of such a scheme is that packet loss can still be inferred by
looking at each batch sized set of the nonce (packet numbers). For example
if the batch size is 128, then missing numbers in this batch size (or a
multiple) will show the extent of packet loss. The other advantage is that
a QUIC diagnostic connection can trivially detect a bad middlebox that
tries to reorder the nonce in sequence as it will be easily distinguishable
from a random network reorder.

--0000000000005f6ac3056970f89a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
I incidentally imple=
mented Fisher-Yates a few days ago=E2=80=A6

But if you permit a window, you can also encrypt pac=
ket numbers using an internal precomputed AES driven PRNG stream - this is =
about 16x faster than direct encryption because one block covers 4 packets,=
 and encryption can be done in a parallel pipeline with current AES-NI hard=
ware. You need to map the window in a hash table, and it must be small or c=
ache effects makes it too expensive.

However, big packet loss would make this scheme either inef=
fective, or complicated with fallback search.

I assume your proposed shuffle is fully determinis=
tic and precomputed. Aside from the problems with a window size vs loss, th=
is looks like a very good way to correlate packets because they now exhibit=
 a distinct pattern for each connection. So I don=E2=80=99t see this as bei=
ng worthwhile, if I understand the scheme correctly.

The shuffle can also be seen as a clever wa=
y to create a perfect hash table for the above mentioned PRNG scheme, but I=
 don't think it would be effective for large enough windows.

Furthermore, all of these schem=
es require extra memory per connection and this can be expensive if there a=
re 10K+ idle connections sitting.

/*
=C2=A0* Given an uninitiali=
zed `index` of `n` uint64_t slots:
=C2=A0* Place a unique value in the range 0 .. n - 1 inclus=
ive in each slot
=C2=
=A0* unbiased randomly (within the prng limits).
=C2=A0*
=C2=A0* Based on Fisher-Yates shuffle - inside out variant=
.
=C2=A0*/
static inline void rand64_ini=
t_shuffle_below(uint64_t *state, uint64_t *index, uint64_t n)
{
=C2=A0 =C2=A0 uint64_t i, x;

=C2=A0 =C2=A0 for (i =3D 0; i < n; ++i) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 x =
=3D rand64_below(state, i + 1); /* unsigned random value (0 .. i) */
<=
div id=3D"bloop_customfont" style=3D"margin:0px">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 index[i] =3D index[x]; /* Uninitialized if i =3D=3D x, which is ok. */<=
/div>
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 index[x] =3D i;
=C2=A0 =C2=A0 }
=
}


Mikkel

 
On 9 April 2018 at 22.48.48, Praveen Balasubramanian (pravb=3D40microsoft.com@dmarc.iet=
f.org) wrote:
 










The current approach in the draft for preventing PN =
ossification is to use a random starting PN. Kazuho pointed out a problem w=
ith this approach where middleboxes could interpret the PN as a sequence nu=
mber. And in an attempt to be =E2=80=9Chelpful=E2=80=9D,
 they could reorder the packets exacerbating the HoL blocking problem and m=
ay cause issues for unreliable semantics.



=C2=A0


If the PN in the clear (the nonce value) didn=
=E2=80=99t always monotonically increase then it will preclude such bad beh=
avior by the middleboxes. Hence we need to find a simple transform that is =
not monotonically increasing and also not
 repeating. 


=C2=A0


Requirements for any PN transform in the single path=
 case:


    

  1. The actual PN mus=
t always increment by 1 and will be used for generating ACKs in ACK frames.

  2. The transfor=
med PN in the clear is a nonce and must not repeat over the connection life=
time.
  3. Middleb=
oxes must not be able to determine the actual PN. Only the QUIC receiver sh=
ould be able to do so.


=C2=A0


PNE is one possible transform that meets all these r=
equirements but it is expensive CPU cost wise and has implications for hard=
ware implementations.



=C2=A0


Following is a proposal for an alternative simple tr=
ansform with low CPU overhead which satisfies these three requirements. The=
 goal is to produce a non-repeating shuffle of the original set of numbers.=
 Since the PN space is very big and
 efficient shuffle algorithms have O(n) space requirement, we need to defin=
e a =E2=80=9Creorder degree=E2=80=9D or a =E2=80=9Cbatch size=E2=80=9D with=
in which we will shuffle the packet numbers.


=C2=A0


As an example consider that the starting random PN i=
s 100. Per the current draft the actual PN increments as follows:


=C2=A0=C2=A0=C2=A0 100, 101, 102, 103, 104, =C2=A0=
=C2=A0=C2=A0105, 106, 107, 108, 109, =E2=80=A6 and so forth


=C2=A0


Let=E2=80=99s assume a =E2=80=9Cbatch size=E2=80=9D =
of 5. Then using one possible outcome of the shuffles we can generate the f=
ollowing as the cleartext nonces:


|=C2=A0 102, 104, 103, 101, 100, |=C2=A0 107, 105, 1=
09, 108, 106 | =C2=A0=C2=A0,=E2=80=A6 and so forth


The bars | indicate batch boundaries.


=C2=A0


Of course since we need the QUIC receiver to get the=
 actual PN from the cleartext value, we need to communicate the offsets in =
the encrypted portion of the packet, which for this example would be:


|=C2=A0 +2, =C2=A0=C2=A0=C2=A0+3, =C2=A0=C2=A0+1, =
=C2=A0=C2=A0-2, =C2=A0=C2=A0-4,=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 -2, =
=C2=A0=C2=A0+1, =C2=A0=C2=A0-2, =C2=A0=C2=A0=C2=A00, =C2=A0=C2=A0=C2=A0=C2=
=A0+3 =C2=A0=C2=A0=C2=A0|, =C2=A0=E2=80=A6.


Middleboxes will not be able to see the offset value=
s in the clear. QUIC receiver will need to do a simple add of a signed numb=
er to get the original PN. This is very cheap operation CPU cost wise.



=C2=A0


A QUIC sender implementation can pick any size for t=
he reorder degree, the trade-off is the space complexity and packet space n=
eeded to communicate the offsets. A reorder degree within 128 numbers will =
need at most an extra byte in the
 encrypted header to communicate the signed offset values. The 128 batch si=
ze i.e. a 1 byte offset size should be more than enough entropy to discoura=
ge a middle box from =E2=80=9Cfixing reordering=E2=80=9D and in practice we=
 may need less.


=C2=A0


One possible algorithm for the shuffle is the Fisher=
=E2=80=93Yates (Knuth) shuffle as documented here:
http=
s://en.wikipedia.org/wiki/Fisher=E2=80=93Yates_shuffle . Please see the=
 =E2=80=9CModern method=E2=80=9D section which is in-place. The random numb=
er generator doesn=E2=80=99t have to be a secure variant.


=C2=A0


One advantage of such a scheme is that packet loss c=
an still be inferred by looking at each batch sized set of the nonce (packe=
t numbers). For example if the batch size is 128, then missing numbers in t=
his batch size (or a multiple) will
 show the extent of packet loss. The other advantage is that a QUIC diagnos=
tic connection can trivially detect a bad middlebox that tries to reorder t=
he nonce in sequence as it will be easily distinguishable from a random net=
work reorder.



=C2=A0


=C2=A0








--0000000000005f6ac3056970f89a--


From nobody Mon Apr  9 14:20:32 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EAF126CBF for ; Mon,  9 Apr 2018 14:20:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523308812; bh=4XkKFqfuSM5sRg7HJ/T4S8iQK9H7+iHuckGJ4pBlC14=; h=From:In-Reply-To:References:Date:Subject:To:To; b=tyRVK/IPSm2K+zOO00AtcSQOVo6Xvdet6EIOevmAWiTIMoQRUGlVq+zWAhQbSDw+e ST77NG+FiFWNP3G/osdZSRlMzmoYWwYoiRRqhnL7cAYICGfWbRr9grfvmRVMQh0N3V Ee96P+u3NMdsPE6zaReFTuuSOXsxtiNn+dsAkptk=
X-Mailbox-Line: From mikkelfj@gmail.com  Mon Apr  9 14:20:12 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F336D12D7ED; Mon,  9 Apr 2018 14:20:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523308812; bh=dhtvQlcSa0D91cvxJf1gmX+gR7au5Ux7qNrS9sfqmcA=; h=From:In-Reply-To:References:Date:Subject:To:To; b=VXS3SrS8N5tyngxdsPCMfPIr+eqkaq8P9Ciu/FL3Lt5d8lIQHTuAQegf4olYulXbM DybdGHN9DmpSV3gAh5LYVsmnIurS5h3AkstW0tPrZvzSPi5qL8TxWHzt9Vk72CcHgP Lcq0GDPLf3ccot7nj33T79Vsu4BHJoQzmqY61xqw=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76B8126CBF for ; Mon,  9 Apr 2018 14:20:11 -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=unavailable 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 bmf-owlbKHMp for ; Mon,  9 Apr 2018 14:20:09 -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 C3D5F12D7ED for ; Mon,  9 Apr 2018 14:20:08 -0700 (PDT)
Received: by mail-it0-x230.google.com with SMTP id 71-v6so12139367ith.2 for ; Mon, 09 Apr 2018 14:20:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to;  bh=FbWAQ6/Jzp85dN8DsS9NQ+3OF1IemOU5TG2kkM6xsyg=; b=e3JCJaPS2A55w9rwfhrRWHw0Ap910P3p6+Ry1Ksp/R6LZYA/XntBbFuFZLtL+WDP+G ByHZl1CWeQn2zeV9y5L3qVHbjHiDcCsCVPpNUV53Vt92HphnhJa8Aclbe4OK/+qqXDLO nnjq2F9RD03l1RN/M21rw2FSkYuwBlNQ0moMHJxq52TBm4WFUqQsj3w2akZ+hIT73dQy HOgQpvqb6xFzz4QGPh4gfsNpxO6siHQzvpprD/YY93BIsWEofvZ692EtJq0sUR6afcY+ wpp+hohW7IkE1lJd0rVnkkbRW0vIwzQeVgzsKrmxEXllR+FRA4Qz6yyxSR9JduQUnzjx RwGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=FbWAQ6/Jzp85dN8DsS9NQ+3OF1IemOU5TG2kkM6xsyg=; b=O83sq9se4HKl9jxbS1qWLBZLZPRBL6gDe4s7Pf5UireD78cgG1trVTCkrdQG0wWhmJ 8gDgOJmh5P9Zmgy/fCRS5sUVJQ0hoT9YW4FE904yFU6p8Z/WcapWhdLM7vDp0314wppW UcipyfFB/4PI60MWaJuh6JfTNSTbS6O/RKihATlj9s9QQW6HWzXB3vDRf+Ls/EzyiH7y LybzkSh4Dm8M+2tH+gKqMEpZWBMQOmvWsbwY6ip4IBRjdeK6/BpnqZ9yHm5Vv70zlQhU HEkkNoc/fVQCFX7y72fTcVxjGOE1XEkrG6rN2fkMTDHVsIw6K0Varkx0ztHODhHG/zqN CiYw==
X-Gm-Message-State: ALQs6tC2650TWlYaeXC89cCcFkqetLNSm4BP6ZZ4/XtmK+/L/BzYTE4Y 7CAjZC/5UDuJXMYzrEUyr6SJOZnxZowt632X0zH9tw==
X-Google-Smtp-Source: AIpwx4/6DzkjkTSMLCt+U5ij8JL3qGCWjDxnvVkPOgNDfroStzPqHz2mfduPVeabz+jZv81cPIC3NVVfj6A+MTu1fhE=
X-Received: by 2002:a24:4922:: with SMTP id z34-v6mr1857762ita.150.1523308807806;  Mon, 09 Apr 2018 14:20:07 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 9 Apr 2018 17:20:06 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References: 
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 9 Apr 2018 17:20:06 -0400
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
Content-Type: multipart/alternative; boundary="0000000000005f6ac3056970f89a"
To: Praveen Balasubramanian 
To: IETF QUIC WG 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 21:20:12 -0000

--0000000000005f6ac3056970f89a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I incidentally implemented Fisher-Yates a few days ago=E2=80=A6

But if you permit a window, you can also encrypt packet numbers using an
internal precomputed AES driven PRNG stream - this is about 16x faster than
direct encryption because one block covers 4 packets, and encryption can be
done in a parallel pipeline with current AES-NI hardware. You need to map
the window in a hash table, and it must be small or cache effects makes it
too expensive.

However, big packet loss would make this scheme either ineffective, or
complicated with fallback search.

I assume your proposed shuffle is fully deterministic and precomputed.
Aside from the problems with a window size vs loss, this looks like a very
good way to correlate packets because they now exhibit a distinct pattern
for each connection. So I don=E2=80=99t see this as being worthwhile, if I
understand the scheme correctly.

The shuffle can also be seen as a clever way to create a perfect hash table
for the above mentioned PRNG scheme, but I don't think it would be
effective for large enough windows.

Furthermore, all of these schemes require extra memory per connection and
this can be expensive if there are 10K+ idle connections sitting.

/*
 * Given an uninitialized `index` of `n` uint64_t slots:
 * Place a unique value in the range 0 .. n - 1 inclusive in each slot
 * unbiased randomly (within the prng limits).
 *
 * Based on Fisher-Yates shuffle - inside out variant.
 */
static inline void rand64_init_shuffle_below(uint64_t *state, uint64_t
*index, uint64_t n)
{
    uint64_t i, x;

    for (i =3D 0; i < n; ++i) {
        x =3D rand64_below(state, i + 1); /* unsigned random value (0 .. i)=
 */
        index[i] =3D index[x]; /* Uninitialized if i =3D=3D x, which is ok.=
 */
        index[x] =3D i;
    }
}


Mikkel


On 9 April 2018 at 22.48.48, Praveen Balasubramanian (
pravb=3D40microsoft.com@dmarc.ietf.org) wrote:

The current approach in the draft for preventing PN ossification is to use
a random starting PN. Kazuho pointed out a problem with this approach where
middleboxes could interpret the PN as a sequence number. And in an attempt
to be =E2=80=9Chelpful=E2=80=9D, they could reorder the packets exacerbatin=
g the HoL
blocking problem and may cause issues for unreliable semantics.



If the PN *in the clear* (the nonce value) didn=E2=80=99t always monotonica=
lly
increase then it will preclude such bad behavior by the middleboxes. Hence
we need to find a simple transform that is not monotonically increasing and
also not repeating.



Requirements for any PN transform in the single path case:

   1. The actual PN must always increment by 1 and will be used for
   generating ACKs in ACK frames.
   2. The transformed PN in the clear is a nonce and must not repeat over
   the connection lifetime.
   3. Middleboxes must not be able to determine the actual PN. Only the
   QUIC receiver should be able to do so.



PNE is one possible transform that meets all these requirements but it is
expensive CPU cost wise and has implications for hardware implementations.



Following is a proposal for an alternative simple transform with low CPU
overhead which satisfies these three requirements. The goal is to produce a
non-repeating shuffle of the original set of numbers. Since the PN space is
very big and efficient shuffle algorithms have O(n) space requirement, we
need to define a =E2=80=9Creorder degree=E2=80=9D or a =E2=80=9Cbatch size=
=E2=80=9D within which we will
shuffle the packet numbers.



As an example consider that the starting random PN is 100. Per the current
draft the actual PN increments as follows:

    100, 101, 102, 103, 104,    105, 106, 107, 108, 109, =E2=80=A6 and so f=
orth



Let=E2=80=99s assume a =E2=80=9Cbatch size=E2=80=9D of 5. Then using one po=
ssible outcome of the
shuffles we can generate the following as the cleartext nonces:

|  102, 104, 103, 101, 100, |  107, 105, 109, 108, 106 |   ,=E2=80=A6 and s=
o forth

The bars | indicate batch boundaries.



Of course since we need the QUIC receiver to get the actual PN from the
cleartext value, we need to communicate the offsets in the encrypted
portion of the packet, which for this example would be:

|  +2,    +3,   +1,   -2,   -4,    |    -2,   +1,   -2,    0,     +3    |,
 =E2=80=A6.

Middleboxes will not be able to see the offset values in the clear. QUIC
receiver will need to do a simple add of a signed number to get the
original PN. This is very cheap operation CPU cost wise.



A QUIC sender implementation can pick any size for the reorder degree, the
trade-off is the space complexity and packet space needed to communicate
the offsets. A reorder degree within 128 numbers will need at most an extra
byte in the encrypted header to communicate the signed offset values. The
128 batch size i.e. a 1 byte offset size should be more than enough entropy
to discourage a middle box from =E2=80=9Cfixing reordering=E2=80=9D and in =
practice we may
need less.



One possible algorithm for the shuffle is the Fisher=E2=80=93Yates (Knuth) =
shuffle
as documented here: https://en.wikipedia.org/wiki/Fisher=E2=80=93Yates_shuf=
fle .
Please see the =E2=80=9CModern method=E2=80=9D section which is in-place. T=
he random number
generator doesn=E2=80=99t have to be a secure variant.



One advantage of such a scheme is that packet loss can still be inferred by
looking at each batch sized set of the nonce (packet numbers). For example
if the batch size is 128, then missing numbers in this batch size (or a
multiple) will show the extent of packet loss. The other advantage is that
a QUIC diagnostic connection can trivially detect a bad middlebox that
tries to reorder the nonce in sequence as it will be easily distinguishable
from a random network reorder.

--0000000000005f6ac3056970f89a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
I incidentally imple=
mented Fisher-Yates a few days ago=E2=80=A6

But if you permit a window, you can also encrypt pac=
ket numbers using an internal precomputed AES driven PRNG stream - this is =
about 16x faster than direct encryption because one block covers 4 packets,=
 and encryption can be done in a parallel pipeline with current AES-NI hard=
ware. You need to map the window in a hash table, and it must be small or c=
ache effects makes it too expensive.

However, big packet loss would make this scheme either inef=
fective, or complicated with fallback search.

I assume your proposed shuffle is fully determinis=
tic and precomputed. Aside from the problems with a window size vs loss, th=
is looks like a very good way to correlate packets because they now exhibit=
 a distinct pattern for each connection. So I don=E2=80=99t see this as bei=
ng worthwhile, if I understand the scheme correctly.

The shuffle can also be seen as a clever wa=
y to create a perfect hash table for the above mentioned PRNG scheme, but I=
 don't think it would be effective for large enough windows.

Furthermore, all of these schem=
es require extra memory per connection and this can be expensive if there a=
re 10K+ idle connections sitting.

/*
=C2=A0* Given an uninitiali=
zed `index` of `n` uint64_t slots:
=C2=A0* Place a unique value in the range 0 .. n - 1 inclus=
ive in each slot
=C2=
=A0* unbiased randomly (within the prng limits).
=C2=A0*
=C2=A0* Based on Fisher-Yates shuffle - inside out variant=
..
=C2=A0*/
static inline void rand64_ini=
t_shuffle_below(uint64_t *state, uint64_t *index, uint64_t n)
{
=C2=A0 =C2=A0 uint64_t i, x;

=C2=A0 =C2=A0 for (i =3D 0; i < n; ++i) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 x =
=3D rand64_below(state, i + 1); /* unsigned random value (0 .. i) */
<=
div id=3D"bloop_customfont" style=3D"margin:0px">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 index[i] =3D index[x]; /* Uninitialized if i =3D=3D x, which is ok. */<=
/div>
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 index[x] =3D i;
=C2=A0 =C2=A0 }
=
}


Mikkel

 
On 9 April 2018 at 22.48.48, Praveen Balasubramanian (pravb=3D40microsoft.com@dmarc.iet=
f.org) wrote:
 










The current approach in the draft for preventing PN =
ossification is to use a random starting PN. Kazuho pointed out a problem w=
ith this approach where middleboxes could interpret the PN as a sequence nu=
mber. And in an attempt to be =E2=80=9Chelpful=E2=80=9D,
 they could reorder the packets exacerbating the HoL blocking problem and m=
ay cause issues for unreliable semantics.



=C2=A0


If the PN in the clear (the nonce value) didn=
=E2=80=99t always monotonically increase then it will preclude such bad beh=
avior by the middleboxes. Hence we need to find a simple transform that is =
not monotonically increasing and also not
 repeating. 


=C2=A0


Requirements for any PN transform in the single path=
 case:


    

  1. The actual PN mus=
t always increment by 1 and will be used for generating ACKs in ACK frames.

  2. The transfor=
med PN in the clear is a nonce and must not repeat over the connection life=
time.
  3. Middleb=
oxes must not be able to determine the actual PN. Only the QUIC receiver sh=
ould be able to do so.


=C2=A0


PNE is one possible transform that meets all these r=
equirements but it is expensive CPU cost wise and has implications for hard=
ware implementations.



=C2=A0


Following is a proposal for an alternative simple tr=
ansform with low CPU overhead which satisfies these three requirements. The=
 goal is to produce a non-repeating shuffle of the original set of numbers.=
 Since the PN space is very big and
 efficient shuffle algorithms have O(n) space requirement, we need to defin=
e a =E2=80=9Creorder degree=E2=80=9D or a =E2=80=9Cbatch size=E2=80=9D with=
in which we will shuffle the packet numbers.


=C2=A0


As an example consider that the starting random PN i=
s 100. Per the current draft the actual PN increments as follows:


=C2=A0=C2=A0=C2=A0 100, 101, 102, 103, 104, =C2=A0=
=C2=A0=C2=A0105, 106, 107, 108, 109, =E2=80=A6 and so forth


=C2=A0


Let=E2=80=99s assume a =E2=80=9Cbatch size=E2=80=9D =
of 5. Then using one possible outcome of the shuffles we can generate the f=
ollowing as the cleartext nonces:


|=C2=A0 102, 104, 103, 101, 100, |=C2=A0 107, 105, 1=
09, 108, 106 | =C2=A0=C2=A0,=E2=80=A6 and so forth


The bars | indicate batch boundaries.


=C2=A0


Of course since we need the QUIC receiver to get the=
 actual PN from the cleartext value, we need to communicate the offsets in =
the encrypted portion of the packet, which for this example would be:


|=C2=A0 +2, =C2=A0=C2=A0=C2=A0+3, =C2=A0=C2=A0+1, =
=C2=A0=C2=A0-2, =C2=A0=C2=A0-4,=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 -2, =
=C2=A0=C2=A0+1, =C2=A0=C2=A0-2, =C2=A0=C2=A0=C2=A00, =C2=A0=C2=A0=C2=A0=C2=
=A0+3 =C2=A0=C2=A0=C2=A0|, =C2=A0=E2=80=A6.


Middleboxes will not be able to see the offset value=
s in the clear. QUIC receiver will need to do a simple add of a signed numb=
er to get the original PN. This is very cheap operation CPU cost wise.



=C2=A0


A QUIC sender implementation can pick any size for t=
he reorder degree, the trade-off is the space complexity and packet space n=
eeded to communicate the offsets. A reorder degree within 128 numbers will =
need at most an extra byte in the
 encrypted header to communicate the signed offset values. The 128 batch si=
ze i.e. a 1 byte offset size should be more than enough entropy to discoura=
ge a middle box from =E2=80=9Cfixing reordering=E2=80=9D and in practice we=
 may need less.


=C2=A0


One possible algorithm for the shuffle is the Fisher=
=E2=80=93Yates (Knuth) shuffle as documented here:
http=
s://en.wikipedia.org/wiki/Fisher=E2=80=93Yates_shuffle . Please see the=
 =E2=80=9CModern method=E2=80=9D section which is in-place. The random numb=
er generator doesn=E2=80=99t have to be a secure variant.


=C2=A0


One advantage of such a scheme is that packet loss c=
an still be inferred by looking at each batch sized set of the nonce (packe=
t numbers). For example if the batch size is 128, then missing numbers in t=
his batch size (or a multiple) will
 show the extent of packet loss. The other advantage is that a QUIC diagnos=
tic connection can trivially detect a bad middlebox that tries to reorder t=
he nonce in sequence as it will be easily distinguishable from a random net=
work reorder.



=C2=A0


=C2=A0








--0000000000005f6ac3056970f89a--


From nobody Mon Apr  9 14:33:12 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB46C12D956 for ; Mon,  9 Apr 2018 14:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.022
X-Spam-Level: 
X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJ7D_VLDOzfY for ; Mon,  9 Apr 2018 14:33:06 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0108.outbound.protection.outlook.com [104.47.33.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D40012D7F5 for ; Mon,  9 Apr 2018 14:33:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RZRhO/A3/zeztzcLNvrK1O7j6SxzC/Av/629bZU3Cro=; b=irBqJ9nLuWJTeGA4ZmU/neCy+w77TkINPJuFETBwel9y7aY9dZyCh5+1s1ssQvAI0fRF8oq/C0jrnFrCtWKmeQEXTjQLpQLGuPnfkw0r3ptxRW6dav+94rdi76mor1g/odQWnYpUJqrDGjZL4snVqvuMjQUnFIz8UbU3jJRhMMk=
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB0885.namprd21.prod.outlook.com (52.132.132.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Mon, 9 Apr 2018 21:33:04 +0000
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::49f0:9e08:d65d:b0dc]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::49f0:9e08:d65d:b0dc%4]) with mapi id 15.20.0696.003; Mon, 9 Apr 2018 21:33:04 +0000
From: Nick Banks 
To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Praveen Balasubramanian , IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwABL1oAAAAKT4A=
Date: Mon, 9 Apr 2018 21:33:04 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-04-09T21:33:02.6402577Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:4::490]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0885; 7:oqAOyQ5L2qQflNmcmOEbXXpOaOqRRgi2FxrC6QcUaszHlwAk2kQjG9Me1mXDRHkFwNgxr92FJXomqXMkqqBBPk1+rOUKn/L6kO8XP6plvQT1lf9/nYFJLfI9dbeapfJhtbWKeK9zd6QoEza9cRfH5e/jl3J/cVD4WF8U0BGRYKbsQG+t5xE6T1vW7xokkE6G3leUwFrpbUEaQsI4kBYOyLLoCPNqy1UDiKTlY0KZ9i/aVawgOOjZ3Uf/yHUcjuMa; 20:ogLqXEhDz2NyiEvo+9d31G3q78cq2CwaRS2GqX7Ck91RTATm35yz+bkzC6sNXdFS8w3U1KF2BuGC4ipnT8M6ywGO2aL2/3RSbQwThupAT1rcazwXXdbZbRAHksRJa7LwdQKTBvgKlOGW3tf+1Oo7SfFY+INlTJ3os/7t8urfUNE=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(3008032)(48565401081)(2017052603328)(7193020); SRVR:DM5PR2101MB0885; 
x-ms-traffictypediagnostic: DM5PR2101MB0885:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(189930954265078)(788757137089)(219752817060721)(21748063052155)(17755550239193)(15185016700835);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR2101MB0885; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0885; 
x-forefront-prvs: 0637FCE711
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(396003)(376002)(366004)(39860400002)(199004)(189003)(39060400002)(74316002)(59450400001)(6246003)(6116002)(790700001)(86362001)(5250100002)(3280700002)(10290500003)(6436002)(10090500001)(3660700001)(53546011)(446003)(53936002)(966005)(6506007)(33656002)(606006)(76176011)(478600001)(7736002)(7696005)(81156014)(476003)(25786009)(8676002)(561944003)(11346002)(46003)(81166006)(8936002)(186003)(55016002)(102836004)(8990500004)(99286004)(236005)(14454004)(54896002)(6306002)(9686003)(316002)(68736007)(486006)(5660300001)(110136005)(22452003)(2906002)(2900100001)(86612001)(229853002)(106356001)(19609705001)(97736004)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0885; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 07Ftk0pjZq+J7MIlHu8yIIBJrSOKBhyIQhpwQ6I0S46ynjqKuuWaqXbgiBZw4qLbImf9t2E0PKEICS3NB6csOQKgPIBbZ/rC8bYSmk7KBrWnmRK6FDM3FkKNYmaUffQUkdOH6u1NYLgtk/R7BMybKuhBz3AtLckMCDSmgZA4ngoF8HNe9ATWzX0K7hiHgDGpIsKPjAVAPm9PKR/1wLB2ye6U41fUDC4HdItA0jGwH/JRHdb62O7PJECn+bdQOsds0xXeZ2E/NUBRU6ezLl+xQD0/l2ivlMBPxQuWnD7cO1CUwbbFejbkT6hGbbXfbwvZUDSGdIfK2HTxRO0hplkr+shxMFb08U/2vcH8cBccG3ZUMTjWrDg8dcBp10SpQveFSBOSUhsfeXfe+a4hiNKezXAQY6gCfjCblhLJ4syvdIQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB0901BDA387CF7CA119926CAFB3BF0DM5PR2101MB0901_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 4d68a1e3-9f03-4afd-0b63-08d59e617a35
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4d68a1e3-9f03-4afd-0b63-08d59e617a35
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 21:33:04.0985 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0885
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 21:33:11 -0000

--_000_DM5PR2101MB0901BDA387CF7CA119926CAFB3BF0DM5PR2101MB0901_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIGdvYWwgaGVyZSB3b3VsZCBlc3NlbnRpYWxseSBqdXN0IHRvIHNodWZmbGUgdGhlIGJpdHMg
aW4gdGhlIGJvdHRvbSBieXRlLCBqdXN0IHRvIG1ha2UgZXZlcnl0aGluZyBsb29rIHJlb3JkZXJl
ZCB0byB0aGUgbWlkZGxlYm94LiBZb3UgZG9u4oCZdCByZWFsbHkgaGF2ZSB0byBwcmVjb21wdXRl
IGFueXRoaW5nLCBhbmQgaXQgc2hvdWxkIGJlIGluZGVwZW5kZW50IG9mIEJEUCBvciBsb3NzLg0K
DQpIZXJlIGlzIGEgc2xpZ2h0IHZhcmlhdGlvbiBvbiBQcmF2ZWVu4oCZcyBzdWdnZXN0aW9uIChh
c3N1bWVzIHVzaW5nIGZ1bGwgMTI4IHBhY2tldCBiYXRjaCBzaXplKToNCg0KDQogICogICBQcmVh
bGxvY2F0ZSBhIGJ1ZmZlciBvZiAxMjggYnl0ZXMgYW5kIHByZXBvcHVsYXRlIGl0IHdpdGggdGhl
IHZhbHVlcyBvZiAwIHRvIDEyNy4NCiAgKiAgIEZvciBlYWNoIHBhY2tldCBzZW50LCByYW5kb21s
eSBncmFiIGFuIGl0ZW0gKGkuZS4gdGhlIG9mZnNldCkgZnJvbSB3aGF04oCZcyBsZWZ0IGluIHRo
ZSBidWZmZXIsIGFuZCByZW1vdmUgaXQgKHN3YXAgd2l0aCBsYXN0IHZhbHVlLCBhbmQgZGVjcmVt
ZW50IGxlbmd0aCkuDQogICogICBSZXBsYWNlIHRoZSBib3R0b20gYnl0ZSBvZiB0aGUgcmVhbCBw
YWNrZXQgbnVtYmVyIHdpdGggdGhlIG9mZnNldCBhbmQgcHV0IHRoYXQgbmV3IHBhY2tldCBudW1i
ZXIgaW4gdGhlIGNsZWFyIHRleHQuDQogICogICBQdXQgdGhlIHJlYWwgYm90dG9tIGJ5dGUgb2Yg
dGhlIHJlYWwgcGFja2V0IG51bWJlciBpbiB0aGUgZW5jcnlwdGVkIHBvcnRpb24uDQogICogICBF
bmNyeXB0IHdpdGggdGhlIG5ldyBjbGVhcnRleHQgcGFja2V0IG51bWJlciBhbmQgc2VuZC4NCiAg
KiAgIE9uY2UgdGhlIHByZWFsbG9jYXRlZCBidWZmZXIgaXMgZW1wdHksIGp1c3Qgc2V0IHRoZSBs
ZW5ndGggYmFjayB0byAxMjggYW5kIGNvbnRpbnVlIG9uLg0KDQpUaGUgc2VuZGVyIGRlY3J5cHRz
IHVzaW5nIHRoZSBjbGVhcnRleHQgcGFja2V0IG51bWJlci4gVGhlbiByZXBsYWNlcyB0aGUgYm90
dG9tIGJ5dGUgb2YgdGhlIHBhY2tldCBudW1iZXIgd2l0aCB0aGUgb2Zmc2V0IGZyb20gdGhlIGVu
Y3J5cHRlZCBwYXlsb2FkIHRvIGdldCB0aGUgdHJ1ZSBwYWNrZXQgbnVtYmVyLg0KDQotIE5pY2sN
Cg0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWlra2Vs
IEZhaG7DuGUgSsO4cmdlbnNlbg0KU2VudDogTW9uZGF5LCBBcHJpbCA5LCAyMDE4IDI6MjAgUE0N
ClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJj
LmlldGYub3JnPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFNp
bXBsZSB0cmFuc2Zvcm0gZm9yIGltcHJvdmluZyBQTiBvc3NpZmljYXRpb24gcHJldmVudGlvbg0K
DQpJIGluY2lkZW50YWxseSBpbXBsZW1lbnRlZCBGaXNoZXItWWF0ZXMgYSBmZXcgZGF5cyBhZ2/i
gKYNCg0KQnV0IGlmIHlvdSBwZXJtaXQgYSB3aW5kb3csIHlvdSBjYW4gYWxzbyBlbmNyeXB0IHBh
Y2tldCBudW1iZXJzIHVzaW5nIGFuIGludGVybmFsIHByZWNvbXB1dGVkIEFFUyBkcml2ZW4gUFJO
RyBzdHJlYW0gLSB0aGlzIGlzIGFib3V0IDE2eCBmYXN0ZXIgdGhhbiBkaXJlY3QgZW5jcnlwdGlv
biBiZWNhdXNlIG9uZSBibG9jayBjb3ZlcnMgNCBwYWNrZXRzLCBhbmQgZW5jcnlwdGlvbiBjYW4g
YmUgZG9uZSBpbiBhIHBhcmFsbGVsIHBpcGVsaW5lIHdpdGggY3VycmVudCBBRVMtTkkgaGFyZHdh
cmUuIFlvdSBuZWVkIHRvIG1hcCB0aGUgd2luZG93IGluIGEgaGFzaCB0YWJsZSwgYW5kIGl0IG11
c3QgYmUgc21hbGwgb3IgY2FjaGUgZWZmZWN0cyBtYWtlcyBpdCB0b28gZXhwZW5zaXZlLg0KDQpI
b3dldmVyLCBiaWcgcGFja2V0IGxvc3Mgd291bGQgbWFrZSB0aGlzIHNjaGVtZSBlaXRoZXIgaW5l
ZmZlY3RpdmUsIG9yIGNvbXBsaWNhdGVkIHdpdGggZmFsbGJhY2sgc2VhcmNoLg0KDQpJIGFzc3Vt
ZSB5b3VyIHByb3Bvc2VkIHNodWZmbGUgaXMgZnVsbHkgZGV0ZXJtaW5pc3RpYyBhbmQgcHJlY29t
cHV0ZWQuIEFzaWRlIGZyb20gdGhlIHByb2JsZW1zIHdpdGggYSB3aW5kb3cgc2l6ZSB2cyBsb3Nz
LCB0aGlzIGxvb2tzIGxpa2UgYSB2ZXJ5IGdvb2Qgd2F5IHRvIGNvcnJlbGF0ZSBwYWNrZXRzIGJl
Y2F1c2UgdGhleSBub3cgZXhoaWJpdCBhIGRpc3RpbmN0IHBhdHRlcm4gZm9yIGVhY2ggY29ubmVj
dGlvbi4gU28gSSBkb27igJl0IHNlZSB0aGlzIGFzIGJlaW5nIHdvcnRod2hpbGUsIGlmIEkgdW5k
ZXJzdGFuZCB0aGUgc2NoZW1lIGNvcnJlY3RseS4NCg0KVGhlIHNodWZmbGUgY2FuIGFsc28gYmUg
c2VlbiBhcyBhIGNsZXZlciB3YXkgdG8gY3JlYXRlIGEgcGVyZmVjdCBoYXNoIHRhYmxlIGZvciB0
aGUgYWJvdmUgbWVudGlvbmVkIFBSTkcgc2NoZW1lLCBidXQgSSBkb24ndCB0aGluayBpdCB3b3Vs
ZCBiZSBlZmZlY3RpdmUgZm9yIGxhcmdlIGVub3VnaCB3aW5kb3dzLg0KDQpGdXJ0aGVybW9yZSwg
YWxsIG9mIHRoZXNlIHNjaGVtZXMgcmVxdWlyZSBleHRyYSBtZW1vcnkgcGVyIGNvbm5lY3Rpb24g
YW5kIHRoaXMgY2FuIGJlIGV4cGVuc2l2ZSBpZiB0aGVyZSBhcmUgMTBLKyBpZGxlIGNvbm5lY3Rp
b25zIHNpdHRpbmcuDQoNCi8qDQogKiBHaXZlbiBhbiB1bmluaXRpYWxpemVkIGBpbmRleGAgb2Yg
YG5gIHVpbnQ2NF90IHNsb3RzOg0KICogUGxhY2UgYSB1bmlxdWUgdmFsdWUgaW4gdGhlIHJhbmdl
IDAgLi4gbiAtIDEgaW5jbHVzaXZlIGluIGVhY2ggc2xvdA0KICogdW5iaWFzZWQgcmFuZG9tbHkg
KHdpdGhpbiB0aGUgcHJuZyBsaW1pdHMpLg0KICoNCiAqIEJhc2VkIG9uIEZpc2hlci1ZYXRlcyBz
aHVmZmxlIC0gaW5zaWRlIG91dCB2YXJpYW50Li4NCiAqLw0Kc3RhdGljIGlubGluZSB2b2lkIHJh
bmQ2NF9pbml0X3NodWZmbGVfYmVsb3codWludDY0X3QgKnN0YXRlLCB1aW50NjRfdCAqaW5kZXgs
IHVpbnQ2NF90IG4pDQp7DQogICAgdWludDY0X3QgaSwgeDsNCg0KICAgIGZvciAoaSA9IDA7IGkg
PCBuOyArK2kpIHsNCiAgICAgICAgeCA9IHJhbmQ2NF9iZWxvdyhzdGF0ZSwgaSArIDEpOyAvKiB1
bnNpZ25lZCByYW5kb20gdmFsdWUgKDAgLi4gaSkgKi8NCiAgICAgICAgaW5kZXhbaV0gPSBpbmRl
eFt4XTsgLyogVW5pbml0aWFsaXplZCBpZiBpID09IHgsIHdoaWNoIGlzIG9rLiAqLw0KICAgICAg
ICBpbmRleFt4XSA9IGk7DQogICAgfQ0KfQ0KDQoNCk1pa2tlbA0KDQoNCg0KT24gOSBBcHJpbCAy
MDE4IGF0IDIyLjQ4LjQ4LCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAocHJhdmI9NDBtaWNyb3Nv
ZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMu
aWV0Zi5vcmc+KSB3cm90ZToNClRoZSBjdXJyZW50IGFwcHJvYWNoIGluIHRoZSBkcmFmdCBmb3Ig
cHJldmVudGluZyBQTiBvc3NpZmljYXRpb24gaXMgdG8gdXNlIGEgcmFuZG9tIHN0YXJ0aW5nIFBO
LiBLYXp1aG8gcG9pbnRlZCBvdXQgYSBwcm9ibGVtIHdpdGggdGhpcyBhcHByb2FjaCB3aGVyZSBt
aWRkbGVib3hlcyBjb3VsZCBpbnRlcnByZXQgdGhlIFBOIGFzIGEgc2VxdWVuY2UgbnVtYmVyLiBB
bmQgaW4gYW4gYXR0ZW1wdCB0byBiZSDigJxoZWxwZnVs4oCdLCB0aGV5IGNvdWxkIHJlb3JkZXIg
dGhlIHBhY2tldHMgZXhhY2VyYmF0aW5nIHRoZSBIb0wgYmxvY2tpbmcgcHJvYmxlbSBhbmQgbWF5
IGNhdXNlIGlzc3VlcyBmb3IgdW5yZWxpYWJsZSBzZW1hbnRpY3MuDQoNCklmIHRoZSBQTiBpbiB0
aGUgY2xlYXIgKHRoZSBub25jZSB2YWx1ZSkgZGlkbuKAmXQgYWx3YXlzIG1vbm90b25pY2FsbHkg
aW5jcmVhc2UgdGhlbiBpdCB3aWxsIHByZWNsdWRlIHN1Y2ggYmFkIGJlaGF2aW9yIGJ5IHRoZSBt
aWRkbGVib3hlcy4gSGVuY2Ugd2UgbmVlZCB0byBmaW5kIGEgc2ltcGxlIHRyYW5zZm9ybSB0aGF0
IGlzIG5vdCBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmcgYW5kIGFsc28gbm90IHJlcGVhdGluZy4N
Cg0KUmVxdWlyZW1lbnRzIGZvciBhbnkgUE4gdHJhbnNmb3JtIGluIHRoZSBzaW5nbGUgcGF0aCBj
YXNlOg0KDQogIDEuICBUaGUgYWN0dWFsIFBOIG11c3QgYWx3YXlzIGluY3JlbWVudCBieSAxIGFu
ZCB3aWxsIGJlIHVzZWQgZm9yIGdlbmVyYXRpbmcgQUNLcyBpbiBBQ0sgZnJhbWVzLg0KICAyLiAg
VGhlIHRyYW5zZm9ybWVkIFBOIGluIHRoZSBjbGVhciBpcyBhIG5vbmNlIGFuZCBtdXN0IG5vdCBy
ZXBlYXQgb3ZlciB0aGUgY29ubmVjdGlvbiBsaWZldGltZS4NCiAgMy4gIE1pZGRsZWJveGVzIG11
c3Qgbm90IGJlIGFibGUgdG8gZGV0ZXJtaW5lIHRoZSBhY3R1YWwgUE4uIE9ubHkgdGhlIFFVSUMg
cmVjZWl2ZXIgc2hvdWxkIGJlIGFibGUgdG8gZG8gc28uDQoNClBORSBpcyBvbmUgcG9zc2libGUg
dHJhbnNmb3JtIHRoYXQgbWVldHMgYWxsIHRoZXNlIHJlcXVpcmVtZW50cyBidXQgaXQgaXMgZXhw
ZW5zaXZlIENQVSBjb3N0IHdpc2UgYW5kIGhhcyBpbXBsaWNhdGlvbnMgZm9yIGhhcmR3YXJlIGlt
cGxlbWVudGF0aW9ucy4NCg0KRm9sbG93aW5nIGlzIGEgcHJvcG9zYWwgZm9yIGFuIGFsdGVybmF0
aXZlIHNpbXBsZSB0cmFuc2Zvcm0gd2l0aCBsb3cgQ1BVIG92ZXJoZWFkIHdoaWNoIHNhdGlzZmll
cyB0aGVzZSB0aHJlZSByZXF1aXJlbWVudHMuIFRoZSBnb2FsIGlzIHRvIHByb2R1Y2UgYSBub24t
cmVwZWF0aW5nIHNodWZmbGUgb2YgdGhlIG9yaWdpbmFsIHNldCBvZiBudW1iZXJzLiBTaW5jZSB0
aGUgUE4gc3BhY2UgaXMgdmVyeSBiaWcgYW5kIGVmZmljaWVudCBzaHVmZmxlIGFsZ29yaXRobXMg
aGF2ZSBPKG4pIHNwYWNlIHJlcXVpcmVtZW50LCB3ZSBuZWVkIHRvIGRlZmluZSBhIOKAnHJlb3Jk
ZXIgZGVncmVl4oCdIG9yIGEg4oCcYmF0Y2ggc2l6ZeKAnSB3aXRoaW4gd2hpY2ggd2Ugd2lsbCBz
aHVmZmxlIHRoZSBwYWNrZXQgbnVtYmVycy4NCg0KQXMgYW4gZXhhbXBsZSBjb25zaWRlciB0aGF0
IHRoZSBzdGFydGluZyByYW5kb20gUE4gaXMgMTAwLiBQZXIgdGhlIGN1cnJlbnQgZHJhZnQgdGhl
IGFjdHVhbCBQTiBpbmNyZW1lbnRzIGFzIGZvbGxvd3M6DQogICAgMTAwLCAxMDEsIDEwMiwgMTAz
LCAxMDQsICAgIDEwNSwgMTA2LCAxMDcsIDEwOCwgMTA5LCDigKYgYW5kIHNvIGZvcnRoDQoNCkxl
dOKAmXMgYXNzdW1lIGEg4oCcYmF0Y2ggc2l6ZeKAnSBvZiA1LiBUaGVuIHVzaW5nIG9uZSBwb3Nz
aWJsZSBvdXRjb21lIG9mIHRoZSBzaHVmZmxlcyB3ZSBjYW4gZ2VuZXJhdGUgdGhlIGZvbGxvd2lu
ZyBhcyB0aGUgY2xlYXJ0ZXh0IG5vbmNlczoNCnwgIDEwMiwgMTA0LCAxMDMsIDEwMSwgMTAwLCB8
ICAxMDcsIDEwNSwgMTA5LCAxMDgsIDEwNiB8ICAgLOKApiBhbmQgc28gZm9ydGgNClRoZSBiYXJz
IHwgaW5kaWNhdGUgYmF0Y2ggYm91bmRhcmllcy4NCg0KT2YgY291cnNlIHNpbmNlIHdlIG5lZWQg
dGhlIFFVSUMgcmVjZWl2ZXIgdG8gZ2V0IHRoZSBhY3R1YWwgUE4gZnJvbSB0aGUgY2xlYXJ0ZXh0
IHZhbHVlLCB3ZSBuZWVkIHRvIGNvbW11bmljYXRlIHRoZSBvZmZzZXRzIGluIHRoZSBlbmNyeXB0
ZWQgcG9ydGlvbiBvZiB0aGUgcGFja2V0LCB3aGljaCBmb3IgdGhpcyBleGFtcGxlIHdvdWxkIGJl
Og0KfCAgKzIsICAgICszLCAgICsxLCAgIC0yLCAgIC00LCAgICB8ICAgIC0yLCAgICsxLCAgIC0y
LCAgICAwLCAgICAgKzMgICAgfCwgIOKApi4NCk1pZGRsZWJveGVzIHdpbGwgbm90IGJlIGFibGUg
dG8gc2VlIHRoZSBvZmZzZXQgdmFsdWVzIGluIHRoZSBjbGVhci4gUVVJQyByZWNlaXZlciB3aWxs
IG5lZWQgdG8gZG8gYSBzaW1wbGUgYWRkIG9mIGEgc2lnbmVkIG51bWJlciB0byBnZXQgdGhlIG9y
aWdpbmFsIFBOLiBUaGlzIGlzIHZlcnkgY2hlYXAgb3BlcmF0aW9uIENQVSBjb3N0IHdpc2UuDQoN
CkEgUVVJQyBzZW5kZXIgaW1wbGVtZW50YXRpb24gY2FuIHBpY2sgYW55IHNpemUgZm9yIHRoZSBy
ZW9yZGVyIGRlZ3JlZSwgdGhlIHRyYWRlLW9mZiBpcyB0aGUgc3BhY2UgY29tcGxleGl0eSBhbmQg
cGFja2V0IHNwYWNlIG5lZWRlZCB0byBjb21tdW5pY2F0ZSB0aGUgb2Zmc2V0cy4gQSByZW9yZGVy
IGRlZ3JlZSB3aXRoaW4gMTI4IG51bWJlcnMgd2lsbCBuZWVkIGF0IG1vc3QgYW4gZXh0cmEgYnl0
ZSBpbiB0aGUgZW5jcnlwdGVkIGhlYWRlciB0byBjb21tdW5pY2F0ZSB0aGUgc2lnbmVkIG9mZnNl
dCB2YWx1ZXMuIFRoZSAxMjggYmF0Y2ggc2l6ZSBpLmUuIGEgMSBieXRlIG9mZnNldCBzaXplIHNo
b3VsZCBiZSBtb3JlIHRoYW4gZW5vdWdoIGVudHJvcHkgdG8gZGlzY291cmFnZSBhIG1pZGRsZSBi
b3ggZnJvbSDigJxmaXhpbmcgcmVvcmRlcmluZ+KAnSBhbmQgaW4gcHJhY3RpY2Ugd2UgbWF5IG5l
ZWQgbGVzcy4NCg0KT25lIHBvc3NpYmxlIGFsZ29yaXRobSBmb3IgdGhlIHNodWZmbGUgaXMgdGhl
IEZpc2hlcuKAk1lhdGVzIChLbnV0aCkgc2h1ZmZsZSBhcyBkb2N1bWVudGVkIGhlcmU6IGh0dHBz
Oi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0Zpc2hlcuKAk1lhdGVzX3NodWZmbGU8aHR0cHM6Ly9u
YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHM6JTJGJTJGZW4u
d2lraXBlZGlhLm9yZyUyRndpa2klMkZGaXNoZXIlRTIlODAlOTNZYXRlc19zaHVmZmxlJmRhdGE9
MDIlN0MwMSU3Q25pYmFua3MlNDBtaWNyb3NvZnQuY29tJTdDY2IxZDJkZWFiNTUxNDE5ZmIzMjIw
OGQ1OWU1ZmIwNjklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD
NjM2NTg5MDU2MTkzODYyODY4JnNkYXRhPUlRaE5QcjFRNlNnJTJCNTRvQUNsYnlHaEhkNnE3cmx3
clA5ZXVINlFrWTZFVSUzRCZyZXNlcnZlZD0wPiAuIFBsZWFzZSBzZWUgdGhlIOKAnE1vZGVybiBt
ZXRob2TigJ0gc2VjdGlvbiB3aGljaCBpcyBpbi1wbGFjZS4gVGhlIHJhbmRvbSBudW1iZXIgZ2Vu
ZXJhdG9yIGRvZXNu4oCZdCBoYXZlIHRvIGJlIGEgc2VjdXJlIHZhcmlhbnQuDQoNCk9uZSBhZHZh
bnRhZ2Ugb2Ygc3VjaCBhIHNjaGVtZSBpcyB0aGF0IHBhY2tldCBsb3NzIGNhbiBzdGlsbCBiZSBp
bmZlcnJlZCBieSBsb29raW5nIGF0IGVhY2ggYmF0Y2ggc2l6ZWQgc2V0IG9mIHRoZSBub25jZSAo
cGFja2V0IG51bWJlcnMpLiBGb3IgZXhhbXBsZSBpZiB0aGUgYmF0Y2ggc2l6ZSBpcyAxMjgsIHRo
ZW4gbWlzc2luZyBudW1iZXJzIGluIHRoaXMgYmF0Y2ggc2l6ZSAob3IgYSBtdWx0aXBsZSkgd2ls
bCBzaG93IHRoZSBleHRlbnQgb2YgcGFja2V0IGxvc3MuIFRoZSBvdGhlciBhZHZhbnRhZ2UgaXMg
dGhhdCBhIFFVSUMgZGlhZ25vc3RpYyBjb25uZWN0aW9uIGNhbiB0cml2aWFsbHkgZGV0ZWN0IGEg
YmFkIG1pZGRsZWJveCB0aGF0IHRyaWVzIHRvIHJlb3JkZXIgdGhlIG5vbmNlIGluIHNlcXVlbmNl
IGFzIGl0IHdpbGwgYmUgZWFzaWx5IGRpc3Rpbmd1aXNoYWJsZSBmcm9tIGEgcmFuZG9tIG5ldHdv
cmsgcmVvcmRlci4NCg0KDQo=

--_000_DM5PR2101MB0901BDA387CF7CA119926CAFB3BF0DM5PR2101MB0901_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7
fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy
IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN
CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp
c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0K
CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs
IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFpbG9uLCBsaS5haXJtYWlsb24sIGRp
di5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6
ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X
b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq
Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTI0MzM2ODExOw0KCW1zby1saXN0LXRlbXBsYXRl
LWlkczotMTUwNTU2NzA4Mjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps
ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl
dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2
ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10
YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl
bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxDQoJe21z
by1saXN0LWlkOjE1MDI2OTc0Nzc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt
dGVtcGxhdGUtaWRzOjYwOTI1MDE5NiA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4
OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs
MTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9
DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg
bDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90
dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i
MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi
IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs
YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk
U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGdvYWwgaGVyZSB3b3VsZCBlc3Nl
bnRpYWxseSBqdXN0IHRvIHNodWZmbGUgdGhlIGJpdHMgaW4gdGhlIGJvdHRvbSBieXRlLCBqdXN0
IHRvIG1ha2UgZXZlcnl0aGluZyBsb29rIHJlb3JkZXJlZCB0byB0aGUgbWlkZGxlYm94LiBZb3Ug
ZG9u4oCZdCByZWFsbHkgaGF2ZSB0byBwcmVjb21wdXRlIGFueXRoaW5nLCBhbmQgaXQgc2hvdWxk
IGJlIGluZGVwZW5kZW50IG9mIEJEUCBvciBsb3NzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I
ZXJlIGlzIGEgc2xpZ2h0IHZhcmlhdGlvbiBvbiBQcmF2ZWVu4oCZcyBzdWdnZXN0aW9uIChhc3N1
bWVzIHVzaW5nIGZ1bGwgMTI4IHBhY2tldCBiYXRjaCBzaXplKTo8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJn
aW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0
eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPlByZWFsbG9jYXRl
IGEgYnVmZmVyIG9mIDEyOCBieXRlcyBhbmQgcHJlcG9wdWxhdGUgaXQgd2l0aCB0aGUgdmFsdWVz
IG9mIDAgdG8gMTI3LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi
IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPkZvciBlYWNo
IHBhY2tldCBzZW50LCByYW5kb21seSBncmFiIGFuIGl0ZW0gKGkuZS4gdGhlIG9mZnNldCkgZnJv
bSB3aGF04oCZcyBsZWZ0IGluIHRoZSBidWZmZXIsIGFuZCByZW1vdmUgaXQgKHN3YXAgd2l0aCBs
YXN0IHZhbHVlLCBhbmQgZGVjcmVtZW50IGxlbmd0aCkuPG86cD48L286cD48L2xpPjxsaSBjbGFz
cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBs
ZXZlbDEgbGZvMiI+UmVwbGFjZSB0aGUgYm90dG9tIGJ5dGUgb2YgdGhlIHJlYWwgcGFja2V0IG51
bWJlciB3aXRoIHRoZSBvZmZzZXQgYW5kIHB1dCB0aGF0IG5ldyBwYWNrZXQgbnVtYmVyIGluIHRo
ZSBjbGVhciB0ZXh0LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi
IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPlB1dCB0aGUg
cmVhbCBib3R0b20gYnl0ZSBvZiB0aGUgcmVhbCBwYWNrZXQgbnVtYmVyIGluIHRoZSBlbmNyeXB0
ZWQgcG9ydGlvbi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj5FbmNyeXB0IHdp
dGggdGhlIG5ldyBjbGVhcnRleHQgcGFja2V0IG51bWJlciBhbmQgc2VuZC48bzpwPjwvbzpwPjwv
bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z
by1saXN0OmwxIGxldmVsMSBsZm8yIj5PbmNlIHRoZSBwcmVhbGxvY2F0ZWQgYnVmZmVyIGlzIGVt
cHR5LCBqdXN0IHNldCB0aGUgbGVuZ3RoIGJhY2sgdG8gMTI4IGFuZCBjb250aW51ZSBvbi48bzpw
PjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNlbmRlciBkZWNyeXB0cyB1c2luZyB0aGUg
Y2xlYXJ0ZXh0IHBhY2tldCBudW1iZXIuIFRoZW4gcmVwbGFjZXMgdGhlIGJvdHRvbSBieXRlIG9m
IHRoZSBwYWNrZXQgbnVtYmVyIHdpdGggdGhlIG9mZnNldCBmcm9tIHRoZSBlbmNyeXB0ZWQgcGF5
bG9hZCB0byBnZXQgdGhlIHRydWUgcGFja2V0IG51bWJlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+LSBOaWNrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0
OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjxicj4NCjxi
PlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDksIDIwMTggMjoyMCBQTTxicj4NCjxiPlRvOjwvYj4g
UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5p
ZXRmLm9yZyZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFNpbXBsZSB0cmFuc2Zvcm0gZm9yIGltcHJvdmluZyBQTiBvc3NpZmlj
YXRpb24gcHJldmVudGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9t
Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBpbmNpZGVu
dGFsbHkgaW1wbGVtZW50ZWQgRmlzaGVyLVlhdGVzIGEgZmV3IGRheXMgYWdv4oCmPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkJ1dCBpZiB5b3UgcGVybWl0IGEgd2luZG93LCB5
b3UgY2FuIGFsc28gZW5jcnlwdCBwYWNrZXQgbnVtYmVycyB1c2luZyBhbiBpbnRlcm5hbCBwcmVj
b21wdXRlZCBBRVMgZHJpdmVuIFBSTkcgc3RyZWFtIC0gdGhpcyBpcyBhYm91dCAxNnggZmFzdGVy
IHRoYW4gZGlyZWN0IGVuY3J5cHRpb24gYmVjYXVzZQ0KIG9uZSBibG9jayBjb3ZlcnMgNCBwYWNr
ZXRzLCBhbmQgZW5jcnlwdGlvbiBjYW4gYmUgZG9uZSBpbiBhIHBhcmFsbGVsIHBpcGVsaW5lIHdp
dGggY3VycmVudCBBRVMtTkkgaGFyZHdhcmUuIFlvdSBuZWVkIHRvIG1hcCB0aGUgd2luZG93IGlu
IGEgaGFzaCB0YWJsZSwgYW5kIGl0IG11c3QgYmUgc21hbGwgb3IgY2FjaGUgZWZmZWN0cyBtYWtl
cyBpdCB0b28gZXhwZW5zaXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBp
ZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9v
cF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5I
b3dldmVyLCBiaWcgcGFja2V0IGxvc3Mgd291bGQgbWFrZSB0aGlzIHNjaGVtZSBlaXRoZXIgaW5l
ZmZlY3RpdmUsIG9yIGNvbXBsaWNhdGVkIHdpdGggZmFsbGJhY2sgc2VhcmNoLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGFzc3VtZSB5b3VyIHByb3Bvc2VkIHNodWZmbGUg
aXMgZnVsbHkgZGV0ZXJtaW5pc3RpYyBhbmQgcHJlY29tcHV0ZWQuIEFzaWRlIGZyb20gdGhlIHBy
b2JsZW1zIHdpdGggYSB3aW5kb3cgc2l6ZSB2cyBsb3NzLCB0aGlzIGxvb2tzIGxpa2UgYSB2ZXJ5
IGdvb2Qgd2F5IHRvIGNvcnJlbGF0ZSBwYWNrZXRzDQogYmVjYXVzZSB0aGV5IG5vdyBleGhpYml0
IGEgZGlzdGluY3QgcGF0dGVybiBmb3IgZWFjaCBjb25uZWN0aW9uLiBTbyBJIGRvbuKAmXQgc2Vl
IHRoaXMgYXMgYmVpbmcgd29ydGh3aGlsZSwgaWYgSSB1bmRlcnN0YW5kIHRoZSBzY2hlbWUgY29y
cmVjdGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3Vz
dG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgc2h1ZmZsZSBj
YW4gYWxzbyBiZSBzZWVuIGFzIGEgY2xldmVyIHdheSB0byBjcmVhdGUgYSBwZXJmZWN0IGhhc2gg
dGFibGUgZm9yIHRoZSBhYm92ZSBtZW50aW9uZWQgUFJORyBzY2hlbWUsIGJ1dCBJIGRvbid0IHRo
aW5rIGl0IHdvdWxkIGJlIGVmZmVjdGl2ZSBmb3IgbGFyZ2UgZW5vdWdoDQogd2luZG93cy48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnVydGhlcm1vcmUsIGFsbCBvZiB0aGVz
ZSBzY2hlbWVzIHJlcXVpcmUgZXh0cmEgbWVtb3J5IHBlciBjb25uZWN0aW9uIGFuZCB0aGlzIGNh
biBiZSBleHBlbnNpdmUgaWYgdGhlcmUgYXJlIDEwSyYjNDM7IGlkbGUgY29ubmVjdGlvbnMgc2l0
dGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3Rv
bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+
DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj4vKjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i
Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+Jm5ic3A7KiBHaXZlbiBhbiB1bmluaXRpYWxpemVkIGBpbmRleGAgb2YgYG5gIHVpbnQ2NF90
IHNsb3RzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3Vz
dG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7
KiBQbGFjZSBhIHVuaXF1ZSB2YWx1ZSBpbiB0aGUgcmFuZ2UgMCAuLiBuIC0gMSBpbmNsdXNpdmUg
aW4gZWFjaCBzbG90PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9v
cF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m
bmJzcDsqIHVuYmlhc2VkIHJhbmRvbWx5ICh3aXRoaW4gdGhlIHBybmcgbGltaXRzKS48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyogQmFzZWQgb24gRmlzaGVyLVlh
dGVzIHNodWZmbGUgLSBpbnNpZGUgb3V0IHZhcmlhbnQuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Ki88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPnN0YXRpYyBpbmxpbmUgdm9pZCByYW5kNjRfaW5pdF9zaHVmZmxlX2Jl
bG93KHVpbnQ2NF90ICpzdGF0ZSwgdWludDY0X3QgKmluZGV4LCB1aW50NjRfdCBuKTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ezxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyB1aW50NjRfdCBpLCB4OzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IGZvciAoaSA9IDA7
IGkgJmx0OyBuOyAmIzQzOyYjNDM7aSkgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHggPSByYW5kNjRfYmVsb3co
c3RhdGUsIGkgJiM0MzsgMSk7IC8qIHVuc2lnbmVkIHJhbmRvbSB2YWx1ZSAoMCAuLiBpKSAqLzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7IGluZGV4W2ldID0gaW5kZXhbeF07IC8qIFVuaW5pdGlhbGl6ZWQgaWYgaSA9
PSB4LCB3aGljaCBpcyBvay4gKi88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg
aWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmRleFt4XSA9IGk7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IH08bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPn08bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPk1pa2tlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9ImFpcm1haWxvbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDkgQXByaWwg
MjAxOCBhdCAyMi40OC40OCwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gKDxhIGhyZWY9Im1haWx0
bzpwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciPnByYXZiPTQwbWljcm9zb2Z0
LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4pIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+VGhlIGN1cnJlbnQgYXBwcm9hY2ggaW4gdGhlIGRyYWZ0IGZvciBwcmV2ZW50aW5nIFBO
IG9zc2lmaWNhdGlvbiBpcyB0byB1c2UgYSByYW5kb20gc3RhcnRpbmcgUE4uIEthenVobyBwb2lu
dGVkDQogb3V0IGEgcHJvYmxlbSB3aXRoIHRoaXMgYXBwcm9hY2ggd2hlcmUgbWlkZGxlYm94ZXMg
Y291bGQgaW50ZXJwcmV0IHRoZSBQTiBhcyBhIHNlcXVlbmNlIG51bWJlci4gQW5kIGluIGFuIGF0
dGVtcHQgdG8gYmUg4oCcaGVscGZ1bOKAnSwgdGhleSBjb3VsZCByZW9yZGVyIHRoZSBwYWNrZXRz
IGV4YWNlcmJhdGluZyB0aGUgSG9MIGJsb2NraW5nIHByb2JsZW0gYW5kIG1heSBjYXVzZSBpc3N1
ZXMgZm9yIHVucmVsaWFibGUgc2VtYW50aWNzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SWYg
dGhlIFBODQo8aT5pbiB0aGUgY2xlYXI8L2k+ICh0aGUgbm9uY2UgdmFsdWUpIGRpZG7igJl0IGFs
d2F5cyBtb25vdG9uaWNhbGx5IGluY3JlYXNlIHRoZW4gaXQgd2lsbCBwcmVjbHVkZSBzdWNoIGJh
ZCBiZWhhdmlvciBieSB0aGUgbWlkZGxlYm94ZXMuIEhlbmNlIHdlIG5lZWQgdG8gZmluZCBhIHNp
bXBsZSB0cmFuc2Zvcm0gdGhhdCBpcyBub3QgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIGFuZCBh
bHNvIG5vdCByZXBlYXRpbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5SZXF1aXJlbWVudHMg
Zm9yIGFueSBQTiB0cmFuc2Zvcm0gaW4gdGhlIHNpbmdsZSBwYXRoIGNhc2U6PG86cD48L286cD48
L3NwYW4+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBhY3R1
YWwgUE4gbXVzdCBhbHdheXMgaW5jcmVtZW50IGJ5IDEgYW5kIHdpbGwgYmUgdXNlZCBmb3IgZ2Vu
ZXJhdGluZyBBQ0tzIGluIEFDSyBmcmFtZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPlRoZSB0cmFuc2Zvcm1lZCBQTiBpbiB0aGUgY2xlYXIgaXMgYSBub25jZSBhbmQgbXVz
dCBub3QgcmVwZWF0IG92ZXIgdGhlIGNvbm5lY3Rpb24gbGlmZXRpbWUuPG86cD48L286cD48L3Nw
YW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N
CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5NaWRkbGVib3hlcyBtdXN0IG5vdCBiZSBhYmxlIHRvIGRldGVy
bWluZSB0aGUgYWN0dWFsIFBOLiBPbmx5IHRoZSBRVUlDIHJlY2VpdmVyIHNob3VsZCBiZSBhYmxl
IHRvIGRvIHNvLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlBORSBpcyBvbmUgcG9zc2li
bGUgdHJhbnNmb3JtIHRoYXQgbWVldHMgYWxsIHRoZXNlIHJlcXVpcmVtZW50cyBidXQgaXQgaXMg
ZXhwZW5zaXZlIENQVSBjb3N0IHdpc2UgYW5kIGhhcyBpbXBsaWNhdGlvbnMNCiBmb3IgaGFyZHdh
cmUgaW1wbGVtZW50YXRpb25zLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gb2xsb3dpbmcgaXMg
YSBwcm9wb3NhbCBmb3IgYW4gYWx0ZXJuYXRpdmUgc2ltcGxlIHRyYW5zZm9ybSB3aXRoIGxvdyBD
UFUgb3ZlcmhlYWQgd2hpY2ggc2F0aXNmaWVzIHRoZXNlIHRocmVlIHJlcXVpcmVtZW50cy4NCiBU
aGUgZ29hbCBpcyB0byBwcm9kdWNlIGEgbm9uLXJlcGVhdGluZyBzaHVmZmxlIG9mIHRoZSBvcmln
aW5hbCBzZXQgb2YgbnVtYmVycy4gU2luY2UgdGhlIFBOIHNwYWNlIGlzIHZlcnkgYmlnIGFuZCBl
ZmZpY2llbnQgc2h1ZmZsZSBhbGdvcml0aG1zIGhhdmUgTyhuKSBzcGFjZSByZXF1aXJlbWVudCwg
d2UgbmVlZCB0byBkZWZpbmUgYSDigJxyZW9yZGVyIGRlZ3JlZeKAnSBvciBhIOKAnGJhdGNoIHNp
emXigJ0gd2l0aGluIHdoaWNoIHdlIHdpbGwgc2h1ZmZsZQ0KIHRoZSBwYWNrZXQgbnVtYmVycy48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj5BcyBhbiBleGFtcGxlIGNvbnNpZGVyIHRoYXQgdGhlIHN0
YXJ0aW5nIHJhbmRvbSBQTiBpcyAxMDAuIFBlciB0aGUgY3VycmVudCBkcmFmdCB0aGUgYWN0dWFs
IFBOIGluY3JlbWVudHMgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgMTAw
LCAxMDEsIDEwMiwgMTAzLCAxMDQsICZuYnNwOyZuYnNwOyZuYnNwOzEwNSwgMTA2LCAxMDcsIDEw
OCwgMTA5LCDigKYgYW5kIHNvIGZvcnRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TGV04oCZcyBh
c3N1bWUgYSDigJxiYXRjaCBzaXpl4oCdIG9mIDUuIFRoZW4gdXNpbmcgb25lIHBvc3NpYmxlIG91
dGNvbWUgb2YgdGhlIHNodWZmbGVzIHdlIGNhbiBnZW5lcmF0ZSB0aGUgZm9sbG93aW5nDQogYXMg
dGhlIGNsZWFydGV4dCBub25jZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+fCZuYnNwOyAxMDIsIDEwNCwgMTAzLCAxMDEs
IDEwMCwgfCZuYnNwOyAxMDcsIDEwNSwgMTA5LCAxMDgsIDEwNiB8ICZuYnNwOyZuYnNwOyzigKYg
YW5kIHNvIGZvcnRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGJhcnMgfCBpbmRpY2F0ZSBiYXRjaCBib3VuZGFyaWVz
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9mIGNvdXJzZSBzaW5jZSB3ZSBuZWVkIHRoZSBRVUlD
IHJlY2VpdmVyIHRvIGdldCB0aGUgYWN0dWFsIFBOIGZyb20gdGhlIGNsZWFydGV4dCB2YWx1ZSwg
d2UgbmVlZCB0byBjb21tdW5pY2F0ZQ0KIHRoZSBvZmZzZXRzIGluIHRoZSBlbmNyeXB0ZWQgcG9y
dGlvbiBvZiB0aGUgcGFja2V0LCB3aGljaCBmb3IgdGhpcyBleGFtcGxlIHdvdWxkIGJlOjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPnwmbmJzcDsgJiM0MzsyLCAmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOzMsICZuYnNwOyZuYnNw
OyYjNDM7MSwgJm5ic3A7Jm5ic3A7LTIsICZuYnNwOyZuYnNwOy00LCZuYnNwOyZuYnNwOyZuYnNw
OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0yLCAmbmJzcDsmbmJzcDsmIzQzOzEsICZuYnNwOyZuYnNw
Oy0yLCAmbmJzcDsmbmJzcDsmbmJzcDswLCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOzMg
Jm5ic3A7Jm5ic3A7Jm5ic3A7fCwgJm5ic3A74oCmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk1pZGRsZWJveGVzIHdpbGwg
bm90IGJlIGFibGUgdG8gc2VlIHRoZSBvZmZzZXQgdmFsdWVzIGluIHRoZSBjbGVhci4gUVVJQyBy
ZWNlaXZlciB3aWxsIG5lZWQgdG8gZG8gYSBzaW1wbGUgYWRkDQogb2YgYSBzaWduZWQgbnVtYmVy
IHRvIGdldCB0aGUgb3JpZ2luYWwgUE4uIFRoaXMgaXMgdmVyeSBjaGVhcCBvcGVyYXRpb24gQ1BV
IGNvc3Qgd2lzZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkEgUVVJQyBzZW5kZXIgaW1wbGVt
ZW50YXRpb24gY2FuIHBpY2sgYW55IHNpemUgZm9yIHRoZSByZW9yZGVyIGRlZ3JlZSwgdGhlIHRy
YWRlLW9mZiBpcyB0aGUgc3BhY2UgY29tcGxleGl0eSBhbmQNCiBwYWNrZXQgc3BhY2UgbmVlZGVk
IHRvIGNvbW11bmljYXRlIHRoZSBvZmZzZXRzLiBBIHJlb3JkZXIgZGVncmVlIHdpdGhpbiAxMjgg
bnVtYmVycyB3aWxsIG5lZWQgYXQgbW9zdCBhbiBleHRyYSBieXRlIGluIHRoZSBlbmNyeXB0ZWQg
aGVhZGVyIHRvIGNvbW11bmljYXRlIHRoZSBzaWduZWQgb2Zmc2V0IHZhbHVlcy4gVGhlIDEyOCBi
YXRjaCBzaXplIGkuZS4gYSAxIGJ5dGUgb2Zmc2V0IHNpemUgc2hvdWxkIGJlIG1vcmUgdGhhbiBl
bm91Z2ggZW50cm9weQ0KIHRvIGRpc2NvdXJhZ2UgYSBtaWRkbGUgYm94IGZyb20g4oCcZml4aW5n
IHJlb3JkZXJpbmfigJ0gYW5kIGluIHByYWN0aWNlIHdlIG1heSBuZWVkIGxlc3MuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+T25lIHBvc3NpYmxlIGFsZ29yaXRobSBmb3IgdGhlIHNodWZmbGUgaXMg
dGhlIEZpc2hlcuKAk1lhdGVzIChLbnV0aCkgc2h1ZmZsZSBhcyBkb2N1bWVudGVkIGhlcmU6DQo8
YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy
bD1odHRwczolMkYlMkZlbi53aWtpcGVkaWEub3JnJTJGd2lraSUyRkZpc2hlciVFMiU4MCU5M1lh
dGVzX3NodWZmbGUmYW1wO2RhdGE9MDIlN0MwMSU3Q25pYmFua3MlNDBtaWNyb3NvZnQuY29tJTdD
Y2IxZDJkZWFiNTUxNDE5ZmIzMjIwOGQ1OWU1ZmIwNjklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk
N2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTg5MDU2MTkzODYyODY4JmFtcDtzZGF0YT1JUWhOUHIx
UTZTZyUyQjU0b0FDbGJ5R2hIZDZxN3Jsd3JQOWV1SDZRa1k2RVUlM0QmYW1wO3Jlc2VydmVkPTAi
Pg0KaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRmlzaGVy4oCTWWF0ZXNfc2h1ZmZsZTwv
YT4gLiBQbGVhc2Ugc2VlIHRoZSDigJxNb2Rlcm4gbWV0aG9k4oCdIHNlY3Rpb24gd2hpY2ggaXMg
aW4tcGxhY2UuIFRoZSByYW5kb20gbnVtYmVyIGdlbmVyYXRvciBkb2VzbuKAmXQgaGF2ZSB0byBi
ZSBhIHNlY3VyZSB2YXJpYW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uZSBhZHZhbnRhZ2Ug
b2Ygc3VjaCBhIHNjaGVtZSBpcyB0aGF0IHBhY2tldCBsb3NzIGNhbiBzdGlsbCBiZSBpbmZlcnJl
ZCBieSBsb29raW5nIGF0IGVhY2ggYmF0Y2ggc2l6ZWQgc2V0IG9mDQogdGhlIG5vbmNlIChwYWNr
ZXQgbnVtYmVycykuIEZvciBleGFtcGxlIGlmIHRoZSBiYXRjaCBzaXplIGlzIDEyOCwgdGhlbiBt
aXNzaW5nIG51bWJlcnMgaW4gdGhpcyBiYXRjaCBzaXplIChvciBhIG11bHRpcGxlKSB3aWxsIHNo
b3cgdGhlIGV4dGVudCBvZiBwYWNrZXQgbG9zcy4gVGhlIG90aGVyIGFkdmFudGFnZSBpcyB0aGF0
IGEgUVVJQyBkaWFnbm9zdGljIGNvbm5lY3Rpb24gY2FuIHRyaXZpYWxseSBkZXRlY3QgYSBiYWQg
bWlkZGxlYm94IHRoYXQNCiB0cmllcyB0byByZW9yZGVyIHRoZSBub25jZSBpbiBzZXF1ZW5jZSBh
cyBpdCB3aWxsIGJlIGVhc2lseSBkaXN0aW5ndWlzaGFibGUgZnJvbSBhIHJhbmRvbSBuZXR3b3Jr
IHJlb3JkZXIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv
Ym9keT4NCjwvaHRtbD4NCg==

--_000_DM5PR2101MB0901BDA387CF7CA119926CAFB3BF0DM5PR2101MB0901_--


From nobody Mon Apr  9 14:33:17 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7034512D7F5 for ; Mon,  9 Apr 2018 14:33:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523309591; bh=RZRhO/A3/zeztzcLNvrK1O7j6SxzC/Av/629bZU3Cro=; h=From:Subject:Date:References:In-Reply-To:To:To:To; b=HXKUlBYUiOU2uXnUYBHbunB4y6FawrncIqT6w6IcWisZ7s82V4RGwo2IQARNvQDTw JbGo9cAH0IuyC+orpa+P93LJtZT7E2dt1wOgXgcSJfX+YxkE3u2RThMSwvIYUlnE3q oXYABCTJOM8EBUWtwm2UfY8cIaCk3OY8XeJHV0wE=
X-Mailbox-Line: From nibanks@microsoft.com  Mon Apr  9 14:33:11 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3926C12D94B; Mon,  9 Apr 2018 14:33:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523309591; bh=RZRhO/A3/zeztzcLNvrK1O7j6SxzC/Av/629bZU3Cro=; h=From:Subject:Date:References:In-Reply-To:To:To:To; b=HXKUlBYUiOU2uXnUYBHbunB4y6FawrncIqT6w6IcWisZ7s82V4RGwo2IQARNvQDTw JbGo9cAH0IuyC+orpa+P93LJtZT7E2dt1wOgXgcSJfX+YxkE3u2RThMSwvIYUlnE3q oXYABCTJOM8EBUWtwm2UfY8cIaCk3OY8XeJHV0wE=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BE112D7F5 for ; Mon,  9 Apr 2018 14:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.021
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable 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 hg7WDjjdSAoP for ; Mon,  9 Apr 2018 14:33:07 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on071b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe41::71b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A43612D94B for ; Mon,  9 Apr 2018 14:33:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RZRhO/A3/zeztzcLNvrK1O7j6SxzC/Av/629bZU3Cro=; b=irBqJ9nLuWJTeGA4ZmU/neCy+w77TkINPJuFETBwel9y7aY9dZyCh5+1s1ssQvAI0fRF8oq/C0jrnFrCtWKmeQEXTjQLpQLGuPnfkw0r3ptxRW6dav+94rdi76mor1g/odQWnYpUJqrDGjZL4snVqvuMjQUnFIz8UbU3jJRhMMk=
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB0885.namprd21.prod.outlook.com (52.132.132.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Mon, 9 Apr 2018 21:33:04 +0000
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::49f0:9e08:d65d:b0dc]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::49f0:9e08:d65d:b0dc%4]) with mapi id 15.20.0696.003; Mon, 9 Apr 2018 21:33:04 +0000
From: Nick Banks 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwABL1oAAAAKT4A=
Date: Mon, 9 Apr 2018 21:33:04 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-04-09T21:33:02.6402577Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:4::490]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0885; 7:oqAOyQ5L2qQflNmcmOEbXXpOaOqRRgi2FxrC6QcUaszHlwAk2kQjG9Me1mXDRHkFwNgxr92FJXomqXMkqqBBPk1+rOUKn/L6kO8XP6plvQT1lf9/nYFJLfI9dbeapfJhtbWKeK9zd6QoEza9cRfH5e/jl3J/cVD4WF8U0BGRYKbsQG+t5xE6T1vW7xokkE6G3leUwFrpbUEaQsI4kBYOyLLoCPNqy1UDiKTlY0KZ9i/aVawgOOjZ3Uf/yHUcjuMa; 20:ogLqXEhDz2NyiEvo+9d31G3q78cq2CwaRS2GqX7Ck91RTATm35yz+bkzC6sNXdFS8w3U1KF2BuGC4ipnT8M6ywGO2aL2/3RSbQwThupAT1rcazwXXdbZbRAHksRJa7LwdQKTBvgKlOGW3tf+1Oo7SfFY+INlTJ3os/7t8urfUNE=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(3008032)(48565401081)(2017052603328)(7193020); SRVR:DM5PR2101MB0885; 
x-ms-traffictypediagnostic: DM5PR2101MB0885:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(189930954265078)(788757137089)(219752817060721)(21748063052155)(17755550239193)(15185016700835);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR2101MB0885; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0885; 
x-forefront-prvs: 0637FCE711
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(396003)(376002)(366004)(39860400002)(199004)(189003)(39060400002)(74316002)(59450400001)(6246003)(6116002)(790700001)(86362001)(5250100002)(3280700002)(10290500003)(6436002)(10090500001)(3660700001)(53546011)(446003)(53936002)(966005)(6506007)(33656002)(606006)(76176011)(478600001)(7736002)(7696005)(81156014)(476003)(25786009)(8676002)(561944003)(11346002)(46003)(81166006)(8936002)(186003)(55016002)(102836004)(8990500004)(99286004)(236005)(14454004)(54896002)(6306002)(9686003)(316002)(68736007)(486006)(5660300001)(110136005)(22452003)(2906002)(2900100001)(86612001)(229853002)(106356001)(19609705001)(97736004)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0885; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 07Ftk0pjZq+J7MIlHu8yIIBJrSOKBhyIQhpwQ6I0S46ynjqKuuWaqXbgiBZw4qLbImf9t2E0PKEICS3NB6csOQKgPIBbZ/rC8bYSmk7KBrWnmRK6FDM3FkKNYmaUffQUkdOH6u1NYLgtk/R7BMybKuhBz3AtLckMCDSmgZA4ngoF8HNe9ATWzX0K7hiHgDGpIsKPjAVAPm9PKR/1wLB2ye6U41fUDC4HdItA0jGwH/JRHdb62O7PJECn+bdQOsds0xXeZ2E/NUBRU6ezLl+xQD0/l2ivlMBPxQuWnD7cO1CUwbbFejbkT6hGbbXfbwvZUDSGdIfK2HTxRO0hplkr+shxMFb08U/2vcH8cBccG3ZUMTjWrDg8dcBp10SpQveFSBOSUhsfeXfe+a4hiNKezXAQY6gCfjCblhLJ4syvdIQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB0901BDA387CF7CA119926CAFB3BF0DM5PR2101MB0901_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 4d68a1e3-9f03-4afd-0b63-08d59e617a35
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4d68a1e3-9f03-4afd-0b63-08d59e617a35
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 21:33:04.0985 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0885
To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= 
To: Praveen Balasubramanian 
To: IETF QUIC WG 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 21:33:12 -0000

--_000_DM5PR2101MB0901BDA387CF7CA119926CAFB3BF0DM5PR2101MB0901_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIGdvYWwgaGVyZSB3b3VsZCBlc3NlbnRpYWxseSBqdXN0IHRvIHNodWZmbGUgdGhlIGJpdHMg
aW4gdGhlIGJvdHRvbSBieXRlLCBqdXN0IHRvIG1ha2UgZXZlcnl0aGluZyBsb29rIHJlb3JkZXJl
ZCB0byB0aGUgbWlkZGxlYm94LiBZb3UgZG9u4oCZdCByZWFsbHkgaGF2ZSB0byBwcmVjb21wdXRl
IGFueXRoaW5nLCBhbmQgaXQgc2hvdWxkIGJlIGluZGVwZW5kZW50IG9mIEJEUCBvciBsb3NzLg0K
DQpIZXJlIGlzIGEgc2xpZ2h0IHZhcmlhdGlvbiBvbiBQcmF2ZWVu4oCZcyBzdWdnZXN0aW9uIChh
c3N1bWVzIHVzaW5nIGZ1bGwgMTI4IHBhY2tldCBiYXRjaCBzaXplKToNCg0KDQogICogICBQcmVh
bGxvY2F0ZSBhIGJ1ZmZlciBvZiAxMjggYnl0ZXMgYW5kIHByZXBvcHVsYXRlIGl0IHdpdGggdGhl
IHZhbHVlcyBvZiAwIHRvIDEyNy4NCiAgKiAgIEZvciBlYWNoIHBhY2tldCBzZW50LCByYW5kb21s
eSBncmFiIGFuIGl0ZW0gKGkuZS4gdGhlIG9mZnNldCkgZnJvbSB3aGF04oCZcyBsZWZ0IGluIHRo
ZSBidWZmZXIsIGFuZCByZW1vdmUgaXQgKHN3YXAgd2l0aCBsYXN0IHZhbHVlLCBhbmQgZGVjcmVt
ZW50IGxlbmd0aCkuDQogICogICBSZXBsYWNlIHRoZSBib3R0b20gYnl0ZSBvZiB0aGUgcmVhbCBw
YWNrZXQgbnVtYmVyIHdpdGggdGhlIG9mZnNldCBhbmQgcHV0IHRoYXQgbmV3IHBhY2tldCBudW1i
ZXIgaW4gdGhlIGNsZWFyIHRleHQuDQogICogICBQdXQgdGhlIHJlYWwgYm90dG9tIGJ5dGUgb2Yg
dGhlIHJlYWwgcGFja2V0IG51bWJlciBpbiB0aGUgZW5jcnlwdGVkIHBvcnRpb24uDQogICogICBF
bmNyeXB0IHdpdGggdGhlIG5ldyBjbGVhcnRleHQgcGFja2V0IG51bWJlciBhbmQgc2VuZC4NCiAg
KiAgIE9uY2UgdGhlIHByZWFsbG9jYXRlZCBidWZmZXIgaXMgZW1wdHksIGp1c3Qgc2V0IHRoZSBs
ZW5ndGggYmFjayB0byAxMjggYW5kIGNvbnRpbnVlIG9uLg0KDQpUaGUgc2VuZGVyIGRlY3J5cHRz
IHVzaW5nIHRoZSBjbGVhcnRleHQgcGFja2V0IG51bWJlci4gVGhlbiByZXBsYWNlcyB0aGUgYm90
dG9tIGJ5dGUgb2YgdGhlIHBhY2tldCBudW1iZXIgd2l0aCB0aGUgb2Zmc2V0IGZyb20gdGhlIGVu
Y3J5cHRlZCBwYXlsb2FkIHRvIGdldCB0aGUgdHJ1ZSBwYWNrZXQgbnVtYmVyLg0KDQotIE5pY2sN
Cg0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWlra2Vs
IEZhaG7DuGUgSsO4cmdlbnNlbg0KU2VudDogTW9uZGF5LCBBcHJpbCA5LCAyMDE4IDI6MjAgUE0N
ClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJj
LmlldGYub3JnPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFNp
bXBsZSB0cmFuc2Zvcm0gZm9yIGltcHJvdmluZyBQTiBvc3NpZmljYXRpb24gcHJldmVudGlvbg0K
DQpJIGluY2lkZW50YWxseSBpbXBsZW1lbnRlZCBGaXNoZXItWWF0ZXMgYSBmZXcgZGF5cyBhZ2/i
gKYNCg0KQnV0IGlmIHlvdSBwZXJtaXQgYSB3aW5kb3csIHlvdSBjYW4gYWxzbyBlbmNyeXB0IHBh
Y2tldCBudW1iZXJzIHVzaW5nIGFuIGludGVybmFsIHByZWNvbXB1dGVkIEFFUyBkcml2ZW4gUFJO
RyBzdHJlYW0gLSB0aGlzIGlzIGFib3V0IDE2eCBmYXN0ZXIgdGhhbiBkaXJlY3QgZW5jcnlwdGlv
biBiZWNhdXNlIG9uZSBibG9jayBjb3ZlcnMgNCBwYWNrZXRzLCBhbmQgZW5jcnlwdGlvbiBjYW4g
YmUgZG9uZSBpbiBhIHBhcmFsbGVsIHBpcGVsaW5lIHdpdGggY3VycmVudCBBRVMtTkkgaGFyZHdh
cmUuIFlvdSBuZWVkIHRvIG1hcCB0aGUgd2luZG93IGluIGEgaGFzaCB0YWJsZSwgYW5kIGl0IG11
c3QgYmUgc21hbGwgb3IgY2FjaGUgZWZmZWN0cyBtYWtlcyBpdCB0b28gZXhwZW5zaXZlLg0KDQpI
b3dldmVyLCBiaWcgcGFja2V0IGxvc3Mgd291bGQgbWFrZSB0aGlzIHNjaGVtZSBlaXRoZXIgaW5l
ZmZlY3RpdmUsIG9yIGNvbXBsaWNhdGVkIHdpdGggZmFsbGJhY2sgc2VhcmNoLg0KDQpJIGFzc3Vt
ZSB5b3VyIHByb3Bvc2VkIHNodWZmbGUgaXMgZnVsbHkgZGV0ZXJtaW5pc3RpYyBhbmQgcHJlY29t
cHV0ZWQuIEFzaWRlIGZyb20gdGhlIHByb2JsZW1zIHdpdGggYSB3aW5kb3cgc2l6ZSB2cyBsb3Nz
LCB0aGlzIGxvb2tzIGxpa2UgYSB2ZXJ5IGdvb2Qgd2F5IHRvIGNvcnJlbGF0ZSBwYWNrZXRzIGJl
Y2F1c2UgdGhleSBub3cgZXhoaWJpdCBhIGRpc3RpbmN0IHBhdHRlcm4gZm9yIGVhY2ggY29ubmVj
dGlvbi4gU28gSSBkb27igJl0IHNlZSB0aGlzIGFzIGJlaW5nIHdvcnRod2hpbGUsIGlmIEkgdW5k
ZXJzdGFuZCB0aGUgc2NoZW1lIGNvcnJlY3RseS4NCg0KVGhlIHNodWZmbGUgY2FuIGFsc28gYmUg
c2VlbiBhcyBhIGNsZXZlciB3YXkgdG8gY3JlYXRlIGEgcGVyZmVjdCBoYXNoIHRhYmxlIGZvciB0
aGUgYWJvdmUgbWVudGlvbmVkIFBSTkcgc2NoZW1lLCBidXQgSSBkb24ndCB0aGluayBpdCB3b3Vs
ZCBiZSBlZmZlY3RpdmUgZm9yIGxhcmdlIGVub3VnaCB3aW5kb3dzLg0KDQpGdXJ0aGVybW9yZSwg
YWxsIG9mIHRoZXNlIHNjaGVtZXMgcmVxdWlyZSBleHRyYSBtZW1vcnkgcGVyIGNvbm5lY3Rpb24g
YW5kIHRoaXMgY2FuIGJlIGV4cGVuc2l2ZSBpZiB0aGVyZSBhcmUgMTBLKyBpZGxlIGNvbm5lY3Rp
b25zIHNpdHRpbmcuDQoNCi8qDQogKiBHaXZlbiBhbiB1bmluaXRpYWxpemVkIGBpbmRleGAgb2Yg
YG5gIHVpbnQ2NF90IHNsb3RzOg0KICogUGxhY2UgYSB1bmlxdWUgdmFsdWUgaW4gdGhlIHJhbmdl
IDAgLi4gbiAtIDEgaW5jbHVzaXZlIGluIGVhY2ggc2xvdA0KICogdW5iaWFzZWQgcmFuZG9tbHkg
KHdpdGhpbiB0aGUgcHJuZyBsaW1pdHMpLg0KICoNCiAqIEJhc2VkIG9uIEZpc2hlci1ZYXRlcyBz
aHVmZmxlIC0gaW5zaWRlIG91dCB2YXJpYW50Li4NCiAqLw0Kc3RhdGljIGlubGluZSB2b2lkIHJh
bmQ2NF9pbml0X3NodWZmbGVfYmVsb3codWludDY0X3QgKnN0YXRlLCB1aW50NjRfdCAqaW5kZXgs
IHVpbnQ2NF90IG4pDQp7DQogICAgdWludDY0X3QgaSwgeDsNCg0KICAgIGZvciAoaSA9IDA7IGkg
PCBuOyArK2kpIHsNCiAgICAgICAgeCA9IHJhbmQ2NF9iZWxvdyhzdGF0ZSwgaSArIDEpOyAvKiB1
bnNpZ25lZCByYW5kb20gdmFsdWUgKDAgLi4gaSkgKi8NCiAgICAgICAgaW5kZXhbaV0gPSBpbmRl
eFt4XTsgLyogVW5pbml0aWFsaXplZCBpZiBpID09IHgsIHdoaWNoIGlzIG9rLiAqLw0KICAgICAg
ICBpbmRleFt4XSA9IGk7DQogICAgfQ0KfQ0KDQoNCk1pa2tlbA0KDQoNCg0KT24gOSBBcHJpbCAy
MDE4IGF0IDIyLjQ4LjQ4LCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAocHJhdmI9NDBtaWNyb3Nv
ZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMu
aWV0Zi5vcmc+KSB3cm90ZToNClRoZSBjdXJyZW50IGFwcHJvYWNoIGluIHRoZSBkcmFmdCBmb3Ig
cHJldmVudGluZyBQTiBvc3NpZmljYXRpb24gaXMgdG8gdXNlIGEgcmFuZG9tIHN0YXJ0aW5nIFBO
LiBLYXp1aG8gcG9pbnRlZCBvdXQgYSBwcm9ibGVtIHdpdGggdGhpcyBhcHByb2FjaCB3aGVyZSBt
aWRkbGVib3hlcyBjb3VsZCBpbnRlcnByZXQgdGhlIFBOIGFzIGEgc2VxdWVuY2UgbnVtYmVyLiBB
bmQgaW4gYW4gYXR0ZW1wdCB0byBiZSDigJxoZWxwZnVs4oCdLCB0aGV5IGNvdWxkIHJlb3JkZXIg
dGhlIHBhY2tldHMgZXhhY2VyYmF0aW5nIHRoZSBIb0wgYmxvY2tpbmcgcHJvYmxlbSBhbmQgbWF5
IGNhdXNlIGlzc3VlcyBmb3IgdW5yZWxpYWJsZSBzZW1hbnRpY3MuDQoNCklmIHRoZSBQTiBpbiB0
aGUgY2xlYXIgKHRoZSBub25jZSB2YWx1ZSkgZGlkbuKAmXQgYWx3YXlzIG1vbm90b25pY2FsbHkg
aW5jcmVhc2UgdGhlbiBpdCB3aWxsIHByZWNsdWRlIHN1Y2ggYmFkIGJlaGF2aW9yIGJ5IHRoZSBt
aWRkbGVib3hlcy4gSGVuY2Ugd2UgbmVlZCB0byBmaW5kIGEgc2ltcGxlIHRyYW5zZm9ybSB0aGF0
IGlzIG5vdCBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmcgYW5kIGFsc28gbm90IHJlcGVhdGluZy4N
Cg0KUmVxdWlyZW1lbnRzIGZvciBhbnkgUE4gdHJhbnNmb3JtIGluIHRoZSBzaW5nbGUgcGF0aCBj
YXNlOg0KDQogIDEuICBUaGUgYWN0dWFsIFBOIG11c3QgYWx3YXlzIGluY3JlbWVudCBieSAxIGFu
ZCB3aWxsIGJlIHVzZWQgZm9yIGdlbmVyYXRpbmcgQUNLcyBpbiBBQ0sgZnJhbWVzLg0KICAyLiAg
VGhlIHRyYW5zZm9ybWVkIFBOIGluIHRoZSBjbGVhciBpcyBhIG5vbmNlIGFuZCBtdXN0IG5vdCBy
ZXBlYXQgb3ZlciB0aGUgY29ubmVjdGlvbiBsaWZldGltZS4NCiAgMy4gIE1pZGRsZWJveGVzIG11
c3Qgbm90IGJlIGFibGUgdG8gZGV0ZXJtaW5lIHRoZSBhY3R1YWwgUE4uIE9ubHkgdGhlIFFVSUMg
cmVjZWl2ZXIgc2hvdWxkIGJlIGFibGUgdG8gZG8gc28uDQoNClBORSBpcyBvbmUgcG9zc2libGUg
dHJhbnNmb3JtIHRoYXQgbWVldHMgYWxsIHRoZXNlIHJlcXVpcmVtZW50cyBidXQgaXQgaXMgZXhw
ZW5zaXZlIENQVSBjb3N0IHdpc2UgYW5kIGhhcyBpbXBsaWNhdGlvbnMgZm9yIGhhcmR3YXJlIGlt
cGxlbWVudGF0aW9ucy4NCg0KRm9sbG93aW5nIGlzIGEgcHJvcG9zYWwgZm9yIGFuIGFsdGVybmF0
aXZlIHNpbXBsZSB0cmFuc2Zvcm0gd2l0aCBsb3cgQ1BVIG92ZXJoZWFkIHdoaWNoIHNhdGlzZmll
cyB0aGVzZSB0aHJlZSByZXF1aXJlbWVudHMuIFRoZSBnb2FsIGlzIHRvIHByb2R1Y2UgYSBub24t
cmVwZWF0aW5nIHNodWZmbGUgb2YgdGhlIG9yaWdpbmFsIHNldCBvZiBudW1iZXJzLiBTaW5jZSB0
aGUgUE4gc3BhY2UgaXMgdmVyeSBiaWcgYW5kIGVmZmljaWVudCBzaHVmZmxlIGFsZ29yaXRobXMg
aGF2ZSBPKG4pIHNwYWNlIHJlcXVpcmVtZW50LCB3ZSBuZWVkIHRvIGRlZmluZSBhIOKAnHJlb3Jk
ZXIgZGVncmVl4oCdIG9yIGEg4oCcYmF0Y2ggc2l6ZeKAnSB3aXRoaW4gd2hpY2ggd2Ugd2lsbCBz
aHVmZmxlIHRoZSBwYWNrZXQgbnVtYmVycy4NCg0KQXMgYW4gZXhhbXBsZSBjb25zaWRlciB0aGF0
IHRoZSBzdGFydGluZyByYW5kb20gUE4gaXMgMTAwLiBQZXIgdGhlIGN1cnJlbnQgZHJhZnQgdGhl
IGFjdHVhbCBQTiBpbmNyZW1lbnRzIGFzIGZvbGxvd3M6DQogICAgMTAwLCAxMDEsIDEwMiwgMTAz
LCAxMDQsICAgIDEwNSwgMTA2LCAxMDcsIDEwOCwgMTA5LCDigKYgYW5kIHNvIGZvcnRoDQoNCkxl
dOKAmXMgYXNzdW1lIGEg4oCcYmF0Y2ggc2l6ZeKAnSBvZiA1LiBUaGVuIHVzaW5nIG9uZSBwb3Nz
aWJsZSBvdXRjb21lIG9mIHRoZSBzaHVmZmxlcyB3ZSBjYW4gZ2VuZXJhdGUgdGhlIGZvbGxvd2lu
ZyBhcyB0aGUgY2xlYXJ0ZXh0IG5vbmNlczoNCnwgIDEwMiwgMTA0LCAxMDMsIDEwMSwgMTAwLCB8
ICAxMDcsIDEwNSwgMTA5LCAxMDgsIDEwNiB8ICAgLOKApiBhbmQgc28gZm9ydGgNClRoZSBiYXJz
IHwgaW5kaWNhdGUgYmF0Y2ggYm91bmRhcmllcy4NCg0KT2YgY291cnNlIHNpbmNlIHdlIG5lZWQg
dGhlIFFVSUMgcmVjZWl2ZXIgdG8gZ2V0IHRoZSBhY3R1YWwgUE4gZnJvbSB0aGUgY2xlYXJ0ZXh0
IHZhbHVlLCB3ZSBuZWVkIHRvIGNvbW11bmljYXRlIHRoZSBvZmZzZXRzIGluIHRoZSBlbmNyeXB0
ZWQgcG9ydGlvbiBvZiB0aGUgcGFja2V0LCB3aGljaCBmb3IgdGhpcyBleGFtcGxlIHdvdWxkIGJl
Og0KfCAgKzIsICAgICszLCAgICsxLCAgIC0yLCAgIC00LCAgICB8ICAgIC0yLCAgICsxLCAgIC0y
LCAgICAwLCAgICAgKzMgICAgfCwgIOKApi4NCk1pZGRsZWJveGVzIHdpbGwgbm90IGJlIGFibGUg
dG8gc2VlIHRoZSBvZmZzZXQgdmFsdWVzIGluIHRoZSBjbGVhci4gUVVJQyByZWNlaXZlciB3aWxs
IG5lZWQgdG8gZG8gYSBzaW1wbGUgYWRkIG9mIGEgc2lnbmVkIG51bWJlciB0byBnZXQgdGhlIG9y
aWdpbmFsIFBOLiBUaGlzIGlzIHZlcnkgY2hlYXAgb3BlcmF0aW9uIENQVSBjb3N0IHdpc2UuDQoN
CkEgUVVJQyBzZW5kZXIgaW1wbGVtZW50YXRpb24gY2FuIHBpY2sgYW55IHNpemUgZm9yIHRoZSBy
ZW9yZGVyIGRlZ3JlZSwgdGhlIHRyYWRlLW9mZiBpcyB0aGUgc3BhY2UgY29tcGxleGl0eSBhbmQg
cGFja2V0IHNwYWNlIG5lZWRlZCB0byBjb21tdW5pY2F0ZSB0aGUgb2Zmc2V0cy4gQSByZW9yZGVy
IGRlZ3JlZSB3aXRoaW4gMTI4IG51bWJlcnMgd2lsbCBuZWVkIGF0IG1vc3QgYW4gZXh0cmEgYnl0
ZSBpbiB0aGUgZW5jcnlwdGVkIGhlYWRlciB0byBjb21tdW5pY2F0ZSB0aGUgc2lnbmVkIG9mZnNl
dCB2YWx1ZXMuIFRoZSAxMjggYmF0Y2ggc2l6ZSBpLmUuIGEgMSBieXRlIG9mZnNldCBzaXplIHNo
b3VsZCBiZSBtb3JlIHRoYW4gZW5vdWdoIGVudHJvcHkgdG8gZGlzY291cmFnZSBhIG1pZGRsZSBi
b3ggZnJvbSDigJxmaXhpbmcgcmVvcmRlcmluZ+KAnSBhbmQgaW4gcHJhY3RpY2Ugd2UgbWF5IG5l
ZWQgbGVzcy4NCg0KT25lIHBvc3NpYmxlIGFsZ29yaXRobSBmb3IgdGhlIHNodWZmbGUgaXMgdGhl
IEZpc2hlcuKAk1lhdGVzIChLbnV0aCkgc2h1ZmZsZSBhcyBkb2N1bWVudGVkIGhlcmU6IGh0dHBz
Oi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0Zpc2hlcuKAk1lhdGVzX3NodWZmbGU8aHR0cHM6Ly9u
YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHM6JTJGJTJGZW4u
d2lraXBlZGlhLm9yZyUyRndpa2klMkZGaXNoZXIlRTIlODAlOTNZYXRlc19zaHVmZmxlJmRhdGE9
MDIlN0MwMSU3Q25pYmFua3MlNDBtaWNyb3NvZnQuY29tJTdDY2IxZDJkZWFiNTUxNDE5ZmIzMjIw
OGQ1OWU1ZmIwNjklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD
NjM2NTg5MDU2MTkzODYyODY4JnNkYXRhPUlRaE5QcjFRNlNnJTJCNTRvQUNsYnlHaEhkNnE3cmx3
clA5ZXVINlFrWTZFVSUzRCZyZXNlcnZlZD0wPiAuIFBsZWFzZSBzZWUgdGhlIOKAnE1vZGVybiBt
ZXRob2TigJ0gc2VjdGlvbiB3aGljaCBpcyBpbi1wbGFjZS4gVGhlIHJhbmRvbSBudW1iZXIgZ2Vu
ZXJhdG9yIGRvZXNu4oCZdCBoYXZlIHRvIGJlIGEgc2VjdXJlIHZhcmlhbnQuDQoNCk9uZSBhZHZh
bnRhZ2Ugb2Ygc3VjaCBhIHNjaGVtZSBpcyB0aGF0IHBhY2tldCBsb3NzIGNhbiBzdGlsbCBiZSBp
bmZlcnJlZCBieSBsb29raW5nIGF0IGVhY2ggYmF0Y2ggc2l6ZWQgc2V0IG9mIHRoZSBub25jZSAo
cGFja2V0IG51bWJlcnMpLiBGb3IgZXhhbXBsZSBpZiB0aGUgYmF0Y2ggc2l6ZSBpcyAxMjgsIHRo
ZW4gbWlzc2luZyBudW1iZXJzIGluIHRoaXMgYmF0Y2ggc2l6ZSAob3IgYSBtdWx0aXBsZSkgd2ls
bCBzaG93IHRoZSBleHRlbnQgb2YgcGFja2V0IGxvc3MuIFRoZSBvdGhlciBhZHZhbnRhZ2UgaXMg
dGhhdCBhIFFVSUMgZGlhZ25vc3RpYyBjb25uZWN0aW9uIGNhbiB0cml2aWFsbHkgZGV0ZWN0IGEg
YmFkIG1pZGRsZWJveCB0aGF0IHRyaWVzIHRvIHJlb3JkZXIgdGhlIG5vbmNlIGluIHNlcXVlbmNl
IGFzIGl0IHdpbGwgYmUgZWFzaWx5IGRpc3Rpbmd1aXNoYWJsZSBmcm9tIGEgcmFuZG9tIG5ldHdv
cmsgcmVvcmRlci4NCg0KDQo=

--_000_DM5PR2101MB0901BDA387CF7CA119926CAFB3BF0DM5PR2101MB0901_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7
fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy
IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN
CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp
c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0K
CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs
IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFpbG9uLCBsaS5haXJtYWlsb24sIGRp
di5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6
ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X
b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq
Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTI0MzM2ODExOw0KCW1zby1saXN0LXRlbXBsYXRl
LWlkczotMTUwNTU2NzA4Mjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps
ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl
dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2
ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10
YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl
bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxDQoJe21z
by1saXN0LWlkOjE1MDI2OTc0Nzc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt
dGVtcGxhdGUtaWRzOjYwOTI1MDE5NiA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4
OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs
MTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9
DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg
bDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90
dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i
MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi
IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs
YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk
U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGdvYWwgaGVyZSB3b3VsZCBlc3Nl
bnRpYWxseSBqdXN0IHRvIHNodWZmbGUgdGhlIGJpdHMgaW4gdGhlIGJvdHRvbSBieXRlLCBqdXN0
IHRvIG1ha2UgZXZlcnl0aGluZyBsb29rIHJlb3JkZXJlZCB0byB0aGUgbWlkZGxlYm94LiBZb3Ug
ZG9u4oCZdCByZWFsbHkgaGF2ZSB0byBwcmVjb21wdXRlIGFueXRoaW5nLCBhbmQgaXQgc2hvdWxk
IGJlIGluZGVwZW5kZW50IG9mIEJEUCBvciBsb3NzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I
ZXJlIGlzIGEgc2xpZ2h0IHZhcmlhdGlvbiBvbiBQcmF2ZWVu4oCZcyBzdWdnZXN0aW9uIChhc3N1
bWVzIHVzaW5nIGZ1bGwgMTI4IHBhY2tldCBiYXRjaCBzaXplKTo8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJn
aW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0
eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPlByZWFsbG9jYXRl
IGEgYnVmZmVyIG9mIDEyOCBieXRlcyBhbmQgcHJlcG9wdWxhdGUgaXQgd2l0aCB0aGUgdmFsdWVz
IG9mIDAgdG8gMTI3LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi
IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPkZvciBlYWNo
IHBhY2tldCBzZW50LCByYW5kb21seSBncmFiIGFuIGl0ZW0gKGkuZS4gdGhlIG9mZnNldCkgZnJv
bSB3aGF04oCZcyBsZWZ0IGluIHRoZSBidWZmZXIsIGFuZCByZW1vdmUgaXQgKHN3YXAgd2l0aCBs
YXN0IHZhbHVlLCBhbmQgZGVjcmVtZW50IGxlbmd0aCkuPG86cD48L286cD48L2xpPjxsaSBjbGFz
cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBs
ZXZlbDEgbGZvMiI+UmVwbGFjZSB0aGUgYm90dG9tIGJ5dGUgb2YgdGhlIHJlYWwgcGFja2V0IG51
bWJlciB3aXRoIHRoZSBvZmZzZXQgYW5kIHB1dCB0aGF0IG5ldyBwYWNrZXQgbnVtYmVyIGluIHRo
ZSBjbGVhciB0ZXh0LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi
IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPlB1dCB0aGUg
cmVhbCBib3R0b20gYnl0ZSBvZiB0aGUgcmVhbCBwYWNrZXQgbnVtYmVyIGluIHRoZSBlbmNyeXB0
ZWQgcG9ydGlvbi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj5FbmNyeXB0IHdp
dGggdGhlIG5ldyBjbGVhcnRleHQgcGFja2V0IG51bWJlciBhbmQgc2VuZC48bzpwPjwvbzpwPjwv
bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z
by1saXN0OmwxIGxldmVsMSBsZm8yIj5PbmNlIHRoZSBwcmVhbGxvY2F0ZWQgYnVmZmVyIGlzIGVt
cHR5LCBqdXN0IHNldCB0aGUgbGVuZ3RoIGJhY2sgdG8gMTI4IGFuZCBjb250aW51ZSBvbi48bzpw
PjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNlbmRlciBkZWNyeXB0cyB1c2luZyB0aGUg
Y2xlYXJ0ZXh0IHBhY2tldCBudW1iZXIuIFRoZW4gcmVwbGFjZXMgdGhlIGJvdHRvbSBieXRlIG9m
IHRoZSBwYWNrZXQgbnVtYmVyIHdpdGggdGhlIG9mZnNldCBmcm9tIHRoZSBlbmNyeXB0ZWQgcGF5
bG9hZCB0byBnZXQgdGhlIHRydWUgcGFja2V0IG51bWJlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+LSBOaWNrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0
OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjxicj4NCjxi
PlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDksIDIwMTggMjoyMCBQTTxicj4NCjxiPlRvOjwvYj4g
UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5p
ZXRmLm9yZyZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFNpbXBsZSB0cmFuc2Zvcm0gZm9yIGltcHJvdmluZyBQTiBvc3NpZmlj
YXRpb24gcHJldmVudGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9t
Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBpbmNpZGVu
dGFsbHkgaW1wbGVtZW50ZWQgRmlzaGVyLVlhdGVzIGEgZmV3IGRheXMgYWdv4oCmPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkJ1dCBpZiB5b3UgcGVybWl0IGEgd2luZG93LCB5
b3UgY2FuIGFsc28gZW5jcnlwdCBwYWNrZXQgbnVtYmVycyB1c2luZyBhbiBpbnRlcm5hbCBwcmVj
b21wdXRlZCBBRVMgZHJpdmVuIFBSTkcgc3RyZWFtIC0gdGhpcyBpcyBhYm91dCAxNnggZmFzdGVy
IHRoYW4gZGlyZWN0IGVuY3J5cHRpb24gYmVjYXVzZQ0KIG9uZSBibG9jayBjb3ZlcnMgNCBwYWNr
ZXRzLCBhbmQgZW5jcnlwdGlvbiBjYW4gYmUgZG9uZSBpbiBhIHBhcmFsbGVsIHBpcGVsaW5lIHdp
dGggY3VycmVudCBBRVMtTkkgaGFyZHdhcmUuIFlvdSBuZWVkIHRvIG1hcCB0aGUgd2luZG93IGlu
IGEgaGFzaCB0YWJsZSwgYW5kIGl0IG11c3QgYmUgc21hbGwgb3IgY2FjaGUgZWZmZWN0cyBtYWtl
cyBpdCB0b28gZXhwZW5zaXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBp
ZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9v
cF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5I
b3dldmVyLCBiaWcgcGFja2V0IGxvc3Mgd291bGQgbWFrZSB0aGlzIHNjaGVtZSBlaXRoZXIgaW5l
ZmZlY3RpdmUsIG9yIGNvbXBsaWNhdGVkIHdpdGggZmFsbGJhY2sgc2VhcmNoLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGFzc3VtZSB5b3VyIHByb3Bvc2VkIHNodWZmbGUg
aXMgZnVsbHkgZGV0ZXJtaW5pc3RpYyBhbmQgcHJlY29tcHV0ZWQuIEFzaWRlIGZyb20gdGhlIHBy
b2JsZW1zIHdpdGggYSB3aW5kb3cgc2l6ZSB2cyBsb3NzLCB0aGlzIGxvb2tzIGxpa2UgYSB2ZXJ5
IGdvb2Qgd2F5IHRvIGNvcnJlbGF0ZSBwYWNrZXRzDQogYmVjYXVzZSB0aGV5IG5vdyBleGhpYml0
IGEgZGlzdGluY3QgcGF0dGVybiBmb3IgZWFjaCBjb25uZWN0aW9uLiBTbyBJIGRvbuKAmXQgc2Vl
IHRoaXMgYXMgYmVpbmcgd29ydGh3aGlsZSwgaWYgSSB1bmRlcnN0YW5kIHRoZSBzY2hlbWUgY29y
cmVjdGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3Vz
dG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgc2h1ZmZsZSBj
YW4gYWxzbyBiZSBzZWVuIGFzIGEgY2xldmVyIHdheSB0byBjcmVhdGUgYSBwZXJmZWN0IGhhc2gg
dGFibGUgZm9yIHRoZSBhYm92ZSBtZW50aW9uZWQgUFJORyBzY2hlbWUsIGJ1dCBJIGRvbid0IHRo
aW5rIGl0IHdvdWxkIGJlIGVmZmVjdGl2ZSBmb3IgbGFyZ2UgZW5vdWdoDQogd2luZG93cy48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnVydGhlcm1vcmUsIGFsbCBvZiB0aGVz
ZSBzY2hlbWVzIHJlcXVpcmUgZXh0cmEgbWVtb3J5IHBlciBjb25uZWN0aW9uIGFuZCB0aGlzIGNh
biBiZSBleHBlbnNpdmUgaWYgdGhlcmUgYXJlIDEwSyYjNDM7IGlkbGUgY29ubmVjdGlvbnMgc2l0
dGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3Rv
bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+
DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj4vKjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i
Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+Jm5ic3A7KiBHaXZlbiBhbiB1bmluaXRpYWxpemVkIGBpbmRleGAgb2YgYG5gIHVpbnQ2NF90
IHNsb3RzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3Vz
dG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7
KiBQbGFjZSBhIHVuaXF1ZSB2YWx1ZSBpbiB0aGUgcmFuZ2UgMCAuLiBuIC0gMSBpbmNsdXNpdmUg
aW4gZWFjaCBzbG90PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9v
cF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m
bmJzcDsqIHVuYmlhc2VkIHJhbmRvbWx5ICh3aXRoaW4gdGhlIHBybmcgbGltaXRzKS48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyogQmFzZWQgb24gRmlzaGVyLVlh
dGVzIHNodWZmbGUgLSBpbnNpZGUgb3V0IHZhcmlhbnQuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Ki88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPnN0YXRpYyBpbmxpbmUgdm9pZCByYW5kNjRfaW5pdF9zaHVmZmxlX2Jl
bG93KHVpbnQ2NF90ICpzdGF0ZSwgdWludDY0X3QgKmluZGV4LCB1aW50NjRfdCBuKTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ezxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyB1aW50NjRfdCBpLCB4OzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IGZvciAoaSA9IDA7
IGkgJmx0OyBuOyAmIzQzOyYjNDM7aSkgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHggPSByYW5kNjRfYmVsb3co
c3RhdGUsIGkgJiM0MzsgMSk7IC8qIHVuc2lnbmVkIHJhbmRvbSB2YWx1ZSAoMCAuLiBpKSAqLzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7IGluZGV4W2ldID0gaW5kZXhbeF07IC8qIFVuaW5pdGlhbGl6ZWQgaWYgaSA9
PSB4LCB3aGljaCBpcyBvay4gKi88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg
aWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmRleFt4XSA9IGk7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IH08bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPn08bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPk1pa2tlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9ImFpcm1haWxvbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDkgQXByaWwg
MjAxOCBhdCAyMi40OC40OCwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gKDxhIGhyZWY9Im1haWx0
bzpwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciPnByYXZiPTQwbWljcm9zb2Z0
LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4pIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+VGhlIGN1cnJlbnQgYXBwcm9hY2ggaW4gdGhlIGRyYWZ0IGZvciBwcmV2ZW50aW5nIFBO
IG9zc2lmaWNhdGlvbiBpcyB0byB1c2UgYSByYW5kb20gc3RhcnRpbmcgUE4uIEthenVobyBwb2lu
dGVkDQogb3V0IGEgcHJvYmxlbSB3aXRoIHRoaXMgYXBwcm9hY2ggd2hlcmUgbWlkZGxlYm94ZXMg
Y291bGQgaW50ZXJwcmV0IHRoZSBQTiBhcyBhIHNlcXVlbmNlIG51bWJlci4gQW5kIGluIGFuIGF0
dGVtcHQgdG8gYmUg4oCcaGVscGZ1bOKAnSwgdGhleSBjb3VsZCByZW9yZGVyIHRoZSBwYWNrZXRz
IGV4YWNlcmJhdGluZyB0aGUgSG9MIGJsb2NraW5nIHByb2JsZW0gYW5kIG1heSBjYXVzZSBpc3N1
ZXMgZm9yIHVucmVsaWFibGUgc2VtYW50aWNzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SWYg
dGhlIFBODQo8aT5pbiB0aGUgY2xlYXI8L2k+ICh0aGUgbm9uY2UgdmFsdWUpIGRpZG7igJl0IGFs
d2F5cyBtb25vdG9uaWNhbGx5IGluY3JlYXNlIHRoZW4gaXQgd2lsbCBwcmVjbHVkZSBzdWNoIGJh
ZCBiZWhhdmlvciBieSB0aGUgbWlkZGxlYm94ZXMuIEhlbmNlIHdlIG5lZWQgdG8gZmluZCBhIHNp
bXBsZSB0cmFuc2Zvcm0gdGhhdCBpcyBub3QgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIGFuZCBh
bHNvIG5vdCByZXBlYXRpbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5SZXF1aXJlbWVudHMg
Zm9yIGFueSBQTiB0cmFuc2Zvcm0gaW4gdGhlIHNpbmdsZSBwYXRoIGNhc2U6PG86cD48L286cD48
L3NwYW4+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBhY3R1
YWwgUE4gbXVzdCBhbHdheXMgaW5jcmVtZW50IGJ5IDEgYW5kIHdpbGwgYmUgdXNlZCBmb3IgZ2Vu
ZXJhdGluZyBBQ0tzIGluIEFDSyBmcmFtZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPlRoZSB0cmFuc2Zvcm1lZCBQTiBpbiB0aGUgY2xlYXIgaXMgYSBub25jZSBhbmQgbXVz
dCBub3QgcmVwZWF0IG92ZXIgdGhlIGNvbm5lY3Rpb24gbGlmZXRpbWUuPG86cD48L286cD48L3Nw
YW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N
CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5NaWRkbGVib3hlcyBtdXN0IG5vdCBiZSBhYmxlIHRvIGRldGVy
bWluZSB0aGUgYWN0dWFsIFBOLiBPbmx5IHRoZSBRVUlDIHJlY2VpdmVyIHNob3VsZCBiZSBhYmxl
IHRvIGRvIHNvLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlBORSBpcyBvbmUgcG9zc2li
bGUgdHJhbnNmb3JtIHRoYXQgbWVldHMgYWxsIHRoZXNlIHJlcXVpcmVtZW50cyBidXQgaXQgaXMg
ZXhwZW5zaXZlIENQVSBjb3N0IHdpc2UgYW5kIGhhcyBpbXBsaWNhdGlvbnMNCiBmb3IgaGFyZHdh
cmUgaW1wbGVtZW50YXRpb25zLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gb2xsb3dpbmcgaXMg
YSBwcm9wb3NhbCBmb3IgYW4gYWx0ZXJuYXRpdmUgc2ltcGxlIHRyYW5zZm9ybSB3aXRoIGxvdyBD
UFUgb3ZlcmhlYWQgd2hpY2ggc2F0aXNmaWVzIHRoZXNlIHRocmVlIHJlcXVpcmVtZW50cy4NCiBU
aGUgZ29hbCBpcyB0byBwcm9kdWNlIGEgbm9uLXJlcGVhdGluZyBzaHVmZmxlIG9mIHRoZSBvcmln
aW5hbCBzZXQgb2YgbnVtYmVycy4gU2luY2UgdGhlIFBOIHNwYWNlIGlzIHZlcnkgYmlnIGFuZCBl
ZmZpY2llbnQgc2h1ZmZsZSBhbGdvcml0aG1zIGhhdmUgTyhuKSBzcGFjZSByZXF1aXJlbWVudCwg
d2UgbmVlZCB0byBkZWZpbmUgYSDigJxyZW9yZGVyIGRlZ3JlZeKAnSBvciBhIOKAnGJhdGNoIHNp
emXigJ0gd2l0aGluIHdoaWNoIHdlIHdpbGwgc2h1ZmZsZQ0KIHRoZSBwYWNrZXQgbnVtYmVycy48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj5BcyBhbiBleGFtcGxlIGNvbnNpZGVyIHRoYXQgdGhlIHN0
YXJ0aW5nIHJhbmRvbSBQTiBpcyAxMDAuIFBlciB0aGUgY3VycmVudCBkcmFmdCB0aGUgYWN0dWFs
IFBOIGluY3JlbWVudHMgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgMTAw
LCAxMDEsIDEwMiwgMTAzLCAxMDQsICZuYnNwOyZuYnNwOyZuYnNwOzEwNSwgMTA2LCAxMDcsIDEw
OCwgMTA5LCDigKYgYW5kIHNvIGZvcnRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TGV04oCZcyBh
c3N1bWUgYSDigJxiYXRjaCBzaXpl4oCdIG9mIDUuIFRoZW4gdXNpbmcgb25lIHBvc3NpYmxlIG91
dGNvbWUgb2YgdGhlIHNodWZmbGVzIHdlIGNhbiBnZW5lcmF0ZSB0aGUgZm9sbG93aW5nDQogYXMg
dGhlIGNsZWFydGV4dCBub25jZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+fCZuYnNwOyAxMDIsIDEwNCwgMTAzLCAxMDEs
IDEwMCwgfCZuYnNwOyAxMDcsIDEwNSwgMTA5LCAxMDgsIDEwNiB8ICZuYnNwOyZuYnNwOyzigKYg
YW5kIHNvIGZvcnRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGJhcnMgfCBpbmRpY2F0ZSBiYXRjaCBib3VuZGFyaWVz
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9mIGNvdXJzZSBzaW5jZSB3ZSBuZWVkIHRoZSBRVUlD
IHJlY2VpdmVyIHRvIGdldCB0aGUgYWN0dWFsIFBOIGZyb20gdGhlIGNsZWFydGV4dCB2YWx1ZSwg
d2UgbmVlZCB0byBjb21tdW5pY2F0ZQ0KIHRoZSBvZmZzZXRzIGluIHRoZSBlbmNyeXB0ZWQgcG9y
dGlvbiBvZiB0aGUgcGFja2V0LCB3aGljaCBmb3IgdGhpcyBleGFtcGxlIHdvdWxkIGJlOjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPnwmbmJzcDsgJiM0MzsyLCAmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOzMsICZuYnNwOyZuYnNw
OyYjNDM7MSwgJm5ic3A7Jm5ic3A7LTIsICZuYnNwOyZuYnNwOy00LCZuYnNwOyZuYnNwOyZuYnNw
OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0yLCAmbmJzcDsmbmJzcDsmIzQzOzEsICZuYnNwOyZuYnNw
Oy0yLCAmbmJzcDsmbmJzcDsmbmJzcDswLCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOzMg
Jm5ic3A7Jm5ic3A7Jm5ic3A7fCwgJm5ic3A74oCmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk1pZGRsZWJveGVzIHdpbGwg
bm90IGJlIGFibGUgdG8gc2VlIHRoZSBvZmZzZXQgdmFsdWVzIGluIHRoZSBjbGVhci4gUVVJQyBy
ZWNlaXZlciB3aWxsIG5lZWQgdG8gZG8gYSBzaW1wbGUgYWRkDQogb2YgYSBzaWduZWQgbnVtYmVy
IHRvIGdldCB0aGUgb3JpZ2luYWwgUE4uIFRoaXMgaXMgdmVyeSBjaGVhcCBvcGVyYXRpb24gQ1BV
IGNvc3Qgd2lzZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkEgUVVJQyBzZW5kZXIgaW1wbGVt
ZW50YXRpb24gY2FuIHBpY2sgYW55IHNpemUgZm9yIHRoZSByZW9yZGVyIGRlZ3JlZSwgdGhlIHRy
YWRlLW9mZiBpcyB0aGUgc3BhY2UgY29tcGxleGl0eSBhbmQNCiBwYWNrZXQgc3BhY2UgbmVlZGVk
IHRvIGNvbW11bmljYXRlIHRoZSBvZmZzZXRzLiBBIHJlb3JkZXIgZGVncmVlIHdpdGhpbiAxMjgg
bnVtYmVycyB3aWxsIG5lZWQgYXQgbW9zdCBhbiBleHRyYSBieXRlIGluIHRoZSBlbmNyeXB0ZWQg
aGVhZGVyIHRvIGNvbW11bmljYXRlIHRoZSBzaWduZWQgb2Zmc2V0IHZhbHVlcy4gVGhlIDEyOCBi
YXRjaCBzaXplIGkuZS4gYSAxIGJ5dGUgb2Zmc2V0IHNpemUgc2hvdWxkIGJlIG1vcmUgdGhhbiBl
bm91Z2ggZW50cm9weQ0KIHRvIGRpc2NvdXJhZ2UgYSBtaWRkbGUgYm94IGZyb20g4oCcZml4aW5n
IHJlb3JkZXJpbmfigJ0gYW5kIGluIHByYWN0aWNlIHdlIG1heSBuZWVkIGxlc3MuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+T25lIHBvc3NpYmxlIGFsZ29yaXRobSBmb3IgdGhlIHNodWZmbGUgaXMg
dGhlIEZpc2hlcuKAk1lhdGVzIChLbnV0aCkgc2h1ZmZsZSBhcyBkb2N1bWVudGVkIGhlcmU6DQo8
YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy
bD1odHRwczolMkYlMkZlbi53aWtpcGVkaWEub3JnJTJGd2lraSUyRkZpc2hlciVFMiU4MCU5M1lh
dGVzX3NodWZmbGUmYW1wO2RhdGE9MDIlN0MwMSU3Q25pYmFua3MlNDBtaWNyb3NvZnQuY29tJTdD
Y2IxZDJkZWFiNTUxNDE5ZmIzMjIwOGQ1OWU1ZmIwNjklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk
N2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTg5MDU2MTkzODYyODY4JmFtcDtzZGF0YT1JUWhOUHIx
UTZTZyUyQjU0b0FDbGJ5R2hIZDZxN3Jsd3JQOWV1SDZRa1k2RVUlM0QmYW1wO3Jlc2VydmVkPTAi
Pg0KaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRmlzaGVy4oCTWWF0ZXNfc2h1ZmZsZTwv
YT4gLiBQbGVhc2Ugc2VlIHRoZSDigJxNb2Rlcm4gbWV0aG9k4oCdIHNlY3Rpb24gd2hpY2ggaXMg
aW4tcGxhY2UuIFRoZSByYW5kb20gbnVtYmVyIGdlbmVyYXRvciBkb2VzbuKAmXQgaGF2ZSB0byBi
ZSBhIHNlY3VyZSB2YXJpYW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uZSBhZHZhbnRhZ2Ug
b2Ygc3VjaCBhIHNjaGVtZSBpcyB0aGF0IHBhY2tldCBsb3NzIGNhbiBzdGlsbCBiZSBpbmZlcnJl
ZCBieSBsb29raW5nIGF0IGVhY2ggYmF0Y2ggc2l6ZWQgc2V0IG9mDQogdGhlIG5vbmNlIChwYWNr
ZXQgbnVtYmVycykuIEZvciBleGFtcGxlIGlmIHRoZSBiYXRjaCBzaXplIGlzIDEyOCwgdGhlbiBt
aXNzaW5nIG51bWJlcnMgaW4gdGhpcyBiYXRjaCBzaXplIChvciBhIG11bHRpcGxlKSB3aWxsIHNo
b3cgdGhlIGV4dGVudCBvZiBwYWNrZXQgbG9zcy4gVGhlIG90aGVyIGFkdmFudGFnZSBpcyB0aGF0
IGEgUVVJQyBkaWFnbm9zdGljIGNvbm5lY3Rpb24gY2FuIHRyaXZpYWxseSBkZXRlY3QgYSBiYWQg
bWlkZGxlYm94IHRoYXQNCiB0cmllcyB0byByZW9yZGVyIHRoZSBub25jZSBpbiBzZXF1ZW5jZSBh
cyBpdCB3aWxsIGJlIGVhc2lseSBkaXN0aW5ndWlzaGFibGUgZnJvbSBhIHJhbmRvbSBuZXR3b3Jr
IHJlb3JkZXIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv
Ym9keT4NCjwvaHRtbD4NCg==

--_000_DM5PR2101MB0901BDA387CF7CA119926CAFB3BF0DM5PR2101MB0901_--


From nobody Mon Apr  9 14:37:08 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B82412D965 for ; Mon,  9 Apr 2018 14:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.291
X-Spam-Level: 
X-Spam-Status: No, score=-0.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbPOz1glxQVp for ; Mon,  9 Apr 2018 14:37:05 -0700 (PDT)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D37512D960 for ; Mon,  9 Apr 2018 14:37:05 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 71DDA1205A1 for ; Mon,  9 Apr 2018 23:37:03 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 56FF4180076 for ; Mon,  9 Apr 2018 23:37:03 +0200 (CEST)
Received: from lat6466.rd.francetelecom.fr (10.168.234.2) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 9 Apr 2018 23:37:03 +0200
Message-ID: <18025_1523309823_5ACBDCFF_18025_318_1_5ACBDD04.2040803@orange.com>
Date: Mon, 9 Apr 2018 23:37:08 +0200
From: 
Organization: Orange
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0
MIME-Version: 1.0
To: IETF QUIC WG 
Subject: Bona fide loss measurement bits
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <2DB3AC71-89B1-425C-8128-E673D34B7AFA@trammell.ch> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.168.234.2]
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Apr 2018 21:37:07 -0000

On 04/04/2018 20:06, Ted Hardie wrote:
> it seems pretty clear that the passive measurement and diagnostic purposes would
> work with fairly small sequence numbers, maybe even down to sizes small enough
> to make the linkability problem less scary.  The other issues ("does this look
> like quic" and "does this look like a known flow") seem like they don't really
> require packet numbers or even deliberately exposed sequence numbers, just
> consistency.   In other words, if we do anything to expose sequences, the wire
> image we engineer does not have to simply re-use the packet numbers used for
> protocol mechanics. It can focus on the message we want to send to the path instead.

If we're to secure a few bits as a "message we want to send to the path", e.g. 
for loss measurement, please note that subsequence numbers are just one option 
among many, with known shortcomings (only losses between sender and observer; 
lack of robustness to strong loss and reordering).

Instead, building on top of the Spin Bit, we propose a 7-bit extension named 
"Spin Counters":

     http://snaggletooth.akam.ai/IETF-101-HotRFC/10-Ferrieux.pdf

they give both up- and downstream losses, are robust to any level of loss and 
reordering, and leverage the Spin Bit's autoscaling to one congestion window.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


From nobody Mon Apr  9 14:52:30 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D4E12D96C for ; Mon,  9 Apr 2018 14:52:28 -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, 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 EM26beV0xv_f for ; Mon,  9 Apr 2018 14:52:25 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B71612D95F for ; Mon,  9 Apr 2018 14:52:25 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id x144-v6so12985960itc.0 for ; Mon, 09 Apr 2018 14:52:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to;  bh=lQ/QFl+HJwpR9yfEyJcasfMXt4s5rb3P+7wilpS4pXg=; b=V9gqJRi7Z7+JLrbGvpjviLnYSmZr03XGTpr1ESV76ymItf5Lkle2YSRTgHZSKeC35N CvaqPAaIZNfifbN1uyq4WFRRgd3AZTlW4EesV/0uJh+CZ9uVHUjcivuIvFZPuQwlO/ZI YFLQnT12QRHvZ/0mOzONDw8vZPUjlnVaPveWF0xix9il9LroK2SNpi1fjmufhdeaSyRZ NWSVRbTnZxy0GjEW7PhBZsscBq0S8O62dFvp9fCNE4KKHU1tJRL4p9D3jq3fEiyuZJtN i9yzuClJMkDQJuOhsyu0o+uKehE4xGiRu12dGOeyRO3sgq8GPbyDuHaI0yP0SsF8oVWa /WNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=lQ/QFl+HJwpR9yfEyJcasfMXt4s5rb3P+7wilpS4pXg=; b=fSghDdB7sqNEsKRV4hEtmIY/55XwNoFAgSe7pS0pYt2cZrpG7pNUIIpEwZiji0UnGi PWiq6LFRhLsgHTqPTazjyQpIWll0TmN5SBff3L9AOJj/QY9MlDXWXP/DVWxpGHmtd8MP o8TfrfwPAJ/R1KntWs7MJDJUAhGdAWfifs4L6xPvgdt8rwh0uDGglWoeTrInD8qKG0Dq Ix35HLZj1E4bIvEYK20wyTjj/FCR86/uEjd6BBVBYcLQKFKTeBSFqrJq2DGKMyYLjGR3 kE0468xICkFWG5zU0WX4gpqUAaftxPIpN1HzQG5xp1EnBpvcxNaXRUnWobenZkBDN0D2 3C6g==
X-Gm-Message-State: ALQs6tBILDMjlqQuPMIin4rYz7ZGQgg3510kR5qj2pyH5ItsMt9/Rse/ trrKjbAaVK7gpCUPSuGIArNdXTeYtpyJzxwv8eQ=
X-Google-Smtp-Source: AIpwx48G2N3XFnA9nvl733plbmrvNqU4l14AFhHIJhjNIMER0scR2EhFm1s8OPwW2M7OCgwMKM2qTUi/ASwxwlVpDso=
X-Received: by 2002:a24:5085:: with SMTP id m127-v6mr1936102itb.118.1523310744423;  Mon, 09 Apr 2018 14:52:24 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 9 Apr 2018 17:52:23 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:   
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 9 Apr 2018 17:52:23 -0400
Message-ID: 
Subject: RE: Simple transform for improving PN ossification prevention
To: Nick Banks ,  Praveen Balasubramanian , IETF QUIC WG 
Content-Type: multipart/alternative; boundary="000000000000cdd3420569716b53"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 21:52:28 -0000

--000000000000cdd3420569716b53
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

OK, so the high bits are kept - this solves the loss problem.
And the sender does not have to decode the shuffle because the packet
number is the packet number - which makes the shuffle order non-recurring
in the batch, but it also makes loss detection very difficult to do with
any degree of precision.
Privacy is also not a goal here because the high bits are an immediate
giveaway if the window is small. Just the average distance between two 0
bytes on the low packet number would make a strong correlation.

So I=E2=80=99m not really sure why - if it is to prevent middle boxes from =
adding
reordering latency by being unorganized, one has to hope that a middlebox
does not try to reorder anyway, but ok, I see.

I=E2=80=99m not convinced. But the scheme has another brilliant property: i=
t solves
the optimistic ACK attack problem with needing to introduce any artificial
gaps. This could be useful even if packet numbers were fully encrypted
because the attacker is then the receiver - were it not for the problem
with loss detection and early retransmission.


On 9 April 2018 at 23.33.05, Nick Banks (nibanks@microsoft.com) wrote:

The goal here would essentially just to shuffle the bits in the bottom
byte, just to make everything look reordered to the middlebox. You don=E2=
=80=99t
really have to precompute anything, and it should be independent of BDP or
loss.



Here is a slight variation on Praveen=E2=80=99s suggestion (assumes using f=
ull 128
packet batch size):



   - Preallocate a buffer of 128 bytes and prepopulate it with the values
   of 0 to 127.
   - For each packet sent, randomly grab an item (i.e. the offset) from
   what=E2=80=99s left in the buffer, and remove it (swap with last value, =
and
   decrement length).
   - Replace the bottom byte of the real packet number with the offset and
   put that new packet number in the clear text.
   - Put the real bottom byte of the real packet number in the encrypted
   portion.
   - Encrypt with the new cleartext packet number and send.
   - Once the preallocated buffer is empty, just set the length back to 128
   and continue on.



The sender decrypts using the cleartext packet number. Then replaces the
bottom byte of the packet number with the offset from the encrypted payload
to get the true packet number.



- Nick



*From:* QUIC  *On Behalf Of * Mikkel Fahn=C3=B8e J=
=C3=B8rgensen
*Sent:* Monday, April 9, 2018 2:20 PM
*To:* Praveen Balasubramanian ; IET=
F
QUIC WG 
*Subject:* Re: Simple transform for improving PN ossification prevention



I incidentally implemented Fisher-Yates a few days ago=E2=80=A6



But if you permit a window, you can also encrypt packet numbers using an
internal precomputed AES driven PRNG stream - this is about 16x faster than
direct encryption because one block covers 4 packets, and encryption can be
done in a parallel pipeline with current AES-NI hardware. You need to map
the window in a hash table, and it must be small or cache effects makes it
too expensive.



However, big packet loss would make this scheme either ineffective, or
complicated with fallback search.



I assume your proposed shuffle is fully deterministic and precomputed.
Aside from the problems with a window size vs loss, this looks like a very
good way to correlate packets because they now exhibit a distinct pattern
for each connection. So I don=E2=80=99t see this as being worthwhile, if I
understand the scheme correctly.



The shuffle can also be seen as a clever way to create a perfect hash table
for the above mentioned PRNG scheme, but I don't think it would be
effective for large enough windows.



Furthermore, all of these schemes require extra memory per connection and
this can be expensive if there are 10K+ idle connections sitting.



/*

 * Given an uninitialized `index` of `n` uint64_t slots:

 * Place a unique value in the range 0 .. n - 1 inclusive in each slot

 * unbiased randomly (within the prng limits).

 *

 * Based on Fisher-Yates shuffle - inside out variant..

 */

static inline void rand64_init_shuffle_below(uint64_t *state, uint64_t
*index, uint64_t n)

{

    uint64_t i, x;



    for (i =3D 0; i < n; ++i) {

        x =3D rand64_below(state, i + 1); /* unsigned random value (0 .. i)=
 */

        index[i] =3D index[x]; /* Uninitialized if i =3D=3D x, which is ok.=
 */

        index[x] =3D i;

    }

}





Mikkel





On 9 April 2018 at 22.48.48, Praveen Balasubramanian (
pravb=3D40microsoft.com@dmarc.ietf.org) wrote:

The current approach in the draft for preventing PN ossification is to use
a random starting PN. Kazuho pointed out a problem with this approach where
middleboxes could interpret the PN as a sequence number. And in an attempt
to be =E2=80=9Chelpful=E2=80=9D, they could reorder the packets exacerbatin=
g the HoL
blocking problem and may cause issues for unreliable semantics.



If the PN *in the clear* (the nonce value) didn=E2=80=99t always monotonica=
lly
increase then it will preclude such bad behavior by the middleboxes. Hence
we need to find a simple transform that is not monotonically increasing and
also not repeating.



Requirements for any PN transform in the single path case:

   1. The actual PN must always increment by 1 and will be used for
   generating ACKs in ACK frames.
   2. The transformed PN in the clear is a nonce and must not repeat over
   the connection lifetime.
   3. Middleboxes must not be able to determine the actual PN. Only the
   QUIC receiver should be able to do so.



PNE is one possible transform that meets all these requirements but it is
expensive CPU cost wise and has implications for hardware implementations.



Following is a proposal for an alternative simple transform with low CPU
overhead which satisfies these three requirements. The goal is to produce a
non-repeating shuffle of the original set of numbers. Since the PN space is
very big and efficient shuffle algorithms have O(n) space requirement, we
need to define a =E2=80=9Creorder degree=E2=80=9D or a =E2=80=9Cbatch size=
=E2=80=9D within which we will
shuffle the packet numbers.



As an example consider that the starting random PN is 100. Per the current
draft the actual PN increments as follows:

    100, 101, 102, 103, 104,    105, 106, 107, 108, 109, =E2=80=A6 and so f=
orth



Let=E2=80=99s assume a =E2=80=9Cbatch size=E2=80=9D of 5. Then using one po=
ssible outcome of the
shuffles we can generate the following as the cleartext nonces:

|  102, 104, 103, 101, 100, |  107, 105, 109, 108, 106 |   ,=E2=80=A6 and s=
o forth

The bars | indicate batch boundaries.



Of course since we need the QUIC receiver to get the actual PN from the
cleartext value, we need to communicate the offsets in the encrypted
portion of the packet, which for this example would be:

|  +2,    +3,   +1,   -2,   -4,    |    -2,   +1,   -2,    0,     +3    |,
 =E2=80=A6.

Middleboxes will not be able to see the offset values in the clear. QUIC
receiver will need to do a simple add of a signed number to get the
original PN. This is very cheap operation CPU cost wise.



A QUIC sender implementation can pick any size for the reorder degree, the
trade-off is the space complexity and packet space needed to communicate
the offsets. A reorder degree within 128 numbers will need at most an extra
byte in the encrypted header to communicate the signed offset values. The
128 batch size i.e. a 1 byte offset size should be more than enough entropy
to discourage a middle box from =E2=80=9Cfixing reordering=E2=80=9D and in =
practice we may
need less.



One possible algorithm for the shuffle is the Fisher=E2=80=93Yates (Knuth) =
shuffle
as documented here: https://en.wikipedia.org/wiki/Fisher=E2=80=93Yates_shuf=
fle

. Please see the =E2=80=9CModern method=E2=80=9D section which is in-place.=
 The random
number generator doesn=E2=80=99t have to be a secure variant.



One advantage of such a scheme is that packet loss can still be inferred by
looking at each batch sized set of the nonce (packet numbers). For example
if the batch size is 128, then missing numbers in this batch size (or a
multiple) will show the extent of packet loss. The other advantage is that
a QUIC diagnostic connection can trivially detect a bad middlebox that
tries to reorder the nonce in sequence as it will be easily distinguishable
from a random network reorder.

--000000000000cdd3420569716b53
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
OK, so the high bits=
 are kept - this solves the loss problem.
And the sender does not have to decode the shu=
ffle because the packet number is the packet number - which makes the shuff=
le order non-recurring in the batch, but it also makes loss detection very =
difficult to do with any degree of precision.
Privacy is also not a goal here because th=
e high bits are an immediate giveaway if the window is small. Just the aver=
age distance between two 0 bytes on the low packet number would make a stro=
ng correlation.

So I=
=E2=80=99m not really sure why - if it is to prevent middle boxes from addi=
ng reordering latency by being unorganized, one has to hope that a middlebo=
x does not try to reorder anyway, but ok, I see.

I=E2=80=99m not convinced. But the scheme has a=
nother brilliant property: it solves the optimistic ACK attack problem with=
 needing to introduce any artificial gaps. This could be useful even if pac=
ket numbers were fully encrypted because the attacker is then the receiver =
- were it not for the problem with loss detection and early retransmission.=

 

 
=

On 9 April 2018 at 23.33.05, Nick Banks (nibanks@microsoft.com) wrote:
 










The goal here would essentially just to shuffle the =
bits in the bottom byte, just to make everything look reordered to the midd=
lebox. You don=E2=80=99t really have to precompute anything, and it should =
be independent of BDP or loss.


=C2=A0


Here is a slight variation on Praveen=E2=80=99s sugg=
estion (assumes using full 128 packet batch size):


=C2=A0


    

  • Preallocate a buff=
er of 128 bytes and prepopulate it with the values of 0 to 127.
  • For each packet sent, ran=
domly grab an item (i.e. the offset) from what=E2=80=99s left in the buffer=
, and remove it (swap with last value, and decrement length).
  • Replace the bottom byte of =
the real packet number with the offset and put that new packet number in th=
e clear text.
  • =
Put the real bottom byte of the real packet number in the encrypted portion=
.
  • Encrypt with=
 the new cleartext packet number and send.
  • Once the preallocated buffer is empty, just se=
t the length back to 128 and continue on.


=C2=A0


The sender decrypts using the cleartext packet numbe=
r. Then replaces the bottom byte of the packet number with the offset from =
the encrypted payload to get the true packet number.


=C2=A0


- Nick


=C2=A0






From: QUIC <quic-bounces@ietf.org> On Behalf Of 
Mikkel Fahn=C3=B8e J=C3=B8rgensen

Sent: Monday, April 9, 2018 2:20 PM

To: Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org>; IETF QUIC WG =
<quic@ietf.org>

Subject: Re: Simple transform for improving PN ossification preventi=
on






=C2=A0




I incidentally implemented Fisher-Yates a few day=
s ago=E2=80=A6






=C2=A0






But if you permit a window, you can also encrypt =
packet numbers using an internal precomputed AES driven PRNG stream - this =
is about 16x faster than direct encryption because
 one block covers 4 packets, and encryption can be done in a parallel pipel=
ine with current AES-NI hardware. You need to map the window in a hash tabl=
e, and it must be small or cache effects makes it too expensive.






=C2=A0






However, big packet loss would make this scheme e=
ither ineffective, or complicated with fallback search.






=C2=A0






I assume your proposed shuffle is fully determini=
stic and precomputed. Aside from the problems with a window size vs loss, t=
his looks like a very good way to correlate packets
 because they now exhibit a distinct pattern for each connection. So I don=
=E2=80=99t see this as being worthwhile, if I understand the scheme correct=
ly.






=C2=A0






The shuffle can also be seen as a clever way to c=
reate a perfect hash table for the above mentioned PRNG scheme, but I don&#=
39;t think it would be effective for large enough
 windows.






=C2=A0






Furthermore, all of these schemes require extra m=
emory per connection and this can be expensive if there are 10K+ idle conne=
ctions sitting.






=C2=A0








/*






=C2=A0* Given an uninitialized `index` of `n` uin=
t64_t slots:






=C2=A0* Place a unique value in the range 0 .. n =
- 1 inclusive in each slot






=C2=A0* unbiased randomly (within the prng limits=
).






=C2=A0*






=C2=A0* Based on Fisher-Yates shuffle - inside ou=
t variant..






=C2=A0*/






static inline void rand64_init_shuffle_below(uint=
64_t *state, uint64_t *index, uint64_t n)






{






=C2=A0 =C2=A0 uint64_t i, x;






=C2=A0






=C2=A0 =C2=A0 for (i =3D 0; i < n; ++i) {






=C2=A0 =C2=A0 =C2=A0 =C2=A0 x =3D rand64_below(st=
ate, i + 1); /* unsigned random value (0 .. i) */






=C2=A0 =C2=A0 =C2=A0 =C2=A0 index[i] =3D index[x]=
; /* Uninitialized if i =3D=3D x, which is ok. */






=C2=A0 =C2=A0 =C2=A0 =C2=A0 index[x] =3D i;






=C2=A0 =C2=A0 }






}






=C2=A0








=C2=A0






Mikkel






=C2=A0




=C2=A0


On 9 April 2018 at 22.48.48, Praveen Balasubraman=
ian (pravb=3D40mi=
crosoft.com@dmarc.ietf.org) wrote:










The current approach in the draft for preventing PN ossificatio=
n is to use a random starting PN. Kazuho pointed
 out a problem with this approach where middleboxes could interpret the PN =
as a sequence number. And in an attempt to be =E2=80=9Chelpful=E2=80=9D, th=
ey could reorder the packets exacerbating the HoL blocking problem and may =
cause issues for unreliable semantics.



=C2=A0


If the PN
in the clear (the nonce value) didn=E2=80=99t always monotonically i=
ncrease then it will preclude such bad behavior by the middleboxes. Hence w=
e need to find a simple transform that is not monotonically increasing and =
also not repeating.



=C2=A0


Requirements for any PN transform in the single path case:


    

  1. 
The actual PN must always increment by 1 and will be used for generating=
 ACKs in ACK frames.

  2. 
The transformed PN in the clear is a nonce and must not repeat over the =
connection lifetime.
  3. 
Middleboxes must not be able to determine the actual PN. Only the QUIC r=
eceiver should be able to do so.


=C2=A0


PNE is one possible transform that meets all these requirements=
 but it is expensive CPU cost wise and has implications
 for hardware implementations. 


=C2=A0


Following is a proposal for an alternative simple transform wit=
h low CPU overhead which satisfies these three requirements.
 The goal is to produce a non-repeating shuffle of the original set of numb=
ers. Since the PN space is very big and efficient shuffle algorithms have O=
(n) space requirement, we need to define a =E2=80=9Creorder degree=E2=80=9D=
 or a =E2=80=9Cbatch size=E2=80=9D within which we will shuffle
 the packet numbers.


=C2=A0


As an example consider that the starting random PN is 100. Per =
the current draft the actual PN increments as follows:


=C2=A0=C2=A0=C2=A0 100, 101, 102, 103, 104, =C2=A0=C2=A0=C2=A01=
05, 106, 107, 108, 109, =E2=80=A6 and so forth


=C2=A0


Let=E2=80=99s assume a =E2=80=9Cbatch size=E2=80=9D of 5. Then =
using one possible outcome of the shuffles we can generate the following
 as the cleartext nonces:


|=C2=A0 102, 104, 103, 101, 100, |=C2=A0 107, 105, 109, 108, 10=
6 | =C2=A0=C2=A0,=E2=80=A6 and so forth


The bars | indicate batch boundaries.


=C2=A0


Of course since we need the QUIC receiver to get the actual PN =
from the cleartext value, we need to communicate
 the offsets in the encrypted portion of the packet, which for this example=
 would be:


|=C2=A0 +2, =C2=A0=C2=A0=C2=A0+3, =C2=A0=C2=A0+1, =C2=A0=C2=A0-=
2, =C2=A0=C2=A0-4,=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 -2, =C2=A0=C2=A0+1=
, =C2=A0=C2=A0-2, =C2=A0=C2=A0=C2=A00, =C2=A0=C2=A0=C2=A0=C2=A0+3 =C2=A0=C2=
=A0=C2=A0|, =C2=A0=E2=80=A6.


Middleboxes will not be able to see the offset values in the cl=
ear. QUIC receiver will need to do a simple add
 of a signed number to get the original PN. This is very cheap operation CP=
U cost wise.



=C2=A0


A QUIC sender implementation can pick any size for the reorder =
degree, the trade-off is the space complexity and
 packet space needed to communicate the offsets. A reorder degree within 12=
8 numbers will need at most an extra byte in the encrypted header to commun=
icate the signed offset values. The 128 batch size i.e. a 1 byte offset siz=
e should be more than enough entropy
 to discourage a middle box from =E2=80=9Cfixing reordering=E2=80=9D and in=
 practice we may need less.


=C2=A0


One possible algorithm for the shuffle is the Fisher=E2=80=93Ya=
tes (Knuth) shuffle as documented here:

https://en.wikipedia.org/wiki/Fisher=E2=80=93Yates_shuffle . Please see=
 the =E2=80=9CModern method=E2=80=9D section which is in-place. The random =
number generator doesn=E2=80=99t have to be a secure variant.


=C2=A0


One advantage of such a scheme is that packet loss can still be=
 inferred by looking at each batch sized set of
 the nonce (packet numbers). For example if the batch size is 128, then mis=
sing numbers in this batch size (or a multiple) will show the extent of pac=
ket loss. The other advantage is that a QUIC diagnostic connection can triv=
ially detect a bad middlebox that
 tries to reorder the nonce in sequence as it will be easily distinguishabl=
e from a random network reorder.



=C2=A0


=C2=A0
















--000000000000cdd3420569716b53--


From nobody Mon Apr  9 14:52:34 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6E612D95F for ; Mon,  9 Apr 2018 14:52:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523310749; bh=i5OH77/R2qPaxzIX2d/L/OIjC3q+QOc1UiDudmEDBm4=; h=From:In-Reply-To:References:Date:Subject:To:To:To; b=gi6UMkLPsfYvjS5MjQ+jBPUHeROqQRrhtnecLrJiF+6HKxjOJOeuk2u9txfiLCD0a nJjk6cgzbbC2O73Sc1yDB+jVnPbcBaypK5zXAE9/5FkBCIBuT7NGgmx3mpt2x2DEYp ZLxyo+Nm8/AbN263txrlw8Z4Za4sCrQXGE3wdeDo=
X-Mailbox-Line: From mikkelfj@gmail.com  Mon Apr  9 14:52:28 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C9412D810; Mon,  9 Apr 2018 14:52:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523310748; bh=ClxAVLX23Ccd5dIPUfR8I7g5AdwYf3CRFFbspbDET4o=; h=From:In-Reply-To:References:Date:Subject:To:To:To; b=eaKHRpz6uUhwV66WpH+CWBK6SkyDONDveI3pv7D0GTfJ1WUV0nlAys0WR8RaxNP8p lxV1hthBuCRbtvzG916fz2uxbao4x/JqzoR3IguD5m2gQg5tFyR9H1M8Hw0eFi9Rg2 XyfW0aN7qeqt9ie9Ws4+Oxof5QmBPYqrsPoiQuO4=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA8D12D95F for ; Mon,  9 Apr 2018 14:52:28 -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=unavailable 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 7xdG3UeW262e for ; Mon,  9 Apr 2018 14:52:25 -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 191C812D810 for ; Mon,  9 Apr 2018 14:52:25 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id t192-v6so12979315itc.1 for ; Mon, 09 Apr 2018 14:52:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to;  bh=lQ/QFl+HJwpR9yfEyJcasfMXt4s5rb3P+7wilpS4pXg=; b=V9gqJRi7Z7+JLrbGvpjviLnYSmZr03XGTpr1ESV76ymItf5Lkle2YSRTgHZSKeC35N CvaqPAaIZNfifbN1uyq4WFRRgd3AZTlW4EesV/0uJh+CZ9uVHUjcivuIvFZPuQwlO/ZI YFLQnT12QRHvZ/0mOzONDw8vZPUjlnVaPveWF0xix9il9LroK2SNpi1fjmufhdeaSyRZ NWSVRbTnZxy0GjEW7PhBZsscBq0S8O62dFvp9fCNE4KKHU1tJRL4p9D3jq3fEiyuZJtN i9yzuClJMkDQJuOhsyu0o+uKehE4xGiRu12dGOeyRO3sgq8GPbyDuHaI0yP0SsF8oVWa /WNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=lQ/QFl+HJwpR9yfEyJcasfMXt4s5rb3P+7wilpS4pXg=; b=N3Ghu9G7JDGdHkspDlIgLwAnX6APBweninzOng/AUlxHqv5EePB0pxApv0zMO0PBIH KNnM8SrNLUeW+aTyJIXMc9zbNdbMSvLtZZAHnlvJFboMuL5MGa6MLlid11v5lL2z74KA H/sm/79dhZKlfjB5a71XbLofLL65A8rpZiitDyywLTzLk29i0vl1Ahdgd7tr4wOfCtpF idp+SDCX1VAHzvD2Cb3Sh7B48UK6lw9g0glrMBEfYNQsu98U0HoXuuSBsRfkIjQh/W3w CyT0DlroeInvVCT2VfEYdur9UiW8u4zxGk+q84fvkbQ+sjELfOtkF75TNQOAKdHupNW5 PBYQ==
X-Gm-Message-State: ALQs6tDHSx0DyTLls+oAWzVwum3j5lN2mX+ZNqxK9jGUdsRdojkCymEj fSpLVX/pKSfx+NUvfEjrTki5aP9VlpZKshYDRQA=
X-Google-Smtp-Source: AIpwx48G2N3XFnA9nvl733plbmrvNqU4l14AFhHIJhjNIMER0scR2EhFm1s8OPwW2M7OCgwMKM2qTUi/ASwxwlVpDso=
X-Received: by 2002:a24:5085:: with SMTP id m127-v6mr1936102itb.118.1523310744423;  Mon, 09 Apr 2018 14:52:24 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 9 Apr 2018 17:52:23 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:   
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 9 Apr 2018 17:52:23 -0400
Message-ID: 
Subject: RE: Simple transform for improving PN ossification prevention
Content-Type: multipart/alternative; boundary="000000000000cdd3420569716b53"
To: Nick Banks 
To: Praveen Balasubramanian 
To: IETF QUIC WG 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 21:52:29 -0000

--000000000000cdd3420569716b53
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

OK, so the high bits are kept - this solves the loss problem.
And the sender does not have to decode the shuffle because the packet
number is the packet number - which makes the shuffle order non-recurring
in the batch, but it also makes loss detection very difficult to do with
any degree of precision.
Privacy is also not a goal here because the high bits are an immediate
giveaway if the window is small. Just the average distance between two 0
bytes on the low packet number would make a strong correlation.

So I=E2=80=99m not really sure why - if it is to prevent middle boxes from =
adding
reordering latency by being unorganized, one has to hope that a middlebox
does not try to reorder anyway, but ok, I see.

I=E2=80=99m not convinced. But the scheme has another brilliant property: i=
t solves
the optimistic ACK attack problem with needing to introduce any artificial
gaps. This could be useful even if packet numbers were fully encrypted
because the attacker is then the receiver - were it not for the problem
with loss detection and early retransmission.


On 9 April 2018 at 23.33.05, Nick Banks (nibanks@microsoft.com) wrote:

The goal here would essentially just to shuffle the bits in the bottom
byte, just to make everything look reordered to the middlebox. You don=E2=
=80=99t
really have to precompute anything, and it should be independent of BDP or
loss.



Here is a slight variation on Praveen=E2=80=99s suggestion (assumes using f=
ull 128
packet batch size):



   - Preallocate a buffer of 128 bytes and prepopulate it with the values
   of 0 to 127.
   - For each packet sent, randomly grab an item (i.e. the offset) from
   what=E2=80=99s left in the buffer, and remove it (swap with last value, =
and
   decrement length).
   - Replace the bottom byte of the real packet number with the offset and
   put that new packet number in the clear text.
   - Put the real bottom byte of the real packet number in the encrypted
   portion.
   - Encrypt with the new cleartext packet number and send.
   - Once the preallocated buffer is empty, just set the length back to 128
   and continue on.



The sender decrypts using the cleartext packet number. Then replaces the
bottom byte of the packet number with the offset from the encrypted payload
to get the true packet number.



- Nick



*From:* QUIC  *On Behalf Of * Mikkel Fahn=C3=B8e J=
=C3=B8rgensen
*Sent:* Monday, April 9, 2018 2:20 PM
*To:* Praveen Balasubramanian ; IET=
F
QUIC WG 
*Subject:* Re: Simple transform for improving PN ossification prevention



I incidentally implemented Fisher-Yates a few days ago=E2=80=A6



But if you permit a window, you can also encrypt packet numbers using an
internal precomputed AES driven PRNG stream - this is about 16x faster than
direct encryption because one block covers 4 packets, and encryption can be
done in a parallel pipeline with current AES-NI hardware. You need to map
the window in a hash table, and it must be small or cache effects makes it
too expensive.



However, big packet loss would make this scheme either ineffective, or
complicated with fallback search.



I assume your proposed shuffle is fully deterministic and precomputed.
Aside from the problems with a window size vs loss, this looks like a very
good way to correlate packets because they now exhibit a distinct pattern
for each connection. So I don=E2=80=99t see this as being worthwhile, if I
understand the scheme correctly.



The shuffle can also be seen as a clever way to create a perfect hash table
for the above mentioned PRNG scheme, but I don't think it would be
effective for large enough windows.



Furthermore, all of these schemes require extra memory per connection and
this can be expensive if there are 10K+ idle connections sitting.



/*

 * Given an uninitialized `index` of `n` uint64_t slots:

 * Place a unique value in the range 0 .. n - 1 inclusive in each slot

 * unbiased randomly (within the prng limits).

 *

 * Based on Fisher-Yates shuffle - inside out variant..

 */

static inline void rand64_init_shuffle_below(uint64_t *state, uint64_t
*index, uint64_t n)

{

    uint64_t i, x;



    for (i =3D 0; i < n; ++i) {

        x =3D rand64_below(state, i + 1); /* unsigned random value (0 .. i)=
 */

        index[i] =3D index[x]; /* Uninitialized if i =3D=3D x, which is ok.=
 */

        index[x] =3D i;

    }

}





Mikkel





On 9 April 2018 at 22.48.48, Praveen Balasubramanian (
pravb=3D40microsoft.com@dmarc.ietf.org) wrote:

The current approach in the draft for preventing PN ossification is to use
a random starting PN. Kazuho pointed out a problem with this approach where
middleboxes could interpret the PN as a sequence number. And in an attempt
to be =E2=80=9Chelpful=E2=80=9D, they could reorder the packets exacerbatin=
g the HoL
blocking problem and may cause issues for unreliable semantics.



If the PN *in the clear* (the nonce value) didn=E2=80=99t always monotonica=
lly
increase then it will preclude such bad behavior by the middleboxes. Hence
we need to find a simple transform that is not monotonically increasing and
also not repeating.



Requirements for any PN transform in the single path case:

   1. The actual PN must always increment by 1 and will be used for
   generating ACKs in ACK frames.
   2. The transformed PN in the clear is a nonce and must not repeat over
   the connection lifetime.
   3. Middleboxes must not be able to determine the actual PN. Only the
   QUIC receiver should be able to do so.



PNE is one possible transform that meets all these requirements but it is
expensive CPU cost wise and has implications for hardware implementations.



Following is a proposal for an alternative simple transform with low CPU
overhead which satisfies these three requirements. The goal is to produce a
non-repeating shuffle of the original set of numbers. Since the PN space is
very big and efficient shuffle algorithms have O(n) space requirement, we
need to define a =E2=80=9Creorder degree=E2=80=9D or a =E2=80=9Cbatch size=
=E2=80=9D within which we will
shuffle the packet numbers.



As an example consider that the starting random PN is 100. Per the current
draft the actual PN increments as follows:

    100, 101, 102, 103, 104,    105, 106, 107, 108, 109, =E2=80=A6 and so f=
orth



Let=E2=80=99s assume a =E2=80=9Cbatch size=E2=80=9D of 5. Then using one po=
ssible outcome of the
shuffles we can generate the following as the cleartext nonces:

|  102, 104, 103, 101, 100, |  107, 105, 109, 108, 106 |   ,=E2=80=A6 and s=
o forth

The bars | indicate batch boundaries.



Of course since we need the QUIC receiver to get the actual PN from the
cleartext value, we need to communicate the offsets in the encrypted
portion of the packet, which for this example would be:

|  +2,    +3,   +1,   -2,   -4,    |    -2,   +1,   -2,    0,     +3    |,
 =E2=80=A6.

Middleboxes will not be able to see the offset values in the clear. QUIC
receiver will need to do a simple add of a signed number to get the
original PN. This is very cheap operation CPU cost wise.



A QUIC sender implementation can pick any size for the reorder degree, the
trade-off is the space complexity and packet space needed to communicate
the offsets. A reorder degree within 128 numbers will need at most an extra
byte in the encrypted header to communicate the signed offset values. The
128 batch size i.e. a 1 byte offset size should be more than enough entropy
to discourage a middle box from =E2=80=9Cfixing reordering=E2=80=9D and in =
practice we may
need less.



One possible algorithm for the shuffle is the Fisher=E2=80=93Yates (Knuth) =
shuffle
as documented here: https://en.wikipedia.org/wiki/Fisher=E2=80=93Yates_shuf=
fle

.. Please see the =E2=80=9CModern method=E2=80=9D section which is in-place.=
 The random
number generator doesn=E2=80=99t have to be a secure variant.



One advantage of such a scheme is that packet loss can still be inferred by
looking at each batch sized set of the nonce (packet numbers). For example
if the batch size is 128, then missing numbers in this batch size (or a
multiple) will show the extent of packet loss. The other advantage is that
a QUIC diagnostic connection can trivially detect a bad middlebox that
tries to reorder the nonce in sequence as it will be easily distinguishable
from a random network reorder.

--000000000000cdd3420569716b53
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
OK, so the high bits=
 are kept - this solves the loss problem.
And the sender does not have to decode the shu=
ffle because the packet number is the packet number - which makes the shuff=
le order non-recurring in the batch, but it also makes loss detection very =
difficult to do with any degree of precision.
Privacy is also not a goal here because th=
e high bits are an immediate giveaway if the window is small. Just the aver=
age distance between two 0 bytes on the low packet number would make a stro=
ng correlation.

So I=
=E2=80=99m not really sure why - if it is to prevent middle boxes from addi=
ng reordering latency by being unorganized, one has to hope that a middlebo=
x does not try to reorder anyway, but ok, I see.

I=E2=80=99m not convinced. But the scheme has a=
nother brilliant property: it solves the optimistic ACK attack problem with=
 needing to introduce any artificial gaps. This could be useful even if pac=
ket numbers were fully encrypted because the attacker is then the receiver =
- were it not for the problem with loss detection and early retransmission.=

 

 
=

On 9 April 2018 at 23.33.05, Nick Banks (nibanks@microsoft.com) wrote:
 










The goal here would essentially just to shuffle the =
bits in the bottom byte, just to make everything look reordered to the midd=
lebox. You don=E2=80=99t really have to precompute anything, and it should =
be independent of BDP or loss.


=C2=A0


Here is a slight variation on Praveen=E2=80=99s sugg=
estion (assumes using full 128 packet batch size):


=C2=A0


    

  • Preallocate a buff=
er of 128 bytes and prepopulate it with the values of 0 to 127.
  • For each packet sent, ran=
domly grab an item (i.e. the offset) from what=E2=80=99s left in the buffer=
, and remove it (swap with last value, and decrement length).
  • Replace the bottom byte of =
the real packet number with the offset and put that new packet number in th=
e clear text.
  • =
Put the real bottom byte of the real packet number in the encrypted portion=
..
  • Encrypt with=
 the new cleartext packet number and send.
  • Once the preallocated buffer is empty, just se=
t the length back to 128 and continue on.


=C2=A0


The sender decrypts using the cleartext packet numbe=
r. Then replaces the bottom byte of the packet number with the offset from =
the encrypted payload to get the true packet number.


=C2=A0


- Nick


=C2=A0






From: QUIC <quic-bounces@ietf.org> On Behalf Of 
Mikkel Fahn=C3=B8e J=C3=B8rgensen

Sent: Monday, April 9, 2018 2:20 PM

To: Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org>; IETF QUIC WG =
<quic@ietf.org>

Subject: Re: Simple transform for improving PN ossification preventi=
on






=C2=A0




I incidentally implemented Fisher-Yates a few day=
s ago=E2=80=A6






=C2=A0






But if you permit a window, you can also encrypt =
packet numbers using an internal precomputed AES driven PRNG stream - this =
is about 16x faster than direct encryption because
 one block covers 4 packets, and encryption can be done in a parallel pipel=
ine with current AES-NI hardware. You need to map the window in a hash tabl=
e, and it must be small or cache effects makes it too expensive.






=C2=A0






However, big packet loss would make this scheme e=
ither ineffective, or complicated with fallback search.






=C2=A0






I assume your proposed shuffle is fully determini=
stic and precomputed. Aside from the problems with a window size vs loss, t=
his looks like a very good way to correlate packets
 because they now exhibit a distinct pattern for each connection. So I don=
=E2=80=99t see this as being worthwhile, if I understand the scheme correct=
ly.






=C2=A0






The shuffle can also be seen as a clever way to c=
reate a perfect hash table for the above mentioned PRNG scheme, but I don&#=
39;t think it would be effective for large enough
 windows.






=C2=A0






Furthermore, all of these schemes require extra m=
emory per connection and this can be expensive if there are 10K+ idle conne=
ctions sitting.






=C2=A0








/*






=C2=A0* Given an uninitialized `index` of `n` uin=
t64_t slots:






=C2=A0* Place a unique value in the range 0 .. n =
- 1 inclusive in each slot






=C2=A0* unbiased randomly (within the prng limits=
).






=C2=A0*






=C2=A0* Based on Fisher-Yates shuffle - inside ou=
t variant..






=C2=A0*/






static inline void rand64_init_shuffle_below(uint=
64_t *state, uint64_t *index, uint64_t n)






{






=C2=A0 =C2=A0 uint64_t i, x;






=C2=A0






=C2=A0 =C2=A0 for (i =3D 0; i < n; ++i) {






=C2=A0 =C2=A0 =C2=A0 =C2=A0 x =3D rand64_below(st=
ate, i + 1); /* unsigned random value (0 .. i) */






=C2=A0 =C2=A0 =C2=A0 =C2=A0 index[i] =3D index[x]=
; /* Uninitialized if i =3D=3D x, which is ok. */






=C2=A0 =C2=A0 =C2=A0 =C2=A0 index[x] =3D i;






=C2=A0 =C2=A0 }






}






=C2=A0








=C2=A0






Mikkel






=C2=A0




=C2=A0


On 9 April 2018 at 22.48.48, Praveen Balasubraman=
ian (pravb=3D40mi=
crosoft.com@dmarc.ietf.org) wrote:










The current approach in the draft for preventing PN ossificatio=
n is to use a random starting PN. Kazuho pointed
 out a problem with this approach where middleboxes could interpret the PN =
as a sequence number. And in an attempt to be =E2=80=9Chelpful=E2=80=9D, th=
ey could reorder the packets exacerbating the HoL blocking problem and may =
cause issues for unreliable semantics.



=C2=A0


If the PN
in the clear (the nonce value) didn=E2=80=99t always monotonically i=
ncrease then it will preclude such bad behavior by the middleboxes. Hence w=
e need to find a simple transform that is not monotonically increasing and =
also not repeating.



=C2=A0


Requirements for any PN transform in the single path case:


    

  1. 
The actual PN must always increment by 1 and will be used for generating=
 ACKs in ACK frames.

  2. 
The transformed PN in the clear is a nonce and must not repeat over the =
connection lifetime.
  3. 
Middleboxes must not be able to determine the actual PN. Only the QUIC r=
eceiver should be able to do so.


=C2=A0


PNE is one possible transform that meets all these requirements=
 but it is expensive CPU cost wise and has implications
 for hardware implementations. 


=C2=A0


Following is a proposal for an alternative simple transform wit=
h low CPU overhead which satisfies these three requirements.
 The goal is to produce a non-repeating shuffle of the original set of numb=
ers. Since the PN space is very big and efficient shuffle algorithms have O=
(n) space requirement, we need to define a =E2=80=9Creorder degree=E2=80=9D=
 or a =E2=80=9Cbatch size=E2=80=9D within which we will shuffle
 the packet numbers.


=C2=A0


As an example consider that the starting random PN is 100. Per =
the current draft the actual PN increments as follows:


=C2=A0=C2=A0=C2=A0 100, 101, 102, 103, 104, =C2=A0=C2=A0=C2=A01=
05, 106, 107, 108, 109, =E2=80=A6 and so forth


=C2=A0


Let=E2=80=99s assume a =E2=80=9Cbatch size=E2=80=9D of 5. Then =
using one possible outcome of the shuffles we can generate the following
 as the cleartext nonces:


|=C2=A0 102, 104, 103, 101, 100, |=C2=A0 107, 105, 109, 108, 10=
6 | =C2=A0=C2=A0,=E2=80=A6 and so forth


The bars | indicate batch boundaries.


=C2=A0


Of course since we need the QUIC receiver to get the actual PN =
from the cleartext value, we need to communicate
 the offsets in the encrypted portion of the packet, which for this example=
 would be:


|=C2=A0 +2, =C2=A0=C2=A0=C2=A0+3, =C2=A0=C2=A0+1, =C2=A0=C2=A0-=
2, =C2=A0=C2=A0-4,=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 -2, =C2=A0=C2=A0+1=
, =C2=A0=C2=A0-2, =C2=A0=C2=A0=C2=A00, =C2=A0=C2=A0=C2=A0=C2=A0+3 =C2=A0=C2=
=A0=C2=A0|, =C2=A0=E2=80=A6.


Middleboxes will not be able to see the offset values in the cl=
ear. QUIC receiver will need to do a simple add
 of a signed number to get the original PN. This is very cheap operation CP=
U cost wise.



=C2=A0


A QUIC sender implementation can pick any size for the reorder =
degree, the trade-off is the space complexity and
 packet space needed to communicate the offsets. A reorder degree within 12=
8 numbers will need at most an extra byte in the encrypted header to commun=
icate the signed offset values. The 128 batch size i.e. a 1 byte offset siz=
e should be more than enough entropy
 to discourage a middle box from =E2=80=9Cfixing reordering=E2=80=9D and in=
 practice we may need less.


=C2=A0


One possible algorithm for the shuffle is the Fisher=E2=80=93Ya=
tes (Knuth) shuffle as documented here:

https://en.wikipedia.org/wiki/Fisher=E2=80=93Yates_shuffle . Please see=
 the =E2=80=9CModern method=E2=80=9D section which is in-place. The random =
number generator doesn=E2=80=99t have to be a secure variant.


=C2=A0


One advantage of such a scheme is that packet loss can still be=
 inferred by looking at each batch sized set of
 the nonce (packet numbers). For example if the batch size is 128, then mis=
sing numbers in this batch size (or a multiple) will show the extent of pac=
ket loss. The other advantage is that a QUIC diagnostic connection can triv=
ially detect a bad middlebox that
 tries to reorder the nonce in sequence as it will be easily distinguishabl=
e from a random network reorder.



=C2=A0


=C2=A0
















--000000000000cdd3420569716b53--


From nobody Mon Apr  9 14:57:09 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C011112DA05 for ; Mon,  9 Apr 2018 14:57:07 -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, 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 pc3FR8wj4h-e for ; Mon,  9 Apr 2018 14:57:04 -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 D70A012D96B for ; Mon,  9 Apr 2018 14:57:03 -0700 (PDT)
Received: by mail-io0-x236.google.com with SMTP id 141so11429675iou.12 for ; Mon, 09 Apr 2018 14:57:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to;  bh=NnPI27uhIfPvziSyIlg8WrW4KoLl0lauHPnPDIFB9Ik=; b=butJPBuCxzU8tAc+KttLoGSiWjxXiYsgGxDTGZa2KPGYQvI4PlX89qulL/Zea3F3/t hhtn5eoR4sH7zDkQ8C69VOTXFz1w9XIUXWgkPpqvCBY2puUBN0zp0yX4QWhpPzMSXy92 kVls+g3lZm0fT17pM49E4QWIrikeiGAB6JJmPhdGredhwuifk2fTezY6wiDdPP1xOiCI VbSBPczmlMkFziX2U2FLtaLISWGfucqIo+lOboneiqcb29DTyVKgQ9cpm5+udLMaaOkD OP0Y/cs+xGBQISp1eqeYOWAerQSl3xAuhHAp7hh22EJTIlGmCaP1id9j314OQDiniTTy BX2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=NnPI27uhIfPvziSyIlg8WrW4KoLl0lauHPnPDIFB9Ik=; b=KA5KMpbHANLYFBo/x8URek/DKruzDjCW8i28f3KN5gIGAGic0Pei9dJmBx2gqQyTBI K//2yv4XrLnrqjWza3ELLSfHMCgGW06hpymDdjOS4txmkvqPTSUJpH4uX+hMS0CP31pE fHBR1QU+r6G6L1AYVWUxx682bmJEQ7gTfn+ZhbydDznXER+KDemrNEtqHwG0JAFPfcdK sMQacxnGDD/TtSSJaN6o8NVAz3K9iENGMnZ96n1GdK/2u+Y8HsdUYO7X7MZkLS8s+8MA v7xWCl+jqs0DsjjvfBJt4I71SiDx38Z00EpYwmh0pn1949Yb7D0NGvLYOdciPQXNXZUe //jw==
X-Gm-Message-State: ALQs6tBdUC95DYH3wTP0MDr/CluEoC0cg/fA57PWrRDGM5qGqnfqJM9P DLExuSBoeW9faJBwhPCbYDSuc404IMYAVzywmFY=
X-Google-Smtp-Source: AIpwx4/7oRccdn9H8ZAlKUkrNlHvYoH0B5Ckh20np3WJrjkNnVFdwlHoNQnTu6+Rq9cjeH3vpvrwc7JZDeWxJHzGfko=
X-Received: by 10.107.6.163 with SMTP id f35mr749369ioi.165.1523311023058; Mon, 09 Apr 2018 14:57:03 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 9 Apr 2018 17:57:02 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:    
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 9 Apr 2018 17:57:02 -0400
Message-ID: 
Subject: RE: Simple transform for improving PN ossification prevention
To: Nick Banks ,  Praveen Balasubramanian , IETF QUIC WG 
Content-Type: multipart/alternative; boundary="001a113e06a26973aa0569717cb8"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 21:57:08 -0000

--001a113e06a26973aa0569717cb8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sorry, the loss is handled by duplication of the packet number in the
encrypted portion, but this then prevents it from protecting against
optimistic ACK attacks.


On 9 April 2018 at 23.52.23, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gm=
ail.com)
wrote:

OK, so the high bits are kept - this solves the loss problem.
And the sender does not have to decode the shuffle because the packet
number is the packet number - which makes the shuffle order non-recurring
in the batch, but it also makes loss detection very difficult to do with
any degree of precision.
Privacy is also not a goal here because the high bits are an immediate
giveaway if the window is small. Just the average distance between two 0
bytes on the low packet number would make a strong correlation.

So I=E2=80=99m not really sure why - if it is to prevent middle boxes from =
adding
reordering latency by being unorganized, one has to hope that a middlebox
does not try to reorder anyway, but ok, I see.

I=E2=80=99m not convinced. But the scheme has another brilliant property: i=
t solves
the optimistic ACK attack problem with needing to introduce any artificial
gaps. This could be useful even if packet numbers were fully encrypted
because the attacker is then the receiver - were it not for the problem
with loss detection and early retransmission.


On 9 April 2018 at 23.33.05, Nick Banks (nibanks@microsoft.com) wrote:

The goal here would essentially just to shuffle the bits in the bottom
byte, just to make everything look reordered to the middlebox. You don=E2=
=80=99t
really have to precompute anything, and it should be independent of BDP or
loss.



Here is a slight variation on Praveen=E2=80=99s suggestion (assumes using f=
ull 128
packet batch size):



   - Preallocate a buffer of 128 bytes and prepopulate it with the values
   of 0 to 127.
   - For each packet sent, randomly grab an item (i.e. the offset) from
   what=E2=80=99s left in the buffer, and remove it (swap with last value, =
and
   decrement length).
   - Replace the bottom byte of the real packet number with the offset and
   put that new packet number in the clear text.
   - Put the real bottom byte of the real packet number in the encrypted
   portion.
   - Encrypt with the new cleartext packet number and send.
   - Once the preallocated buffer is empty, just set the length back to 128
   and continue on.



The sender decrypts using the cleartext packet number. Then replaces the
bottom byte of the packet number with the offset from the encrypted payload
to get the true packet number.



- Nick



*From:* QUIC  *On Behalf Of * Mikkel Fahn=C3=B8e J=
=C3=B8rgensen
*Sent:* Monday, April 9, 2018 2:20 PM
*To:* Praveen Balasubramanian ; IET=
F
QUIC WG 
*Subject:* Re: Simple transform for improving PN ossification prevention



I incidentally implemented Fisher-Yates a few days ago=E2=80=A6



But if you permit a window, you can also encrypt packet numbers using an
internal precomputed AES driven PRNG stream - this is about 16x faster than
direct encryption because one block covers 4 packets, and encryption can be
done in a parallel pipeline with current AES-NI hardware. You need to map
the window in a hash table, and it must be small or cache effects makes it
too expensive.



However, big packet loss would make this scheme either ineffective, or
complicated with fallback search.



I assume your proposed shuffle is fully deterministic and precomputed.
Aside from the problems with a window size vs loss, this looks like a very
good way to correlate packets because they now exhibit a distinct pattern
for each connection. So I don=E2=80=99t see this as being worthwhile, if I
understand the scheme correctly.



The shuffle can also be seen as a clever way to create a perfect hash table
for the above mentioned PRNG scheme, but I don't think it would be
effective for large enough windows.



Furthermore, all of these schemes require extra memory per connection and
this can be expensive if there are 10K+ idle connections sitting.



/*

 * Given an uninitialized `index` of `n` uint64_t slots:

 * Place a unique value in the range 0 .. n - 1 inclusive in each slot

 * unbiased randomly (within the prng limits).

 *

 * Based on Fisher-Yates shuffle - inside out variant..

 */

static inline void rand64_init_shuffle_below(uint64_t *state, uint64_t
*index, uint64_t n)

{

    uint64_t i, x;



    for (i =3D 0; i < n; ++i) {

        x =3D rand64_below(state, i + 1); /* unsigned random value (0 .. i)=
 */

        index[i] =3D index[x]; /* Uninitialized if i =3D=3D x, which is ok.=
 */

        index[x] =3D i;

    }

}





Mikkel





On 9 April 2018 at 22.48.48, Praveen Balasubramanian (
pravb=3D40microsoft.com@dmarc.ietf.org) wrote:

The current approach in the draft for preventing PN ossification is to use
a random starting PN. Kazuho pointed out a problem with this approach where
middleboxes could interpret the PN as a sequence number. And in an attempt
to be =E2=80=9Chelpful=E2=80=9D, they could reorder the packets exacerbatin=
g the HoL
blocking problem and may cause issues for unreliable semantics.



If the PN *in the clear* (the nonce value) didn=E2=80=99t always monotonica=
lly
increase then it will preclude such bad behavior by the middleboxes. Hence
we need to find a simple transform that is not monotonically increasing and
also not repeating.



Requirements for any PN transform in the single path case:

   1. The actual PN must always increment by 1 and will be used for
   generating ACKs in ACK frames.
   2. The transformed PN in the clear is a nonce and must not repeat over
   the connection lifetime.
   3. Middleboxes must not be able to determine the actual PN. Only the
   QUIC receiver should be able to do so.



PNE is one possible transform that meets all these requirements but it is
expensive CPU cost wise and has implications for hardware implementations.



Following is a proposal for an alternative simple transform with low CPU
overhead which satisfies these three requirements. The goal is to produce a
non-repeating shuffle of the original set of numbers. Since the PN space is
very big and efficient shuffle algorithms have O(n) space requirement, we
need to define a =E2=80=9Creorder degree=E2=80=9D or a =E2=80=9Cbatch size=
=E2=80=9D within which we will
shuffle the packet numbers.



As an example consider that the starting random PN is 100. Per the current
draft the actual PN increments as follows:

    100, 101, 102, 103, 104,    105, 106, 107, 108, 109, =E2=80=A6 and so f=
orth



Let=E2=80=99s assume a =E2=80=9Cbatch size=E2=80=9D of 5. Then using one po=
ssible outcome of the
shuffles we can generate the following as the cleartext nonces:

|  102, 104, 103, 101, 100, |  107, 105, 109, 108, 106 |   ,=E2=80=A6 and s=
o forth

The bars | indicate batch boundaries.



Of course since we need the QUIC receiver to get the actual PN from the
cleartext value, we need to communicate the offsets in the encrypted
portion of the packet, which for this example would be:

|  +2,    +3,   +1,   -2,   -4,    |    -2,   +1,   -2,    0,     +3    |,
 =E2=80=A6.

Middleboxes will not be able to see the offset values in the clear. QUIC
receiver will need to do a simple add of a signed number to get the
original PN. This is very cheap operation CPU cost wise.



A QUIC sender implementation can pick any size for the reorder degree, the
trade-off is the space complexity and packet space needed to communicate
the offsets. A reorder degree within 128 numbers will need at most an extra
byte in the encrypted header to communicate the signed offset values. The
128 batch size i.e. a 1 byte offset size should be more than enough entropy
to discourage a middle box from =E2=80=9Cfixing reordering=E2=80=9D and in =
practice we may
need less.



One possible algorithm for the shuffle is the Fisher=E2=80=93Yates (Knuth) =
shuffle
as documented here: https://en.wikipedia.org/wiki/Fisher=E2=80=93Yates_shuf=
fle

. Please see the =E2=80=9CModern method=E2=80=9D section which is in-place.=
 The random
number generator doesn=E2=80=99t have to be a secure variant.



One advantage of such a scheme is that packet loss can still be inferred by
looking at each batch sized set of the nonce (packet numbers). For example
if the batch size is 128, then missing numbers in this batch size (or a
multiple) will show the extent of packet loss. The other advantage is that
a QUIC diagnostic connection can trivially detect a bad middlebox that
tries to reorder the nonce in sequence as it will be easily distinguishable
from a random network reorder.

--001a113e06a26973aa0569717cb8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
Sorry, the loss is h=
andled by duplication of the packet number in the encrypted portion, but th=
is then prevents it from protecting against optimistic ACK attacks. <=
div id=3D"bloop_sign_1523310922794253824" class=3D"bloop_sign">

 
On 9 April 2018 at 23.52.23, Mikkel Fahn=C3=B8e J=C3=B8rg=
ensen (mikkelfj@gmail.com) wrote:=

 
OK, so the high bits are kept -=
 this solves the loss problem.
And the sender does not have to decode the shuffle becaus=
e the packet number is the packet number - which makes the shuffle order no=
n-recurring in the batch, but it also makes loss detection very difficult t=
o do with any degree of precision.
Privacy is also not a goal here because the high bit=
s are an immediate giveaway if the window is small. Just the average distan=
ce between two 0 bytes on the low packet number would make a strong correla=
tion.

So I=E2=80=99m =
not really sure why - if it is to prevent middle boxes from adding reorderi=
ng latency by being unorganized, one has to hope that a middlebox does not =
try to reorder anyway, but ok, I see.

I=E2=80=99m not convinced. But the scheme has another bril=
liant property: it solves the optimistic ACK attack problem with needing to=
 introduce any artificial gaps. This could be useful even if packet numbers=
 were fully encrypted because the attacker is then the receiver - were it n=
ot for the problem with loss detection and early retransmission.
 

 
On 9 April 2018 at 23.33.05, Nick Banks (nibanks@microsoft.com) wrote:
 










The goal here would essentially just to shuffle the =
bits in the bottom byte, just to make everything look reordered to the midd=
lebox. You don=E2=80=99t really have to precompute anything, and it should =
be independent of BDP or loss.


=C2=A0


Here is a slight variation on Praveen=E2=80=99s sugg=
estion (assumes using full 128 packet batch size):


=C2=A0


    

  • Preallocate a buff=
er of 128 bytes and prepopulate it with the values of 0 to 127.
  • For each packet sent, ran=
domly grab an item (i.e. the offset) from what=E2=80=99s left in the buffer=
, and remove it (swap with last value, and decrement length).
  • Replace the bottom byte of =
the real packet number with the offset and put that new packet number in th=
e clear text.
  • =
Put the real bottom byte of the real packet number in the encrypted portion=
.
  • Encrypt with=
 the new cleartext packet number and send.
  • Once the preallocated buffer is empty, just se=
t the length back to 128 and continue on.


=C2=A0


The sender decrypts using the cleartext packet numbe=
r. Then replaces the bottom byte of the packet number with the offset from =
the encrypted payload to get the true packet number.


=C2=A0


- Nick


=C2=A0






From: QUIC <quic-bounces@ietf.org> On Behalf Of 
Mikkel Fahn=C3=B8e J=C3=B8rgensen

Sent: Monday, April 9, 2018 2:20 PM

To: Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org>; IETF QUIC WG =
<quic@ietf.org>

Subject: Re: Simple transform for improving PN ossification preventi=
on






=C2=A0




I incidentally implemented Fisher-Yates a few day=
s ago=E2=80=A6






=C2=A0






But if you permit a window, you can also encrypt =
packet numbers using an internal precomputed AES driven PRNG stream - this =
is about 16x faster than direct encryption because
 one block covers 4 packets, and encryption can be done in a parallel pipel=
ine with current AES-NI hardware. You need to map the window in a hash tabl=
e, and it must be small or cache effects makes it too expensive.






=C2=A0






However, big packet loss would make this scheme e=
ither ineffective, or complicated with fallback search.






=C2=A0






I assume your proposed shuffle is fully determini=
stic and precomputed. Aside from the problems with a window size vs loss, t=
his looks like a very good way to correlate packets
 because they now exhibit a distinct pattern for each connection. So I don=
=E2=80=99t see this as being worthwhile, if I understand the scheme correct=
ly.






=C2=A0






The shuffle can also be seen as a clever way to c=
reate a perfect hash table for the above mentioned PRNG scheme, but I don&#=
39;t think it would be effective for large enough
 windows.






=C2=A0






Furthermore, all of these schemes require extra m=
emory per connection and this can be expensive if there are 10K+ idle conne=
ctions sitting.






=C2=A0








/*






=C2=A0* Given an uninitialized `index` of `n` uin=
t64_t slots:






=C2=A0* Place a unique value in the range 0 .. n =
- 1 inclusive in each slot






=C2=A0* unbiased randomly (within the prng limits=
).






=C2=A0*






=C2=A0* Based on Fisher-Yates shuffle - inside ou=
t variant..






=C2=A0*/






static inline void rand64_init_shuffle_below(uint=
64_t *state, uint64_t *index, uint64_t n)






{






=C2=A0 =C2=A0 uint64_t i, x;






=C2=A0






=C2=A0 =C2=A0 for (i =3D 0; i < n; ++i) {






=C2=A0 =C2=A0 =C2=A0 =C2=A0 x =3D rand64_below(st=
ate, i + 1); /* unsigned random value (0 .. i) */






=C2=A0 =C2=A0 =C2=A0 =C2=A0 index[i] =3D index[x]=
; /* Uninitialized if i =3D=3D x, which is ok. */






=C2=A0 =C2=A0 =C2=A0 =C2=A0 index[x] =3D i;






=C2=A0 =C2=A0 }






}






=C2=A0








=C2=A0






Mikkel






=C2=A0




=C2=A0


On 9 April 2018 at 22.48.48, Praveen Balasubraman=
ian (pravb=3D40mi=
crosoft.com@dmarc.ietf.org) wrote:










The current approach in the draft for preventing PN ossificatio=
n is to use a random starting PN. Kazuho pointed
 out a problem with this approach where middleboxes could interpret the PN =
as a sequence number. And in an attempt to be =E2=80=9Chelpful=E2=80=9D, th=
ey could reorder the packets exacerbating the HoL blocking problem and may =
cause issues for unreliable semantics.



=C2=A0


If the PN
in the clear (the nonce value) didn=E2=80=99t always monotonically i=
ncrease then it will preclude such bad behavior by the middleboxes. Hence w=
e need to find a simple transform that is not monotonically increasing and =
also not repeating.



=C2=A0


Requirements for any PN transform in the single path case:


    

  1. 
The actual PN must always increment by 1 and will be used for generating=
 ACKs in ACK frames.

  2. 
The transformed PN in the clear is a nonce and must not repeat over the =
connection lifetime.
  3. 
Middleboxes must not be able to determine the actual PN. Only the QUIC r=
eceiver should be able to do so.


=C2=A0


PNE is one possible transform that meets all these requirements=
 but it is expensive CPU cost wise and has implications
 for hardware implementations. 


=C2=A0


Following is a proposal for an alternative simple transform wit=
h low CPU overhead which satisfies these three requirements.
 The goal is to produce a non-repeating shuffle of the original set of numb=
ers. Since the PN space is very big and efficient shuffle algorithms have O=
(n) space requirement, we need to define a =E2=80=9Creorder degree=E2=80=9D=
 or a =E2=80=9Cbatch size=E2=80=9D within which we will shuffle
 the packet numbers.


=C2=A0


As an example consider that the starting random PN is 100. Per =
the current draft the actual PN increments as follows:


=C2=A0=C2=A0=C2=A0 100, 101, 102, 103, 104, =C2=A0=C2=A0=C2=A01=
05, 106, 107, 108, 109, =E2=80=A6 and so forth


=C2=A0


Let=E2=80=99s assume a =E2=80=9Cbatch size=E2=80=9D of 5. Then =
using one possible outcome of the shuffles we can generate the following
 as the cleartext nonces:


|=C2=A0 102, 104, 103, 101, 100, |=C2=A0 107, 105, 109, 108, 10=
6 | =C2=A0=C2=A0,=E2=80=A6 and so forth


The bars | indicate batch boundaries.


=C2=A0


Of course since we need the QUIC receiver to get the actual PN =
from the cleartext value, we need to communicate
 the offsets in the encrypted portion of the packet, which for this example=
 would be:


|=C2=A0 +2, =C2=A0=C2=A0=C2=A0+3, =C2=A0=C2=A0+1, =C2=A0=C2=A0-=
2, =C2=A0=C2=A0-4,=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 -2, =C2=A0=C2=A0+1=
, =C2=A0=C2=A0-2, =C2=A0=C2=A0=C2=A00, =C2=A0=C2=A0=C2=A0=C2=A0+3 =C2=A0=C2=
=A0=C2=A0|, =C2=A0=E2=80=A6.


Middleboxes will not be able to see the offset values in the cl=
ear. QUIC receiver will need to do a simple add
 of a signed number to get the original PN. This is very cheap operation CP=
U cost wise.



=C2=A0


A QUIC sender implementation can pick any size for the reorder =
degree, the trade-off is the space complexity and
 packet space needed to communicate the offsets. A reorder degree within 12=
8 numbers will need at most an extra byte in the encrypted header to commun=
icate the signed offset values. The 128 batch size i.e. a 1 byte offset siz=
e should be more than enough entropy
 to discourage a middle box from =E2=80=9Cfixing reordering=E2=80=9D and in=
 practice we may need less.


=C2=A0


One possible algorithm for the shuffle is the Fisher=E2=80=93Ya=
tes (Knuth) shuffle as documented here:

https://en.wikipedia.org/wiki/Fisher=E2=80=93Yates_shuffle . Please see=
 the =E2=80=9CModern method=E2=80=9D section which is in-place. The random =
number generator doesn=E2=80=99t have to be a secure variant.


=C2=A0


One advantage of such a scheme is that packet loss can still be=
 inferred by looking at each batch sized set of
 the nonce (packet numbers). For example if the batch size is 128, then mis=
sing numbers in this batch size (or a multiple) will show the extent of pac=
ket loss. The other advantage is that a QUIC diagnostic connection can triv=
ially detect a bad middlebox that
 tries to reorder the nonce in sequence as it will be easily distinguishabl=
e from a random network reorder.



=C2=A0


=C2=A0
















--001a113e06a26973aa0569717cb8--


From nobody Mon Apr  9 14:57:27 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D6012D96C for ; Mon,  9 Apr 2018 14:57:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523311028; bh=XfoYmx65NYFLDVuTw57O4eDgmvl2PrBDDM8itYUdrW0=; h=From:In-Reply-To:References:Date:Subject:To:To:To; b=s7Hdd0gC5/KAaxPvul+kXUzmMZ6LMLjJJoUe6h5MnD72DMq+rfE2vC/EnK0NLXfX+ NWrDyFbXosYKLlHCvBI/MMfnxfSc30s4s59GYtYna5TpTd+4GUv932ruZkabScDhSU 0Jnc1P8FWkywuaGl4HYnShFhGE8XUn7XLKnIdUr0=
X-Mailbox-Line: From mikkelfj@gmail.com  Mon Apr  9 14:57:08 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B49D812D810; Mon,  9 Apr 2018 14:57:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523311028; bh=AxQRkz/ojCR+POlnyGY7DSVGwrf0epY4svN1joHNHf4=; h=From:In-Reply-To:References:Date:Subject:To:To:To; b=w5kJehUeTHNQeeeEiwxzifn/s77tQPhLvRcYSKvhQ2UWQCFAT2TOJns7izskCF75D wHcMMT2CyI+IYgy0NuiPqhZwiZxRB1AiO8FWLaYJSXJ7iqUdtE9P3Ka2Ilw7EI0Q4l ZCJXffoALTcjnqNfHCu/VpcQQltG60fnRGOUPJXI=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F42F12D96B for ; Mon,  9 Apr 2018 14:57:08 -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, UNPARSEABLE_RELAY=0.001] autolearn=unavailable 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 wYeNEKcPyri7 for ; Mon,  9 Apr 2018 14:57:04 -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 BBAE412D810 for ; Mon,  9 Apr 2018 14:57:03 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id q84so11434614iod.10 for ; Mon, 09 Apr 2018 14:57:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to;  bh=NnPI27uhIfPvziSyIlg8WrW4KoLl0lauHPnPDIFB9Ik=; b=butJPBuCxzU8tAc+KttLoGSiWjxXiYsgGxDTGZa2KPGYQvI4PlX89qulL/Zea3F3/t hhtn5eoR4sH7zDkQ8C69VOTXFz1w9XIUXWgkPpqvCBY2puUBN0zp0yX4QWhpPzMSXy92 kVls+g3lZm0fT17pM49E4QWIrikeiGAB6JJmPhdGredhwuifk2fTezY6wiDdPP1xOiCI VbSBPczmlMkFziX2U2FLtaLISWGfucqIo+lOboneiqcb29DTyVKgQ9cpm5+udLMaaOkD OP0Y/cs+xGBQISp1eqeYOWAerQSl3xAuhHAp7hh22EJTIlGmCaP1id9j314OQDiniTTy BX2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=NnPI27uhIfPvziSyIlg8WrW4KoLl0lauHPnPDIFB9Ik=; b=PtSXos7ehKj+ykZLwfuHqx+g8htdXiw3DYHnz8Mq27XzUJFSJ0be2dkWOKOd12X4ah qtM6qgxVLSTzYnRje25bKjlZnVT5Ah86IFNGap3Kh6hi/FgxI3nWmjXF5xfOD9fGnoea f07vkl3hmQwMCC6x9/KPoqrw+lJbjAMhfxShzsV3A2AK3nNus8DlE8x/RUUcpO9kCC+E RwqKoz//WJqyYP/Wi8gTphXC6GMNRXV+NjMmTL9m/zvfJkeXz14nV5DPdXZ1WGISEp/f seKRJ5XUiqKexUmozdueQwJ/Jef5Pi34UeHPjkIZVIOyOCCFRTxnQODdM2+fCNNYWRZG Zgjw==
X-Gm-Message-State: ALQs6tD5604TwBSID8l4ytoYBJMQQg3atWLQdN2P23UeaO6zSkJodVlI uz6CXTFPlta/KQGfHK+A5I9o0srvg7SzdGIO/5o=
X-Google-Smtp-Source: AIpwx4/7oRccdn9H8ZAlKUkrNlHvYoH0B5Ckh20np3WJrjkNnVFdwlHoNQnTu6+Rq9cjeH3vpvrwc7JZDeWxJHzGfko=
X-Received: by 10.107.6.163 with SMTP id f35mr749369ioi.165.1523311023058; Mon, 09 Apr 2018 14:57:03 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 9 Apr 2018 17:57:02 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:    
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 9 Apr 2018 17:57:02 -0400
Message-ID: 
Subject: RE: Simple transform for improving PN ossification prevention
Content-Type: multipart/alternative; boundary="001a113e06a26973aa0569717cb8"
To: Nick Banks 
To: Praveen Balasubramanian 
To: IETF QUIC WG 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Apr 2018 21:57:09 -0000

--001a113e06a26973aa0569717cb8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sorry, the loss is handled by duplication of the packet number in the
encrypted portion, but this then prevents it from protecting against
optimistic ACK attacks.


On 9 April 2018 at 23.52.23, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gm=
ail.com)
wrote:

OK, so the high bits are kept - this solves the loss problem.
And the sender does not have to decode the shuffle because the packet
number is the packet number - which makes the shuffle order non-recurring
in the batch, but it also makes loss detection very difficult to do with
any degree of precision.
Privacy is also not a goal here because the high bits are an immediate
giveaway if the window is small. Just the average distance between two 0
bytes on the low packet number would make a strong correlation.

So I=E2=80=99m not really sure why - if it is to prevent middle boxes from =
adding
reordering latency by being unorganized, one has to hope that a middlebox
does not try to reorder anyway, but ok, I see.

I=E2=80=99m not convinced. But the scheme has another brilliant property: i=
t solves
the optimistic ACK attack problem with needing to introduce any artificial
gaps. This could be useful even if packet numbers were fully encrypted
because the attacker is then the receiver - were it not for the problem
with loss detection and early retransmission.


On 9 April 2018 at 23.33.05, Nick Banks (nibanks@microsoft.com) wrote:

The goal here would essentially just to shuffle the bits in the bottom
byte, just to make everything look reordered to the middlebox. You don=E2=
=80=99t
really have to precompute anything, and it should be independent of BDP or
loss.



Here is a slight variation on Praveen=E2=80=99s suggestion (assumes using f=
ull 128
packet batch size):



   - Preallocate a buffer of 128 bytes and prepopulate it with the values
   of 0 to 127.
   - For each packet sent, randomly grab an item (i.e. the offset) from
   what=E2=80=99s left in the buffer, and remove it (swap with last value, =
and
   decrement length).
   - Replace the bottom byte of the real packet number with the offset and
   put that new packet number in the clear text.
   - Put the real bottom byte of the real packet number in the encrypted
   portion.
   - Encrypt with the new cleartext packet number and send.
   - Once the preallocated buffer is empty, just set the length back to 128
   and continue on.



The sender decrypts using the cleartext packet number. Then replaces the
bottom byte of the packet number with the offset from the encrypted payload
to get the true packet number.



- Nick



*From:* QUIC  *On Behalf Of * Mikkel Fahn=C3=B8e J=
=C3=B8rgensen
*Sent:* Monday, April 9, 2018 2:20 PM
*To:* Praveen Balasubramanian ; IET=
F
QUIC WG 
*Subject:* Re: Simple transform for improving PN ossification prevention



I incidentally implemented Fisher-Yates a few days ago=E2=80=A6



But if you permit a window, you can also encrypt packet numbers using an
internal precomputed AES driven PRNG stream - this is about 16x faster than
direct encryption because one block covers 4 packets, and encryption can be
done in a parallel pipeline with current AES-NI hardware. You need to map
the window in a hash table, and it must be small or cache effects makes it
too expensive.



However, big packet loss would make this scheme either ineffective, or
complicated with fallback search.



I assume your proposed shuffle is fully deterministic and precomputed.
Aside from the problems with a window size vs loss, this looks like a very
good way to correlate packets because they now exhibit a distinct pattern
for each connection. So I don=E2=80=99t see this as being worthwhile, if I
understand the scheme correctly.



The shuffle can also be seen as a clever way to create a perfect hash table
for the above mentioned PRNG scheme, but I don't think it would be
effective for large enough windows.



Furthermore, all of these schemes require extra memory per connection and
this can be expensive if there are 10K+ idle connections sitting.



/*

 * Given an uninitialized `index` of `n` uint64_t slots:

 * Place a unique value in the range 0 .. n - 1 inclusive in each slot

 * unbiased randomly (within the prng limits).

 *

 * Based on Fisher-Yates shuffle - inside out variant..

 */

static inline void rand64_init_shuffle_below(uint64_t *state, uint64_t
*index, uint64_t n)

{

    uint64_t i, x;



    for (i =3D 0; i < n; ++i) {

        x =3D rand64_below(state, i + 1); /* unsigned random value (0 .. i)=
 */

        index[i] =3D index[x]; /* Uninitialized if i =3D=3D x, which is ok.=
 */

        index[x] =3D i;

    }

}





Mikkel





On 9 April 2018 at 22.48.48, Praveen Balasubramanian (
pravb=3D40microsoft.com@dmarc.ietf.org) wrote:

The current approach in the draft for preventing PN ossification is to use
a random starting PN. Kazuho pointed out a problem with this approach where
middleboxes could interpret the PN as a sequence number. And in an attempt
to be =E2=80=9Chelpful=E2=80=9D, they could reorder the packets exacerbatin=
g the HoL
blocking problem and may cause issues for unreliable semantics.



If the PN *in the clear* (the nonce value) didn=E2=80=99t always monotonica=
lly
increase then it will preclude such bad behavior by the middleboxes. Hence
we need to find a simple transform that is not monotonically increasing and
also not repeating.



Requirements for any PN transform in the single path case:

   1. The actual PN must always increment by 1 and will be used for
   generating ACKs in ACK frames.
   2. The transformed PN in the clear is a nonce and must not repeat over
   the connection lifetime.
   3. Middleboxes must not be able to determine the actual PN. Only the
   QUIC receiver should be able to do so.



PNE is one possible transform that meets all these requirements but it is
expensive CPU cost wise and has implications for hardware implementations.



Following is a proposal for an alternative simple transform with low CPU
overhead which satisfies these three requirements. The goal is to produce a
non-repeating shuffle of the original set of numbers. Since the PN space is
very big and efficient shuffle algorithms have O(n) space requirement, we
need to define a =E2=80=9Creorder degree=E2=80=9D or a =E2=80=9Cbatch size=
=E2=80=9D within which we will
shuffle the packet numbers.



As an example consider that the starting random PN is 100. Per the current
draft the actual PN increments as follows:

    100, 101, 102, 103, 104,    105, 106, 107, 108, 109, =E2=80=A6 and so f=
orth



Let=E2=80=99s assume a =E2=80=9Cbatch size=E2=80=9D of 5. Then using one po=
ssible outcome of the
shuffles we can generate the following as the cleartext nonces:

|  102, 104, 103, 101, 100, |  107, 105, 109, 108, 106 |   ,=E2=80=A6 and s=
o forth

The bars | indicate batch boundaries.



Of course since we need the QUIC receiver to get the actual PN from the
cleartext value, we need to communicate the offsets in the encrypted
portion of the packet, which for this example would be:

|  +2,    +3,   +1,   -2,   -4,    |    -2,   +1,   -2,    0,     +3    |,
 =E2=80=A6.

Middleboxes will not be able to see the offset values in the clear. QUIC
receiver will need to do a simple add of a signed number to get the
original PN. This is very cheap operation CPU cost wise.



A QUIC sender implementation can pick any size for the reorder degree, the
trade-off is the space complexity and packet space needed to communicate
the offsets. A reorder degree within 128 numbers will need at most an extra
byte in the encrypted header to communicate the signed offset values. The
128 batch size i.e. a 1 byte offset size should be more than enough entropy
to discourage a middle box from =E2=80=9Cfixing reordering=E2=80=9D and in =
practice we may
need less.



One possible algorithm for the shuffle is the Fisher=E2=80=93Yates (Knuth) =
shuffle
as documented here: https://en.wikipedia.org/wiki/Fisher=E2=80=93Yates_shuf=
fle

.. Please see the =E2=80=9CModern method=E2=80=9D section which is in-place.=
 The random
number generator doesn=E2=80=99t have to be a secure variant.



One advantage of such a scheme is that packet loss can still be inferred by
looking at each batch sized set of the nonce (packet numbers). For example
if the batch size is 128, then missing numbers in this batch size (or a
multiple) will show the extent of packet loss. The other advantage is that
a QUIC diagnostic connection can trivially detect a bad middlebox that
tries to reorder the nonce in sequence as it will be easily distinguishable
from a random network reorder.

--001a113e06a26973aa0569717cb8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
Sorry, the loss is h=
andled by duplication of the packet number in the encrypted portion, but th=
is then prevents it from protecting against optimistic ACK attacks. <=
div id=3D"bloop_sign_1523310922794253824" class=3D"bloop_sign">

 
On 9 April 2018 at 23.52.23, Mikkel Fahn=C3=B8e J=C3=B8rg=
ensen (mikkelfj@gmail.com) wrote:=

 
OK, so the high bits are kept -=
 this solves the loss problem.
And the sender does not have to decode the shuffle becaus=
e the packet number is the packet number - which makes the shuffle order no=
n-recurring in the batch, but it also makes loss detection very difficult t=
o do with any degree of precision.
Privacy is also not a goal here because the high bit=
s are an immediate giveaway if the window is small. Just the average distan=
ce between two 0 bytes on the low packet number would make a strong correla=
tion.

So I=E2=80=99m =
not really sure why - if it is to prevent middle boxes from adding reorderi=
ng latency by being unorganized, one has to hope that a middlebox does not =
try to reorder anyway, but ok, I see.

I=E2=80=99m not convinced. But the scheme has another bril=
liant property: it solves the optimistic ACK attack problem with needing to=
 introduce any artificial gaps. This could be useful even if packet numbers=
 were fully encrypted because the attacker is then the receiver - were it n=
ot for the problem with loss detection and early retransmission.
 

 
On 9 April 2018 at 23.33.05, Nick Banks (nibanks@microsoft.com) wrote:
 










The goal here would essentially just to shuffle the =
bits in the bottom byte, just to make everything look reordered to the midd=
lebox. You don=E2=80=99t really have to precompute anything, and it should =
be independent of BDP or loss.


=C2=A0


Here is a slight variation on Praveen=E2=80=99s sugg=
estion (assumes using full 128 packet batch size):


=C2=A0


    

  • Preallocate a buff=
er of 128 bytes and prepopulate it with the values of 0 to 127.
  • For each packet sent, ran=
domly grab an item (i.e. the offset) from what=E2=80=99s left in the buffer=
, and remove it (swap with last value, and decrement length).
  • Replace the bottom byte of =
the real packet number with the offset and put that new packet number in th=
e clear text.
  • =
Put the real bottom byte of the real packet number in the encrypted portion=
..
  • Encrypt with=
 the new cleartext packet number and send.
  • Once the preallocated buffer is empty, just se=
t the length back to 128 and continue on.


=C2=A0


The sender decrypts using the cleartext packet numbe=
r. Then replaces the bottom byte of the packet number with the offset from =
the encrypted payload to get the true packet number.


=C2=A0


- Nick


=C2=A0






From: QUIC <quic-bounces@ietf.org> On Behalf Of 
Mikkel Fahn=C3=B8e J=C3=B8rgensen

Sent: Monday, April 9, 2018 2:20 PM

To: Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org>; IETF QUIC WG =
<quic@ietf.org>

Subject: Re: Simple transform for improving PN ossification preventi=
on






=C2=A0




I incidentally implemented Fisher-Yates a few day=
s ago=E2=80=A6






=C2=A0






But if you permit a window, you can also encrypt =
packet numbers using an internal precomputed AES driven PRNG stream - this =
is about 16x faster than direct encryption because
 one block covers 4 packets, and encryption can be done in a parallel pipel=
ine with current AES-NI hardware. You need to map the window in a hash tabl=
e, and it must be small or cache effects makes it too expensive.






=C2=A0






However, big packet loss would make this scheme e=
ither ineffective, or complicated with fallback search.






=C2=A0






I assume your proposed shuffle is fully determini=
stic and precomputed. Aside from the problems with a window size vs loss, t=
his looks like a very good way to correlate packets
 because they now exhibit a distinct pattern for each connection. So I don=
=E2=80=99t see this as being worthwhile, if I understand the scheme correct=
ly.






=C2=A0






The shuffle can also be seen as a clever way to c=
reate a perfect hash table for the above mentioned PRNG scheme, but I don&#=
39;t think it would be effective for large enough
 windows.






=C2=A0






Furthermore, all of these schemes require extra m=
emory per connection and this can be expensive if there are 10K+ idle conne=
ctions sitting.






=C2=A0








/*






=C2=A0* Given an uninitialized `index` of `n` uin=
t64_t slots:






=C2=A0* Place a unique value in the range 0 .. n =
- 1 inclusive in each slot






=C2=A0* unbiased randomly (within the prng limits=
).






=C2=A0*






=C2=A0* Based on Fisher-Yates shuffle - inside ou=
t variant..






=C2=A0*/






static inline void rand64_init_shuffle_below(uint=
64_t *state, uint64_t *index, uint64_t n)






{






=C2=A0 =C2=A0 uint64_t i, x;






=C2=A0






=C2=A0 =C2=A0 for (i =3D 0; i < n; ++i) {






=C2=A0 =C2=A0 =C2=A0 =C2=A0 x =3D rand64_below(st=
ate, i + 1); /* unsigned random value (0 .. i) */






=C2=A0 =C2=A0 =C2=A0 =C2=A0 index[i] =3D index[x]=
; /* Uninitialized if i =3D=3D x, which is ok. */






=C2=A0 =C2=A0 =C2=A0 =C2=A0 index[x] =3D i;






=C2=A0 =C2=A0 }






}






=C2=A0








=C2=A0






Mikkel






=C2=A0




=C2=A0


On 9 April 2018 at 22.48.48, Praveen Balasubraman=
ian (pravb=3D40mi=
crosoft.com@dmarc.ietf.org) wrote:










The current approach in the draft for preventing PN ossificatio=
n is to use a random starting PN. Kazuho pointed
 out a problem with this approach where middleboxes could interpret the PN =
as a sequence number. And in an attempt to be =E2=80=9Chelpful=E2=80=9D, th=
ey could reorder the packets exacerbating the HoL blocking problem and may =
cause issues for unreliable semantics.



=C2=A0


If the PN
in the clear (the nonce value) didn=E2=80=99t always monotonically i=
ncrease then it will preclude such bad behavior by the middleboxes. Hence w=
e need to find a simple transform that is not monotonically increasing and =
also not repeating.



=C2=A0


Requirements for any PN transform in the single path case:


    

  1. 
The actual PN must always increment by 1 and will be used for generating=
 ACKs in ACK frames.

  2. 
The transformed PN in the clear is a nonce and must not repeat over the =
connection lifetime.
  3. 
Middleboxes must not be able to determine the actual PN. Only the QUIC r=
eceiver should be able to do so.


=C2=A0


PNE is one possible transform that meets all these requirements=
 but it is expensive CPU cost wise and has implications
 for hardware implementations. 


=C2=A0


Following is a proposal for an alternative simple transform wit=
h low CPU overhead which satisfies these three requirements.
 The goal is to produce a non-repeating shuffle of the original set of numb=
ers. Since the PN space is very big and efficient shuffle algorithms have O=
(n) space requirement, we need to define a =E2=80=9Creorder degree=E2=80=9D=
 or a =E2=80=9Cbatch size=E2=80=9D within which we will shuffle
 the packet numbers.


=C2=A0


As an example consider that the starting random PN is 100. Per =
the current draft the actual PN increments as follows:


=C2=A0=C2=A0=C2=A0 100, 101, 102, 103, 104, =C2=A0=C2=A0=C2=A01=
05, 106, 107, 108, 109, =E2=80=A6 and so forth


=C2=A0


Let=E2=80=99s assume a =E2=80=9Cbatch size=E2=80=9D of 5. Then =
using one possible outcome of the shuffles we can generate the following
 as the cleartext nonces:


|=C2=A0 102, 104, 103, 101, 100, |=C2=A0 107, 105, 109, 108, 10=
6 | =C2=A0=C2=A0,=E2=80=A6 and so forth


The bars | indicate batch boundaries.


=C2=A0


Of course since we need the QUIC receiver to get the actual PN =
from the cleartext value, we need to communicate
 the offsets in the encrypted portion of the packet, which for this example=
 would be:


|=C2=A0 +2, =C2=A0=C2=A0=C2=A0+3, =C2=A0=C2=A0+1, =C2=A0=C2=A0-=
2, =C2=A0=C2=A0-4,=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 -2, =C2=A0=C2=A0+1=
, =C2=A0=C2=A0-2, =C2=A0=C2=A0=C2=A00, =C2=A0=C2=A0=C2=A0=C2=A0+3 =C2=A0=C2=
=A0=C2=A0|, =C2=A0=E2=80=A6.


Middleboxes will not be able to see the offset values in the cl=
ear. QUIC receiver will need to do a simple add
 of a signed number to get the original PN. This is very cheap operation CP=
U cost wise.



=C2=A0


A QUIC sender implementation can pick any size for the reorder =
degree, the trade-off is the space complexity and
 packet space needed to communicate the offsets. A reorder degree within 12=
8 numbers will need at most an extra byte in the encrypted header to commun=
icate the signed offset values. The 128 batch size i.e. a 1 byte offset siz=
e should be more than enough entropy
 to discourage a middle box from =E2=80=9Cfixing reordering=E2=80=9D and in=
 practice we may need less.


=C2=A0


One possible algorithm for the shuffle is the Fisher=E2=80=93Ya=
tes (Knuth) shuffle as documented here:

https://en.wikipedia.org/wiki/Fisher=E2=80=93Yates_shuffle . Please see=
 the =E2=80=9CModern method=E2=80=9D section which is in-place. The random =
number generator doesn=E2=80=99t have to be a secure variant.


=C2=A0


One advantage of such a scheme is that packet loss can still be=
 inferred by looking at each batch sized set of
 the nonce (packet numbers). For example if the batch size is 128, then mis=
sing numbers in this batch size (or a multiple) will show the extent of pac=
ket loss. The other advantage is that a QUIC diagnostic connection can triv=
ially detect a bad middlebox that
 tries to reorder the nonce in sequence as it will be easily distinguishabl=
e from a random network reorder.



=C2=A0


=C2=A0
















--001a113e06a26973aa0569717cb8--


From nobody Mon Apr  9 17:31:38 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4C912D87B for ; Mon,  9 Apr 2018 17:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Zgat__58IJcn for ; Mon,  9 Apr 2018 17:31:35 -0700 (PDT)
Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C389120227 for ; Mon,  9 Apr 2018 17:31:35 -0700 (PDT)
Received: by mail-ot0-x22a.google.com with SMTP id y46-v6so10799072otd.4 for ; Mon, 09 Apr 2018 17:31:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7X2KvuwJtCrTfYzhEkzLxsUpFHn24Ec2SUuiYgZXcW8=; b=O44OVneZU0yxDe6idEcR7pJcCt3QfH/mnMmanaYd1dJ/dXG4pxHNn5e5XpTsCizzKc 6aAa2Aaw+KGaDUZXilo+IFQQnCzPLa8i8917uTSqMtLTvBVnROwJjsVRqm2R9+LJOeeT DbZm3Zcj+2+H80ef1wmFZsl7rj5WYxIsoN9IiBNrtKc7rGM9mAkoblTtgbHJ1o98kDnV raqvgjLcdqXNn2EAuXkV2vB4ini2xPAtK8vfuYEfwpjzbyw1E31yaM37ayc/6T9DwLZG PebFIMyJcO97eiefIHq2405xSUrpg/jIWjMpJjLMQ5Wej4InGQfdE1qDUbJSTc7v6L2r ngdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=7X2KvuwJtCrTfYzhEkzLxsUpFHn24Ec2SUuiYgZXcW8=; b=it87UzWoojR1sIW+6u/uAsDSlqXLMU1iWtvsU6+1GSt1KlaYt8s6dNY8hrSYmklaWJ h6XHRe0c1YAW7DzEEAiVNzeajVBGuvAQg9o2aCGZweOUeCBsIe4w64ZfUQIULuiqguBM 3zRwJIf77sJZ3Ou56C9pdKcsq62W1C0tojlvz7XmJlAcvLVPHr7V6zgnTBXSwBxQWAvY z6NpbqNIHfaS8W4+B7SLaguN1kJ1Gk7sVpICwTPjaDErWqpiwn4yxZVpE34B4KWnxnrv CShG02Xj6gbHKdx3N4F+uIdBf/ukwqPtCS78pDZkQ7Upe7K2vuq+/XULHFKr6bhvCft2 TTHw==
X-Gm-Message-State: ALQs6tC9N2YMaiDJohcq2N90LZKCmVWc5hY4zUFplQB/cs1ZASe2b7Sx KgzmN7hJDDPQGzSY4qkr4fivGhcF0cDl44uP6JX6eFqm
X-Google-Smtp-Source: AIpwx4+r3qjdIsL58C2JjnXX7Hx6ds+zRog/KjSsMlGP4mLPWeh+1F/wN785q0lOCOxHsxJXBiv189rgKR+ixVIrwAs=
X-Received: by 2002:a9d:2a09:: with SMTP id t9-v6mr15223197ota.392.1523320294622;  Mon, 09 Apr 2018 17:31:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 9 Apr 2018 17:31:33 -0700 (PDT)
In-Reply-To: 
References: 
From: Martin Thomson 
Date: Tue, 10 Apr 2018 10:31:33 +1000
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Praveen Balasubramanian 
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, 10 Apr 2018 00:31:37 -0000

Hi Praveen,

Thanks for sharing your thoughts on this.

Let's look at the requirements a little closer first, because I think
that this isn't quite right.

On Tue, Apr 10, 2018 at 6:48 AM, Praveen Balasubramanian
 wrote:
> Requirements for any PN transform in the single path case:
>
> The actual PN must always increment by 1 and will be used for generating
> ACKs in ACK frames.

This is good.

> The transformed PN in the clear is a nonce and must not repeat over the
> connection lifetime.

I don't think that this is correct, or at least it could be turned
into a requirement and a separate insight about that observation.
Namely that the PN is used as a nonce, but we don't need to use nonces
in the order they are presented.

What is incorrect here is that we use the actual PN as a nonce.  This
confusion is understandable because - at the moment - we shift the
actual PN by a random offset.  But that's a mistake and we should
rectify that anyway as #1079 does.  Even if we don't do #1079, any
design we have can and should remove that initial randomization and
use a random offset transformation instead; the same for packet number
gaps: we can use a different random offset in the transformation.

But I see where you are going with this.  You want to use a packet
number that is near the real packet number, ensure that each value is
only used once, and also include the real packet number under
encryption.  Given that, if it weren't for the way that loss detection
reacts to reordering, you could almost just send packets with out of
order packet numbers.

The effect of this is that the degree to which you do this
"reordering" will affect the performance of the packet number
reconstruction in the face of actual reordering.  That puts a hard
upper limit on the amount of reordering you do.   It will also cost
some number of bytes to reconstruct the real packet number.

> Middleboxes must not be able to determine the actual PN. Only the QUIC
> receiver should be able to do so.

This sounds like a good goal, but I think that your design misses it.
The point with the #1079 design is that it is semantically secure: you
need the keys to get the real packet number.

In your design, a middlebox can reconstruct packet numbers with high
fidelity based on arrival times and knowledge of the non-secret
parameter (the 5 you used in your example).  Only reordering within
that set (e.g., between packet 101 and 102 in your example) will be
undetectable, but reordering across a boundary (e.g., between packet
104 and 105) will be easily detectable.  Finally, if the PRNG used to
seed Fisher-Yates isn't a CSPRNG, then its state can be reconstructed
eventually and then the reordering problem goes away.

So all that this effectively does is confound the process by which
things like the spin bit are managed.  It doesn't provide any real
barrier.

But maybe that is the real goal, to make it harder to do this, on the
assumption that anyone willing to do that won't also ossify the
protocol in the process.  I don't see that happening, but that's
clearly a point on which different people reach different conclusions.

FWIW, Fisher-Yates is pretty inefficient as a PRP.  I'm surprised that
you are suggesting it.  How are you seeding the PRNG?  Is it a CSPRNG?
 Have you tested the overall performance?

A different cheap PRP would be XOR-shift (PN>>a|PN>>b|PN>>c), or (PN +
a) * b.  They are each trivially reversed though.  While that violates
your stipulated requirement, it doesn't violate the implied one.  If
the requirement is that it be *difficult* to reconstruct the actual
packet number based on the sequence of transformed packet numbers,
then maybe those are better.  Based on those you wouldn't need to also
include the real packet number under encryption, which saves that many
octets.


From nobody Mon Apr  9 17:31:46 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8836120227 for ; Mon,  9 Apr 2018 17:31:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523320297; bh=f7ZlnBIn5qVInISmRAO4dm7DVy7jtF08F4H7nKgJclU=; h=In-Reply-To:References:From:Date:Subject:Cc:To; b=ITsdVN/dTTQ2KLVV79w1YaMqraVUVKydfmv/svFCtqPuzTTiP2uHegtiikxASg8bK 29Qz5TTC7DibgYsSB+WsuneU4RcyW96BKc56CkyNaiKxLw9MYc4yqgFHc8neDI9olL mfU3ooQj9+i0NVLmtHk49OHfMoc4ptybEJE5AWW8=
X-Mailbox-Line: From martin.thomson@gmail.com  Mon Apr  9 17:31:37 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F6A12D875 for ; Mon,  9 Apr 2018 17:31:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523320297; bh=f7ZlnBIn5qVInISmRAO4dm7DVy7jtF08F4H7nKgJclU=; h=In-Reply-To:References:From:Date:Subject:Cc:To; b=ITsdVN/dTTQ2KLVV79w1YaMqraVUVKydfmv/svFCtqPuzTTiP2uHegtiikxASg8bK 29Qz5TTC7DibgYsSB+WsuneU4RcyW96BKc56CkyNaiKxLw9MYc4yqgFHc8neDI9olL mfU3ooQj9+i0NVLmtHk49OHfMoc4ptybEJE5AWW8=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90642120227 for ; Mon,  9 Apr 2018 17:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 vH1faJ9CUAZS for ; Mon,  9 Apr 2018 17:31:36 -0700 (PDT)
Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886EE12D875 for ; Mon,  9 Apr 2018 17:31:35 -0700 (PDT)
Received: by mail-ot0-x22f.google.com with SMTP id o9-v6so10804169otj.5 for ; Mon, 09 Apr 2018 17:31:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7X2KvuwJtCrTfYzhEkzLxsUpFHn24Ec2SUuiYgZXcW8=; b=O44OVneZU0yxDe6idEcR7pJcCt3QfH/mnMmanaYd1dJ/dXG4pxHNn5e5XpTsCizzKc 6aAa2Aaw+KGaDUZXilo+IFQQnCzPLa8i8917uTSqMtLTvBVnROwJjsVRqm2R9+LJOeeT DbZm3Zcj+2+H80ef1wmFZsl7rj5WYxIsoN9IiBNrtKc7rGM9mAkoblTtgbHJ1o98kDnV raqvgjLcdqXNn2EAuXkV2vB4ini2xPAtK8vfuYEfwpjzbyw1E31yaM37ayc/6T9DwLZG PebFIMyJcO97eiefIHq2405xSUrpg/jIWjMpJjLMQ5Wej4InGQfdE1qDUbJSTc7v6L2r ngdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=7X2KvuwJtCrTfYzhEkzLxsUpFHn24Ec2SUuiYgZXcW8=; b=N1erSljAHN0uI9DNfyb27QfGehYNVZzsNG626HmCCrEvn7DbeQ7EQbmOXvjLiiYa94 pnuTe2I+Idq/L3A+EwEM7eE6Ed+203Hfr3vwAME7YNAtqYFhuLV3kd4zCBQZcAe+f/A/ zb5dHYXQO2UkDIg233Vy7ZnlnsxK5Llekww/rI4MZOnf84+cb9d1A2lndI3pOJuuFhB2 ydtSC38jGaCm+Ij6VWJTuRGQTEAZrteSKfbIcasCkbrZQXURWaSD3eusvKOgNPgXlIYd sx8kLWjzWaMxV/1W5LjP+oF4QkJKewrvXpYS+9wGjW+ljlu2a3rUOqtRhYPlcHgWIw78 8ncQ==
X-Gm-Message-State: ALQs6tAJ8BYKGtYmlASH+wZT84jeF+QX/+gSAAjC/G0Y+zxaSY8XF1+V 4L4HDvCiVsRE/pseQT1grtbTbtnJibRuHeadjjEg6iEs
X-Google-Smtp-Source: AIpwx4+r3qjdIsL58C2JjnXX7Hx6ds+zRog/KjSsMlGP4mLPWeh+1F/wN785q0lOCOxHsxJXBiv189rgKR+ixVIrwAs=
X-Received: by 2002:a9d:2a09:: with SMTP id t9-v6mr15223197ota.392.1523320294622;  Mon, 09 Apr 2018 17:31:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 9 Apr 2018 17:31:33 -0700 (PDT)
In-Reply-To: 
References: 
From: Martin Thomson 
Date: Tue, 10 Apr 2018 10:31:33 +1000
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
Cc: IETF QUIC WG 
Content-Type: text/plain; charset="UTF-8"
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 00:31:38 -0000

Hi Praveen,

Thanks for sharing your thoughts on this.

Let's look at the requirements a little closer first, because I think
that this isn't quite right.

On Tue, Apr 10, 2018 at 6:48 AM, Praveen Balasubramanian
 wrote:
> Requirements for any PN transform in the single path case:
>
> The actual PN must always increment by 1 and will be used for generating
> ACKs in ACK frames.

This is good.

> The transformed PN in the clear is a nonce and must not repeat over the
> connection lifetime.

I don't think that this is correct, or at least it could be turned
into a requirement and a separate insight about that observation.
Namely that the PN is used as a nonce, but we don't need to use nonces
in the order they are presented.

What is incorrect here is that we use the actual PN as a nonce.  This
confusion is understandable because - at the moment - we shift the
actual PN by a random offset.  But that's a mistake and we should
rectify that anyway as #1079 does.  Even if we don't do #1079, any
design we have can and should remove that initial randomization and
use a random offset transformation instead; the same for packet number
gaps: we can use a different random offset in the transformation.

But I see where you are going with this.  You want to use a packet
number that is near the real packet number, ensure that each value is
only used once, and also include the real packet number under
encryption.  Given that, if it weren't for the way that loss detection
reacts to reordering, you could almost just send packets with out of
order packet numbers.

The effect of this is that the degree to which you do this
"reordering" will affect the performance of the packet number
reconstruction in the face of actual reordering.  That puts a hard
upper limit on the amount of reordering you do.   It will also cost
some number of bytes to reconstruct the real packet number.

> Middleboxes must not be able to determine the actual PN. Only the QUIC
> receiver should be able to do so.

This sounds like a good goal, but I think that your design misses it.
The point with the #1079 design is that it is semantically secure: you
need the keys to get the real packet number.

In your design, a middlebox can reconstruct packet numbers with high
fidelity based on arrival times and knowledge of the non-secret
parameter (the 5 you used in your example).  Only reordering within
that set (e.g., between packet 101 and 102 in your example) will be
undetectable, but reordering across a boundary (e.g., between packet
104 and 105) will be easily detectable.  Finally, if the PRNG used to
seed Fisher-Yates isn't a CSPRNG, then its state can be reconstructed
eventually and then the reordering problem goes away.

So all that this effectively does is confound the process by which
things like the spin bit are managed.  It doesn't provide any real
barrier.

But maybe that is the real goal, to make it harder to do this, on the
assumption that anyone willing to do that won't also ossify the
protocol in the process.  I don't see that happening, but that's
clearly a point on which different people reach different conclusions.

FWIW, Fisher-Yates is pretty inefficient as a PRP.  I'm surprised that
you are suggesting it.  How are you seeding the PRNG?  Is it a CSPRNG?
 Have you tested the overall performance?

A different cheap PRP would be XOR-shift (PN>>a|PN>>b|PN>>c), or (PN +
a) * b.  They are each trivially reversed though.  While that violates
your stipulated requirement, it doesn't violate the implied one.  If
the requirement is that it be *difficult* to reconstruct the actual
packet number based on the sequence of transformed packet numbers,
then maybe those are better.  Based on those you wouldn't need to also
include the real packet number under encryption, which saves that many
octets.


From nobody Mon Apr  9 17:49:51 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55675120227 for ; Mon,  9 Apr 2018 17:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 5BDVvNRJRMFR for ; Mon,  9 Apr 2018 17:49:47 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0106.outbound.protection.outlook.com [104.47.38.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24B0124239 for ; Mon,  9 Apr 2018 17:49:46 -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=vibwggmX/1OxIV6dQrWD03qxP0DBr+lXhvnwvjD0NMY=; b=F7rV+r0tCx1lwCD1g7rdn3WiE4ju+XaVoucv9gfWIw7qpQSURBBQ5cn9DaSYOiaaALoolhuFp7SaV9XFrPdXrujux4np5YLZUAgwoFFckf/wCGJYAAaxO/JiEwqsm8uk8R2Zx+byRFYSOTnGtxfVhbaAjiS0Uz7VEDrr8b/PaO8=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0854.namprd21.prod.outlook.com (10.173.192.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Tue, 10 Apr 2018 00:49:44 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Tue, 10 Apr 2018 00:49:44 +0000
From: Praveen Balasubramanian 
To: Martin Thomson , Praveen Balasubramanian 
CC: IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAH3w2AAAAjVmA=
Date: Tue, 10 Apr 2018 00:49:44 +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:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0854; 7:gW0ROpfO1wPCcuxkI4kGhtQysppvOU49/SYfYbSfOK0QLStpyn4SPvh8M2kir7vcFj0XT2wmzBlxUeMnl3v0RToKZO+JBDDzlSeVid1LjGVG+55BRMOKdTRqEhq8payu3pl9Kqw9Yix/cT5qLFkeKyGLDS3Krm30V0ipYb30RqFvGj8UBuHHqTTqQqV5nHTB/80Q8eCexwdszEVPsANSnNav9qHc3PM7LavmI+AO0yHytHdszfmhR88pfqCSDcSX; 20:Km9jhPJb1Qv5PVbWGgpZ/xtVPErXpdA9A57WSNZm3eimaZhBXtoo0tI0ie/qOl6HXtyhFe1nbL4VCOSyZbZ/bhtCFbCTEf//yfhNP/Lu5qJlS9fuL7h6HRWZgfJa2+Y1jblgIko2qEZ3cGUnZIvNCfrBpNfE0+ipfu50Gg7Gh1o=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0854; 
x-ms-traffictypediagnostic: CY4PR21MB0854:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(155532106045638);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR21MB0854; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0854; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(396003)(39380400002)(39860400002)(189003)(199004)(51444003)(13464003)(8990500004)(86612001)(3660700001)(316002)(7736002)(110136005)(305945005)(3280700002)(22452003)(33656002)(2906002)(229853002)(5250100002)(14454004)(6116002)(2900100001)(8936002)(10090500001)(8676002)(68736007)(81166006)(81156014)(53936002)(478600001)(6246003)(6436002)(106356001)(55016002)(9686003)(10290500003)(97736004)(86362001)(7696005)(76176011)(4326008)(99286004)(105586002)(46003)(25786009)(59450400001)(5660300001)(102836004)(53546011)(39060400002)(6506007)(11346002)(74316002)(476003)(186003)(486006)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0854; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 0J0Uy6JhGvCQ0wqHnzdjdUKo8aX7VOWZS66dlZMBu5FmK0ClpKRKuStG1pz/zFwu/A6psJnSl1ISxHu67fm4N286HvhIsOyQfquzrlwk/fM2iU3qXc3/PxEHa/0jTB17PMbUy6ZE0nnlDk7eCMV/NeFOk2TCdV4ns4Ni+8GtRKIi6URsph7feaL7jAQV4U9RsLUJJQ5WUodnSjlVesEGTgbIiXck+467Vw3aQL6Hp1/gsXZT3QtpQuTvIHpGIzHaeEMmr0a245eeV+00sSWkLBwc2y9T3FMXeMqoKhYU7pqafCc50hXFJ+NjXNf2U8cKa2hsejNuDu2fs+4BPYV/VH7nw/T0IpZQ12jnyt38lFJtcafeYjwtWXW214eoB4Ky123YxZWrsTabMenXZhPUylOTh1gL0WjTSwzuVC7r9A0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: a5d948fe-234e-4ee4-5e3e-08d59e7cf3c6
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a5d948fe-234e-4ee4-5e3e-08d59e7cf3c6
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 00:49:44.4384 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0854
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 00:49:50 -0000

Pj4gWW91IHdhbnQgdG8gdXNlIGEgcGFja2V0IG51bWJlciB0aGF0IGlzIG5lYXIgdGhlIHJlYWwg
cGFja2V0IG51bWJlciwgZW5zdXJlIHRoYXQgZWFjaCB2YWx1ZSBpcyBvbmx5IHVzZWQgb25jZSwg
YW5kIGFsc28gaW5jbHVkZSB0aGUgcmVhbCBwYWNrZXQgbnVtYmVyIHVuZGVyIGVuY3J5cHRpb24N
Ck5vdCB0aGUgZW50aXJlIHBhY2tldCBudW1iZXIsIGp1c3QgZW5vdWdoIGluZm9ybWF0aW9uIHRv
IHJlY29uc3RydWN0IHRoZSByZWFsIHBhY2tldCBudW1iZXIuIEluIHRoaXMgc2NoZW1lIGl0IGlz
IGp1c3QgYW4gZXh0cmEgYnl0ZSBpbiB0aGUgZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIGhlYWRl
ci4gSUYgdGhlIGJhdGNoIHNpemUgaXMgc21hbGxlciB3ZSBjYW4gZG8gZmV3ZXIgYml0cyBwZXIg
cGFja2V0LiANCg0KPj4gdG8gd2hpY2ggeW91IGRvIHRoaXMgInJlb3JkZXJpbmciIHdpbGwgYWZm
ZWN0IHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgcGFja2V0IG51bWJlciByZWNvbnN0cnVjdGlvbiBp
biB0aGUgZmFjZSBvZiBhY3R1YWwgcmVvcmRlcmluZw0KRWFjaCBwYWNrZXQgaXMgc2VsZiBjb250
YWluZWQgYW5kIHRoZSByZWFsIFBOIGNhbiBiZSByZWNvbnN0cnVjdGVkIGp1c3QgdXNpbmcgdGhl
IG9mZnNldCBzdG9yZWQgaW4gdGhlIGVuY3J5cHRlZCBoZWFkZXIuIEkgZG9u4oCZdCBzZWUgYW55
IGlzc3VlcyB3aXRoIGFkZGl0aW9uYWwgbmV0d29yayBpbmR1Y2VkIHJlb3JkZXJpbmcuIFRoZXJl
IGlzIG5vIGRlcGVuZGVuY3kgYmV0d2VlbiBwYWNrZXRzIHdpdGggdGhpcyBzY2hlbWUuDQoNCj4+
IG1pZGRsZWJveCBjYW4gcmVjb25zdHJ1Y3QgcGFja2V0IG51bWJlcnMNClRoZSBudW1iZXIgNSB3
YXMgZm9yIGlsbHVzdHJhdGl2ZSBwdXJwb3Nlcy4gSW4gcHJhY3RpY2UgdGhlIGFjdHVhbCB2YWx1
ZSB3b3VsZCBsaWtlbHkgbmVlZCB0byBiZSBiZXR3ZWVuIDMyIHRvIDEyOC4gVGhlIG1pZGRsZWJv
eCBoYXMgbm8gaW5mb3JtYXRpb24gYWJvdXQgdGhlIG9mZnNldHMgYW5kIEkgZG9u4oCZdCBzZWUg
d2hhdCBwdXJwb3NlIGlzIHNlcnZlZCBieSBpdCB0cnlpbmcgdG8gZ3Vlc3MgYW55IG9yZGVyLiBC
eSByZW9yZGVyaW5nIGFsbCBudW1iZXJzIHdlIGxlYXZlIGxpdHRsZSByb29tIGZvciBhIG1pZGRs
ZWJveCB0byBtYWtlIGEgbWlzdGFrZSBhcm91bmQgdHJ5aW5nIHRvIHJlb3JkZXIgcGFja2V0cyB1
c2luZyB0aGUgbm9uY2UgZmllbGQuIFJlbWVtYmVyIHRoYXQgdGhpcyBzY2hlbWUgaXMgZm9yIHNp
bmdsZSBwYXRoIGFuZCBpcyBub3QgdHJ5aW5nIHRvIHNvbHZlIGxpbmthYmlsaXR5LiBJdCBpcyBq
dXN0IHRyeWluZyB0byBwcmV2ZW50IG9zc2lmaWNhdGlvbiBieSBkb2luZyBiZXR0ZXIgZ3JlYXNp
bmcuIA0KDQo+PiBjb25mb3VuZCB0aGUgcHJvY2VzcyBieSB3aGljaCB0aGluZ3MgbGlrZSB0aGUg
c3BpbiBiaXQgYXJlIG1hbmFnZWQNCkkgY29uY2VkZSB0aGF0IEkgaGF2ZW7igJl0IHRob3VnaHQg
b2YgdGhlIGltcGxpY2F0aW9ucyB0byBzcGluIGJpdCwgYnV0IEkgc3VzcGVjdCB0aGF0IGFzIGxv
bmcgYXMgYmF0Y2hlcyBhcmUgd2l0aGluIHRoZSBSVFQgdGhlcmUgaXMgbm8gYWN0dWFsIGlzc3Vl
IHNpbmNlIFJUVCBkZXRlY3Rpb24gaXMgbm90IGRlcGVuZGVudCBvbiB0aGUgUE4uIFdoeSB3b3Vs
ZCBpdCBtYXR0ZXIgaWYgdGhlIFBOIGlzIHRyYW5zZm9ybWVkIHVzaW5nIHRoaXMgc2NoZW1lIG9y
IHdpdGggZW5jcnlwdGlvbj8gUmVtZW1iZXIgd2UgYXJlIG5vdCBhY3R1YWxseSByZW9yZGVyaW5n
IHBhY2tldHMsIGp1c3QgcmVvcmRlcmluZyB0aGUgY2xlYXIgdGV4dCBub25jZSB2YWx1ZS4NCg0K
Pj4gUmUuIEZpc2hlci1ZYXRlcyBwZXJmDQpJIGFtIG5vdCBzdWdnZXN0aW5nIHRoaXMgYXMgdGhl
IG9ubHkgcG9zc2libGUgYWxnb3JpdGhtIGZvciBnZW5lcmF0aW5nIG5vbi1yZXBlYXRpbmcgcmFu
ZG9tIG51bWJlcnMuIEkgY2VydGFpbmx5IGRvbuKAmXQgdGhpbmsgd2UgbmVlZCB0byBtYWtlIHRo
ZSB0cmFuc2Zvcm0gc2VjdXJlLiBJIGRvbuKAmXQgdGhpbmsgaXRzIGFuIGlzc3VlIGlmIHRoZSBt
aWRkbGVib3ggZ29lcyBvdXQgb2YgaXRzIHdheSB0byBkbyBvZmZsaW5lIGFuYWx5c2lzIHRvIGZp
Z3VyZSBvdXQgdGhlIHJpZ2h0IFBOLiBXZSBhcmUgbm90IHRyeWluZyB0byBzb2x2ZSB1bmxpbmth
YmlsaXR5IHdpdGggdGhpcyBzY2hlbWUuIEl0IGlzIGp1c3QgYmV0dGVyIG9zc2lmaWNhdGlvbiBw
cmV2ZW50aW9uIGZvciBjb25uZWN0aW9ucyB0aGF0IGFyZSBvbiBhIHNpbmdsZSBwYXRoLg0KDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NClNlbnQ6IE1vbmRheSwg
QXByaWwgOSwgMjAxOCA1OjMyIFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZi
PTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBJRVRGIFFVSUMgV0cgPHF1aWNA
aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBO
IG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uDQoNCkhpIFByYXZlZW4sDQoNClRoYW5rcyBmb3Igc2hh
cmluZyB5b3VyIHRob3VnaHRzIG9uIHRoaXMuDQoNCkxldCdzIGxvb2sgYXQgdGhlIHJlcXVpcmVt
ZW50cyBhIGxpdHRsZSBjbG9zZXIgZmlyc3QsIGJlY2F1c2UgSSB0aGluayB0aGF0IHRoaXMgaXNu
J3QgcXVpdGUgcmlnaHQuDQoNCk9uIFR1ZSwgQXByIDEwLCAyMDE4IGF0IDY6NDggQU0sIFByYXZl
ZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+
IHdyb3RlOg0KPiBSZXF1aXJlbWVudHMgZm9yIGFueSBQTiB0cmFuc2Zvcm0gaW4gdGhlIHNpbmds
ZSBwYXRoIGNhc2U6DQo+DQo+IFRoZSBhY3R1YWwgUE4gbXVzdCBhbHdheXMgaW5jcmVtZW50IGJ5
IDEgYW5kIHdpbGwgYmUgdXNlZCBmb3IgDQo+IGdlbmVyYXRpbmcgQUNLcyBpbiBBQ0sgZnJhbWVz
Lg0KDQpUaGlzIGlzIGdvb2QuDQoNCj4gVGhlIHRyYW5zZm9ybWVkIFBOIGluIHRoZSBjbGVhciBp
cyBhIG5vbmNlIGFuZCBtdXN0IG5vdCByZXBlYXQgb3ZlciANCj4gdGhlIGNvbm5lY3Rpb24gbGlm
ZXRpbWUuDQoNCkkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIGlzIGNvcnJlY3QsIG9yIGF0IGxlYXN0
IGl0IGNvdWxkIGJlIHR1cm5lZCBpbnRvIGEgcmVxdWlyZW1lbnQgYW5kIGEgc2VwYXJhdGUgaW5z
aWdodCBhYm91dCB0aGF0IG9ic2VydmF0aW9uLg0KTmFtZWx5IHRoYXQgdGhlIFBOIGlzIHVzZWQg
YXMgYSBub25jZSwgYnV0IHdlIGRvbid0IG5lZWQgdG8gdXNlIG5vbmNlcyBpbiB0aGUgb3JkZXIg
dGhleSBhcmUgcHJlc2VudGVkLg0KDQpXaGF0IGlzIGluY29ycmVjdCBoZXJlIGlzIHRoYXQgd2Ug
dXNlIHRoZSBhY3R1YWwgUE4gYXMgYSBub25jZS4gIFRoaXMgY29uZnVzaW9uIGlzIHVuZGVyc3Rh
bmRhYmxlIGJlY2F1c2UgLSBhdCB0aGUgbW9tZW50IC0gd2Ugc2hpZnQgdGhlIGFjdHVhbCBQTiBi
eSBhIHJhbmRvbSBvZmZzZXQuICBCdXQgdGhhdCdzIGEgbWlzdGFrZSBhbmQgd2Ugc2hvdWxkIHJl
Y3RpZnkgdGhhdCBhbnl3YXkgYXMgIzEwNzkgZG9lcy4gIEV2ZW4gaWYgd2UgZG9uJ3QgZG8gIzEw
NzksIGFueSBkZXNpZ24gd2UgaGF2ZSBjYW4gYW5kIHNob3VsZCByZW1vdmUgdGhhdCBpbml0aWFs
IHJhbmRvbWl6YXRpb24gYW5kIHVzZSBhIHJhbmRvbSBvZmZzZXQgdHJhbnNmb3JtYXRpb24gaW5z
dGVhZDsgdGhlIHNhbWUgZm9yIHBhY2tldCBudW1iZXINCmdhcHM6IHdlIGNhbiB1c2UgYSBkaWZm
ZXJlbnQgcmFuZG9tIG9mZnNldCBpbiB0aGUgdHJhbnNmb3JtYXRpb24uDQoNCkJ1dCBJIHNlZSB3
aGVyZSB5b3UgYXJlIGdvaW5nIHdpdGggdGhpcy4gIFlvdSB3YW50IHRvIHVzZSBhIHBhY2tldCBu
dW1iZXIgdGhhdCBpcyBuZWFyIHRoZSByZWFsIHBhY2tldCBudW1iZXIsIGVuc3VyZSB0aGF0IGVh
Y2ggdmFsdWUgaXMgb25seSB1c2VkIG9uY2UsIGFuZCBhbHNvIGluY2x1ZGUgdGhlIHJlYWwgcGFj
a2V0IG51bWJlciB1bmRlciBlbmNyeXB0aW9uLiAgR2l2ZW4gdGhhdCwgaWYgaXQgd2VyZW4ndCBm
b3IgdGhlIHdheSB0aGF0IGxvc3MgZGV0ZWN0aW9uIHJlYWN0cyB0byByZW9yZGVyaW5nLCB5b3Ug
Y291bGQgYWxtb3N0IGp1c3Qgc2VuZCBwYWNrZXRzIHdpdGggb3V0IG9mIG9yZGVyIHBhY2tldCBu
dW1iZXJzLg0KDQpUaGUgZWZmZWN0IG9mIHRoaXMgaXMgdGhhdCB0aGUgZGVncmVlIHRvIHdoaWNo
IHlvdSBkbyB0aGlzICJyZW9yZGVyaW5nIiB3aWxsIGFmZmVjdCB0aGUgcGVyZm9ybWFuY2Ugb2Yg
dGhlIHBhY2tldCBudW1iZXIgcmVjb25zdHJ1Y3Rpb24gaW4gdGhlIGZhY2Ugb2YgYWN0dWFsIHJl
b3JkZXJpbmcuICBUaGF0IHB1dHMgYSBoYXJkDQp1cHBlciBsaW1pdCBvbiB0aGUgYW1vdW50IG9m
IHJlb3JkZXJpbmcgeW91IGRvLiAgIEl0IHdpbGwgYWxzbyBjb3N0DQpzb21lIG51bWJlciBvZiBi
eXRlcyB0byByZWNvbnN0cnVjdCB0aGUgcmVhbCBwYWNrZXQgbnVtYmVyLg0KDQo+IE1pZGRsZWJv
eGVzIG11c3Qgbm90IGJlIGFibGUgdG8gZGV0ZXJtaW5lIHRoZSBhY3R1YWwgUE4uIE9ubHkgdGhl
IFFVSUMgDQo+IHJlY2VpdmVyIHNob3VsZCBiZSBhYmxlIHRvIGRvIHNvLg0KDQpUaGlzIHNvdW5k
cyBsaWtlIGEgZ29vZCBnb2FsLCBidXQgSSB0aGluayB0aGF0IHlvdXIgZGVzaWduIG1pc3NlcyBp
dC4NClRoZSBwb2ludCB3aXRoIHRoZSAjMTA3OSBkZXNpZ24gaXMgdGhhdCBpdCBpcyBzZW1hbnRp
Y2FsbHkgc2VjdXJlOiB5b3UgbmVlZCB0aGUga2V5cyB0byBnZXQgdGhlIHJlYWwgcGFja2V0IG51
bWJlci4NCg0KSW4geW91ciBkZXNpZ24sIGEgbWlkZGxlYm94IGNhbiByZWNvbnN0cnVjdCBwYWNr
ZXQgbnVtYmVycyB3aXRoIGhpZ2ggZmlkZWxpdHkgYmFzZWQgb24gYXJyaXZhbCB0aW1lcyBhbmQg
a25vd2xlZGdlIG9mIHRoZSBub24tc2VjcmV0IHBhcmFtZXRlciAodGhlIDUgeW91IHVzZWQgaW4g
eW91ciBleGFtcGxlKS4gIE9ubHkgcmVvcmRlcmluZyB3aXRoaW4gdGhhdCBzZXQgKGUuZy4sIGJl
dHdlZW4gcGFja2V0IDEwMSBhbmQgMTAyIGluIHlvdXIgZXhhbXBsZSkgd2lsbCBiZSB1bmRldGVj
dGFibGUsIGJ1dCByZW9yZGVyaW5nIGFjcm9zcyBhIGJvdW5kYXJ5IChlLmcuLCBiZXR3ZWVuIHBh
Y2tldA0KMTA0IGFuZCAxMDUpIHdpbGwgYmUgZWFzaWx5IGRldGVjdGFibGUuICBGaW5hbGx5LCBp
ZiB0aGUgUFJORyB1c2VkIHRvIHNlZWQgRmlzaGVyLVlhdGVzIGlzbid0IGEgQ1NQUk5HLCB0aGVu
IGl0cyBzdGF0ZSBjYW4gYmUgcmVjb25zdHJ1Y3RlZCBldmVudHVhbGx5IGFuZCB0aGVuIHRoZSBy
ZW9yZGVyaW5nIHByb2JsZW0gZ29lcyBhd2F5Lg0KDQpTbyBhbGwgdGhhdCB0aGlzIGVmZmVjdGl2
ZWx5IGRvZXMgaXMgY29uZm91bmQgdGhlIHByb2Nlc3MgYnkgd2hpY2ggdGhpbmdzIGxpa2UgdGhl
IHNwaW4gYml0IGFyZSBtYW5hZ2VkLiAgSXQgZG9lc24ndCBwcm92aWRlIGFueSByZWFsIGJhcnJp
ZXIuDQoNCkJ1dCBtYXliZSB0aGF0IGlzIHRoZSByZWFsIGdvYWwsIHRvIG1ha2UgaXQgaGFyZGVy
IHRvIGRvIHRoaXMsIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgYW55b25lIHdpbGxpbmcgdG8gZG8g
dGhhdCB3b24ndCBhbHNvIG9zc2lmeSB0aGUgcHJvdG9jb2wgaW4gdGhlIHByb2Nlc3MuICBJIGRv
bid0IHNlZSB0aGF0IGhhcHBlbmluZywgYnV0IHRoYXQncyBjbGVhcmx5IGEgcG9pbnQgb24gd2hp
Y2ggZGlmZmVyZW50IHBlb3BsZSByZWFjaCBkaWZmZXJlbnQgY29uY2x1c2lvbnMuDQoNCkZXSVcs
IEZpc2hlci1ZYXRlcyBpcyBwcmV0dHkgaW5lZmZpY2llbnQgYXMgYSBQUlAuICBJJ20gc3VycHJp
c2VkIHRoYXQgeW91IGFyZSBzdWdnZXN0aW5nIGl0LiAgSG93IGFyZSB5b3Ugc2VlZGluZyB0aGUg
UFJORz8gIElzIGl0IGEgQ1NQUk5HPw0KIEhhdmUgeW91IHRlc3RlZCB0aGUgb3ZlcmFsbCBwZXJm
b3JtYW5jZT8NCg0KQSBkaWZmZXJlbnQgY2hlYXAgUFJQIHdvdWxkIGJlIFhPUi1zaGlmdCAoUE4+
PmF8UE4+PmJ8UE4+PmMpLCBvciAoUE4gKw0KYSkgKiBiLiAgVGhleSBhcmUgZWFjaCB0cml2aWFs
bHkgcmV2ZXJzZWQgdGhvdWdoLiAgV2hpbGUgdGhhdCB2aW9sYXRlcyB5b3VyIHN0aXB1bGF0ZWQg
cmVxdWlyZW1lbnQsIGl0IGRvZXNuJ3QgdmlvbGF0ZSB0aGUgaW1wbGllZCBvbmUuICBJZiB0aGUg
cmVxdWlyZW1lbnQgaXMgdGhhdCBpdCBiZSAqZGlmZmljdWx0KiB0byByZWNvbnN0cnVjdCB0aGUg
YWN0dWFsIHBhY2tldCBudW1iZXIgYmFzZWQgb24gdGhlIHNlcXVlbmNlIG9mIHRyYW5zZm9ybWVk
IHBhY2tldCBudW1iZXJzLCB0aGVuIG1heWJlIHRob3NlIGFyZSBiZXR0ZXIuICBCYXNlZCBvbiB0
aG9zZSB5b3Ugd291bGRuJ3QgbmVlZCB0byBhbHNvIGluY2x1ZGUgdGhlIHJlYWwgcGFja2V0IG51
bWJlciB1bmRlciBlbmNyeXB0aW9uLCB3aGljaCBzYXZlcyB0aGF0IG1hbnkgb2N0ZXRzLg0KDQo=


From nobody Mon Apr  9 17:49:57 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A31120227 for ; Mon,  9 Apr 2018 17:49:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523321391; bh=vibwggmX/1OxIV6dQrWD03qxP0DBr+lXhvnwvjD0NMY=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=kAtt2y9yBSc113ShkGCKNySpgte36t7m91jUf/UY7WRyZGSHrlKV7aEVGGIzl9beF jYmA4z72TMLF/DMZzHolhSWv6UNA+kGz4ZzWoEyZ8oDaysOM/wNisCo7fMc1J5pTIo +RulwbvvaIQbRxF9j61hbqx6q5gD347lrbVqoPbY=
X-Mailbox-Line: From pravb@microsoft.com  Mon Apr  9 17:49:50 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C23C1126B72 for ; Mon,  9 Apr 2018 17:49:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523321390; bh=vibwggmX/1OxIV6dQrWD03qxP0DBr+lXhvnwvjD0NMY=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=NRaCOLRXAidAycpKZLp/NtPKvZe4Irvkr6w8EjSwVN9X3CuudlKqWTUdwbDxai+ER 9FoTKHA6AkbrNvIne4ZyeF6IInyjCdWvrz3licpcfTt+26eUABe8KefKw6n/uWa0nk mPPfS88prmCDs8C+GPSPUOjdVxypwwZi6zirpCCo=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E82124239 for ; Mon,  9 Apr 2018 17:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 dlXOGB5swTW3 for ; Mon,  9 Apr 2018 17:49:47 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe46::702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B7E126B72 for ; Mon,  9 Apr 2018 17:49:47 -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=vibwggmX/1OxIV6dQrWD03qxP0DBr+lXhvnwvjD0NMY=; b=F7rV+r0tCx1lwCD1g7rdn3WiE4ju+XaVoucv9gfWIw7qpQSURBBQ5cn9DaSYOiaaALoolhuFp7SaV9XFrPdXrujux4np5YLZUAgwoFFckf/wCGJYAAaxO/JiEwqsm8uk8R2Zx+byRFYSOTnGtxfVhbaAjiS0Uz7VEDrr8b/PaO8=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0854.namprd21.prod.outlook.com (10.173.192.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Tue, 10 Apr 2018 00:49:44 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Tue, 10 Apr 2018 00:49:44 +0000
From: Praveen Balasubramanian 
CC: IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAH3w2AAAAjVmA=
Date: Tue, 10 Apr 2018 00:49:44 +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:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0854; 7:gW0ROpfO1wPCcuxkI4kGhtQysppvOU49/SYfYbSfOK0QLStpyn4SPvh8M2kir7vcFj0XT2wmzBlxUeMnl3v0RToKZO+JBDDzlSeVid1LjGVG+55BRMOKdTRqEhq8payu3pl9Kqw9Yix/cT5qLFkeKyGLDS3Krm30V0ipYb30RqFvGj8UBuHHqTTqQqV5nHTB/80Q8eCexwdszEVPsANSnNav9qHc3PM7LavmI+AO0yHytHdszfmhR88pfqCSDcSX; 20:Km9jhPJb1Qv5PVbWGgpZ/xtVPErXpdA9A57WSNZm3eimaZhBXtoo0tI0ie/qOl6HXtyhFe1nbL4VCOSyZbZ/bhtCFbCTEf//yfhNP/Lu5qJlS9fuL7h6HRWZgfJa2+Y1jblgIko2qEZ3cGUnZIvNCfrBpNfE0+ipfu50Gg7Gh1o=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0854; 
x-ms-traffictypediagnostic: CY4PR21MB0854:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(155532106045638);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR21MB0854; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0854; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(396003)(39380400002)(39860400002)(189003)(199004)(51444003)(13464003)(8990500004)(86612001)(3660700001)(316002)(7736002)(110136005)(305945005)(3280700002)(22452003)(33656002)(2906002)(229853002)(5250100002)(14454004)(6116002)(2900100001)(8936002)(10090500001)(8676002)(68736007)(81166006)(81156014)(53936002)(478600001)(6246003)(6436002)(106356001)(55016002)(9686003)(10290500003)(97736004)(86362001)(7696005)(76176011)(4326008)(99286004)(105586002)(46003)(25786009)(59450400001)(5660300001)(102836004)(53546011)(39060400002)(6506007)(11346002)(74316002)(476003)(186003)(486006)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0854; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 0J0Uy6JhGvCQ0wqHnzdjdUKo8aX7VOWZS66dlZMBu5FmK0ClpKRKuStG1pz/zFwu/A6psJnSl1ISxHu67fm4N286HvhIsOyQfquzrlwk/fM2iU3qXc3/PxEHa/0jTB17PMbUy6ZE0nnlDk7eCMV/NeFOk2TCdV4ns4Ni+8GtRKIi6URsph7feaL7jAQV4U9RsLUJJQ5WUodnSjlVesEGTgbIiXck+467Vw3aQL6Hp1/gsXZT3QtpQuTvIHpGIzHaeEMmr0a245eeV+00sSWkLBwc2y9T3FMXeMqoKhYU7pqafCc50hXFJ+NjXNf2U8cKa2hsejNuDu2fs+4BPYV/VH7nw/T0IpZQ12jnyt38lFJtcafeYjwtWXW214eoB4Ky123YxZWrsTabMenXZhPUylOTh1gL0WjTSwzuVC7r9A0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: a5d948fe-234e-4ee4-5e3e-08d59e7cf3c6
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a5d948fe-234e-4ee4-5e3e-08d59e7cf3c6
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 00:49:44.4384 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0854
To: Martin Thomson 
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 00:49:51 -0000

Pj4gWW91IHdhbnQgdG8gdXNlIGEgcGFja2V0IG51bWJlciB0aGF0IGlzIG5lYXIgdGhlIHJlYWwg
cGFja2V0IG51bWJlciwgZW5zdXJlIHRoYXQgZWFjaCB2YWx1ZSBpcyBvbmx5IHVzZWQgb25jZSwg
YW5kIGFsc28gaW5jbHVkZSB0aGUgcmVhbCBwYWNrZXQgbnVtYmVyIHVuZGVyIGVuY3J5cHRpb24N
Ck5vdCB0aGUgZW50aXJlIHBhY2tldCBudW1iZXIsIGp1c3QgZW5vdWdoIGluZm9ybWF0aW9uIHRv
IHJlY29uc3RydWN0IHRoZSByZWFsIHBhY2tldCBudW1iZXIuIEluIHRoaXMgc2NoZW1lIGl0IGlz
IGp1c3QgYW4gZXh0cmEgYnl0ZSBpbiB0aGUgZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIGhlYWRl
ci4gSUYgdGhlIGJhdGNoIHNpemUgaXMgc21hbGxlciB3ZSBjYW4gZG8gZmV3ZXIgYml0cyBwZXIg
cGFja2V0LiANCg0KPj4gdG8gd2hpY2ggeW91IGRvIHRoaXMgInJlb3JkZXJpbmciIHdpbGwgYWZm
ZWN0IHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgcGFja2V0IG51bWJlciByZWNvbnN0cnVjdGlvbiBp
biB0aGUgZmFjZSBvZiBhY3R1YWwgcmVvcmRlcmluZw0KRWFjaCBwYWNrZXQgaXMgc2VsZiBjb250
YWluZWQgYW5kIHRoZSByZWFsIFBOIGNhbiBiZSByZWNvbnN0cnVjdGVkIGp1c3QgdXNpbmcgdGhl
IG9mZnNldCBzdG9yZWQgaW4gdGhlIGVuY3J5cHRlZCBoZWFkZXIuIEkgZG9u4oCZdCBzZWUgYW55
IGlzc3VlcyB3aXRoIGFkZGl0aW9uYWwgbmV0d29yayBpbmR1Y2VkIHJlb3JkZXJpbmcuIFRoZXJl
IGlzIG5vIGRlcGVuZGVuY3kgYmV0d2VlbiBwYWNrZXRzIHdpdGggdGhpcyBzY2hlbWUuDQoNCj4+
IG1pZGRsZWJveCBjYW4gcmVjb25zdHJ1Y3QgcGFja2V0IG51bWJlcnMNClRoZSBudW1iZXIgNSB3
YXMgZm9yIGlsbHVzdHJhdGl2ZSBwdXJwb3Nlcy4gSW4gcHJhY3RpY2UgdGhlIGFjdHVhbCB2YWx1
ZSB3b3VsZCBsaWtlbHkgbmVlZCB0byBiZSBiZXR3ZWVuIDMyIHRvIDEyOC4gVGhlIG1pZGRsZWJv
eCBoYXMgbm8gaW5mb3JtYXRpb24gYWJvdXQgdGhlIG9mZnNldHMgYW5kIEkgZG9u4oCZdCBzZWUg
d2hhdCBwdXJwb3NlIGlzIHNlcnZlZCBieSBpdCB0cnlpbmcgdG8gZ3Vlc3MgYW55IG9yZGVyLiBC
eSByZW9yZGVyaW5nIGFsbCBudW1iZXJzIHdlIGxlYXZlIGxpdHRsZSByb29tIGZvciBhIG1pZGRs
ZWJveCB0byBtYWtlIGEgbWlzdGFrZSBhcm91bmQgdHJ5aW5nIHRvIHJlb3JkZXIgcGFja2V0cyB1
c2luZyB0aGUgbm9uY2UgZmllbGQuIFJlbWVtYmVyIHRoYXQgdGhpcyBzY2hlbWUgaXMgZm9yIHNp
bmdsZSBwYXRoIGFuZCBpcyBub3QgdHJ5aW5nIHRvIHNvbHZlIGxpbmthYmlsaXR5LiBJdCBpcyBq
dXN0IHRyeWluZyB0byBwcmV2ZW50IG9zc2lmaWNhdGlvbiBieSBkb2luZyBiZXR0ZXIgZ3JlYXNp
bmcuIA0KDQo+PiBjb25mb3VuZCB0aGUgcHJvY2VzcyBieSB3aGljaCB0aGluZ3MgbGlrZSB0aGUg
c3BpbiBiaXQgYXJlIG1hbmFnZWQNCkkgY29uY2VkZSB0aGF0IEkgaGF2ZW7igJl0IHRob3VnaHQg
b2YgdGhlIGltcGxpY2F0aW9ucyB0byBzcGluIGJpdCwgYnV0IEkgc3VzcGVjdCB0aGF0IGFzIGxv
bmcgYXMgYmF0Y2hlcyBhcmUgd2l0aGluIHRoZSBSVFQgdGhlcmUgaXMgbm8gYWN0dWFsIGlzc3Vl
IHNpbmNlIFJUVCBkZXRlY3Rpb24gaXMgbm90IGRlcGVuZGVudCBvbiB0aGUgUE4uIFdoeSB3b3Vs
ZCBpdCBtYXR0ZXIgaWYgdGhlIFBOIGlzIHRyYW5zZm9ybWVkIHVzaW5nIHRoaXMgc2NoZW1lIG9y
IHdpdGggZW5jcnlwdGlvbj8gUmVtZW1iZXIgd2UgYXJlIG5vdCBhY3R1YWxseSByZW9yZGVyaW5n
IHBhY2tldHMsIGp1c3QgcmVvcmRlcmluZyB0aGUgY2xlYXIgdGV4dCBub25jZSB2YWx1ZS4NCg0K
Pj4gUmUuIEZpc2hlci1ZYXRlcyBwZXJmDQpJIGFtIG5vdCBzdWdnZXN0aW5nIHRoaXMgYXMgdGhl
IG9ubHkgcG9zc2libGUgYWxnb3JpdGhtIGZvciBnZW5lcmF0aW5nIG5vbi1yZXBlYXRpbmcgcmFu
ZG9tIG51bWJlcnMuIEkgY2VydGFpbmx5IGRvbuKAmXQgdGhpbmsgd2UgbmVlZCB0byBtYWtlIHRo
ZSB0cmFuc2Zvcm0gc2VjdXJlLiBJIGRvbuKAmXQgdGhpbmsgaXRzIGFuIGlzc3VlIGlmIHRoZSBt
aWRkbGVib3ggZ29lcyBvdXQgb2YgaXRzIHdheSB0byBkbyBvZmZsaW5lIGFuYWx5c2lzIHRvIGZp
Z3VyZSBvdXQgdGhlIHJpZ2h0IFBOLiBXZSBhcmUgbm90IHRyeWluZyB0byBzb2x2ZSB1bmxpbmth
YmlsaXR5IHdpdGggdGhpcyBzY2hlbWUuIEl0IGlzIGp1c3QgYmV0dGVyIG9zc2lmaWNhdGlvbiBw
cmV2ZW50aW9uIGZvciBjb25uZWN0aW9ucyB0aGF0IGFyZSBvbiBhIHNpbmdsZSBwYXRoLg0KDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NClNlbnQ6IE1vbmRheSwg
QXByaWwgOSwgMjAxOCA1OjMyIFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZi
PTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBJRVRGIFFVSUMgV0cgPHF1aWNA
aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBO
IG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uDQoNCkhpIFByYXZlZW4sDQoNClRoYW5rcyBmb3Igc2hh
cmluZyB5b3VyIHRob3VnaHRzIG9uIHRoaXMuDQoNCkxldCdzIGxvb2sgYXQgdGhlIHJlcXVpcmVt
ZW50cyBhIGxpdHRsZSBjbG9zZXIgZmlyc3QsIGJlY2F1c2UgSSB0aGluayB0aGF0IHRoaXMgaXNu
J3QgcXVpdGUgcmlnaHQuDQoNCk9uIFR1ZSwgQXByIDEwLCAyMDE4IGF0IDY6NDggQU0sIFByYXZl
ZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+
IHdyb3RlOg0KPiBSZXF1aXJlbWVudHMgZm9yIGFueSBQTiB0cmFuc2Zvcm0gaW4gdGhlIHNpbmds
ZSBwYXRoIGNhc2U6DQo+DQo+IFRoZSBhY3R1YWwgUE4gbXVzdCBhbHdheXMgaW5jcmVtZW50IGJ5
IDEgYW5kIHdpbGwgYmUgdXNlZCBmb3IgDQo+IGdlbmVyYXRpbmcgQUNLcyBpbiBBQ0sgZnJhbWVz
Lg0KDQpUaGlzIGlzIGdvb2QuDQoNCj4gVGhlIHRyYW5zZm9ybWVkIFBOIGluIHRoZSBjbGVhciBp
cyBhIG5vbmNlIGFuZCBtdXN0IG5vdCByZXBlYXQgb3ZlciANCj4gdGhlIGNvbm5lY3Rpb24gbGlm
ZXRpbWUuDQoNCkkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIGlzIGNvcnJlY3QsIG9yIGF0IGxlYXN0
IGl0IGNvdWxkIGJlIHR1cm5lZCBpbnRvIGEgcmVxdWlyZW1lbnQgYW5kIGEgc2VwYXJhdGUgaW5z
aWdodCBhYm91dCB0aGF0IG9ic2VydmF0aW9uLg0KTmFtZWx5IHRoYXQgdGhlIFBOIGlzIHVzZWQg
YXMgYSBub25jZSwgYnV0IHdlIGRvbid0IG5lZWQgdG8gdXNlIG5vbmNlcyBpbiB0aGUgb3JkZXIg
dGhleSBhcmUgcHJlc2VudGVkLg0KDQpXaGF0IGlzIGluY29ycmVjdCBoZXJlIGlzIHRoYXQgd2Ug
dXNlIHRoZSBhY3R1YWwgUE4gYXMgYSBub25jZS4gIFRoaXMgY29uZnVzaW9uIGlzIHVuZGVyc3Rh
bmRhYmxlIGJlY2F1c2UgLSBhdCB0aGUgbW9tZW50IC0gd2Ugc2hpZnQgdGhlIGFjdHVhbCBQTiBi
eSBhIHJhbmRvbSBvZmZzZXQuICBCdXQgdGhhdCdzIGEgbWlzdGFrZSBhbmQgd2Ugc2hvdWxkIHJl
Y3RpZnkgdGhhdCBhbnl3YXkgYXMgIzEwNzkgZG9lcy4gIEV2ZW4gaWYgd2UgZG9uJ3QgZG8gIzEw
NzksIGFueSBkZXNpZ24gd2UgaGF2ZSBjYW4gYW5kIHNob3VsZCByZW1vdmUgdGhhdCBpbml0aWFs
IHJhbmRvbWl6YXRpb24gYW5kIHVzZSBhIHJhbmRvbSBvZmZzZXQgdHJhbnNmb3JtYXRpb24gaW5z
dGVhZDsgdGhlIHNhbWUgZm9yIHBhY2tldCBudW1iZXINCmdhcHM6IHdlIGNhbiB1c2UgYSBkaWZm
ZXJlbnQgcmFuZG9tIG9mZnNldCBpbiB0aGUgdHJhbnNmb3JtYXRpb24uDQoNCkJ1dCBJIHNlZSB3
aGVyZSB5b3UgYXJlIGdvaW5nIHdpdGggdGhpcy4gIFlvdSB3YW50IHRvIHVzZSBhIHBhY2tldCBu
dW1iZXIgdGhhdCBpcyBuZWFyIHRoZSByZWFsIHBhY2tldCBudW1iZXIsIGVuc3VyZSB0aGF0IGVh
Y2ggdmFsdWUgaXMgb25seSB1c2VkIG9uY2UsIGFuZCBhbHNvIGluY2x1ZGUgdGhlIHJlYWwgcGFj
a2V0IG51bWJlciB1bmRlciBlbmNyeXB0aW9uLiAgR2l2ZW4gdGhhdCwgaWYgaXQgd2VyZW4ndCBm
b3IgdGhlIHdheSB0aGF0IGxvc3MgZGV0ZWN0aW9uIHJlYWN0cyB0byByZW9yZGVyaW5nLCB5b3Ug
Y291bGQgYWxtb3N0IGp1c3Qgc2VuZCBwYWNrZXRzIHdpdGggb3V0IG9mIG9yZGVyIHBhY2tldCBu
dW1iZXJzLg0KDQpUaGUgZWZmZWN0IG9mIHRoaXMgaXMgdGhhdCB0aGUgZGVncmVlIHRvIHdoaWNo
IHlvdSBkbyB0aGlzICJyZW9yZGVyaW5nIiB3aWxsIGFmZmVjdCB0aGUgcGVyZm9ybWFuY2Ugb2Yg
dGhlIHBhY2tldCBudW1iZXIgcmVjb25zdHJ1Y3Rpb24gaW4gdGhlIGZhY2Ugb2YgYWN0dWFsIHJl
b3JkZXJpbmcuICBUaGF0IHB1dHMgYSBoYXJkDQp1cHBlciBsaW1pdCBvbiB0aGUgYW1vdW50IG9m
IHJlb3JkZXJpbmcgeW91IGRvLiAgIEl0IHdpbGwgYWxzbyBjb3N0DQpzb21lIG51bWJlciBvZiBi
eXRlcyB0byByZWNvbnN0cnVjdCB0aGUgcmVhbCBwYWNrZXQgbnVtYmVyLg0KDQo+IE1pZGRsZWJv
eGVzIG11c3Qgbm90IGJlIGFibGUgdG8gZGV0ZXJtaW5lIHRoZSBhY3R1YWwgUE4uIE9ubHkgdGhl
IFFVSUMgDQo+IHJlY2VpdmVyIHNob3VsZCBiZSBhYmxlIHRvIGRvIHNvLg0KDQpUaGlzIHNvdW5k
cyBsaWtlIGEgZ29vZCBnb2FsLCBidXQgSSB0aGluayB0aGF0IHlvdXIgZGVzaWduIG1pc3NlcyBp
dC4NClRoZSBwb2ludCB3aXRoIHRoZSAjMTA3OSBkZXNpZ24gaXMgdGhhdCBpdCBpcyBzZW1hbnRp
Y2FsbHkgc2VjdXJlOiB5b3UgbmVlZCB0aGUga2V5cyB0byBnZXQgdGhlIHJlYWwgcGFja2V0IG51
bWJlci4NCg0KSW4geW91ciBkZXNpZ24sIGEgbWlkZGxlYm94IGNhbiByZWNvbnN0cnVjdCBwYWNr
ZXQgbnVtYmVycyB3aXRoIGhpZ2ggZmlkZWxpdHkgYmFzZWQgb24gYXJyaXZhbCB0aW1lcyBhbmQg
a25vd2xlZGdlIG9mIHRoZSBub24tc2VjcmV0IHBhcmFtZXRlciAodGhlIDUgeW91IHVzZWQgaW4g
eW91ciBleGFtcGxlKS4gIE9ubHkgcmVvcmRlcmluZyB3aXRoaW4gdGhhdCBzZXQgKGUuZy4sIGJl
dHdlZW4gcGFja2V0IDEwMSBhbmQgMTAyIGluIHlvdXIgZXhhbXBsZSkgd2lsbCBiZSB1bmRldGVj
dGFibGUsIGJ1dCByZW9yZGVyaW5nIGFjcm9zcyBhIGJvdW5kYXJ5IChlLmcuLCBiZXR3ZWVuIHBh
Y2tldA0KMTA0IGFuZCAxMDUpIHdpbGwgYmUgZWFzaWx5IGRldGVjdGFibGUuICBGaW5hbGx5LCBp
ZiB0aGUgUFJORyB1c2VkIHRvIHNlZWQgRmlzaGVyLVlhdGVzIGlzbid0IGEgQ1NQUk5HLCB0aGVu
IGl0cyBzdGF0ZSBjYW4gYmUgcmVjb25zdHJ1Y3RlZCBldmVudHVhbGx5IGFuZCB0aGVuIHRoZSBy
ZW9yZGVyaW5nIHByb2JsZW0gZ29lcyBhd2F5Lg0KDQpTbyBhbGwgdGhhdCB0aGlzIGVmZmVjdGl2
ZWx5IGRvZXMgaXMgY29uZm91bmQgdGhlIHByb2Nlc3MgYnkgd2hpY2ggdGhpbmdzIGxpa2UgdGhl
IHNwaW4gYml0IGFyZSBtYW5hZ2VkLiAgSXQgZG9lc24ndCBwcm92aWRlIGFueSByZWFsIGJhcnJp
ZXIuDQoNCkJ1dCBtYXliZSB0aGF0IGlzIHRoZSByZWFsIGdvYWwsIHRvIG1ha2UgaXQgaGFyZGVy
IHRvIGRvIHRoaXMsIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgYW55b25lIHdpbGxpbmcgdG8gZG8g
dGhhdCB3b24ndCBhbHNvIG9zc2lmeSB0aGUgcHJvdG9jb2wgaW4gdGhlIHByb2Nlc3MuICBJIGRv
bid0IHNlZSB0aGF0IGhhcHBlbmluZywgYnV0IHRoYXQncyBjbGVhcmx5IGEgcG9pbnQgb24gd2hp
Y2ggZGlmZmVyZW50IHBlb3BsZSByZWFjaCBkaWZmZXJlbnQgY29uY2x1c2lvbnMuDQoNCkZXSVcs
IEZpc2hlci1ZYXRlcyBpcyBwcmV0dHkgaW5lZmZpY2llbnQgYXMgYSBQUlAuICBJJ20gc3VycHJp
c2VkIHRoYXQgeW91IGFyZSBzdWdnZXN0aW5nIGl0LiAgSG93IGFyZSB5b3Ugc2VlZGluZyB0aGUg
UFJORz8gIElzIGl0IGEgQ1NQUk5HPw0KIEhhdmUgeW91IHRlc3RlZCB0aGUgb3ZlcmFsbCBwZXJm
b3JtYW5jZT8NCg0KQSBkaWZmZXJlbnQgY2hlYXAgUFJQIHdvdWxkIGJlIFhPUi1zaGlmdCAoUE4+
PmF8UE4+PmJ8UE4+PmMpLCBvciAoUE4gKw0KYSkgKiBiLiAgVGhleSBhcmUgZWFjaCB0cml2aWFs
bHkgcmV2ZXJzZWQgdGhvdWdoLiAgV2hpbGUgdGhhdCB2aW9sYXRlcyB5b3VyIHN0aXB1bGF0ZWQg
cmVxdWlyZW1lbnQsIGl0IGRvZXNuJ3QgdmlvbGF0ZSB0aGUgaW1wbGllZCBvbmUuICBJZiB0aGUg
cmVxdWlyZW1lbnQgaXMgdGhhdCBpdCBiZSAqZGlmZmljdWx0KiB0byByZWNvbnN0cnVjdCB0aGUg
YWN0dWFsIHBhY2tldCBudW1iZXIgYmFzZWQgb24gdGhlIHNlcXVlbmNlIG9mIHRyYW5zZm9ybWVk
IHBhY2tldCBudW1iZXJzLCB0aGVuIG1heWJlIHRob3NlIGFyZSBiZXR0ZXIuICBCYXNlZCBvbiB0
aG9zZSB5b3Ugd291bGRuJ3QgbmVlZCB0byBhbHNvIGluY2x1ZGUgdGhlIHJlYWwgcGFja2V0IG51
bWJlciB1bmRlciBlbmNyeXB0aW9uLCB3aGljaCBzYXZlcyB0aGF0IG1hbnkgb2N0ZXRzLg0KDQo=


From nobody Mon Apr  9 17:58:02 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CFC126B72 for ; Mon,  9 Apr 2018 17:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523321881; bh=3w0ETGrNS8d/HWvi9WLBV5I7/aOqig+RU6QuqRBALGo=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=AEtLrDO4neWDvnyNN9UoVfyxC2pRMdsqJrjmCm7Zchr6r2XzNoy4BkFLkk7cJKSNm rb9HL7IUF73kWau9Htw4w4UEiA4xkKRt1jc3eAzadHWNoQfeGmlz8MppS/iEXqhAIw hlNVOy2+aPa7JrlUFfhmUK7P2z3R2NbKiIxEnB0c=
X-Mailbox-Line: From martin.thomson@gmail.com  Mon Apr  9 17:58:01 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0976A124239; Mon,  9 Apr 2018 17:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523321881; bh=3w0ETGrNS8d/HWvi9WLBV5I7/aOqig+RU6QuqRBALGo=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=AEtLrDO4neWDvnyNN9UoVfyxC2pRMdsqJrjmCm7Zchr6r2XzNoy4BkFLkk7cJKSNm rb9HL7IUF73kWau9Htw4w4UEiA4xkKRt1jc3eAzadHWNoQfeGmlz8MppS/iEXqhAIw hlNVOy2+aPa7JrlUFfhmUK7P2z3R2NbKiIxEnB0c=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E536E126B72 for ; Mon,  9 Apr 2018 17:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 qmCiFtvdgf2b for ; Mon,  9 Apr 2018 17:57:59 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8EC124239 for ; Mon,  9 Apr 2018 17:57:59 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id l190-v6so9526651oig.9 for ; Mon, 09 Apr 2018 17:57:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=adXK/+tvDKT9nS8xY7+hzGhqbUp0uyZlPeN8qZmbkmQ=; b=fnoqJBdxgKVoKI/L5zf0Z6ezzLYTPM9/FRasJVf57QCYHX5tyiPkdqkc/q5Skxxmvv ioKkeJKsDtjuNYsgL57xFWWB19J/h3SK14Iy5XPP3ZI7tCAoK3iPRK8run5/QIC8/HEW N4Ft6ykX7spu7e/Jqr1G0A86RKARj9MPzGH32T0nfO+vsIGOOSagiawMlUl75tgrZFE5 qeriKAwLesChlfh38nPn96lnPSss6pvEs7BghWqqnuHW/7wOMypIpb0/xHnVwLldjlBn GHOhpQB6IMzIbdrIfzU/PCLTGauHhnTA6ZKOjEKm15pwCtuo6uG6MBsg9MqYxF3U8Lkf qqVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=adXK/+tvDKT9nS8xY7+hzGhqbUp0uyZlPeN8qZmbkmQ=; b=QqLp2Vszt7X05N5GZdU3GOe+keBcZQG4MW8jRqZ+FLYwezYJcl+q1LKAzBLV66Nt/4 b4k139yy2mA9IaDhSoYf3+Vm9Nz7N2eqtZ5p/wWrwXrxewhTZ2TVCDYD1zWxizW30p3h 1sXHdgcG8Q0w/P5VuFLJDnX2EjQLKlFDyDPYwsO+VowrMO7gGRTr4LgwGHIT+me84QxA bfLEinzLIA8Mb3TDOqUwmWRYXTcTNf8erECZGKU/C+minPK/T1j6x+PLR/pvbLICYkXO dlID9W9gxul8QPWlnbqWcVBmA76T44gZe/+KDGPcA94wcWKgw96mg2tI7c4Aijeft276 xmYA==
X-Gm-Message-State: ALQs6tDGtWqJMAwHsh+Fx85QFxi9xlRRreTwQdHih4803193WBz1Kr4D j+0zWP7mkY7jkybfBnFbQ+Udbg9lHtVble7MSL0=
X-Google-Smtp-Source: AIpwx4+YCiNYtdF5J5DAFB2oujdOxi+gS/tWEKhdwI4lIbYIFVlC6FEctFvRSGGFxjDy/Cf5TieoJSM8DFld89i30Yc=
X-Received: by 2002:aca:ab44:: with SMTP id u65-v6mr779084oie.272.1523321878469;  Mon, 09 Apr 2018 17:57:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 9 Apr 2018 17:57:58 -0700 (PDT)
In-Reply-To: 
References:   
From: Martin Thomson 
Date: Tue, 10 Apr 2018 10:57:58 +1000
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Praveen Balasubramanian 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Praveen Balasubramanian 
Cc: IETF QUIC WG 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 00:58:01 -0000

On Tue, Apr 10, 2018 at 10:49 AM, Praveen Balasubramanian
 wrote:
>>> You want to use a packet number that is near the real packet number, en=
sure that each value is only used once, and also include the real packet nu=
mber under encryption
> Not the entire packet number, just enough information to reconstruct the =
real packet number. In this scheme it is just an extra byte in the encrypte=
d portion of the header. IF the batch size is smaller we can do fewer bits =
per packet.

If I understand your scheme, then you reconstruct the nonce in the
same way that you reconstruct the packet number.  Is that a
misunderstanding?  Or are you suggesting that there is an explicit
nonce in the packet?

>>> to which you do this "reordering" will affect the performance of the pa=
cket number reconstruction in the face of actual reordering
> Each packet is self contained and the real PN can be reconstructed just u=
sing the offset stored in the encrypted header. I don=E2=80=99t see any iss=
ues with additional network induced reordering. There is no dependency betw=
een packets with this scheme.

The current design places requirements on the size of the truncated
packet number that is based on the exposure to reordering.  Your
design effectively induces reordering into this process, so the number
of bytes you spend on the "packet number" (really a nonce in your
design) encoding has to increase to compensate.


From nobody Mon Apr  9 17:58:07 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8572F124239 for ; Mon,  9 Apr 2018 17:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 7CZCpPOcmpwf for ; Mon,  9 Apr 2018 17:57:59 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA731201F8 for ; Mon,  9 Apr 2018 17:57:59 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id 71-v6so9538100oie.12 for ; Mon, 09 Apr 2018 17:57:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=adXK/+tvDKT9nS8xY7+hzGhqbUp0uyZlPeN8qZmbkmQ=; b=fnoqJBdxgKVoKI/L5zf0Z6ezzLYTPM9/FRasJVf57QCYHX5tyiPkdqkc/q5Skxxmvv ioKkeJKsDtjuNYsgL57xFWWB19J/h3SK14Iy5XPP3ZI7tCAoK3iPRK8run5/QIC8/HEW N4Ft6ykX7spu7e/Jqr1G0A86RKARj9MPzGH32T0nfO+vsIGOOSagiawMlUl75tgrZFE5 qeriKAwLesChlfh38nPn96lnPSss6pvEs7BghWqqnuHW/7wOMypIpb0/xHnVwLldjlBn GHOhpQB6IMzIbdrIfzU/PCLTGauHhnTA6ZKOjEKm15pwCtuo6uG6MBsg9MqYxF3U8Lkf qqVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=adXK/+tvDKT9nS8xY7+hzGhqbUp0uyZlPeN8qZmbkmQ=; b=IHgGrn2Nv0tPHeXVomT58HJJIsIoXdQ6t2FdzJ2OqF5l/IJK4sXSvt2K+vb2nm46R0 GJ8PttCUR6InbtORylP27IGzZRqYK95TLcArSQJoX3HLhUQjSLcaRRFPUImsUi2v2jJQ 39Be+7ekWlHXrnesm+n0UoOVo80ZQxFx/DSfB70iuZMKN5rWsk7WOcJ8/q2aGWaco9Q0 CRtpGI/iyIDlaxebyo+Fdktf1YGiKAloJn+ikWtPJUoLOBWqWeqL9LrIHz7qU4enw9fU 98I27ixG/+stKLGKNfgzMwRFeB+NF96s6vrXJPGVS8hY7LV8pW2eW3FHgFZp1xExPNWl R/WQ==
X-Gm-Message-State: ALQs6tB1iUX27vYWoa0hcRf+o4ocIIvK6lIE+cgDGXwLX+VWh3RN+iND gY5MNEcfHFOdpZf/vCrbBvw49YxUiq+IT+TKtC4=
X-Google-Smtp-Source: AIpwx4+YCiNYtdF5J5DAFB2oujdOxi+gS/tWEKhdwI4lIbYIFVlC6FEctFvRSGGFxjDy/Cf5TieoJSM8DFld89i30Yc=
X-Received: by 2002:aca:ab44:: with SMTP id u65-v6mr779084oie.272.1523321878469;  Mon, 09 Apr 2018 17:57:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 9 Apr 2018 17:57:58 -0700 (PDT)
In-Reply-To: 
References:   
From: Martin Thomson 
Date: Tue, 10 Apr 2018 10:57:58 +1000
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Praveen Balasubramanian 
Cc: Praveen Balasubramanian , 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, 10 Apr 2018 00:58:01 -0000

On Tue, Apr 10, 2018 at 10:49 AM, Praveen Balasubramanian
 wrote:
>>> You want to use a packet number that is near the real packet number, en=
sure that each value is only used once, and also include the real packet nu=
mber under encryption
> Not the entire packet number, just enough information to reconstruct the =
real packet number. In this scheme it is just an extra byte in the encrypte=
d portion of the header. IF the batch size is smaller we can do fewer bits =
per packet.

If I understand your scheme, then you reconstruct the nonce in the
same way that you reconstruct the packet number.  Is that a
misunderstanding?  Or are you suggesting that there is an explicit
nonce in the packet?

>>> to which you do this "reordering" will affect the performance of the pa=
cket number reconstruction in the face of actual reordering
> Each packet is self contained and the real PN can be reconstructed just u=
sing the offset stored in the encrypted header. I don=E2=80=99t see any iss=
ues with additional network induced reordering. There is no dependency betw=
een packets with this scheme.

The current design places requirements on the size of the truncated
packet number that is based on the exposure to reordering.  Your
design effectively induces reordering into this process, so the number
of bytes you spend on the "packet number" (really a nonce in your
design) encoding has to increase to compensate.


From nobody Mon Apr  9 18:05:06 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599C7124239 for ; Mon,  9 Apr 2018 18:05: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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-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=fb.com header.b=ezTHsUDd; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=NJnDsFlD
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlOP2JAPuoE9 for ; Mon,  9 Apr 2018 18:05: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 9C8191201F8 for ; Mon,  9 Apr 2018 18:05:02 -0700 (PDT)
Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3A140sH030213; Mon, 9 Apr 2018 18:04:59 -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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=h+28MSuJSRwE5mXU30MSKdFP4El5VgVTzrr4S9u8f8c=; b=ezTHsUDdI5bBiu4ZOG9tpGYHCqpeGB2Idjt4k6Oe8kvV1qxVMfe0FLdhyzDgBZDIEUPT G01aYlAFipVHEO1Jfwx0J6VINMX55MemJ9ptBrWMO0r0mLpiUAgLTHbwr5M5+2NM1Go8 PiibvJ4zWXW9a1svoX/0LIvro1KaRZaTCnU= 
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2h8jqk02t0-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 09 Apr 2018 18:04:58 -0700
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.16) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 9 Apr 2018 18:04:57 -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=h+28MSuJSRwE5mXU30MSKdFP4El5VgVTzrr4S9u8f8c=; b=NJnDsFlDUd7pdFtoRtoqxT9wfUwybAqh0TFiq2xSoy8IvtfKP45D1C8hQdP7irWkI7BTuKIRIAiXFjirEtNm8Lg6uVZ2dJfmNXOr0EtQkHAtCf0siXTu6hFF3BDAH5Jrzhz0Ck5hcr/GmrI03/xFY8dfh8sfmXs1rtbyXhFdEbY=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0885.namprd15.prod.outlook.com (10.164.171.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Tue, 10 Apr 2018 01:04:55 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::78a6:3a7a:1195:dd02]) by BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::78a6:3a7a:1195:dd02%13]) with mapi id 15.20.0653.018; Tue, 10 Apr 2018 01:04:55 +0000
From: Roberto Peon 
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Christian Huitema 
CC: "quic@ietf.org" 
Subject: Re: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GjyGQaKf4GI0anNhXTngANsKPwZ0sAgAC4ugCAAARcAIAAG5CAgAAFCACAAACJgIAAEVkAgACR+ICAAVFHAA==
Date: Tue, 10 Apr 2018 01:04:52 +0000
Message-ID: <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.a.0.180210
x-originating-ip: [2620:10d:c090:180::1:740c]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0885; 7:dNJ4dMk+pyO9iEsStYlWQOWjy4CbW7zYcblF97cj8SBAwgSBegMLWCo1Qcu3AMZvQMrIwww135aSB742tfZX4rEp3ZuugHQFm0Lfb+eUdydqPVLvKt7EDldLQSYk/Mvk6Mub8IFr4GBTaX4McE2sbbsmn69iN2jnV1e3wKtpWp1dKg18HIuwtLuWOesbLTGFeb1y9AWnVdkc77r4Ee30Fn2Pl+3L191boygUmGmZpfykgNUZUndcNezNEYfbDXp7; 20:MSi7s/UVOlphhKDHKc4ikzh/g/I9mnddKGuYVz6so2XM0mBj0GG60WSk614naUokjAFLVRltxd+nIQ03sM2ovQUPJfVdoBSNAWpEB+JXie8DfhR//KUPL9CrEC/1UCaVGYCNr6vsqds2ed/K4JLZ85Qn1zq+bxjJtr79K0E8grY=
X-MS-Office365-Filtering-Correlation-Id: 278b42de-7795-4430-584b-08d59e7f128e
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR15MB0885; 
x-ms-traffictypediagnostic: BY2PR15MB0885:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(11241501184)(944501327)(52105095)(3002001)(10201501046)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BY2PR15MB0885; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0885; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(39860400002)(396003)(39380400002)(199004)(189003)(54014002)(6512007)(2906002)(59450400001)(5250100002)(105586002)(76176011)(11346002)(446003)(2616005)(478600001)(33656002)(3280700002)(97736004)(46003)(106356001)(68736007)(3660700001)(305945005)(8676002)(81166006)(186003)(8936002)(81156014)(102836004)(99286004)(476003)(14454004)(6116002)(2900100001)(5660300001)(7736002)(110136005)(6666003)(82746002)(6246003)(36756003)(58126008)(53936002)(86362001)(6436002)(25786009)(93886005)(486006)(6506007)(6486002)(83716003)(229853002)(4326008)(316002)(427584002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0885; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: jFSq9VECBJcHkaKpj8brqB5Q3m714Pl0ZkBPOzDYbFtE1/pDz2pwY0ZEP+3CLhwDoP5HrKRH/S8jbphYqqQwQnnfgwnEggfyZly7i5wuJ112GUXelEe2kUx89PiBRw5U43eRkv3lIhbHF+uLeW5O0CDi/XPC+gL1RLGy0bvW9qX5DAtWhjDPgf5PJwjMd1zy5gjaoUR7s3FruAAXmdhLhNYf6ocEFC4C1aqvtDJhPyhfuPB/oixrQ1xD/qXCYE/M/w6ObLIvzBYrT/RGlUXqhbP6Xgjjmt2ca5IedSluyg3fAI69bqhttYgjNX2CwAypXRrvqVDap+Dlqhj7ao/ETdLCEWmPtQXQA56Hywbi9V96KmNxOhnBdw17mmosM7ewW2FPRvWf1g4ZtSl8qhsWol1Tioy8wTnuSpb3V3kcMRw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <9C20C3E47290F041BC5AF73E0D7AD2AA@namprd15.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 278b42de-7795-4430-584b-08d59e7f128e
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 01:04:52.5739 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0885
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-09_11:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Apr 2018 01:05:05 -0000

QWRkaW5nIGFub3RoZXIgUE4gd291bGQgcHJvYmFibHkgbm90IGJlIHN1ZmZpY2llbnQtLSBvbmUg
d291bGQgbmVlZCB0byBlbnN1cmUgdGhhdCB0aGUgb3NzaWZpZWQgUE4gd2FzIHByZXNlbnRlZCB3
aXRoIHRoZSByaWdodCBzZXF1ZW5jaW5nIGFzIHdlbGwsIHdoaWNoIG1pZ2h0IGJlIGRpZmZpY3Vs
dCwgb3IgZXhwZW5zaXZlLg0KT3NzaWZpY2F0aW9uIGlzIHN1cnByaXNpbmdseSBkaWZmaWN1bHQg
dG8gd29yayBhcm91bmQgb25jZSBpdCBzZXRzIGluLCBhcyBldmVuIGZpZ3VyaW5nIG91dCBob3cg
aXQgaXMgaW1wYWN0aW5nIHlvdSBjYW4gYmUgc3Vic3RhbnRpYWwgd29yay4NCg0KLT1SDQoNCu+7
v09uIDQvNS8xOCwgMjoyNyBBTSwgIlFVSUMgb24gYmVoYWxmIG9mIE1pcmphIEvDvGhsZXdpbmQi
IDxxdWljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1pcmphLmt1ZWhsZXdpbmRAdGlr
LmVlLmV0aHouY2g+IHdyb3RlOg0KDQogICAgTGV0IG1lIHJlcGVhdCBhbm90aGVyIHBvc2l0aW9u
IHRoZW4gYXMgd2VsbDoNCiAgICANCiAgICA+IEFtIDA1LjA0LjIwMTggdW0gMDI6NDQgc2Nocmll
YiBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD46DQogICAgPiANCiAgICA+
IElmIHdlIGFyZSBpbiB0aGUgYnVzaW5lc3Mgb2YgcmVwZWF0aW5nIG91ciBwb3NpdGlvbnMsIHNv
IGJlIGl0LiBJIGFtIHByZXR0eSBtdWNoIG9uIHRoZSBzYW1lIGxpbmUgYXMgUGF0cmljayBhbmQg
b3RoZXJzOg0KICAgID4gDQogICAgPiAxKSBQcml2YWN5IGlzIG5vdCBvcHRpb25hbC4gQW5kIHll
cywgcmVtb3ZpbmcgImxpbmthYmlsaXR5IHRocm91Z2ggUE4iIGlzIGltcG9ydGFudCwgYmVjYXVz
ZSB3aGVuIHRoZSBjb25uZWN0aW9uIElEIGFuZCB0aGUgc291cmNlIGFkZHJlc3MgYWxzbyBjaGFu
Z2UsIHRoZSBvbmx5IG90aGVyIGN1ZSBmb3IgbGlua2FiaWxpdHkgaXMgdGltaW5nLiBUaW1pbmcg
Y2FuIGJlIGFkZHJlc3NlZCBieSBoYXZpbmcgb3ZlcmxhcHBpbmcgY29ubmVjdGlvbnMuDQogICAg
PiANCiAgICBUaW1pbmcgZG9lc27igJl0IGhlbHAgaGVyZSBlaXRoZXIgYmVjYXVzZSB5b3Ugc3Rp
bGwgaGF2ZSB0aGUgc2FtZSBkZXN0aW5hdGlvbiBJUCwgYm90aCBwb3J0IG51bWJlcnMgYW5kIHRo
ZSBmYWN0IHRoYXQgYSBtaWdyYXRlZCBjb25uZWN0aW9uIGRvZXMgbm90IGhhdmUgYSBoYW5kc2hh
a2UuIElmIHdlIHdhbnQgdG8gYWRkcmVzcyB0aGUgbGlua2FiaWxpdHkgcHJvYmxlbSwgd2Ugd291
bGQgbmVlZCB0byBkbyBtdWNoIG1vcmUsIHByb2JhYmx5IGJhcmluZyBtb3JlIGhpdHMgb24gcGVy
Zm9ybWFuY2UuIA0KICAgIA0KICAgIEkgdGhvdWdodCB3ZSBkaXNjdXNzZWQgdGhpcyBhbHJlYWR5
IGVuZGxlc3NseSBhbmQgY29uY2x1ZGVkIHRoYXQgUE5FIGRvZXMgbm90IGhlbHAgbGlua2FiaWxp
dHkuDQogICAgDQogICAgVGhlbiBhbiBhcmd1bWVudCBmb3Igb3NzaWZpY2F0aW9uIHdhcyBicm9h
ZCB1cC4gSG93ZXZlciwgd2UgcmVhbGx5IGNhbm5vdCBjb21wYXJlIHRoZSBzaXR1YXRpb24gaGVy
ZSB3aXRoIFRDUC4gV2l0aCBUQ1AgZXZlcnl0aGluZyBpcyBpbiB0aGUgY2xlYXIgaW5jbC4gYWxz
byB0aGUgcmV0cmFuc21pc3Npb25zLiBJbiBjYXNlIG9mIE1QVENQIHRoaXMgd2FzIHJhdGhlciB0
aGUgcHJvYmxlbSB0aGUgdGhlIHNlcSMgYmVjYXVzZSBpZiB5b3XigJlkIHVzZSB0aGUgc2FtZSBz
ZXEjIG51bWJlciBzcGFjZSBvbiBib3RoIGNvbm5lY3Rpb25zIGl0IHdvdWxkIGxpa2UgbG9zcyBi
dXQgd2l0aG91dCBhIHJldHJhbnNtaXNzaW9uLiBGdXJ0aGVyIGJveGVzIHRoYXQgcmVvcmRlciwg
dXN1YWxseSBkbyB0aGF0IGluIHNpdHVhdGlvbiB3aGVyZSBwYWNrZXRzIHdlcmUgdHJhbnNtaXR0
ZWQgZm9yIGEga25vd24gcmVhc29uIG91dC1vZiBvcmRlciBwcmV2aW91c2x5LCBlLmcuIHdoZW4g
bXVsdGlwbGUgcGF0aHMgYXJlIHVzZWQgaW4gdGhlIG5ldHdvcmsuIFRoZSByZWNvbW1lbmRhdGlv
biB3ZSBzdGlsbCBnaXZlIGluIHRoZSBJRVRGIHRyYW5zcG9ydCBhcmVhIGlzIHRoYXQgaW4gc3Vj
aCBhIHNpdHVhdGlvbiB0aGUgc2NoZWR1bGluZyBzaG91bGQgbm90IGJlIGRvbmUgb24gYSBwZXIt
cGFja2V0IGxldmVsIGJ1dCBwZXItZmxvdy4gSG93ZXZlciwgdGhvc2Ugc2NoZW1lIHRoYXQgZG8g
cGVyLXBhY2tldCBzY2hlZHVsaW5nIHVzdWFsbHkgYWxzbyBhcHBseSBtZWNoYW5pc20gdG8gcmUt
b3JkZXIgYWZ0ZXJ3YXJkcy4gVGhleSBjYW4ganVzdCB1c2UgdGhlIFRDUCBzZXEjIGZvciB0aGF0
IGJ1dCBmb3Igbm9uLVRDUCB0aGV5IHdvdWxkIHNpbXBseSBhZGQgdGhlaXIgb3duIGVuY2Fwc3Vs
YXRpb24gd2l0aCBhIHNlcSPigKYNCiAgICANCiAgICBQbGVhc2Uga2VlcCBpbiBtaW5kIHRoYXQg
ZXZlbiBpZiBhbiAodW5lbmNyeXB0ZWQpIFBOIGdldHMgb3NzaWZpZWQgYnkgdGhlIG5ldHdvcmss
DQogICAgaW4gY2FzZSBvZiBRVUlDIHRoYXQgZG9lcyBub3QgbWVhbiB0aGF0IHdlIGNhbuKAmXQg
Y2hhbmdlIHRoZSB0cmFuc3BvcnQgbWFjaGluZXJ5IGFueW1vcmUuIEN1cnJlbnRseSB0aGUgZXhw
b3NlZCBQTiBpcyBhbHNvIHVzZWQgZm9yIGNvbmdlc3Rpb24gY29udHJvbCBhbmQgcmV0cmFuc21p
c3Npb24sIGhvd2V2ZXIsIHdlIGNhbiBzdGlsbCBhZGQgYW5vdGhlciBQTiBpbiB0aGUgZW5jcnlw
dGVkIHBhcnQgYW5kIHJlc29sdmVkIHRoZSBmYWN0IHRoYXQgdGhlIGN1cnJlbnQgUE4gaXMgb3Zl
cmxvYWRlZCBmb3IgZGlmZmVyZW50IGZ1bmN0aW9ucy4NCiAgICANCiAgICBDdXJyZW50bHksIEkg
cmVhbGx5IHN0aWxsIGRvbuKAmXQgc2VlIHRoZSBiZW5lZml0IG9mIFBORSBidXQgb25seSBhZGRp
dGlvbmFsIGNvbXBsZXhpdHkgYW5kIGtub3duIHBlcmZvcm1hbmNlIGRlZ3JhZGF0aW9uLg0KICAg
IA0KICAgIE1pcmphDQogICAgDQogICAgDQogICAgDQogICAgDQoNCg==


From nobody Mon Apr  9 18:07:23 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9411201F8 for ; Mon,  9 Apr 2018 18:07:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523322442; bh=wDoljbTwOHgqSLAo+Cn3O4VB3F0QiERHskFdrAKgQWA=; h=From:To:Subject:Date:References:In-Reply-To:Cc:Cc; b=XrHMyy/uCo5v7NTGnqoefFuN5S2Jv3n28WRXW5si+zLxFxPL5TUIxClgLQsbbIltw yD1qvtbbQeN42vtqzV9BoOVa9PQIWGQaiBYK/VLJIZZOcJfQAHQlJBOpXGgDG9jlEz v4xFj5YGZhW2kc1w9bRm/3DeEikqrRzP3639oISI=
X-Mailbox-Line: From pravb@microsoft.com  Mon Apr  9 18:07:22 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0FE120227; Mon,  9 Apr 2018 18:07:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523322442; bh=wDoljbTwOHgqSLAo+Cn3O4VB3F0QiERHskFdrAKgQWA=; h=From:To:Subject:Date:References:In-Reply-To:Cc:Cc; b=XrHMyy/uCo5v7NTGnqoefFuN5S2Jv3n28WRXW5si+zLxFxPL5TUIxClgLQsbbIltw yD1qvtbbQeN42vtqzV9BoOVa9PQIWGQaiBYK/VLJIZZOcJfQAHQlJBOpXGgDG9jlEz v4xFj5YGZhW2kc1w9bRm/3DeEikqrRzP3639oISI=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFD41201F8 for ; Mon,  9 Apr 2018 18:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 H8PcPsIxG-xk for ; Mon,  9 Apr 2018 18:07:20 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 365E2120227 for ; Mon,  9 Apr 2018 18:07:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wDoljbTwOHgqSLAo+Cn3O4VB3F0QiERHskFdrAKgQWA=; b=cjolCd1TLVvrk72FU3l9YRuAm6XDxEYjPf5JISFfVvsXZR1zaOn/Ru4cpeexel5EUV00c1YGRn5ta3x5kkPs8pNumtv/E2WjjUqH2U/MABBtGW43uIQaYC2onHTOTJlgqdiYvkGhVsCeCxnMQsp9Gu1kckkv39L4SYIzwSCx7Ds=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0773.namprd21.prod.outlook.com (10.173.192.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.3; Tue, 10 Apr 2018 01:07:18 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Tue, 10 Apr 2018 01:07:18 +0000
From: Praveen Balasubramanian 
To: Martin Thomson 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAH3w2AAAAjVmAAAMjZAAAADK3g
Date: Tue, 10 Apr 2018 01:07:18 +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:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0773; 7:gOr2GCVtLLxrxj+m5b2JwxnZnlq5vewfxSWbuQ4Tv/Lgta5aLgl1BTt10cnfu1XneOLwXwHR0MiI8pbgjDZlNDkTdsoYXSCbucRlya1+ZH5iJC6yQJSPOFSumbYpRQB+wn+N36NFE4WijtodUEN4T2o+xLuRUyIWs8n8+bAv6wpcsLrSIRav7TEJP5zY75UJt5FVbtaz3EQ99F9MsfRPxA2nIWdBkiqScwrfO37fTcFgg2VCaCx2ISGpN/z+IcVP; 20:u+w1pHcLW7kY68Qc4u3QahwOm5zJNW1FG8Pi2rKJIWppRSUKs6IfITAFz6datj9syQHpjK1Zkq75DRqt9Ho0Lkuc8c4efWU0MA/oJScBvqbdN1zOVb6xvDdxJ9EUoSGEqIS7c8053Uoi9y7kZQL3X2o10kpRbp0Gd01846lEmew=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0773; 
x-ms-traffictypediagnostic: CY4PR21MB0773:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(3002001)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0773; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0773; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39860400002)(39380400002)(366004)(376002)(13464003)(199004)(189003)(102836004)(229853002)(9686003)(6116002)(446003)(8990500004)(5660300001)(14454004)(7696005)(8936002)(81166006)(81156014)(86362001)(8676002)(6246003)(99286004)(76176011)(476003)(68736007)(6506007)(486006)(6436002)(55016002)(53546011)(5250100002)(11346002)(6916009)(53936002)(46003)(2900100001)(106356001)(105586002)(316002)(54906003)(186003)(33656002)(86612001)(39060400002)(10290500003)(2906002)(25786009)(305945005)(7736002)(93886005)(10090500001)(97736004)(22452003)(74316002)(4326008)(3280700002)(3660700001)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0773; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: pZsZfge9HgqgRw2qs2b0fk6kKJmbulU5iN85yCUYIo80H1Kt2QsVAMD3ZG7/SZLbXSmgzSP+Ltr8XyaUOxxHdSvqDyHATc61CVx4ye+J3jeQ7G5Z0JEknRLjcQkgVP1g3yMp4OmNQgBrnXOeDqO27f+xAM+ktYdvZtA6Et6E4D7UKGyQFR6zVIIige5lXTUKxqjy69xT/yhBzGuB2n0xQ1C0g28i/Lh/QTfdDp5gmnlMEs8y+TE/D7D1/GmRbWQtqWQjjph9f1QxRqQJmw96X8YuJHt+PpcJni89vEE3NE9WNpcfXDL1boGqdE0hySD3g2PPuDYiRVZsrl97wGmwKJ7VqLi0gJO0KB1yZZ94goWjYUtIBzNMjTuhPxjMjrTE6F/VYPEa3sHBBHD90EkFHRTR9cn67DoEDnFV6eDG498=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 4f53243c-7266-42ef-c44d-08d59e7f6813
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4f53243c-7266-42ef-c44d-08d59e7f6813
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 01:07:18.5547 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0773
Cc: Praveen Balasubramanian 
Cc: IETF QUIC WG 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 01:07:23 -0000

U2luY2UgdGhlIHRleHQgaXMgdmVyYm9zZSBtYXliZSB0aGlzIHBzZXVkbyBjb2RlIGV4cGxhaW5z
IGl0IGluIGFuIGVhc3kgd2F5Og0KDQoxLiBTZXQgYmF0Y2hfc2l6ZSA9IDEyOC4gQWxsb2NhdGUg
YW4gYXJyYXkgQSBvZiAxMjggcGFja2V0IG51bWJlcnMgcGVyIGNvbm5lY3Rpb24uIFNldCBpID0g
MC4gDQoNCjIuIEZvciBnZW5lcmF0aW5nIGVhY2ggcGFja2V0DQogICAgICAgICAgICAgIElmIGkg
PCBiYXRjaF9zaXplIA0KICAgICAgICAgICAgICB7DQoJCWEuIHVzZSBGaXNoZXItWWF0ZXMgKG9y
IGVxdWl2YWxlbnQpIG9uIHRoZSBhcnJheSB0byBnZW5lcmF0ZSB0aGUgbmV4dCB1bmlxdWUgcmFu
ZG9tIG51bWJlciBSIGJldHdlZW4gInJlYWwgcGFja2V0IG51bWJlciIgYW5kICJyZWFsIHBhY2tl
dCBudW1iZXIiICsgMTI4DQoJCWIuIGkrKw0KCQljLiBzZXQgUiBhcyB0aGUgbm9uY2UgKGluIGNs
ZWFyIHBhY2tldCBudW1iZXIpIGFmdGVyIGVuY29kaW5nDQoJCWQuIHNldCAoInJlYWwgcGFja2V0
IG51bWJlciIgLSBSKSwgaS5lLiB0aGUgc3VidHJhY3Rpb24gYXMgYSBzaWduZWQgb2Zmc2V0IHZh
bHVlIE8gaW4gZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIGhlYWRlci4gTyBpcyBieSBkZWZpbml0
aW9uIDw9IDEyOCBhbmQgYXMgYSBzaWduZWQgCW51bWJlciBuZWVkcyBhdCBtb3N0IGEgYnl0ZSB0
byByZXByZXNlbnQgaW4gdGhlIHBhY2tldC4NCgkJZS4gInJlYWwgcGFja2V0IG51bWJlciIrKw0K
CQlmLiBEbyByZXN0IG9mIHN0ZXBzIG9mIGdlbmVyYXRpbmcgYSBwYWNrZXQgdGhlbiBEb25lDQog
ICAgICAgICAgICAgICB9DQoJZWxzZSANCiAgICAgICAgICAgICAgIHsNCgkJYS4gY2xlYXIgdGhl
IGFycmF5LCByZXNldCBpID0gMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiLiBnb3Rv
IDIuDQogICAgICAgICAgICAgICB9DQoNCkkgYW0gbm90IHJlYWxseSBzdXJlIHdoeSB0aGUgdHJh
bnNmb3JtZWQgUE4gd2hpY2ggYWx3YXlzIGlzIHdpdGhpbiAxMjggKG9yIGJhdGNoX3NpemUpIG51
bWJlcnMgb2YgdGhlIG9yaWdpbmFsIFBOIHdpbGwgbmVlZCBtb3JlIHNwYWNlIHRvIGVuY29kZS4g
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFp
bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIEFwcmlsIDksIDIw
MTggNTo1OCBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQu
Y29tPg0KQ2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21A
ZG1hcmMuaWV0Zi5vcmc+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS
ZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50
aW9uDQoNCk9uIFR1ZSwgQXByIDEwLCAyMDE4IGF0IDEwOjQ5IEFNLCBQcmF2ZWVuIEJhbGFzdWJy
YW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+Pj4gWW91IHdhbnQgdG8gdXNl
IGEgcGFja2V0IG51bWJlciB0aGF0IGlzIG5lYXIgdGhlIHJlYWwgcGFja2V0IG51bWJlciwgDQo+
Pj4gZW5zdXJlIHRoYXQgZWFjaCB2YWx1ZSBpcyBvbmx5IHVzZWQgb25jZSwgYW5kIGFsc28gaW5j
bHVkZSB0aGUgcmVhbCANCj4+PiBwYWNrZXQgbnVtYmVyIHVuZGVyIGVuY3J5cHRpb24NCj4gTm90
IHRoZSBlbnRpcmUgcGFja2V0IG51bWJlciwganVzdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gcmVj
b25zdHJ1Y3QgdGhlIHJlYWwgcGFja2V0IG51bWJlci4gSW4gdGhpcyBzY2hlbWUgaXQgaXMganVz
dCBhbiBleHRyYSBieXRlIGluIHRoZSBlbmNyeXB0ZWQgcG9ydGlvbiBvZiB0aGUgaGVhZGVyLiBJ
RiB0aGUgYmF0Y2ggc2l6ZSBpcyBzbWFsbGVyIHdlIGNhbiBkbyBmZXdlciBiaXRzIHBlciBwYWNr
ZXQuDQoNCklmIEkgdW5kZXJzdGFuZCB5b3VyIHNjaGVtZSwgdGhlbiB5b3UgcmVjb25zdHJ1Y3Qg
dGhlIG5vbmNlIGluIHRoZSBzYW1lIHdheSB0aGF0IHlvdSByZWNvbnN0cnVjdCB0aGUgcGFja2V0
IG51bWJlci4gIElzIHRoYXQgYSBtaXN1bmRlcnN0YW5kaW5nPyAgT3IgYXJlIHlvdSBzdWdnZXN0
aW5nIHRoYXQgdGhlcmUgaXMgYW4gZXhwbGljaXQgbm9uY2UgaW4gdGhlIHBhY2tldD8NCg0KPj4+
IHRvIHdoaWNoIHlvdSBkbyB0aGlzICJyZW9yZGVyaW5nIiB3aWxsIGFmZmVjdCB0aGUgcGVyZm9y
bWFuY2Ugb2YgdGhlIA0KPj4+IHBhY2tldCBudW1iZXIgcmVjb25zdHJ1Y3Rpb24gaW4gdGhlIGZh
Y2Ugb2YgYWN0dWFsIHJlb3JkZXJpbmcNCj4gRWFjaCBwYWNrZXQgaXMgc2VsZiBjb250YWluZWQg
YW5kIHRoZSByZWFsIFBOIGNhbiBiZSByZWNvbnN0cnVjdGVkIGp1c3QgdXNpbmcgdGhlIG9mZnNl
dCBzdG9yZWQgaW4gdGhlIGVuY3J5cHRlZCBoZWFkZXIuIEkgZG9u4oCZdCBzZWUgYW55IGlzc3Vl
cyB3aXRoIGFkZGl0aW9uYWwgbmV0d29yayBpbmR1Y2VkIHJlb3JkZXJpbmcuIFRoZXJlIGlzIG5v
IGRlcGVuZGVuY3kgYmV0d2VlbiBwYWNrZXRzIHdpdGggdGhpcyBzY2hlbWUuDQoNClRoZSBjdXJy
ZW50IGRlc2lnbiBwbGFjZXMgcmVxdWlyZW1lbnRzIG9uIHRoZSBzaXplIG9mIHRoZSB0cnVuY2F0
ZWQgcGFja2V0IG51bWJlciB0aGF0IGlzIGJhc2VkIG9uIHRoZSBleHBvc3VyZSB0byByZW9yZGVy
aW5nLiAgWW91ciBkZXNpZ24gZWZmZWN0aXZlbHkgaW5kdWNlcyByZW9yZGVyaW5nIGludG8gdGhp
cyBwcm9jZXNzLCBzbyB0aGUgbnVtYmVyIG9mIGJ5dGVzIHlvdSBzcGVuZCBvbiB0aGUgInBhY2tl
dCBudW1iZXIiIChyZWFsbHkgYSBub25jZSBpbiB5b3VyDQpkZXNpZ24pIGVuY29kaW5nIGhhcyB0
byBpbmNyZWFzZSB0byBjb21wZW5zYXRlLg0K


From nobody Mon Apr  9 18:07:37 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52261120227 for ; Mon,  9 Apr 2018 18:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 8e7p3MsNpBSV for ; Mon,  9 Apr 2018 18:07:21 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0091.outbound.protection.outlook.com [104.47.38.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E862124239 for ; Mon,  9 Apr 2018 18:07:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wDoljbTwOHgqSLAo+Cn3O4VB3F0QiERHskFdrAKgQWA=; b=cjolCd1TLVvrk72FU3l9YRuAm6XDxEYjPf5JISFfVvsXZR1zaOn/Ru4cpeexel5EUV00c1YGRn5ta3x5kkPs8pNumtv/E2WjjUqH2U/MABBtGW43uIQaYC2onHTOTJlgqdiYvkGhVsCeCxnMQsp9Gu1kckkv39L4SYIzwSCx7Ds=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0773.namprd21.prod.outlook.com (10.173.192.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.3; Tue, 10 Apr 2018 01:07:18 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Tue, 10 Apr 2018 01:07:18 +0000
From: Praveen Balasubramanian 
To: Martin Thomson 
CC: Praveen Balasubramanian , IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAH3w2AAAAjVmAAAMjZAAAADK3g
Date: Tue, 10 Apr 2018 01:07:18 +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:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0773; 7:gOr2GCVtLLxrxj+m5b2JwxnZnlq5vewfxSWbuQ4Tv/Lgta5aLgl1BTt10cnfu1XneOLwXwHR0MiI8pbgjDZlNDkTdsoYXSCbucRlya1+ZH5iJC6yQJSPOFSumbYpRQB+wn+N36NFE4WijtodUEN4T2o+xLuRUyIWs8n8+bAv6wpcsLrSIRav7TEJP5zY75UJt5FVbtaz3EQ99F9MsfRPxA2nIWdBkiqScwrfO37fTcFgg2VCaCx2ISGpN/z+IcVP; 20:u+w1pHcLW7kY68Qc4u3QahwOm5zJNW1FG8Pi2rKJIWppRSUKs6IfITAFz6datj9syQHpjK1Zkq75DRqt9Ho0Lkuc8c4efWU0MA/oJScBvqbdN1zOVb6xvDdxJ9EUoSGEqIS7c8053Uoi9y7kZQL3X2o10kpRbp0Gd01846lEmew=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0773; 
x-ms-traffictypediagnostic: CY4PR21MB0773:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(3002001)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0773; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0773; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39860400002)(39380400002)(366004)(376002)(13464003)(199004)(189003)(102836004)(229853002)(9686003)(6116002)(446003)(8990500004)(5660300001)(14454004)(7696005)(8936002)(81166006)(81156014)(86362001)(8676002)(6246003)(99286004)(76176011)(476003)(68736007)(6506007)(486006)(6436002)(55016002)(53546011)(5250100002)(11346002)(6916009)(53936002)(46003)(2900100001)(106356001)(105586002)(316002)(54906003)(186003)(33656002)(86612001)(39060400002)(10290500003)(2906002)(25786009)(305945005)(7736002)(93886005)(10090500001)(97736004)(22452003)(74316002)(4326008)(3280700002)(3660700001)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0773; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: pZsZfge9HgqgRw2qs2b0fk6kKJmbulU5iN85yCUYIo80H1Kt2QsVAMD3ZG7/SZLbXSmgzSP+Ltr8XyaUOxxHdSvqDyHATc61CVx4ye+J3jeQ7G5Z0JEknRLjcQkgVP1g3yMp4OmNQgBrnXOeDqO27f+xAM+ktYdvZtA6Et6E4D7UKGyQFR6zVIIige5lXTUKxqjy69xT/yhBzGuB2n0xQ1C0g28i/Lh/QTfdDp5gmnlMEs8y+TE/D7D1/GmRbWQtqWQjjph9f1QxRqQJmw96X8YuJHt+PpcJni89vEE3NE9WNpcfXDL1boGqdE0hySD3g2PPuDYiRVZsrl97wGmwKJ7VqLi0gJO0KB1yZZ94goWjYUtIBzNMjTuhPxjMjrTE6F/VYPEa3sHBBHD90EkFHRTR9cn67DoEDnFV6eDG498=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 4f53243c-7266-42ef-c44d-08d59e7f6813
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4f53243c-7266-42ef-c44d-08d59e7f6813
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 01:07:18.5547 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0773
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 01:07:23 -0000

U2luY2UgdGhlIHRleHQgaXMgdmVyYm9zZSBtYXliZSB0aGlzIHBzZXVkbyBjb2RlIGV4cGxhaW5z
IGl0IGluIGFuIGVhc3kgd2F5Og0KDQoxLiBTZXQgYmF0Y2hfc2l6ZSA9IDEyOC4gQWxsb2NhdGUg
YW4gYXJyYXkgQSBvZiAxMjggcGFja2V0IG51bWJlcnMgcGVyIGNvbm5lY3Rpb24uIFNldCBpID0g
MC4gDQoNCjIuIEZvciBnZW5lcmF0aW5nIGVhY2ggcGFja2V0DQogICAgICAgICAgICAgIElmIGkg
PCBiYXRjaF9zaXplIA0KICAgICAgICAgICAgICB7DQoJCWEuIHVzZSBGaXNoZXItWWF0ZXMgKG9y
IGVxdWl2YWxlbnQpIG9uIHRoZSBhcnJheSB0byBnZW5lcmF0ZSB0aGUgbmV4dCB1bmlxdWUgcmFu
ZG9tIG51bWJlciBSIGJldHdlZW4gInJlYWwgcGFja2V0IG51bWJlciIgYW5kICJyZWFsIHBhY2tl
dCBudW1iZXIiICsgMTI4DQoJCWIuIGkrKw0KCQljLiBzZXQgUiBhcyB0aGUgbm9uY2UgKGluIGNs
ZWFyIHBhY2tldCBudW1iZXIpIGFmdGVyIGVuY29kaW5nDQoJCWQuIHNldCAoInJlYWwgcGFja2V0
IG51bWJlciIgLSBSKSwgaS5lLiB0aGUgc3VidHJhY3Rpb24gYXMgYSBzaWduZWQgb2Zmc2V0IHZh
bHVlIE8gaW4gZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIGhlYWRlci4gTyBpcyBieSBkZWZpbml0
aW9uIDw9IDEyOCBhbmQgYXMgYSBzaWduZWQgCW51bWJlciBuZWVkcyBhdCBtb3N0IGEgYnl0ZSB0
byByZXByZXNlbnQgaW4gdGhlIHBhY2tldC4NCgkJZS4gInJlYWwgcGFja2V0IG51bWJlciIrKw0K
CQlmLiBEbyByZXN0IG9mIHN0ZXBzIG9mIGdlbmVyYXRpbmcgYSBwYWNrZXQgdGhlbiBEb25lDQog
ICAgICAgICAgICAgICB9DQoJZWxzZSANCiAgICAgICAgICAgICAgIHsNCgkJYS4gY2xlYXIgdGhl
IGFycmF5LCByZXNldCBpID0gMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiLiBnb3Rv
IDIuDQogICAgICAgICAgICAgICB9DQoNCkkgYW0gbm90IHJlYWxseSBzdXJlIHdoeSB0aGUgdHJh
bnNmb3JtZWQgUE4gd2hpY2ggYWx3YXlzIGlzIHdpdGhpbiAxMjggKG9yIGJhdGNoX3NpemUpIG51
bWJlcnMgb2YgdGhlIG9yaWdpbmFsIFBOIHdpbGwgbmVlZCBtb3JlIHNwYWNlIHRvIGVuY29kZS4g
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFp
bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIEFwcmlsIDksIDIw
MTggNTo1OCBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQu
Y29tPg0KQ2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21A
ZG1hcmMuaWV0Zi5vcmc+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS
ZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50
aW9uDQoNCk9uIFR1ZSwgQXByIDEwLCAyMDE4IGF0IDEwOjQ5IEFNLCBQcmF2ZWVuIEJhbGFzdWJy
YW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+Pj4gWW91IHdhbnQgdG8gdXNl
IGEgcGFja2V0IG51bWJlciB0aGF0IGlzIG5lYXIgdGhlIHJlYWwgcGFja2V0IG51bWJlciwgDQo+
Pj4gZW5zdXJlIHRoYXQgZWFjaCB2YWx1ZSBpcyBvbmx5IHVzZWQgb25jZSwgYW5kIGFsc28gaW5j
bHVkZSB0aGUgcmVhbCANCj4+PiBwYWNrZXQgbnVtYmVyIHVuZGVyIGVuY3J5cHRpb24NCj4gTm90
IHRoZSBlbnRpcmUgcGFja2V0IG51bWJlciwganVzdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gcmVj
b25zdHJ1Y3QgdGhlIHJlYWwgcGFja2V0IG51bWJlci4gSW4gdGhpcyBzY2hlbWUgaXQgaXMganVz
dCBhbiBleHRyYSBieXRlIGluIHRoZSBlbmNyeXB0ZWQgcG9ydGlvbiBvZiB0aGUgaGVhZGVyLiBJ
RiB0aGUgYmF0Y2ggc2l6ZSBpcyBzbWFsbGVyIHdlIGNhbiBkbyBmZXdlciBiaXRzIHBlciBwYWNr
ZXQuDQoNCklmIEkgdW5kZXJzdGFuZCB5b3VyIHNjaGVtZSwgdGhlbiB5b3UgcmVjb25zdHJ1Y3Qg
dGhlIG5vbmNlIGluIHRoZSBzYW1lIHdheSB0aGF0IHlvdSByZWNvbnN0cnVjdCB0aGUgcGFja2V0
IG51bWJlci4gIElzIHRoYXQgYSBtaXN1bmRlcnN0YW5kaW5nPyAgT3IgYXJlIHlvdSBzdWdnZXN0
aW5nIHRoYXQgdGhlcmUgaXMgYW4gZXhwbGljaXQgbm9uY2UgaW4gdGhlIHBhY2tldD8NCg0KPj4+
IHRvIHdoaWNoIHlvdSBkbyB0aGlzICJyZW9yZGVyaW5nIiB3aWxsIGFmZmVjdCB0aGUgcGVyZm9y
bWFuY2Ugb2YgdGhlIA0KPj4+IHBhY2tldCBudW1iZXIgcmVjb25zdHJ1Y3Rpb24gaW4gdGhlIGZh
Y2Ugb2YgYWN0dWFsIHJlb3JkZXJpbmcNCj4gRWFjaCBwYWNrZXQgaXMgc2VsZiBjb250YWluZWQg
YW5kIHRoZSByZWFsIFBOIGNhbiBiZSByZWNvbnN0cnVjdGVkIGp1c3QgdXNpbmcgdGhlIG9mZnNl
dCBzdG9yZWQgaW4gdGhlIGVuY3J5cHRlZCBoZWFkZXIuIEkgZG9u4oCZdCBzZWUgYW55IGlzc3Vl
cyB3aXRoIGFkZGl0aW9uYWwgbmV0d29yayBpbmR1Y2VkIHJlb3JkZXJpbmcuIFRoZXJlIGlzIG5v
IGRlcGVuZGVuY3kgYmV0d2VlbiBwYWNrZXRzIHdpdGggdGhpcyBzY2hlbWUuDQoNClRoZSBjdXJy
ZW50IGRlc2lnbiBwbGFjZXMgcmVxdWlyZW1lbnRzIG9uIHRoZSBzaXplIG9mIHRoZSB0cnVuY2F0
ZWQgcGFja2V0IG51bWJlciB0aGF0IGlzIGJhc2VkIG9uIHRoZSBleHBvc3VyZSB0byByZW9yZGVy
aW5nLiAgWW91ciBkZXNpZ24gZWZmZWN0aXZlbHkgaW5kdWNlcyByZW9yZGVyaW5nIGludG8gdGhp
cyBwcm9jZXNzLCBzbyB0aGUgbnVtYmVyIG9mIGJ5dGVzIHlvdSBzcGVuZCBvbiB0aGUgInBhY2tl
dCBudW1iZXIiIChyZWFsbHkgYSBub25jZSBpbiB5b3VyDQpkZXNpZ24pIGVuY29kaW5nIGhhcyB0
byBpbmNyZWFzZSB0byBjb21wZW5zYXRlLg0K


From nobody Mon Apr  9 18:12:03 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 138B6126C0F for ; Mon,  9 Apr 2018 18:12:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523322722; bh=HoBJimqO1HTZ2PHM1E1w7baw241PUM71csaOnzVhHyU=; h=From:To:Subject:Date:References:In-Reply-To:Cc:Cc; b=sgkJ/NJbcrX+wOCaw9gnG2btxgrMVi4S/c0cn/OlZWa46ZWgCie0TIk6iOQUkAF5E vpW2CbC5HD5F2cMymDz5+WBoUlEMTQ0g6ev/jrxcMo4ZkSGYGvyLwtevm+OeAu/Mt4 Qt5X65rpFoXMk0MgJqrTe6bqDFlBk4sgAlXWyyh0=
X-Mailbox-Line: From pravb@microsoft.com  Mon Apr  9 18:12:01 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE232120227; Mon,  9 Apr 2018 18:12:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523322721; bh=HoBJimqO1HTZ2PHM1E1w7baw241PUM71csaOnzVhHyU=; h=From:To:Subject:Date:References:In-Reply-To:Cc:Cc; b=O+tNH6PVi+bq4Wy3S7pKtW30rtEfXFyziAV55LZmc8xYnoUGOBRN4Hoy5RUQ0yXIJ 2daluGrS5nrxjJdRFO+UWSVuSgjGKh7prJmEZGcq4nwizXfUd0CrkvlK/ftWoqw0WM yBqYPs8C+wk6K0uYDCr+kG3pmex1Cno4c15USds4=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22AF126B72 for ; Mon,  9 Apr 2018 18:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 HgzGt8yMLpqe for ; Mon,  9 Apr 2018 18:11:59 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe44::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62076120227 for ; Mon,  9 Apr 2018 18:11:59 -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=HoBJimqO1HTZ2PHM1E1w7baw241PUM71csaOnzVhHyU=; b=hloNwe27TSstJDnt5RUYObheDhoTKOsk74hXWT5bIbnMn3pDTwh8cffKcbScONV4ySUus6x+dly1GZm56x5eFEBQult45icp3ixKWMF3bEwCWbFtapRJVg9+pHwg774kf0zpi0/0nuf4r11e6b4CSAYNjKh6vrFvErU4GX2a/4M=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.2; Tue, 10 Apr 2018 01:11:57 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Tue, 10 Apr 2018 01:11:57 +0000
From: Praveen Balasubramanian 
To: Martin Thomson 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAH3w2AAAAjVmAAAMjZAAAADK3gAABh4DA=
Date: Tue, 10 Apr 2018 01:11: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: [2001:4898:80e8:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0630; 7:hGq8r5qC9IavG2E+uDvACSgD1UlGIOxViLSOoo27XLfriZmCd9tGkb6OWCrvGDiatnaNJYlYApcI43+IPNaSRcao00ixVX3mkaGPRRmBHHIp1K9ZAydvf5jpFMCfNoq8RyuGHgU9l0Qrtoh+N2u82ocgLI+QPnFEKXrZ/hx1qoot2SiUzJ85sWIJUrpQ5atyvCLoh2gT8ktCQtaOI/nku4nhTEmRtLxruKJPhqobQFf1ELpQFxavbsDqarb9ni+6; 20:CCyM0OSaOdIS+BVeZfZGlOX4jA8hKc05lpvtpc32UPv2NX/5wteD9Q7u1D8Cr5OajbHONlQJBbnuK89b1sjPEGqpjBqSBKD2ulGVT4c0M75IPXzp3ONXX/h94E3OIEuoy2fuAPIqNcNOfYImFgXAhNLuAEj8Ez9g04x8V9H6Uxc=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0630; 
x-ms-traffictypediagnostic: CY4PR21MB0630:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0630; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0630; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(39860400002)(396003)(39380400002)(199004)(189003)(13464003)(486006)(6116002)(99286004)(14454004)(3660700001)(68736007)(3280700002)(478600001)(76176011)(97736004)(7696005)(10290500003)(33656002)(53546011)(186003)(446003)(2900100001)(6506007)(2906002)(102836004)(46003)(11346002)(476003)(106356001)(8676002)(25786009)(9686003)(316002)(22452003)(2940100002)(86362001)(4326008)(81156014)(81166006)(55016002)(5250100002)(8936002)(6246003)(39060400002)(5660300001)(6916009)(305945005)(10090500001)(53936002)(74316002)(105586002)(54906003)(93886005)(229853002)(86612001)(7736002)(8990500004)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0630; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: qeHcMQvQDLS6WNQsFUFyTpg/05XdRatfz8eUGgaFr4w7VN0eso/yk5Npb7sdpzVZNxfpHwIFn5GluhaEvSVFak4jj5Sp2dqfFDFIv7M1cvanhUZ423fk4IxTSWQrNSbZAO+FjQFFwVBH866LA3FUIsrXgDcIkxdWA2bO6Gojpv+wA7ZOflbpN7vxVb9M6AFtChqgV9zYzK7okh1CUthd1fGRd73GkIaG1+eQGgbeAzNfgVGhCfQ6RuHM5Rde1OHcOnJjsUYv+NjuCfyi9KhJVD3wg2nsudGA997wvhgnelYGD4tIJWAQVXevNZnl7GugF+a7+nCWtOBPHEyBzFzaICLyBs/cqYAZ0od1ZqiCkl/UbLQf1DtERziFkY2AhhTTYDCF1gUt6Ct7CkVuQglReJFjo1asRKLqQ/OPHvuaZM8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 1938c96b-afc9-4e80-c8d0-08d59e800e57
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1938c96b-afc9-4e80-c8d0-08d59e800e57
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 01:11:57.5179 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0630
Cc: Praveen Balasubramanian 
Cc: IETF QUIC WG 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 01:12:02 -0000

SW5jbHVkaW5nIHJlY2VpdmVyIHBzZXVkbyBjb2RlIGZvciBjb21wbGV0ZW5lc3M6DQoNCk9uIHJl
Y2VpdmluZyBwYWNrZXQ6DQoxLiBEZWNyeXB0IHBhY2tldCB1c2luZyBkZWNvZGVkIG5vbmNlIFIu
IFRoZSB2YWx1ZSBPIHdpbGwgbm93IGJlIGF2YWlsYWJsZS4gDQoyLiBDYWxjdWxhdGUgInJlYWwg
cGFja2V0IG51bWJlciIgPSBSICsgTy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIA0KU2VudDogTW9uZGF5LCBBcHJpbCA5LCAyMDE4
IDY6MDcgUE0NClRvOiAnTWFydGluIFRob21zb24nIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+
DQpDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFy
Yy5pZXRmLm9yZz47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBT
aW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24N
Cg0KU2luY2UgdGhlIHRleHQgaXMgdmVyYm9zZSBtYXliZSB0aGlzIHBzZXVkbyBjb2RlIGV4cGxh
aW5zIGl0IGluIGFuIGVhc3kgd2F5Og0KDQoxLiBTZXQgYmF0Y2hfc2l6ZSA9IDEyOC4gQWxsb2Nh
dGUgYW4gYXJyYXkgQSBvZiAxMjggcGFja2V0IG51bWJlcnMgcGVyIGNvbm5lY3Rpb24uIFNldCBp
ID0gMC4gDQoNCjIuIEZvciBnZW5lcmF0aW5nIGVhY2ggcGFja2V0DQogICAgICAgICAgICAgIElm
IGkgPCBiYXRjaF9zaXplIA0KICAgICAgICAgICAgICB7DQoJCWEuIHVzZSBGaXNoZXItWWF0ZXMg
KG9yIGVxdWl2YWxlbnQpIG9uIHRoZSBhcnJheSB0byBnZW5lcmF0ZSB0aGUgbmV4dCB1bmlxdWUg
cmFuZG9tIG51bWJlciBSIGJldHdlZW4gInJlYWwgcGFja2V0IG51bWJlciIgYW5kICJyZWFsIHBh
Y2tldCBudW1iZXIiICsgMTI4DQoJCWIuIGkrKw0KCQljLiBzZXQgUiBhcyB0aGUgbm9uY2UgKGlu
IGNsZWFyIHBhY2tldCBudW1iZXIpIGFmdGVyIGVuY29kaW5nDQoJCWQuIHNldCAoInJlYWwgcGFj
a2V0IG51bWJlciIgLSBSKSwgaS5lLiB0aGUgc3VidHJhY3Rpb24gYXMgYSBzaWduZWQgb2Zmc2V0
IHZhbHVlIE8gaW4gZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIGhlYWRlci4gTyBpcyBieSBkZWZp
bml0aW9uIDw9IDEyOCBhbmQgYXMgYSBzaWduZWQgCW51bWJlciBuZWVkcyBhdCBtb3N0IGEgYnl0
ZSB0byByZXByZXNlbnQgaW4gdGhlIHBhY2tldC4NCgkJZS4gInJlYWwgcGFja2V0IG51bWJlciIr
Kw0KCQlmLiBEbyByZXN0IG9mIHN0ZXBzIG9mIGdlbmVyYXRpbmcgYSBwYWNrZXQgdGhlbiBEb25l
DQogICAgICAgICAgICAgICB9DQoJZWxzZSANCiAgICAgICAgICAgICAgIHsNCgkJYS4gY2xlYXIg
dGhlIGFycmF5LCByZXNldCBpID0gMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiLiBn
b3RvIDIuDQogICAgICAgICAgICAgICB9DQoNCkkgYW0gbm90IHJlYWxseSBzdXJlIHdoeSB0aGUg
dHJhbnNmb3JtZWQgUE4gd2hpY2ggYWx3YXlzIGlzIHdpdGhpbiAxMjggKG9yIGJhdGNoX3NpemUp
IG51bWJlcnMgb2YgdGhlIG9yaWdpbmFsIFBOIHdpbGwgbmVlZCBtb3JlIHNwYWNlIHRvIGVuY29k
ZS4gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBb
bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgQXByaWwgOSwg
MjAxOCA1OjU4IFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29m
dC5jb20+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiPTQwbWljcm9zb2Z0LmNv
bUBkbWFyYy5pZXRmLm9yZz47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6
IFJlOiBTaW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZl
bnRpb24NCg0KT24gVHVlLCBBcHIgMTAsIDIwMTggYXQgMTA6NDkgQU0sIFByYXZlZW4gQmFsYXN1
YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4+PiBZb3Ugd2FudCB0byB1
c2UgYSBwYWNrZXQgbnVtYmVyIHRoYXQgaXMgbmVhciB0aGUgcmVhbCBwYWNrZXQgbnVtYmVyLCAN
Cj4+PiBlbnN1cmUgdGhhdCBlYWNoIHZhbHVlIGlzIG9ubHkgdXNlZCBvbmNlLCBhbmQgYWxzbyBp
bmNsdWRlIHRoZSByZWFsIA0KPj4+IHBhY2tldCBudW1iZXIgdW5kZXIgZW5jcnlwdGlvbg0KPiBO
b3QgdGhlIGVudGlyZSBwYWNrZXQgbnVtYmVyLCBqdXN0IGVub3VnaCBpbmZvcm1hdGlvbiB0byBy
ZWNvbnN0cnVjdCB0aGUgcmVhbCBwYWNrZXQgbnVtYmVyLiBJbiB0aGlzIHNjaGVtZSBpdCBpcyBq
dXN0IGFuIGV4dHJhIGJ5dGUgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBoZWFkZXIu
IElGIHRoZSBiYXRjaCBzaXplIGlzIHNtYWxsZXIgd2UgY2FuIGRvIGZld2VyIGJpdHMgcGVyIHBh
Y2tldC4NCg0KSWYgSSB1bmRlcnN0YW5kIHlvdXIgc2NoZW1lLCB0aGVuIHlvdSByZWNvbnN0cnVj
dCB0aGUgbm9uY2UgaW4gdGhlIHNhbWUgd2F5IHRoYXQgeW91IHJlY29uc3RydWN0IHRoZSBwYWNr
ZXQgbnVtYmVyLiAgSXMgdGhhdCBhIG1pc3VuZGVyc3RhbmRpbmc/ICBPciBhcmUgeW91IHN1Z2dl
c3RpbmcgdGhhdCB0aGVyZSBpcyBhbiBleHBsaWNpdCBub25jZSBpbiB0aGUgcGFja2V0Pw0KDQo+
Pj4gdG8gd2hpY2ggeW91IGRvIHRoaXMgInJlb3JkZXJpbmciIHdpbGwgYWZmZWN0IHRoZSBwZXJm
b3JtYW5jZSBvZiB0aGUgDQo+Pj4gcGFja2V0IG51bWJlciByZWNvbnN0cnVjdGlvbiBpbiB0aGUg
ZmFjZSBvZiBhY3R1YWwgcmVvcmRlcmluZw0KPiBFYWNoIHBhY2tldCBpcyBzZWxmIGNvbnRhaW5l
ZCBhbmQgdGhlIHJlYWwgUE4gY2FuIGJlIHJlY29uc3RydWN0ZWQganVzdCB1c2luZyB0aGUgb2Zm
c2V0IHN0b3JlZCBpbiB0aGUgZW5jcnlwdGVkIGhlYWRlci4gSSBkb27igJl0IHNlZSBhbnkgaXNz
dWVzIHdpdGggYWRkaXRpb25hbCBuZXR3b3JrIGluZHVjZWQgcmVvcmRlcmluZy4gVGhlcmUgaXMg
bm8gZGVwZW5kZW5jeSBiZXR3ZWVuIHBhY2tldHMgd2l0aCB0aGlzIHNjaGVtZS4NCg0KVGhlIGN1
cnJlbnQgZGVzaWduIHBsYWNlcyByZXF1aXJlbWVudHMgb24gdGhlIHNpemUgb2YgdGhlIHRydW5j
YXRlZCBwYWNrZXQgbnVtYmVyIHRoYXQgaXMgYmFzZWQgb24gdGhlIGV4cG9zdXJlIHRvIHJlb3Jk
ZXJpbmcuICBZb3VyIGRlc2lnbiBlZmZlY3RpdmVseSBpbmR1Y2VzIHJlb3JkZXJpbmcgaW50byB0
aGlzIHByb2Nlc3MsIHNvIHRoZSBudW1iZXIgb2YgYnl0ZXMgeW91IHNwZW5kIG9uIHRoZSAicGFj
a2V0IG51bWJlciIgKHJlYWxseSBhIG5vbmNlIGluIHlvdXINCmRlc2lnbikgZW5jb2RpbmcgaGFz
IHRvIGluY3JlYXNlIHRvIGNvbXBlbnNhdGUuDQo=


From nobody Mon Apr  9 18:12:08 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CB112D86E for ; Mon,  9 Apr 2018 18:12:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 8RvaG2Sz3Dlx for ; Mon,  9 Apr 2018 18:11:59 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0130.outbound.protection.outlook.com [104.47.36.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5653C1201F8 for ; Mon,  9 Apr 2018 18:11:59 -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=HoBJimqO1HTZ2PHM1E1w7baw241PUM71csaOnzVhHyU=; b=hloNwe27TSstJDnt5RUYObheDhoTKOsk74hXWT5bIbnMn3pDTwh8cffKcbScONV4ySUus6x+dly1GZm56x5eFEBQult45icp3ixKWMF3bEwCWbFtapRJVg9+pHwg774kf0zpi0/0nuf4r11e6b4CSAYNjKh6vrFvErU4GX2a/4M=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.2; Tue, 10 Apr 2018 01:11:57 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Tue, 10 Apr 2018 01:11:57 +0000
From: Praveen Balasubramanian 
To: Martin Thomson 
CC: Praveen Balasubramanian , IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAH3w2AAAAjVmAAAMjZAAAADK3gAABh4DA=
Date: Tue, 10 Apr 2018 01:11: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: [2001:4898:80e8:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0630; 7:hGq8r5qC9IavG2E+uDvACSgD1UlGIOxViLSOoo27XLfriZmCd9tGkb6OWCrvGDiatnaNJYlYApcI43+IPNaSRcao00ixVX3mkaGPRRmBHHIp1K9ZAydvf5jpFMCfNoq8RyuGHgU9l0Qrtoh+N2u82ocgLI+QPnFEKXrZ/hx1qoot2SiUzJ85sWIJUrpQ5atyvCLoh2gT8ktCQtaOI/nku4nhTEmRtLxruKJPhqobQFf1ELpQFxavbsDqarb9ni+6; 20:CCyM0OSaOdIS+BVeZfZGlOX4jA8hKc05lpvtpc32UPv2NX/5wteD9Q7u1D8Cr5OajbHONlQJBbnuK89b1sjPEGqpjBqSBKD2ulGVT4c0M75IPXzp3ONXX/h94E3OIEuoy2fuAPIqNcNOfYImFgXAhNLuAEj8Ez9g04x8V9H6Uxc=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0630; 
x-ms-traffictypediagnostic: CY4PR21MB0630:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0630; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0630; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(39860400002)(396003)(39380400002)(199004)(189003)(13464003)(486006)(6116002)(99286004)(14454004)(3660700001)(68736007)(3280700002)(478600001)(76176011)(97736004)(7696005)(10290500003)(33656002)(53546011)(186003)(446003)(2900100001)(6506007)(2906002)(102836004)(46003)(11346002)(476003)(106356001)(8676002)(25786009)(9686003)(316002)(22452003)(2940100002)(86362001)(4326008)(81156014)(81166006)(55016002)(5250100002)(8936002)(6246003)(39060400002)(5660300001)(6916009)(305945005)(10090500001)(53936002)(74316002)(105586002)(54906003)(93886005)(229853002)(86612001)(7736002)(8990500004)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0630; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: qeHcMQvQDLS6WNQsFUFyTpg/05XdRatfz8eUGgaFr4w7VN0eso/yk5Npb7sdpzVZNxfpHwIFn5GluhaEvSVFak4jj5Sp2dqfFDFIv7M1cvanhUZ423fk4IxTSWQrNSbZAO+FjQFFwVBH866LA3FUIsrXgDcIkxdWA2bO6Gojpv+wA7ZOflbpN7vxVb9M6AFtChqgV9zYzK7okh1CUthd1fGRd73GkIaG1+eQGgbeAzNfgVGhCfQ6RuHM5Rde1OHcOnJjsUYv+NjuCfyi9KhJVD3wg2nsudGA997wvhgnelYGD4tIJWAQVXevNZnl7GugF+a7+nCWtOBPHEyBzFzaICLyBs/cqYAZ0od1ZqiCkl/UbLQf1DtERziFkY2AhhTTYDCF1gUt6Ct7CkVuQglReJFjo1asRKLqQ/OPHvuaZM8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 1938c96b-afc9-4e80-c8d0-08d59e800e57
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1938c96b-afc9-4e80-c8d0-08d59e800e57
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 01:11:57.5179 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0630
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 01:12:02 -0000

SW5jbHVkaW5nIHJlY2VpdmVyIHBzZXVkbyBjb2RlIGZvciBjb21wbGV0ZW5lc3M6DQoNCk9uIHJl
Y2VpdmluZyBwYWNrZXQ6DQoxLiBEZWNyeXB0IHBhY2tldCB1c2luZyBkZWNvZGVkIG5vbmNlIFIu
IFRoZSB2YWx1ZSBPIHdpbGwgbm93IGJlIGF2YWlsYWJsZS4gDQoyLiBDYWxjdWxhdGUgInJlYWwg
cGFja2V0IG51bWJlciIgPSBSICsgTy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIA0KU2VudDogTW9uZGF5LCBBcHJpbCA5LCAyMDE4
IDY6MDcgUE0NClRvOiAnTWFydGluIFRob21zb24nIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+
DQpDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFy
Yy5pZXRmLm9yZz47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBT
aW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24N
Cg0KU2luY2UgdGhlIHRleHQgaXMgdmVyYm9zZSBtYXliZSB0aGlzIHBzZXVkbyBjb2RlIGV4cGxh
aW5zIGl0IGluIGFuIGVhc3kgd2F5Og0KDQoxLiBTZXQgYmF0Y2hfc2l6ZSA9IDEyOC4gQWxsb2Nh
dGUgYW4gYXJyYXkgQSBvZiAxMjggcGFja2V0IG51bWJlcnMgcGVyIGNvbm5lY3Rpb24uIFNldCBp
ID0gMC4gDQoNCjIuIEZvciBnZW5lcmF0aW5nIGVhY2ggcGFja2V0DQogICAgICAgICAgICAgIElm
IGkgPCBiYXRjaF9zaXplIA0KICAgICAgICAgICAgICB7DQoJCWEuIHVzZSBGaXNoZXItWWF0ZXMg
KG9yIGVxdWl2YWxlbnQpIG9uIHRoZSBhcnJheSB0byBnZW5lcmF0ZSB0aGUgbmV4dCB1bmlxdWUg
cmFuZG9tIG51bWJlciBSIGJldHdlZW4gInJlYWwgcGFja2V0IG51bWJlciIgYW5kICJyZWFsIHBh
Y2tldCBudW1iZXIiICsgMTI4DQoJCWIuIGkrKw0KCQljLiBzZXQgUiBhcyB0aGUgbm9uY2UgKGlu
IGNsZWFyIHBhY2tldCBudW1iZXIpIGFmdGVyIGVuY29kaW5nDQoJCWQuIHNldCAoInJlYWwgcGFj
a2V0IG51bWJlciIgLSBSKSwgaS5lLiB0aGUgc3VidHJhY3Rpb24gYXMgYSBzaWduZWQgb2Zmc2V0
IHZhbHVlIE8gaW4gZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIGhlYWRlci4gTyBpcyBieSBkZWZp
bml0aW9uIDw9IDEyOCBhbmQgYXMgYSBzaWduZWQgCW51bWJlciBuZWVkcyBhdCBtb3N0IGEgYnl0
ZSB0byByZXByZXNlbnQgaW4gdGhlIHBhY2tldC4NCgkJZS4gInJlYWwgcGFja2V0IG51bWJlciIr
Kw0KCQlmLiBEbyByZXN0IG9mIHN0ZXBzIG9mIGdlbmVyYXRpbmcgYSBwYWNrZXQgdGhlbiBEb25l
DQogICAgICAgICAgICAgICB9DQoJZWxzZSANCiAgICAgICAgICAgICAgIHsNCgkJYS4gY2xlYXIg
dGhlIGFycmF5LCByZXNldCBpID0gMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiLiBn
b3RvIDIuDQogICAgICAgICAgICAgICB9DQoNCkkgYW0gbm90IHJlYWxseSBzdXJlIHdoeSB0aGUg
dHJhbnNmb3JtZWQgUE4gd2hpY2ggYWx3YXlzIGlzIHdpdGhpbiAxMjggKG9yIGJhdGNoX3NpemUp
IG51bWJlcnMgb2YgdGhlIG9yaWdpbmFsIFBOIHdpbGwgbmVlZCBtb3JlIHNwYWNlIHRvIGVuY29k
ZS4gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBb
bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgQXByaWwgOSwg
MjAxOCA1OjU4IFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29m
dC5jb20+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiPTQwbWljcm9zb2Z0LmNv
bUBkbWFyYy5pZXRmLm9yZz47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6
IFJlOiBTaW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZl
bnRpb24NCg0KT24gVHVlLCBBcHIgMTAsIDIwMTggYXQgMTA6NDkgQU0sIFByYXZlZW4gQmFsYXN1
YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4+PiBZb3Ugd2FudCB0byB1
c2UgYSBwYWNrZXQgbnVtYmVyIHRoYXQgaXMgbmVhciB0aGUgcmVhbCBwYWNrZXQgbnVtYmVyLCAN
Cj4+PiBlbnN1cmUgdGhhdCBlYWNoIHZhbHVlIGlzIG9ubHkgdXNlZCBvbmNlLCBhbmQgYWxzbyBp
bmNsdWRlIHRoZSByZWFsIA0KPj4+IHBhY2tldCBudW1iZXIgdW5kZXIgZW5jcnlwdGlvbg0KPiBO
b3QgdGhlIGVudGlyZSBwYWNrZXQgbnVtYmVyLCBqdXN0IGVub3VnaCBpbmZvcm1hdGlvbiB0byBy
ZWNvbnN0cnVjdCB0aGUgcmVhbCBwYWNrZXQgbnVtYmVyLiBJbiB0aGlzIHNjaGVtZSBpdCBpcyBq
dXN0IGFuIGV4dHJhIGJ5dGUgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBoZWFkZXIu
IElGIHRoZSBiYXRjaCBzaXplIGlzIHNtYWxsZXIgd2UgY2FuIGRvIGZld2VyIGJpdHMgcGVyIHBh
Y2tldC4NCg0KSWYgSSB1bmRlcnN0YW5kIHlvdXIgc2NoZW1lLCB0aGVuIHlvdSByZWNvbnN0cnVj
dCB0aGUgbm9uY2UgaW4gdGhlIHNhbWUgd2F5IHRoYXQgeW91IHJlY29uc3RydWN0IHRoZSBwYWNr
ZXQgbnVtYmVyLiAgSXMgdGhhdCBhIG1pc3VuZGVyc3RhbmRpbmc/ICBPciBhcmUgeW91IHN1Z2dl
c3RpbmcgdGhhdCB0aGVyZSBpcyBhbiBleHBsaWNpdCBub25jZSBpbiB0aGUgcGFja2V0Pw0KDQo+
Pj4gdG8gd2hpY2ggeW91IGRvIHRoaXMgInJlb3JkZXJpbmciIHdpbGwgYWZmZWN0IHRoZSBwZXJm
b3JtYW5jZSBvZiB0aGUgDQo+Pj4gcGFja2V0IG51bWJlciByZWNvbnN0cnVjdGlvbiBpbiB0aGUg
ZmFjZSBvZiBhY3R1YWwgcmVvcmRlcmluZw0KPiBFYWNoIHBhY2tldCBpcyBzZWxmIGNvbnRhaW5l
ZCBhbmQgdGhlIHJlYWwgUE4gY2FuIGJlIHJlY29uc3RydWN0ZWQganVzdCB1c2luZyB0aGUgb2Zm
c2V0IHN0b3JlZCBpbiB0aGUgZW5jcnlwdGVkIGhlYWRlci4gSSBkb27igJl0IHNlZSBhbnkgaXNz
dWVzIHdpdGggYWRkaXRpb25hbCBuZXR3b3JrIGluZHVjZWQgcmVvcmRlcmluZy4gVGhlcmUgaXMg
bm8gZGVwZW5kZW5jeSBiZXR3ZWVuIHBhY2tldHMgd2l0aCB0aGlzIHNjaGVtZS4NCg0KVGhlIGN1
cnJlbnQgZGVzaWduIHBsYWNlcyByZXF1aXJlbWVudHMgb24gdGhlIHNpemUgb2YgdGhlIHRydW5j
YXRlZCBwYWNrZXQgbnVtYmVyIHRoYXQgaXMgYmFzZWQgb24gdGhlIGV4cG9zdXJlIHRvIHJlb3Jk
ZXJpbmcuICBZb3VyIGRlc2lnbiBlZmZlY3RpdmVseSBpbmR1Y2VzIHJlb3JkZXJpbmcgaW50byB0
aGlzIHByb2Nlc3MsIHNvIHRoZSBudW1iZXIgb2YgYnl0ZXMgeW91IHNwZW5kIG9uIHRoZSAicGFj
a2V0IG51bWJlciIgKHJlYWxseSBhIG5vbmNlIGluIHlvdXINCmRlc2lnbikgZW5jb2RpbmcgaGFz
IHRvIGluY3JlYXNlIHRvIGNvbXBlbnNhdGUuDQo=


From nobody Mon Apr  9 18:22:12 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E5F12D86E for ; Mon,  9 Apr 2018 18:22:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523323330; bh=1zAsZhSQcqt6BU56WhfXHH5MydPF6wlO1n6WzAv3Szo=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=C2qTGMy7TpOenkxBf55zcL0yKyDnI8i7nbyT6q426apVpLVVbTIumZZhdBK/KyqN2 0AyGT/6X8Jd4kSDPPBNlaIVLGE6+csD7Nv7P8tNnvI/+nTy2ZmdZ9PrY54QhEURDlQ /0XR5hkpH/OYIQM6svNwWkR+X/b8fq07L1Rw6QCw=
X-Mailbox-Line: From martin.thomson@gmail.com  Mon Apr  9 18:22:10 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6ECE126B72; Mon,  9 Apr 2018 18:22:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523323330; bh=1zAsZhSQcqt6BU56WhfXHH5MydPF6wlO1n6WzAv3Szo=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=C2qTGMy7TpOenkxBf55zcL0yKyDnI8i7nbyT6q426apVpLVVbTIumZZhdBK/KyqN2 0AyGT/6X8Jd4kSDPPBNlaIVLGE6+csD7Nv7P8tNnvI/+nTy2ZmdZ9PrY54QhEURDlQ /0XR5hkpH/OYIQM6svNwWkR+X/b8fq07L1Rw6QCw=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B588712D86E for ; Mon,  9 Apr 2018 18:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tp2EbkJ3084P for ; Mon,  9 Apr 2018 18:22:09 -0700 (PDT)
Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F2F126B72 for ; Mon,  9 Apr 2018 18:22:08 -0700 (PDT)
Received: by mail-ot0-x22e.google.com with SMTP id p33-v6so10886433otp.11 for ; Mon, 09 Apr 2018 18:22:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zq7d3ezNj/Yf/QRLrbCrJbH9jbJF3NDwWFFYl6M9UfI=; b=PyNUmcXyx6yjgHhfueUxQfBgr6lLPIuKO7/E4p5hs/BYSxsb5cLZLZuD+vjmoZAqJN n+2pOLvie+hUBlyVXy3jYM0N/LA47I0Ye5Sq2Iwzqk5AMZifSZR4fbNIecKCPF0EZJ9Q TuP74qw7BBtc/4LkhzNUuWLTug6TAZXEuDLhcVjrL071QCbuXzzqIYZ6n9KuhgLQy6QM 1VKEunnmqDsE3Vz94/oPy3HeN3jA5F5xwkST07JDMY6hmRo+VjMk+KoszVIT096XNHnZ dKvwCatzWNbZxlHMNrmxw4jcZAoIzIULsNdf8jPB1Q8rPHTOsI6TkgjT/bIB5on/4MYo r4kw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=zq7d3ezNj/Yf/QRLrbCrJbH9jbJF3NDwWFFYl6M9UfI=; b=bnMUW6pRnuLVJiKSwPZhV60+Jh2lRvU27XbgTpUwVRtZA+lNyTkPnbrSfz04dYZtsU xKFs0a01BKj5QSSc16Yn4au7o4kySNYJD2igM6CIPyWuX3VvDphY+ENhRrdVXeTQ2bqD /0iuN9zPoiM7JmDVM4CTeKISPeKO326+0ij5cmFkAD+vRDZGDZRKqoyTZN20A6Or6c/J l5VdMsoYGK8/ctxGNw7nimvULSHg1nY3Pt2fdDRmOGs2ZMSt7yk2gt6Hter1jJK9kC5N 4wIaXYJYONNY8oHSVpsY8mJmHPWIpD6mn7wvKgxRaHCrGAjsKNR2TzH6bT6PL3N+zb1Z +IQg==
X-Gm-Message-State: ALQs6tBZ9Xj4Vw4U9RK4cM41onEd3dyLMjLqdgsobt+uCKpU8yOfTCpG fih9V99K+5D9nYNkXnEnfgt7MMN0T2bXVAhvoqIffA==
X-Google-Smtp-Source: AIpwx48FE7xbfkkdIjk1WN+eZgp+dlujnuaXWhnoL25aI7sN0IXhAuHDzprTPQzlM6OV4SCqV3y0dcWjCZgwQBg5R64=
X-Received: by 2002:a9d:2150:: with SMTP id l16-v6mr7475714otd.394.1523323328190;  Mon, 09 Apr 2018 18:22:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 9 Apr 2018 18:22:07 -0700 (PDT)
In-Reply-To: 
References:     
From: Martin Thomson 
Date: Tue, 10 Apr 2018 11:22:07 +1000
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Praveen Balasubramanian 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Praveen Balasubramanian 
Cc: IETF QUIC WG 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 01:22:11 -0000

Do you truncate the randomized value?  Do you reconstruct using the
process for reconstructing a packet number in the current QUIC draft?

If the answer is yes to both, then you need to add batch_size to the
number of outstanding packets when determining the length of the
truncated packet number.  That's all.

On Tue, Apr 10, 2018 at 11:07 AM, Praveen Balasubramanian
 wrote:
> Since the text is verbose maybe this pseudo code explains it in an easy w=
ay:
>
> 1. Set batch_size =3D 128. Allocate an array A of 128 packet numbers per =
connection. Set i =3D 0.
>
> 2. For generating each packet
>               If i < batch_size
>               {
>                 a. use Fisher-Yates (or equivalent) on the array to gener=
ate the next unique random number R between "real packet number" and "real =
packet number" + 128
>                 b. i++
>                 c. set R as the nonce (in clear packet number) after enco=
ding
>                 d. set ("real packet number" - R), i.e. the subtraction a=
s a signed offset value O in encrypted portion of the header. O is by defin=
ition <=3D 128 and as a signed        number needs at most a byte to repres=
ent in the packet.
>                 e. "real packet number"++
>                 f. Do rest of steps of generating a packet then Done
>                }
>         else
>                {
>                 a. clear the array, reset i =3D 0
>                              b. goto 2.
>                }
>
> I am not really sure why the transformed PN which always is within 128 (o=
r batch_size) numbers of the original PN will need more space to encode.
>
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: Monday, April 9, 2018 5:58 PM
> To: Praveen Balasubramanian 
> Cc: Praveen Balasubramanian ; IET=
F QUIC WG 
> Subject: Re: Simple transform for improving PN ossification prevention
>
> On Tue, Apr 10, 2018 at 10:49 AM, Praveen Balasubramanian  wrote:
>>>> You want to use a packet number that is near the real packet number,
>>>> ensure that each value is only used once, and also include the real
>>>> packet number under encryption
>> Not the entire packet number, just enough information to reconstruct the=
 real packet number. In this scheme it is just an extra byte in the encrypt=
ed portion of the header. IF the batch size is smaller we can do fewer bits=
 per packet.
>
> If I understand your scheme, then you reconstruct the nonce in the same w=
ay that you reconstruct the packet number.  Is that a misunderstanding?  Or=
 are you suggesting that there is an explicit nonce in the packet?
>
>>>> to which you do this "reordering" will affect the performance of the
>>>> packet number reconstruction in the face of actual reordering
>> Each packet is self contained and the real PN can be reconstructed just =
using the offset stored in the encrypted header. I don=E2=80=99t see any is=
sues with additional network induced reordering. There is no dependency bet=
ween packets with this scheme.
>
> The current design places requirements on the size of the truncated packe=
t number that is based on the exposure to reordering.  Your design effectiv=
ely induces reordering into this process, so the number of bytes you spend =
on the "packet number" (really a nonce in your
> design) encoding has to increase to compensate.


From nobody Mon Apr  9 18:22:16 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B34C126B72 for ; Mon,  9 Apr 2018 18:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 NruHA_yPvlov for ; Mon,  9 Apr 2018 18:22:09 -0700 (PDT)
Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAAEC1201F8 for ; Mon,  9 Apr 2018 18:22:08 -0700 (PDT)
Received: by mail-ot0-x234.google.com with SMTP id y46-v6so10902870otd.4 for ; Mon, 09 Apr 2018 18:22:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zq7d3ezNj/Yf/QRLrbCrJbH9jbJF3NDwWFFYl6M9UfI=; b=PyNUmcXyx6yjgHhfueUxQfBgr6lLPIuKO7/E4p5hs/BYSxsb5cLZLZuD+vjmoZAqJN n+2pOLvie+hUBlyVXy3jYM0N/LA47I0Ye5Sq2Iwzqk5AMZifSZR4fbNIecKCPF0EZJ9Q TuP74qw7BBtc/4LkhzNUuWLTug6TAZXEuDLhcVjrL071QCbuXzzqIYZ6n9KuhgLQy6QM 1VKEunnmqDsE3Vz94/oPy3HeN3jA5F5xwkST07JDMY6hmRo+VjMk+KoszVIT096XNHnZ dKvwCatzWNbZxlHMNrmxw4jcZAoIzIULsNdf8jPB1Q8rPHTOsI6TkgjT/bIB5on/4MYo r4kw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=zq7d3ezNj/Yf/QRLrbCrJbH9jbJF3NDwWFFYl6M9UfI=; b=dejN8Gu6wSSPnv8cUUzAG8RMdxlCApzxn5apvAbYA+5XLZnvZFahx4SzescO7++9FT rwgZUYpkolIIWAekX3pt5uNHeK41TCC9VAoodUNt612GokPRBnVmzqE3stvDbrcwkxWy Y+gfbF0Pk7/BVzm36zO4rISkrB8eV40Hj0WSBHpLj6wA60SsURpniD2IXB3rTK97NulG sqTH1QvCCYXCwLbLadHihagX/0qdFlMCVW3fwsbNQzBjD7WfDaLTyFrK45klqkcvapfb WmBbNEbYujIr+GFRi0YfH+VdSIn7wm1+RRGwObcAr4GsMrMAKDtHhE9hachpgMPfdCvg qVTw==
X-Gm-Message-State: ALQs6tCMCfyfFYEezcYH1QxEA2hGnOFZCMEBc7SSvFXOCYk6K9oCo++5 uuY1C8Rjgm4IfMw7Kg5ZUJjO+QOkvyT+yWP6r2o=
X-Google-Smtp-Source: AIpwx48FE7xbfkkdIjk1WN+eZgp+dlujnuaXWhnoL25aI7sN0IXhAuHDzprTPQzlM6OV4SCqV3y0dcWjCZgwQBg5R64=
X-Received: by 2002:a9d:2150:: with SMTP id l16-v6mr7475714otd.394.1523323328190;  Mon, 09 Apr 2018 18:22:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 9 Apr 2018 18:22:07 -0700 (PDT)
In-Reply-To: 
References:     
From: Martin Thomson 
Date: Tue, 10 Apr 2018 11:22:07 +1000
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Praveen Balasubramanian 
Cc: Praveen Balasubramanian , 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, 10 Apr 2018 01:22:11 -0000

Do you truncate the randomized value?  Do you reconstruct using the
process for reconstructing a packet number in the current QUIC draft?

If the answer is yes to both, then you need to add batch_size to the
number of outstanding packets when determining the length of the
truncated packet number.  That's all.

On Tue, Apr 10, 2018 at 11:07 AM, Praveen Balasubramanian
 wrote:
> Since the text is verbose maybe this pseudo code explains it in an easy w=
ay:
>
> 1. Set batch_size =3D 128. Allocate an array A of 128 packet numbers per =
connection. Set i =3D 0.
>
> 2. For generating each packet
>               If i < batch_size
>               {
>                 a. use Fisher-Yates (or equivalent) on the array to gener=
ate the next unique random number R between "real packet number" and "real =
packet number" + 128
>                 b. i++
>                 c. set R as the nonce (in clear packet number) after enco=
ding
>                 d. set ("real packet number" - R), i.e. the subtraction a=
s a signed offset value O in encrypted portion of the header. O is by defin=
ition <=3D 128 and as a signed        number needs at most a byte to repres=
ent in the packet.
>                 e. "real packet number"++
>                 f. Do rest of steps of generating a packet then Done
>                }
>         else
>                {
>                 a. clear the array, reset i =3D 0
>                              b. goto 2.
>                }
>
> I am not really sure why the transformed PN which always is within 128 (o=
r batch_size) numbers of the original PN will need more space to encode.
>
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: Monday, April 9, 2018 5:58 PM
> To: Praveen Balasubramanian 
> Cc: Praveen Balasubramanian ; IET=
F QUIC WG 
> Subject: Re: Simple transform for improving PN ossification prevention
>
> On Tue, Apr 10, 2018 at 10:49 AM, Praveen Balasubramanian  wrote:
>>>> You want to use a packet number that is near the real packet number,
>>>> ensure that each value is only used once, and also include the real
>>>> packet number under encryption
>> Not the entire packet number, just enough information to reconstruct the=
 real packet number. In this scheme it is just an extra byte in the encrypt=
ed portion of the header. IF the batch size is smaller we can do fewer bits=
 per packet.
>
> If I understand your scheme, then you reconstruct the nonce in the same w=
ay that you reconstruct the packet number.  Is that a misunderstanding?  Or=
 are you suggesting that there is an explicit nonce in the packet?
>
>>>> to which you do this "reordering" will affect the performance of the
>>>> packet number reconstruction in the face of actual reordering
>> Each packet is self contained and the real PN can be reconstructed just =
using the offset stored in the encrypted header. I don=E2=80=99t see any is=
sues with additional network induced reordering. There is no dependency bet=
ween packets with this scheme.
>
> The current design places requirements on the size of the truncated packe=
t number that is based on the exposure to reordering.  Your design effectiv=
ely induces reordering into this process, so the number of bytes you spend =
on the "packet number" (really a nonce in your
> design) encoding has to increase to compensate.


From nobody Mon Apr  9 18:27:50 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB5E12D87A for ; Mon,  9 Apr 2018 18:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 MY13n-49mAT4 for ; Mon,  9 Apr 2018 18:27:47 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0110.outbound.protection.outlook.com [104.47.41.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408BF126B72 for ; Mon,  9 Apr 2018 18:27:47 -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=MwmsvJxxcf5zr3y0d0Bd3ExjiurSica11RUSergasXQ=; b=IfCt/me5XrbkX73DP3Hhhbn4GSEAA4pjuy70NOHMYLgnUcLru29K4ifCNr4BhBPCG8tmHjHOi6L6cDCTxu54HMzUjsEgxEj8fPMXukNh484RrjmRWtzbBbrbemfX1/dAhzZhYlbuNunCXE3fo4+6+Bwo9QWFOMK0LK9oYEzy6u8=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0470.namprd21.prod.outlook.com (10.172.121.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Tue, 10 Apr 2018 01:27:45 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Tue, 10 Apr 2018 01:27:45 +0000
From: Praveen Balasubramanian 
To: Martin Thomson 
CC: Praveen Balasubramanian , IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAH3w2AAAAjVmAAAMjZAAAADK3gAADLPoAAAAaPMA==
Date: Tue, 10 Apr 2018 01:27:45 +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:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0470; 7:LPvyVyOx+2vZF9oWhZlnbY/yqe6zTO3NlgV0TTKLU8H9RduJxhUUbf8d0F/apYDQeYZ8+rQPyhW2WFgREecB4A/LzzEul5+k/C1D/Kmfa9FZsSY5A0FpKw7xRcCxzu4ECX7y03wBGghEMZRwgtOwOjLQE5heRAemM9bqD0okyShmtt8qNZYNOT6fT2QGHDTb+LaqDfdgiBK45HTq76E63ca7XXEicnNk5LCcUmLzc3qUt0M8fvMKyE8+pd7YejQh; 20:NKKJK+S5sVOPRF5wjyDQjfuRmx5MYkiNXkyfT6QYH9FeZXbFGn05N14Ppo22Gfjk8ukB1a/4oO8g8lfygtY31NhltYcqF2DrZ9Kxtfr/RO4bdK9ITn1/YF8H+jkhZYqGqSGsPk6paacYumNbtpDR+aGd81c6AjVHhsiSAcplg7k=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0470; 
x-ms-traffictypediagnostic: CY4PR21MB0470:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0470; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0470; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(346002)(376002)(39860400002)(396003)(13464003)(199004)(189003)(11346002)(446003)(3280700002)(478600001)(476003)(10090500001)(46003)(76176011)(22452003)(316002)(7696005)(8990500004)(105586002)(81156014)(81166006)(229853002)(8676002)(10290500003)(53546011)(6506007)(102836004)(6116002)(486006)(14454004)(68736007)(186003)(6916009)(86612001)(3660700001)(99286004)(2906002)(8936002)(25786009)(4326008)(39060400002)(7736002)(305945005)(86362001)(74316002)(33656002)(93886005)(53936002)(5660300001)(97736004)(6246003)(2900100001)(5250100002)(6436002)(9686003)(55016002)(54906003)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0470; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: dg+aBSFkK0nCrOq/0k3w6N4v8Gb90rOJU1UMq2qpv+hTsBgfp900AFmUoFu2vHzBOt5mEW0vkHNOAhL1XaXe0IZJJfyfOE5htS4TuHgsbjzAc7ldpqhBaC3CY0o1kXo704aAPk5I/5CtlcFX70IEmKJEk2ibb3X7UwrOug4ot2asMUF8gBTaECoLgLaSDgGcZViZWYj6k31jEvbt3RKLeXWFCdFRAz9oUg4PEf0xGT1+USgwT55TpY67yOskyuCZhjEHnEQzE195VmDFcq5WYfVfLP6+EOERiA+qD4zkoA+b+ZrHs4rBffCt1Rcpmf+90Czp5eNM8nacVpEc+6he72FwEE9aHjfjEe9NVE0YoWxMxVrOIW5utKFVklQ7Lg7aZ5nrkjTyWPoGu8OpdUA5MLm3vZ69fwaKmHeYqcSgMsk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: d19f22a6-dc0d-4f1d-e37c-08d59e824365
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d19f22a6-dc0d-4f1d-e37c-08d59e824365
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 01:27:45.5231 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0470
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 01:27:49 -0000

WWVzIHRvIGJvdGguIFllYWggdGhhbmtzIEkgYWdyZWUgdGhhdCBhZGRpdGlvbiB3aWxsIGJlIHJl
cXVpcmVkIHNpbmNlIHRoZSBub25jZSB2YWx1ZSAoInJlYWwgcGFja2V0IG51bWJlciIgKyBiYXRj
aF9zaXplKSBtYXkgdmVyeSB3ZWxsIGFycml2ZSBmaXJzdCBpbiBhIGdpdmVuICBiYXRjaC4gDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRv
Om1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIEFwcmlsIDksIDIwMTgg
NjoyMiBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29t
Pg0KQ2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1h
cmMuaWV0Zi5vcmc+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog
U2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9u
DQoNCkRvIHlvdSB0cnVuY2F0ZSB0aGUgcmFuZG9taXplZCB2YWx1ZT8gIERvIHlvdSByZWNvbnN0
cnVjdCB1c2luZyB0aGUgcHJvY2VzcyBmb3IgcmVjb25zdHJ1Y3RpbmcgYSBwYWNrZXQgbnVtYmVy
IGluIHRoZSBjdXJyZW50IFFVSUMgZHJhZnQ/DQoNCklmIHRoZSBhbnN3ZXIgaXMgeWVzIHRvIGJv
dGgsIHRoZW4geW91IG5lZWQgdG8gYWRkIGJhdGNoX3NpemUgdG8gdGhlIG51bWJlciBvZiBvdXRz
dGFuZGluZyBwYWNrZXRzIHdoZW4gZGV0ZXJtaW5pbmcgdGhlIGxlbmd0aCBvZiB0aGUgdHJ1bmNh
dGVkIHBhY2tldCBudW1iZXIuICBUaGF0J3MgYWxsLg0KDQpPbiBUdWUsIEFwciAxMCwgMjAxOCBh
dCAxMTowNyBBTSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+
IHdyb3RlOg0KPiBTaW5jZSB0aGUgdGV4dCBpcyB2ZXJib3NlIG1heWJlIHRoaXMgcHNldWRvIGNv
ZGUgZXhwbGFpbnMgaXQgaW4gYW4gZWFzeSB3YXk6DQo+DQo+IDEuIFNldCBiYXRjaF9zaXplID0g
MTI4LiBBbGxvY2F0ZSBhbiBhcnJheSBBIG9mIDEyOCBwYWNrZXQgbnVtYmVycyBwZXIgY29ubmVj
dGlvbi4gU2V0IGkgPSAwLg0KPg0KPiAyLiBGb3IgZ2VuZXJhdGluZyBlYWNoIHBhY2tldA0KPiAg
ICAgICAgICAgICAgIElmIGkgPCBiYXRjaF9zaXplDQo+ICAgICAgICAgICAgICAgew0KPiAgICAg
ICAgICAgICAgICAgYS4gdXNlIEZpc2hlci1ZYXRlcyAob3IgZXF1aXZhbGVudCkgb24gdGhlIGFy
cmF5IHRvIGdlbmVyYXRlIHRoZSBuZXh0IHVuaXF1ZSByYW5kb20gbnVtYmVyIFIgYmV0d2VlbiAi
cmVhbCBwYWNrZXQgbnVtYmVyIiBhbmQgInJlYWwgcGFja2V0IG51bWJlciIgKyAxMjgNCj4gICAg
ICAgICAgICAgICAgIGIuIGkrKw0KPiAgICAgICAgICAgICAgICAgYy4gc2V0IFIgYXMgdGhlIG5v
bmNlIChpbiBjbGVhciBwYWNrZXQgbnVtYmVyKSBhZnRlciBlbmNvZGluZw0KPiAgICAgICAgICAg
ICAgICAgZC4gc2V0ICgicmVhbCBwYWNrZXQgbnVtYmVyIiAtIFIpLCBpLmUuIHRoZSBzdWJ0cmFj
dGlvbiBhcyBhIHNpZ25lZCBvZmZzZXQgdmFsdWUgTyBpbiBlbmNyeXB0ZWQgcG9ydGlvbiBvZiB0
aGUgaGVhZGVyLiBPIGlzIGJ5IGRlZmluaXRpb24gPD0gMTI4IGFuZCBhcyBhIHNpZ25lZCAgICAg
ICAgbnVtYmVyIG5lZWRzIGF0IG1vc3QgYSBieXRlIHRvIHJlcHJlc2VudCBpbiB0aGUgcGFja2V0
Lg0KPiAgICAgICAgICAgICAgICAgZS4gInJlYWwgcGFja2V0IG51bWJlciIrKw0KPiAgICAgICAg
ICAgICAgICAgZi4gRG8gcmVzdCBvZiBzdGVwcyBvZiBnZW5lcmF0aW5nIGEgcGFja2V0IHRoZW4g
RG9uZQ0KPiAgICAgICAgICAgICAgICB9DQo+ICAgICAgICAgZWxzZQ0KPiAgICAgICAgICAgICAg
ICB7DQo+ICAgICAgICAgICAgICAgICBhLiBjbGVhciB0aGUgYXJyYXksIHJlc2V0IGkgPSAwDQo+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYi4gZ290byAyLg0KPiAgICAgICAgICAgICAg
ICB9DQo+DQo+IEkgYW0gbm90IHJlYWxseSBzdXJlIHdoeSB0aGUgdHJhbnNmb3JtZWQgUE4gd2hp
Y2ggYWx3YXlzIGlzIHdpdGhpbiAxMjggKG9yIGJhdGNoX3NpemUpIG51bWJlcnMgb2YgdGhlIG9y
aWdpbmFsIFBOIHdpbGwgbmVlZCBtb3JlIHNwYWNlIHRvIGVuY29kZS4NCj4NCj4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4u
dGhvbXNvbkBnbWFpbC5jb21dDQo+IFNlbnQ6IE1vbmRheSwgQXByaWwgOSwgMjAxOCA1OjU4IFBN
DQo+IFRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4NCj4g
Q2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMu
aWV0Zi5vcmc+OyANCj4gSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KPiBTdWJqZWN0OiBS
ZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50
aW9uDQo+DQo+IE9uIFR1ZSwgQXByIDEwLCAyMDE4IGF0IDEwOjQ5IEFNLCBQcmF2ZWVuIEJhbGFz
dWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+Pj4+IFlvdSB3YW50IHRv
IHVzZSBhIHBhY2tldCBudW1iZXIgdGhhdCBpcyBuZWFyIHRoZSByZWFsIHBhY2tldCANCj4+Pj4g
bnVtYmVyLCBlbnN1cmUgdGhhdCBlYWNoIHZhbHVlIGlzIG9ubHkgdXNlZCBvbmNlLCBhbmQgYWxz
byBpbmNsdWRlIA0KPj4+PiB0aGUgcmVhbCBwYWNrZXQgbnVtYmVyIHVuZGVyIGVuY3J5cHRpb24N
Cj4+IE5vdCB0aGUgZW50aXJlIHBhY2tldCBudW1iZXIsIGp1c3QgZW5vdWdoIGluZm9ybWF0aW9u
IHRvIHJlY29uc3RydWN0IHRoZSByZWFsIHBhY2tldCBudW1iZXIuIEluIHRoaXMgc2NoZW1lIGl0
IGlzIGp1c3QgYW4gZXh0cmEgYnl0ZSBpbiB0aGUgZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIGhl
YWRlci4gSUYgdGhlIGJhdGNoIHNpemUgaXMgc21hbGxlciB3ZSBjYW4gZG8gZmV3ZXIgYml0cyBw
ZXIgcGFja2V0Lg0KPg0KPiBJZiBJIHVuZGVyc3RhbmQgeW91ciBzY2hlbWUsIHRoZW4geW91IHJl
Y29uc3RydWN0IHRoZSBub25jZSBpbiB0aGUgc2FtZSB3YXkgdGhhdCB5b3UgcmVjb25zdHJ1Y3Qg
dGhlIHBhY2tldCBudW1iZXIuICBJcyB0aGF0IGEgbWlzdW5kZXJzdGFuZGluZz8gIE9yIGFyZSB5
b3Ugc3VnZ2VzdGluZyB0aGF0IHRoZXJlIGlzIGFuIGV4cGxpY2l0IG5vbmNlIGluIHRoZSBwYWNr
ZXQ/DQo+DQo+Pj4+IHRvIHdoaWNoIHlvdSBkbyB0aGlzICJyZW9yZGVyaW5nIiB3aWxsIGFmZmVj
dCB0aGUgcGVyZm9ybWFuY2Ugb2YgDQo+Pj4+IHRoZSBwYWNrZXQgbnVtYmVyIHJlY29uc3RydWN0
aW9uIGluIHRoZSBmYWNlIG9mIGFjdHVhbCByZW9yZGVyaW5nDQo+PiBFYWNoIHBhY2tldCBpcyBz
ZWxmIGNvbnRhaW5lZCBhbmQgdGhlIHJlYWwgUE4gY2FuIGJlIHJlY29uc3RydWN0ZWQganVzdCB1
c2luZyB0aGUgb2Zmc2V0IHN0b3JlZCBpbiB0aGUgZW5jcnlwdGVkIGhlYWRlci4gSSBkb27igJl0
IHNlZSBhbnkgaXNzdWVzIHdpdGggYWRkaXRpb25hbCBuZXR3b3JrIGluZHVjZWQgcmVvcmRlcmlu
Zy4gVGhlcmUgaXMgbm8gZGVwZW5kZW5jeSBiZXR3ZWVuIHBhY2tldHMgd2l0aCB0aGlzIHNjaGVt
ZS4NCj4NCj4gVGhlIGN1cnJlbnQgZGVzaWduIHBsYWNlcyByZXF1aXJlbWVudHMgb24gdGhlIHNp
emUgb2YgdGhlIHRydW5jYXRlZCANCj4gcGFja2V0IG51bWJlciB0aGF0IGlzIGJhc2VkIG9uIHRo
ZSBleHBvc3VyZSB0byByZW9yZGVyaW5nLiAgWW91ciANCj4gZGVzaWduIGVmZmVjdGl2ZWx5IGlu
ZHVjZXMgcmVvcmRlcmluZyBpbnRvIHRoaXMgcHJvY2Vzcywgc28gdGhlIG51bWJlciANCj4gb2Yg
Ynl0ZXMgeW91IHNwZW5kIG9uIHRoZSAicGFja2V0IG51bWJlciIgKHJlYWxseSBhIG5vbmNlIGlu
IHlvdXINCj4gZGVzaWduKSBlbmNvZGluZyBoYXMgdG8gaW5jcmVhc2UgdG8gY29tcGVuc2F0ZS4N
Cg==


From nobody Mon Apr  9 18:28:05 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D93412D87A for ; Mon,  9 Apr 2018 18:27:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523323670; bh=MwmsvJxxcf5zr3y0d0Bd3ExjiurSica11RUSergasXQ=; h=From:To:Subject:Date:References:In-Reply-To:Cc:Cc; b=Z6zdbGFL5Z0GTbK4KR4GdwLYw6J0+7U7qXChMOOvMnY/AbruwljL/RDoDbh72VNvq 41nxu0WeeIKZs1spY99QjaTtIsedjkTBWVDPa1Air3GzlWl0lclKBqOfZ3bIs0FDSp bEEwaMfL8i3HE410VqE+wSVo82krNEdv+bzipPOo=
X-Mailbox-Line: From pravb@microsoft.com  Mon Apr  9 18:27:50 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D52312D86E; Mon,  9 Apr 2018 18:27:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523323670; bh=MwmsvJxxcf5zr3y0d0Bd3ExjiurSica11RUSergasXQ=; h=From:To:Subject:Date:References:In-Reply-To:Cc:Cc; b=Z6zdbGFL5Z0GTbK4KR4GdwLYw6J0+7U7qXChMOOvMnY/AbruwljL/RDoDbh72VNvq 41nxu0WeeIKZs1spY99QjaTtIsedjkTBWVDPa1Air3GzlWl0lclKBqOfZ3bIs0FDSp bEEwaMfL8i3HE410VqE+wSVo82krNEdv+bzipPOo=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073A1126B72 for ; Mon,  9 Apr 2018 18:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 MAR22a_6oeE1 for ; Mon,  9 Apr 2018 18:27:47 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on070e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::70e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4370F12D86E for ; Mon,  9 Apr 2018 18:27:47 -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=MwmsvJxxcf5zr3y0d0Bd3ExjiurSica11RUSergasXQ=; b=IfCt/me5XrbkX73DP3Hhhbn4GSEAA4pjuy70NOHMYLgnUcLru29K4ifCNr4BhBPCG8tmHjHOi6L6cDCTxu54HMzUjsEgxEj8fPMXukNh484RrjmRWtzbBbrbemfX1/dAhzZhYlbuNunCXE3fo4+6+Bwo9QWFOMK0LK9oYEzy6u8=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0470.namprd21.prod.outlook.com (10.172.121.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Tue, 10 Apr 2018 01:27:45 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Tue, 10 Apr 2018 01:27:45 +0000
From: Praveen Balasubramanian 
To: Martin Thomson 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAH3w2AAAAjVmAAAMjZAAAADK3gAADLPoAAAAaPMA==
Date: Tue, 10 Apr 2018 01:27:45 +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:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0470; 7:LPvyVyOx+2vZF9oWhZlnbY/yqe6zTO3NlgV0TTKLU8H9RduJxhUUbf8d0F/apYDQeYZ8+rQPyhW2WFgREecB4A/LzzEul5+k/C1D/Kmfa9FZsSY5A0FpKw7xRcCxzu4ECX7y03wBGghEMZRwgtOwOjLQE5heRAemM9bqD0okyShmtt8qNZYNOT6fT2QGHDTb+LaqDfdgiBK45HTq76E63ca7XXEicnNk5LCcUmLzc3qUt0M8fvMKyE8+pd7YejQh; 20:NKKJK+S5sVOPRF5wjyDQjfuRmx5MYkiNXkyfT6QYH9FeZXbFGn05N14Ppo22Gfjk8ukB1a/4oO8g8lfygtY31NhltYcqF2DrZ9Kxtfr/RO4bdK9ITn1/YF8H+jkhZYqGqSGsPk6paacYumNbtpDR+aGd81c6AjVHhsiSAcplg7k=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0470; 
x-ms-traffictypediagnostic: CY4PR21MB0470:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0470; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0470; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(346002)(376002)(39860400002)(396003)(13464003)(199004)(189003)(11346002)(446003)(3280700002)(478600001)(476003)(10090500001)(46003)(76176011)(22452003)(316002)(7696005)(8990500004)(105586002)(81156014)(81166006)(229853002)(8676002)(10290500003)(53546011)(6506007)(102836004)(6116002)(486006)(14454004)(68736007)(186003)(6916009)(86612001)(3660700001)(99286004)(2906002)(8936002)(25786009)(4326008)(39060400002)(7736002)(305945005)(86362001)(74316002)(33656002)(93886005)(53936002)(5660300001)(97736004)(6246003)(2900100001)(5250100002)(6436002)(9686003)(55016002)(54906003)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0470; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: dg+aBSFkK0nCrOq/0k3w6N4v8Gb90rOJU1UMq2qpv+hTsBgfp900AFmUoFu2vHzBOt5mEW0vkHNOAhL1XaXe0IZJJfyfOE5htS4TuHgsbjzAc7ldpqhBaC3CY0o1kXo704aAPk5I/5CtlcFX70IEmKJEk2ibb3X7UwrOug4ot2asMUF8gBTaECoLgLaSDgGcZViZWYj6k31jEvbt3RKLeXWFCdFRAz9oUg4PEf0xGT1+USgwT55TpY67yOskyuCZhjEHnEQzE195VmDFcq5WYfVfLP6+EOERiA+qD4zkoA+b+ZrHs4rBffCt1Rcpmf+90Czp5eNM8nacVpEc+6he72FwEE9aHjfjEe9NVE0YoWxMxVrOIW5utKFVklQ7Lg7aZ5nrkjTyWPoGu8OpdUA5MLm3vZ69fwaKmHeYqcSgMsk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: d19f22a6-dc0d-4f1d-e37c-08d59e824365
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d19f22a6-dc0d-4f1d-e37c-08d59e824365
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 01:27:45.5231 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0470
Cc: Praveen Balasubramanian 
Cc: IETF QUIC WG 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 01:27:51 -0000

WWVzIHRvIGJvdGguIFllYWggdGhhbmtzIEkgYWdyZWUgdGhhdCBhZGRpdGlvbiB3aWxsIGJlIHJl
cXVpcmVkIHNpbmNlIHRoZSBub25jZSB2YWx1ZSAoInJlYWwgcGFja2V0IG51bWJlciIgKyBiYXRj
aF9zaXplKSBtYXkgdmVyeSB3ZWxsIGFycml2ZSBmaXJzdCBpbiBhIGdpdmVuICBiYXRjaC4gDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRv
Om1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIEFwcmlsIDksIDIwMTgg
NjoyMiBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29t
Pg0KQ2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1h
cmMuaWV0Zi5vcmc+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog
U2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9u
DQoNCkRvIHlvdSB0cnVuY2F0ZSB0aGUgcmFuZG9taXplZCB2YWx1ZT8gIERvIHlvdSByZWNvbnN0
cnVjdCB1c2luZyB0aGUgcHJvY2VzcyBmb3IgcmVjb25zdHJ1Y3RpbmcgYSBwYWNrZXQgbnVtYmVy
IGluIHRoZSBjdXJyZW50IFFVSUMgZHJhZnQ/DQoNCklmIHRoZSBhbnN3ZXIgaXMgeWVzIHRvIGJv
dGgsIHRoZW4geW91IG5lZWQgdG8gYWRkIGJhdGNoX3NpemUgdG8gdGhlIG51bWJlciBvZiBvdXRz
dGFuZGluZyBwYWNrZXRzIHdoZW4gZGV0ZXJtaW5pbmcgdGhlIGxlbmd0aCBvZiB0aGUgdHJ1bmNh
dGVkIHBhY2tldCBudW1iZXIuICBUaGF0J3MgYWxsLg0KDQpPbiBUdWUsIEFwciAxMCwgMjAxOCBh
dCAxMTowNyBBTSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+
IHdyb3RlOg0KPiBTaW5jZSB0aGUgdGV4dCBpcyB2ZXJib3NlIG1heWJlIHRoaXMgcHNldWRvIGNv
ZGUgZXhwbGFpbnMgaXQgaW4gYW4gZWFzeSB3YXk6DQo+DQo+IDEuIFNldCBiYXRjaF9zaXplID0g
MTI4LiBBbGxvY2F0ZSBhbiBhcnJheSBBIG9mIDEyOCBwYWNrZXQgbnVtYmVycyBwZXIgY29ubmVj
dGlvbi4gU2V0IGkgPSAwLg0KPg0KPiAyLiBGb3IgZ2VuZXJhdGluZyBlYWNoIHBhY2tldA0KPiAg
ICAgICAgICAgICAgIElmIGkgPCBiYXRjaF9zaXplDQo+ICAgICAgICAgICAgICAgew0KPiAgICAg
ICAgICAgICAgICAgYS4gdXNlIEZpc2hlci1ZYXRlcyAob3IgZXF1aXZhbGVudCkgb24gdGhlIGFy
cmF5IHRvIGdlbmVyYXRlIHRoZSBuZXh0IHVuaXF1ZSByYW5kb20gbnVtYmVyIFIgYmV0d2VlbiAi
cmVhbCBwYWNrZXQgbnVtYmVyIiBhbmQgInJlYWwgcGFja2V0IG51bWJlciIgKyAxMjgNCj4gICAg
ICAgICAgICAgICAgIGIuIGkrKw0KPiAgICAgICAgICAgICAgICAgYy4gc2V0IFIgYXMgdGhlIG5v
bmNlIChpbiBjbGVhciBwYWNrZXQgbnVtYmVyKSBhZnRlciBlbmNvZGluZw0KPiAgICAgICAgICAg
ICAgICAgZC4gc2V0ICgicmVhbCBwYWNrZXQgbnVtYmVyIiAtIFIpLCBpLmUuIHRoZSBzdWJ0cmFj
dGlvbiBhcyBhIHNpZ25lZCBvZmZzZXQgdmFsdWUgTyBpbiBlbmNyeXB0ZWQgcG9ydGlvbiBvZiB0
aGUgaGVhZGVyLiBPIGlzIGJ5IGRlZmluaXRpb24gPD0gMTI4IGFuZCBhcyBhIHNpZ25lZCAgICAg
ICAgbnVtYmVyIG5lZWRzIGF0IG1vc3QgYSBieXRlIHRvIHJlcHJlc2VudCBpbiB0aGUgcGFja2V0
Lg0KPiAgICAgICAgICAgICAgICAgZS4gInJlYWwgcGFja2V0IG51bWJlciIrKw0KPiAgICAgICAg
ICAgICAgICAgZi4gRG8gcmVzdCBvZiBzdGVwcyBvZiBnZW5lcmF0aW5nIGEgcGFja2V0IHRoZW4g
RG9uZQ0KPiAgICAgICAgICAgICAgICB9DQo+ICAgICAgICAgZWxzZQ0KPiAgICAgICAgICAgICAg
ICB7DQo+ICAgICAgICAgICAgICAgICBhLiBjbGVhciB0aGUgYXJyYXksIHJlc2V0IGkgPSAwDQo+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYi4gZ290byAyLg0KPiAgICAgICAgICAgICAg
ICB9DQo+DQo+IEkgYW0gbm90IHJlYWxseSBzdXJlIHdoeSB0aGUgdHJhbnNmb3JtZWQgUE4gd2hp
Y2ggYWx3YXlzIGlzIHdpdGhpbiAxMjggKG9yIGJhdGNoX3NpemUpIG51bWJlcnMgb2YgdGhlIG9y
aWdpbmFsIFBOIHdpbGwgbmVlZCBtb3JlIHNwYWNlIHRvIGVuY29kZS4NCj4NCj4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4u
dGhvbXNvbkBnbWFpbC5jb21dDQo+IFNlbnQ6IE1vbmRheSwgQXByaWwgOSwgMjAxOCA1OjU4IFBN
DQo+IFRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4NCj4g
Q2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMu
aWV0Zi5vcmc+OyANCj4gSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KPiBTdWJqZWN0OiBS
ZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50
aW9uDQo+DQo+IE9uIFR1ZSwgQXByIDEwLCAyMDE4IGF0IDEwOjQ5IEFNLCBQcmF2ZWVuIEJhbGFz
dWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+Pj4+IFlvdSB3YW50IHRv
IHVzZSBhIHBhY2tldCBudW1iZXIgdGhhdCBpcyBuZWFyIHRoZSByZWFsIHBhY2tldCANCj4+Pj4g
bnVtYmVyLCBlbnN1cmUgdGhhdCBlYWNoIHZhbHVlIGlzIG9ubHkgdXNlZCBvbmNlLCBhbmQgYWxz
byBpbmNsdWRlIA0KPj4+PiB0aGUgcmVhbCBwYWNrZXQgbnVtYmVyIHVuZGVyIGVuY3J5cHRpb24N
Cj4+IE5vdCB0aGUgZW50aXJlIHBhY2tldCBudW1iZXIsIGp1c3QgZW5vdWdoIGluZm9ybWF0aW9u
IHRvIHJlY29uc3RydWN0IHRoZSByZWFsIHBhY2tldCBudW1iZXIuIEluIHRoaXMgc2NoZW1lIGl0
IGlzIGp1c3QgYW4gZXh0cmEgYnl0ZSBpbiB0aGUgZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIGhl
YWRlci4gSUYgdGhlIGJhdGNoIHNpemUgaXMgc21hbGxlciB3ZSBjYW4gZG8gZmV3ZXIgYml0cyBw
ZXIgcGFja2V0Lg0KPg0KPiBJZiBJIHVuZGVyc3RhbmQgeW91ciBzY2hlbWUsIHRoZW4geW91IHJl
Y29uc3RydWN0IHRoZSBub25jZSBpbiB0aGUgc2FtZSB3YXkgdGhhdCB5b3UgcmVjb25zdHJ1Y3Qg
dGhlIHBhY2tldCBudW1iZXIuICBJcyB0aGF0IGEgbWlzdW5kZXJzdGFuZGluZz8gIE9yIGFyZSB5
b3Ugc3VnZ2VzdGluZyB0aGF0IHRoZXJlIGlzIGFuIGV4cGxpY2l0IG5vbmNlIGluIHRoZSBwYWNr
ZXQ/DQo+DQo+Pj4+IHRvIHdoaWNoIHlvdSBkbyB0aGlzICJyZW9yZGVyaW5nIiB3aWxsIGFmZmVj
dCB0aGUgcGVyZm9ybWFuY2Ugb2YgDQo+Pj4+IHRoZSBwYWNrZXQgbnVtYmVyIHJlY29uc3RydWN0
aW9uIGluIHRoZSBmYWNlIG9mIGFjdHVhbCByZW9yZGVyaW5nDQo+PiBFYWNoIHBhY2tldCBpcyBz
ZWxmIGNvbnRhaW5lZCBhbmQgdGhlIHJlYWwgUE4gY2FuIGJlIHJlY29uc3RydWN0ZWQganVzdCB1
c2luZyB0aGUgb2Zmc2V0IHN0b3JlZCBpbiB0aGUgZW5jcnlwdGVkIGhlYWRlci4gSSBkb27igJl0
IHNlZSBhbnkgaXNzdWVzIHdpdGggYWRkaXRpb25hbCBuZXR3b3JrIGluZHVjZWQgcmVvcmRlcmlu
Zy4gVGhlcmUgaXMgbm8gZGVwZW5kZW5jeSBiZXR3ZWVuIHBhY2tldHMgd2l0aCB0aGlzIHNjaGVt
ZS4NCj4NCj4gVGhlIGN1cnJlbnQgZGVzaWduIHBsYWNlcyByZXF1aXJlbWVudHMgb24gdGhlIHNp
emUgb2YgdGhlIHRydW5jYXRlZCANCj4gcGFja2V0IG51bWJlciB0aGF0IGlzIGJhc2VkIG9uIHRo
ZSBleHBvc3VyZSB0byByZW9yZGVyaW5nLiAgWW91ciANCj4gZGVzaWduIGVmZmVjdGl2ZWx5IGlu
ZHVjZXMgcmVvcmRlcmluZyBpbnRvIHRoaXMgcHJvY2Vzcywgc28gdGhlIG51bWJlciANCj4gb2Yg
Ynl0ZXMgeW91IHNwZW5kIG9uIHRoZSAicGFja2V0IG51bWJlciIgKHJlYWxseSBhIG5vbmNlIGlu
IHlvdXINCj4gZGVzaWduKSBlbmNvZGluZyBoYXMgdG8gaW5jcmVhc2UgdG8gY29tcGVuc2F0ZS4N
Cg==


From nobody Mon Apr  9 18:37:04 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A5512D87B for ; Mon,  9 Apr 2018 18:37:02 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 x8WRxZwSrhSu for ; Mon,  9 Apr 2018 18:36:58 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0127.outbound.protection.outlook.com [104.47.40.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E20412D86E for ; Mon,  9 Apr 2018 18:36:58 -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=IzWmFdPHyMI5RU1tq3vpS9DbCjS/6nhyIo26MKk4Q/Q=; b=D28sZ2Gt7C6PfdttLzc2MZeqATz0R0to5T1kxBcHmCU6sC9U9dN41QU+7egFuv63nDqpHT9l3W+ZKcGRc82fx+BZYfkCbn9S/T379J31+EF+lbLBmxyhj/ruA0+rU55ctJTc5XsEVgOhtaTK+2PZJDaQXG3sH4Nn6fMSLFp+wi8=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0632.namprd21.prod.outlook.com (10.175.115.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Tue, 10 Apr 2018 01:36:56 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Tue, 10 Apr 2018 01:36:56 +0000
From: Praveen Balasubramanian 
To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Nick Banks , IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwABL1oAAAAKT4AAARZUgAAAKZMAAAT/X3A=
Date: Tue, 10 Apr 2018 01:36:56 +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:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0632; 7:MIlr6eR7fFWRvXnnf5UUvJH/cznl4QgUQq2E9Nlm8FYUK+WYc3L0/wokooldGgYmQK1aMX6zL2WwiiyoJC12UgTHxRO6UB1ev9YE+V98kvQI5E8gyiR2to5vCDxZk4nbunlFNbnqW2ft1NQT1oG2NYKQHFeniLyWaokNK9jmMs3Cr5fv2VlzH+1i53r6GgVHPtfoBEP5vtAsNxdAc85l5hJALcXwvOjB9YU5IBrNn2uvxW9/My58aCIM4OzEZiro; 20:FliwjcPzXvEORt1fJ/ktO5GyWV/un4b+d9SalivOqhYCiAP5GW9CilWybOfUDhwHDb4BnHfb0Rs0UE1smGym/PtNxz42AGL7CAEZVIYivlo9BRCm6u1iVjJVJnqtaaA1+4dqdxk5nUBgEjREB5f3yvuTIlRkw07X2gBb+NFOw+Q=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0632; 
x-ms-traffictypediagnostic: CY4PR21MB0632:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(189930954265078)(85827821059158)(15185016700835)(788757137089)(219752817060721)(21748063052155)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(3002001)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0632; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0632; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(396003)(39380400002)(366004)(346002)(52314003)(189003)(199004)(54896002)(7696005)(53946003)(53936002)(7736002)(46003)(236005)(10290500003)(478600001)(110136005)(22452003)(316002)(68736007)(2906002)(74316002)(106356001)(93886005)(8936002)(99286004)(81156014)(6506007)(59450400001)(81166006)(86362001)(25786009)(76176011)(6306002)(8676002)(39060400002)(229853002)(6246003)(97736004)(6436002)(9686003)(55016002)(2900100001)(86612001)(3660700001)(53546011)(5250100002)(186003)(105586002)(3280700002)(966005)(8990500004)(6116002)(790700001)(19609705001)(446003)(561944003)(11346002)(1511001)(486006)(5660300001)(14454004)(606006)(476003)(102836004)(10090500001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0632; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: MN3lopwMJBiDMUddooZFgOwh2OH+zTI49R5DVwkjGSAvKrzme1Du+zdIu+tTIcAi236xrRJoYji+oada/BtJTV4zlGJ6mKRp7r364tBoMsz3F6+0qXFMjIdtY/DeZXi0ruaf1QZNpjLtp2f0/ahBKIGjZcGo2U24ZZD/TkHZBmovo1GG2kVvpg3TUKGVCARkLV9CUsm+jNL87zSYNUEtEnwYwCl8w2gTxAJEYIqPky87d8/+9kk+pTMOgt/2SYLtedamRZCn/5Gf+C1BhllPf7atmQH4w5OxPY2URtlgx1/0tKmKsIznPFQ2LEpAXvFT6pGsTlyTYuLF5AJonIRTl94UxgfjdpcpIwRcM5fWB29ROPITv4iOg3rN00PhuuhVT86QZAE4cZdl9oWz4JFOFiFPi0Q+BmAVbsrcR5BKovE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630A663DA8595170C9135C1B6BE0CY4PR21MB0630namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 71694244-fb1a-4fe1-e616-08d59e838bbe
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 71694244-fb1a-4fe1-e616-08d59e838bbe
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 01:36:56.3835 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0632
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 01:37:02 -0000

--_000_CY4PR21MB0630A663DA8595170C9135C1B6BE0CY4PR21MB0630namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Pj4gYnV0IGl0IGFsc28gbWFrZXMgbG9zcyBkZXRlY3Rpb24gdmVyeSBkaWZmaWN1bHQgdG8gZG8g
d2l0aCBhbnkgZGVncmVlIG9mIHByZWNpc2lvbg0KTG9zcyBkZXRlY3Rpb24gaXMgYWN0dWFsbHkg
c3RyYWlnaHRmb3J3YXJkIGFzIGxvbmcgYXMgdGhlIG1pZGRsZWJveCBrbm93cyB0aGUgYmF0Y2gg
c2l6ZS4gSXQgd2lsbCBuZWVkIHRvIGxvb2sgZm9yIG1pc3NpbmcgcGFja2V0IG51bWJlcnMgd2l0
aGluIGEgYmF0Y2guIFJlb3JkZXIgZGV0ZWN0aW9uIGlzIGhvd2V2ZXIgZXh0cmVtZWx5IGRpZmZp
Y3VsdCBzaW5jZSB0aGUgc2NoZW1lIGl0c2VsZiBkb2VzIHJlb3JkZXJpbmcgb2YgdGhlIG5vbmNl
Lg0KDQo+PiB5b3UgY2FuIGFsc28gZW5jcnlwdCBwYWNrZXQgbnVtYmVycyB1c2luZyBhbiBpbnRl
cm5hbCBwcmVjb21wdXRlZCBBRVMgZHJpdmVuIFBSTkcgc3RyZQ0KQW4gaW1wbGVtZW50YXRpb24g
Y291bGQgYnV0IGl0cyBub3QgYSBtdXN0LiBUaGUgcmFuZG9tIGdlbmVyYXRpb24gZm9yIHNodWZm
bGluZyBkb2VzbuKAmXQgbmVlZCB0byBiZSBjcnlwdG9ncmFwaGljYWxseSBzZWN1cmUsIG9ubHkg
Z3VhcmFudGVlIHVuaXF1ZW5lc3MuDQoNCj4+IEkgYXNzdW1lIHlvdXIgcHJvcG9zZWQgc2h1ZmZs
ZSBpcyBmdWxseSBkZXRlcm1pbmlzdGljIGFuZCBwcmVjb21wdXRlZA0KRmlzaGVyLVlhdGVzIHJl
cXVpcmVzIE8obikgc3BhY2UgY29ycmVzcG9uZGluZyB0byB0aGUgYmF0Y2ggc2l6ZSBidXQgdGhl
cmUgaXMgbm8gbmVlZCB0byBwcmVjb21wdXRlLiBZb3UgY2FuIGdlbmVyYXRlIHRoZSBuZXh0IHJh
bmRvbSBudW1iZXIgd2l0aGluIHRoZSBiYXRjaCBhcyB5b3UgZ28gZ2VuZXJhdGluZyBwYWNrZXRz
IG9yIHlvdSBjYW4gYWxzbyBkbyBpdCB1cCBmcm9udCBwZXIgYmF0Y2guIERldGVybWluaXNtIGRl
cGVuZHMgb24gUFJORyBhbmQgc2VlZC4NCg0KPj4gYWxsIG9mIHRoZXNlIHNjaGVtZXMgcmVxdWly
ZSBleHRyYSBtZW1vcnkgcGVyIGNvbm5lY3Rpb24NCkFncmVlZCB0aGVyZSBpcyBtZW1vcnkgb3Zl
cmhlYWQgYnV0IGl0cyBjb25zdGFudCBzaXplLiBXaXRoIGEgYmF0Y2ggc2l6ZSBvZiAxMjggeW91
IHdpbGwgbmVlZCAxMjgqc2l6ZW9mKFBOKSBieXRlcy4gSW4gcHJhY3RpY2UgaWYgd2UgZGVjaWRl
IGEgbXVjaCBzbWFsbGVyIGJhdGNoIHNpemUgaXMgc3VmZmljaWVudCBsaWtlIDMyLCB0aGVuIHRo
ZSBzcGFjZSByZXF1aXJlbWVudCBiZWNvbWVzIG11Y2ggbGVzcyBhbmQgd2lsbCBhbHNvIHJlcXVp
cmUgZmV3ZXIgYml0cyBmb3IgdGhlIG9mZnNldCB2YWx1ZXMgdG8gYmUgY29tbXVuaWNhdGVkIHBl
ciBwYWNrZXQuDQoNClRoYW5rcw0KDQpGcm9tOiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFtt
YWlsdG86bWlra2VsZmpAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBBcHJpbCA5LCAyMDE4IDI6
NTcgUE0NClRvOiBOaWNrIEJhbmtzIDxuaWJhbmtzQG1pY3Jvc29mdC5jb20+OyBQcmF2ZWVuIEJh
bGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0Bp
ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBTaW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4g
b3NzaWZpY2F0aW9uIHByZXZlbnRpb24NCg0KU29ycnksIHRoZSBsb3NzIGlzIGhhbmRsZWQgYnkg
ZHVwbGljYXRpb24gb2YgdGhlIHBhY2tldCBudW1iZXIgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9u
LCBidXQgdGhpcyB0aGVuIHByZXZlbnRzIGl0IGZyb20gcHJvdGVjdGluZyBhZ2FpbnN0IG9wdGlt
aXN0aWMgQUNLIGF0dGFja3MuDQoNCg0KDQpPbiA5IEFwcmlsIDIwMTggYXQgMjMuNTIuMjMsIE1p
a2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gKG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2Vs
ZmpAZ21haWwuY29tPikgd3JvdGU6DQpPSywgc28gdGhlIGhpZ2ggYml0cyBhcmUga2VwdCAtIHRo
aXMgc29sdmVzIHRoZSBsb3NzIHByb2JsZW0uDQpBbmQgdGhlIHNlbmRlciBkb2VzIG5vdCBoYXZl
IHRvIGRlY29kZSB0aGUgc2h1ZmZsZSBiZWNhdXNlIHRoZSBwYWNrZXQgbnVtYmVyIGlzIHRoZSBw
YWNrZXQgbnVtYmVyIC0gd2hpY2ggbWFrZXMgdGhlIHNodWZmbGUgb3JkZXIgbm9uLXJlY3Vycmlu
ZyBpbiB0aGUgYmF0Y2gsIGJ1dCBpdCBhbHNvIG1ha2VzIGxvc3MgZGV0ZWN0aW9uIHZlcnkgZGlm
ZmljdWx0IHRvIGRvIHdpdGggYW55IGRlZ3JlZSBvZiBwcmVjaXNpb24uDQpQcml2YWN5IGlzIGFs
c28gbm90IGEgZ29hbCBoZXJlIGJlY2F1c2UgdGhlIGhpZ2ggYml0cyBhcmUgYW4gaW1tZWRpYXRl
IGdpdmVhd2F5IGlmIHRoZSB3aW5kb3cgaXMgc21hbGwuIEp1c3QgdGhlIGF2ZXJhZ2UgZGlzdGFu
Y2UgYmV0d2VlbiB0d28gMCBieXRlcyBvbiB0aGUgbG93IHBhY2tldCBudW1iZXIgd291bGQgbWFr
ZSBhIHN0cm9uZyBjb3JyZWxhdGlvbi4NCg0KU28gSeKAmW0gbm90IHJlYWxseSBzdXJlIHdoeSAt
IGlmIGl0IGlzIHRvIHByZXZlbnQgbWlkZGxlIGJveGVzIGZyb20gYWRkaW5nIHJlb3JkZXJpbmcg
bGF0ZW5jeSBieSBiZWluZyB1bm9yZ2FuaXplZCwgb25lIGhhcyB0byBob3BlIHRoYXQgYSBtaWRk
bGVib3ggZG9lcyBub3QgdHJ5IHRvIHJlb3JkZXIgYW55d2F5LCBidXQgb2ssIEkgc2VlLg0KDQpJ
4oCZbSBub3QgY29udmluY2VkLiBCdXQgdGhlIHNjaGVtZSBoYXMgYW5vdGhlciBicmlsbGlhbnQg
cHJvcGVydHk6IGl0IHNvbHZlcyB0aGUgb3B0aW1pc3RpYyBBQ0sgYXR0YWNrIHByb2JsZW0gd2l0
aCBuZWVkaW5nIHRvIGludHJvZHVjZSBhbnkgYXJ0aWZpY2lhbCBnYXBzLiBUaGlzIGNvdWxkIGJl
IHVzZWZ1bCBldmVuIGlmIHBhY2tldCBudW1iZXJzIHdlcmUgZnVsbHkgZW5jcnlwdGVkIGJlY2F1
c2UgdGhlIGF0dGFja2VyIGlzIHRoZW4gdGhlIHJlY2VpdmVyIC0gd2VyZSBpdCBub3QgZm9yIHRo
ZSBwcm9ibGVtIHdpdGggbG9zcyBkZXRlY3Rpb24gYW5kIGVhcmx5IHJldHJhbnNtaXNzaW9uLg0K
DQoNCg0KT24gOSBBcHJpbCAyMDE4IGF0IDIzLjMzLjA1LCBOaWNrIEJhbmtzIChuaWJhbmtzQG1p
Y3Jvc29mdC5jb208bWFpbHRvOm5pYmFua3NAbWljcm9zb2Z0LmNvbT4pIHdyb3RlOg0KVGhlIGdv
YWwgaGVyZSB3b3VsZCBlc3NlbnRpYWxseSBqdXN0IHRvIHNodWZmbGUgdGhlIGJpdHMgaW4gdGhl
IGJvdHRvbSBieXRlLCBqdXN0IHRvIG1ha2UgZXZlcnl0aGluZyBsb29rIHJlb3JkZXJlZCB0byB0
aGUgbWlkZGxlYm94LiBZb3UgZG9u4oCZdCByZWFsbHkgaGF2ZSB0byBwcmVjb21wdXRlIGFueXRo
aW5nLCBhbmQgaXQgc2hvdWxkIGJlIGluZGVwZW5kZW50IG9mIEJEUCBvciBsb3NzLg0KDQpIZXJl
IGlzIGEgc2xpZ2h0IHZhcmlhdGlvbiBvbiBQcmF2ZWVu4oCZcyBzdWdnZXN0aW9uIChhc3N1bWVz
IHVzaW5nIGZ1bGwgMTI4IHBhY2tldCBiYXRjaCBzaXplKToNCg0KDQogICogICBQcmVhbGxvY2F0
ZSBhIGJ1ZmZlciBvZiAxMjggYnl0ZXMgYW5kIHByZXBvcHVsYXRlIGl0IHdpdGggdGhlIHZhbHVl
cyBvZiAwIHRvIDEyNy4NCiAgKiAgIEZvciBlYWNoIHBhY2tldCBzZW50LCByYW5kb21seSBncmFi
IGFuIGl0ZW0gKGkuZS4gdGhlIG9mZnNldCkgZnJvbSB3aGF04oCZcyBsZWZ0IGluIHRoZSBidWZm
ZXIsIGFuZCByZW1vdmUgaXQgKHN3YXAgd2l0aCBsYXN0IHZhbHVlLCBhbmQgZGVjcmVtZW50IGxl
bmd0aCkuDQogICogICBSZXBsYWNlIHRoZSBib3R0b20gYnl0ZSBvZiB0aGUgcmVhbCBwYWNrZXQg
bnVtYmVyIHdpdGggdGhlIG9mZnNldCBhbmQgcHV0IHRoYXQgbmV3IHBhY2tldCBudW1iZXIgaW4g
dGhlIGNsZWFyIHRleHQuDQogICogICBQdXQgdGhlIHJlYWwgYm90dG9tIGJ5dGUgb2YgdGhlIHJl
YWwgcGFja2V0IG51bWJlciBpbiB0aGUgZW5jcnlwdGVkIHBvcnRpb24uLg0KICAqICAgRW5jcnlw
dCB3aXRoIHRoZSBuZXcgY2xlYXJ0ZXh0IHBhY2tldCBudW1iZXIgYW5kIHNlbmQuDQogICogICBP
bmNlIHRoZSBwcmVhbGxvY2F0ZWQgYnVmZmVyIGlzIGVtcHR5LCBqdXN0IHNldCB0aGUgbGVuZ3Ro
IGJhY2sgdG8gMTI4IGFuZCBjb250aW51ZSBvbi4NCg0KVGhlIHNlbmRlciBkZWNyeXB0cyB1c2lu
ZyB0aGUgY2xlYXJ0ZXh0IHBhY2tldCBudW1iZXIuIFRoZW4gcmVwbGFjZXMgdGhlIGJvdHRvbSBi
eXRlIG9mIHRoZSBwYWNrZXQgbnVtYmVyIHdpdGggdGhlIG9mZnNldCBmcm9tIHRoZSBlbmNyeXB0
ZWQgcGF5bG9hZCB0byBnZXQgdGhlIHRydWUgcGFja2V0IG51bWJlci4NCg0KLSBOaWNrDQoNCkZy
b206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu
b3JnPj4gT24gQmVoYWxmIE9mIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NClNlbnQ6IE1vbmRh
eSwgQXByaWwgOSwgMjAxOCAyOjIwIFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHBy
YXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29t
QGRtYXJjLmlldGYub3JnPj47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVp
Y0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5n
IFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uDQoNCkkgaW5jaWRlbnRhbGx5IGltcGxlbWVudGVk
IEZpc2hlci1ZYXRlcyBhIGZldyBkYXlzIGFnb+KApg0KDQpCdXQgaWYgeW91IHBlcm1pdCBhIHdp
bmRvdywgeW91IGNhbiBhbHNvIGVuY3J5cHQgcGFja2V0IG51bWJlcnMgdXNpbmcgYW4gaW50ZXJu
YWwgcHJlY29tcHV0ZWQgQUVTIGRyaXZlbiBQUk5HIHN0cmVhbSAtIHRoaXMgaXMgYWJvdXQgMTZ4
IGZhc3RlciB0aGFuIGRpcmVjdCBlbmNyeXB0aW9uIGJlY2F1c2Ugb25lIGJsb2NrIGNvdmVycyA0
IHBhY2tldHMsIGFuZCBlbmNyeXB0aW9uIGNhbiBiZSBkb25lIGluIGEgcGFyYWxsZWwgcGlwZWxp
bmUgd2l0aCBjdXJyZW50IEFFUy1OSSBoYXJkd2FyZS4gWW91IG5lZWQgdG8gbWFwIHRoZSB3aW5k
b3cgaW4gYSBoYXNoIHRhYmxlLCBhbmQgaXQgbXVzdCBiZSBzbWFsbCBvciBjYWNoZSBlZmZlY3Rz
IG1ha2VzIGl0IHRvbyBleHBlbnNpdmUuDQoNCkhvd2V2ZXIsIGJpZyBwYWNrZXQgbG9zcyB3b3Vs
ZCBtYWtlIHRoaXMgc2NoZW1lIGVpdGhlciBpbmVmZmVjdGl2ZSwgb3IgY29tcGxpY2F0ZWQgd2l0
aCBmYWxsYmFjayBzZWFyY2guDQoNCkkgYXNzdW1lIHlvdXIgcHJvcG9zZWQgc2h1ZmZsZSBpcyBm
dWxseSBkZXRlcm1pbmlzdGljIGFuZCBwcmVjb21wdXRlZC4gQXNpZGUgZnJvbSB0aGUgcHJvYmxl
bXMgd2l0aCBhIHdpbmRvdyBzaXplIHZzIGxvc3MsIHRoaXMgbG9va3MgbGlrZSBhIHZlcnkgZ29v
ZCB3YXkgdG8gY29ycmVsYXRlIHBhY2tldHMgYmVjYXVzZSB0aGV5IG5vdyBleGhpYml0IGEgZGlz
dGluY3QgcGF0dGVybiBmb3IgZWFjaCBjb25uZWN0aW9uLiBTbyBJIGRvbuKAmXQgc2VlIHRoaXMg
YXMgYmVpbmcgd29ydGh3aGlsZSwgaWYgSSB1bmRlcnN0YW5kIHRoZSBzY2hlbWUgY29ycmVjdGx5
Lg0KDQpUaGUgc2h1ZmZsZSBjYW4gYWxzbyBiZSBzZWVuIGFzIGEgY2xldmVyIHdheSB0byBjcmVh
dGUgYSBwZXJmZWN0IGhhc2ggdGFibGUgZm9yIHRoZSBhYm92ZSBtZW50aW9uZWQgUFJORyBzY2hl
bWUsIGJ1dCBJIGRvbid0IHRoaW5rIGl0IHdvdWxkIGJlIGVmZmVjdGl2ZSBmb3IgbGFyZ2UgZW5v
dWdoIHdpbmRvd3MuDQoNCkZ1cnRoZXJtb3JlLCBhbGwgb2YgdGhlc2Ugc2NoZW1lcyByZXF1aXJl
IGV4dHJhIG1lbW9yeSBwZXIgY29ubmVjdGlvbiBhbmQgdGhpcyBjYW4gYmUgZXhwZW5zaXZlIGlm
IHRoZXJlIGFyZSAxMEsrIGlkbGUgY29ubmVjdGlvbnMgc2l0dGluZy4NCg0KLyoNCiAqIEdpdmVu
IGFuIHVuaW5pdGlhbGl6ZWQgYGluZGV4YCBvZiBgbmAgdWludDY0X3Qgc2xvdHM6DQogKiBQbGFj
ZSBhIHVuaXF1ZSB2YWx1ZSBpbiB0aGUgcmFuZ2UgMCAuLiBuIC0gMSBpbmNsdXNpdmUgaW4gZWFj
aCBzbG90DQogKiB1bmJpYXNlZCByYW5kb21seSAod2l0aGluIHRoZSBwcm5nIGxpbWl0cykuDQog
Kg0KICogQmFzZWQgb24gRmlzaGVyLVlhdGVzIHNodWZmbGUgLSBpbnNpZGUgb3V0IHZhcmlhbnQu
Lg0KICovDQpzdGF0aWMgaW5saW5lIHZvaWQgcmFuZDY0X2luaXRfc2h1ZmZsZV9iZWxvdyh1aW50
NjRfdCAqc3RhdGUsIHVpbnQ2NF90ICppbmRleCwgdWludDY0X3QgbikNCnsNCiAgICB1aW50NjRf
dCBpLCB4Ow0KDQogICAgZm9yIChpID0gMDsgaSA8IG47ICsraSkgew0KICAgICAgICB4ID0gcmFu
ZDY0X2JlbG93KHN0YXRlLCBpICsgMSk7IC8qIHVuc2lnbmVkIHJhbmRvbSB2YWx1ZSAoMCAuLiBp
KSAqLw0KICAgICAgICBpbmRleFtpXSA9IGluZGV4W3hdOyAvKiBVbmluaXRpYWxpemVkIGlmIGkg
PT0geCwgd2hpY2ggaXMgb2suICovDQogICAgICAgIGluZGV4W3hdID0gaTsNCiAgICB9DQp9DQoN
Cg0KTWlra2VsDQoNCg0KDQpPbiA5IEFwcmlsIDIwMTggYXQgMjIuNDguNDgsIFByYXZlZW4gQmFs
YXN1YnJhbWFuaWFuIChwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRv
OnByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4pIHdyb3RlOg0KVGhlIGN1cnJl
bnQgYXBwcm9hY2ggaW4gdGhlIGRyYWZ0IGZvciBwcmV2ZW50aW5nIFBOIG9zc2lmaWNhdGlvbiBp
cyB0byB1c2UgYSByYW5kb20gc3RhcnRpbmcgUE4uIEthenVobyBwb2ludGVkIG91dCBhIHByb2Js
ZW0gd2l0aCB0aGlzIGFwcHJvYWNoIHdoZXJlIG1pZGRsZWJveGVzIGNvdWxkIGludGVycHJldCB0
aGUgUE4gYXMgYSBzZXF1ZW5jZSBudW1iZXIuIEFuZCBpbiBhbiBhdHRlbXB0IHRvIGJlIOKAnGhl
bHBmdWzigJ0sIHRoZXkgY291bGQgcmVvcmRlciB0aGUgcGFja2V0cyBleGFjZXJiYXRpbmcgdGhl
IEhvTCBibG9ja2luZyBwcm9ibGVtIGFuZCBtYXkgY2F1c2UgaXNzdWVzIGZvciB1bnJlbGlhYmxl
IHNlbWFudGljcy4NCg0KSWYgdGhlIFBOIGluIHRoZSBjbGVhciAodGhlIG5vbmNlIHZhbHVlKSBk
aWRu4oCZdCBhbHdheXMgbW9ub3RvbmljYWxseSBpbmNyZWFzZSB0aGVuIGl0IHdpbGwgcHJlY2x1
ZGUgc3VjaCBiYWQgYmVoYXZpb3IgYnkgdGhlIG1pZGRsZWJveGVzLiBIZW5jZSB3ZSBuZWVkIHRv
IGZpbmQgYSBzaW1wbGUgdHJhbnNmb3JtIHRoYXQgaXMgbm90IG1vbm90b25pY2FsbHkgaW5jcmVh
c2luZyBhbmQgYWxzbyBub3QgcmVwZWF0aW5nLg0KDQpSZXF1aXJlbWVudHMgZm9yIGFueSBQTiB0
cmFuc2Zvcm0gaW4gdGhlIHNpbmdsZSBwYXRoIGNhc2U6DQoNCiAgMS4gIFRoZSBhY3R1YWwgUE4g
bXVzdCBhbHdheXMgaW5jcmVtZW50IGJ5IDEgYW5kIHdpbGwgYmUgdXNlZCBmb3IgZ2VuZXJhdGlu
ZyBBQ0tzIGluIEFDSyBmcmFtZXMuDQogIDIuICBUaGUgdHJhbnNmb3JtZWQgUE4gaW4gdGhlIGNs
ZWFyIGlzIGEgbm9uY2UgYW5kIG11c3Qgbm90IHJlcGVhdCBvdmVyIHRoZSBjb25uZWN0aW9uIGxp
ZmV0aW1lLg0KICAzLiAgTWlkZGxlYm94ZXMgbXVzdCBub3QgYmUgYWJsZSB0byBkZXRlcm1pbmUg
dGhlIGFjdHVhbCBQTi4gT25seSB0aGUgUVVJQyByZWNlaXZlciBzaG91bGQgYmUgYWJsZSB0byBk
byBzby4NCg0KUE5FIGlzIG9uZSBwb3NzaWJsZSB0cmFuc2Zvcm0gdGhhdCBtZWV0cyBhbGwgdGhl
c2UgcmVxdWlyZW1lbnRzIGJ1dCBpdCBpcyBleHBlbnNpdmUgQ1BVIGNvc3Qgd2lzZSBhbmQgaGFz
IGltcGxpY2F0aW9ucyBmb3IgaGFyZHdhcmUgaW1wbGVtZW50YXRpb25zLg0KDQpGb2xsb3dpbmcg
aXMgYSBwcm9wb3NhbCBmb3IgYW4gYWx0ZXJuYXRpdmUgc2ltcGxlIHRyYW5zZm9ybSB3aXRoIGxv
dyBDUFUgb3ZlcmhlYWQgd2hpY2ggc2F0aXNmaWVzIHRoZXNlIHRocmVlIHJlcXVpcmVtZW50cy4g
VGhlIGdvYWwgaXMgdG8gcHJvZHVjZSBhIG5vbi1yZXBlYXRpbmcgc2h1ZmZsZSBvZiB0aGUgb3Jp
Z2luYWwgc2V0IG9mIG51bWJlcnMuIFNpbmNlIHRoZSBQTiBzcGFjZSBpcyB2ZXJ5IGJpZyBhbmQg
ZWZmaWNpZW50IHNodWZmbGUgYWxnb3JpdGhtcyBoYXZlIE8obikgc3BhY2UgcmVxdWlyZW1lbnQs
IHdlIG5lZWQgdG8gZGVmaW5lIGEg4oCccmVvcmRlciBkZWdyZWXigJ0gb3IgYSDigJxiYXRjaCBz
aXpl4oCdIHdpdGhpbiB3aGljaCB3ZSB3aWxsIHNodWZmbGUgdGhlIHBhY2tldCBudW1iZXJzLg0K
DQpBcyBhbiBleGFtcGxlIGNvbnNpZGVyIHRoYXQgdGhlIHN0YXJ0aW5nIHJhbmRvbSBQTiBpcyAx
MDAuIFBlciB0aGUgY3VycmVudCBkcmFmdCB0aGUgYWN0dWFsIFBOIGluY3JlbWVudHMgYXMgZm9s
bG93czoNCiAgICAxMDAsIDEwMSwgMTAyLCAxMDMsIDEwNCwgICAgMTA1LCAxMDYsIDEwNywgMTA4
LCAxMDksIOKApiBhbmQgc28gZm9ydGgNCg0KTGV04oCZcyBhc3N1bWUgYSDigJxiYXRjaCBzaXpl
4oCdIG9mIDUuIFRoZW4gdXNpbmcgb25lIHBvc3NpYmxlIG91dGNvbWUgb2YgdGhlIHNodWZmbGVz
IHdlIGNhbiBnZW5lcmF0ZSB0aGUgZm9sbG93aW5nIGFzIHRoZSBjbGVhcnRleHQgbm9uY2VzOg0K
fCAgMTAyLCAxMDQsIDEwMywgMTAxLCAxMDAsIHwgIDEwNywgMTA1LCAxMDksIDEwOCwgMTA2IHwg
ICAs4oCmIGFuZCBzbyBmb3J0aA0KVGhlIGJhcnMgfCBpbmRpY2F0ZSBiYXRjaCBib3VuZGFyaWVz
Lg0KDQpPZiBjb3Vyc2Ugc2luY2Ugd2UgbmVlZCB0aGUgUVVJQyByZWNlaXZlciB0byBnZXQgdGhl
IGFjdHVhbCBQTiBmcm9tIHRoZSBjbGVhcnRleHQgdmFsdWUsIHdlIG5lZWQgdG8gY29tbXVuaWNh
dGUgdGhlIG9mZnNldHMgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBwYWNrZXQsIHdo
aWNoIGZvciB0aGlzIGV4YW1wbGUgd291bGQgYmU6DQp8ICArMiwgICAgKzMsICAgKzEsICAgLTIs
ICAgLTQsICAgIHwgICAgLTIsICAgKzEsICAgLTIsICAgIDAsICAgICArMyAgICB8LCAg4oCmLg0K
TWlkZGxlYm94ZXMgd2lsbCBub3QgYmUgYWJsZSB0byBzZWUgdGhlIG9mZnNldCB2YWx1ZXMgaW4g
dGhlIGNsZWFyLiBRVUlDIHJlY2VpdmVyIHdpbGwgbmVlZCB0byBkbyBhIHNpbXBsZSBhZGQgb2Yg
YSBzaWduZWQgbnVtYmVyIHRvIGdldCB0aGUgb3JpZ2luYWwgUE4uIFRoaXMgaXMgdmVyeSBjaGVh
cCBvcGVyYXRpb24gQ1BVIGNvc3Qgd2lzZS4NCg0KQSBRVUlDIHNlbmRlciBpbXBsZW1lbnRhdGlv
biBjYW4gcGljayBhbnkgc2l6ZSBmb3IgdGhlIHJlb3JkZXIgZGVncmVlLCB0aGUgdHJhZGUtb2Zm
IGlzIHRoZSBzcGFjZSBjb21wbGV4aXR5IGFuZCBwYWNrZXQgc3BhY2UgbmVlZGVkIHRvIGNvbW11
bmljYXRlIHRoZSBvZmZzZXRzLiBBIHJlb3JkZXIgZGVncmVlIHdpdGhpbiAxMjggbnVtYmVycyB3
aWxsIG5lZWQgYXQgbW9zdCBhbiBleHRyYSBieXRlIGluIHRoZSBlbmNyeXB0ZWQgaGVhZGVyIHRv
IGNvbW11bmljYXRlIHRoZSBzaWduZWQgb2Zmc2V0IHZhbHVlcy4gVGhlIDEyOCBiYXRjaCBzaXpl
IGkuZS4gYSAxIGJ5dGUgb2Zmc2V0IHNpemUgc2hvdWxkIGJlIG1vcmUgdGhhbiBlbm91Z2ggZW50
cm9weSB0byBkaXNjb3VyYWdlIGEgbWlkZGxlIGJveCBmcm9tIOKAnGZpeGluZyByZW9yZGVyaW5n
4oCdIGFuZCBpbiBwcmFjdGljZSB3ZSBtYXkgbmVlZCBsZXNzLg0KDQpPbmUgcG9zc2libGUgYWxn
b3JpdGhtIGZvciB0aGUgc2h1ZmZsZSBpcyB0aGUgRmlzaGVy4oCTWWF0ZXMgKEtudXRoKSBzaHVm
ZmxlIGFzIGRvY3VtZW50ZWQgaGVyZTogaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRmlz
aGVy4oCTWWF0ZXNfc2h1ZmZsZTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0
bG9vay5jb20vP3VybD1odHRwczolMkYlMkZlbi53aWtpcGVkaWEub3JnJTJGd2lraSUyRkZpc2hl
ciVFMiU4MCU5M1lhdGVzX3NodWZmbGUmZGF0YT0wMiU3QzAxJTdDbmliYW5rcyU0MG1pY3Jvc29m
dC5jb20lN0NjYjFkMmRlYWI1NTE0MTlmYjMyMjA4ZDU5ZTVmYjA2OSU3QzcyZjk4OGJmODZmMTQx
YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY1ODkwNTYxOTM4NjI4Njgmc2RhdGE9SVFo
TlByMVE2U2clMkI1NG9BQ2xieUdoSGQ2cTdybHdyUDlldUg2UWtZNkVVJTNEJnJlc2VydmVkPTA+
IC4gUGxlYXNlIHNlZSB0aGUg4oCcTW9kZXJuIG1ldGhvZOKAnSBzZWN0aW9uIHdoaWNoIGlzIGlu
LXBsYWNlLiBUaGUgcmFuZG9tIG51bWJlciBnZW5lcmF0b3IgZG9lc27igJl0IGhhdmUgdG8gYmUg
YSBzZWN1cmUgdmFyaWFudC4NCg0KT25lIGFkdmFudGFnZSBvZiBzdWNoIGEgc2NoZW1lIGlzIHRo
YXQgcGFja2V0IGxvc3MgY2FuIHN0aWxsIGJlIGluZmVycmVkIGJ5IGxvb2tpbmcgYXQgZWFjaCBi
YXRjaCBzaXplZCBzZXQgb2YgdGhlIG5vbmNlIChwYWNrZXQgbnVtYmVycykuIEZvciBleGFtcGxl
IGlmIHRoZSBiYXRjaCBzaXplIGlzIDEyOCwgdGhlbiBtaXNzaW5nIG51bWJlcnMgaW4gdGhpcyBi
YXRjaCBzaXplIChvciBhIG11bHRpcGxlKSB3aWxsIHNob3cgdGhlIGV4dGVudCBvZiBwYWNrZXQg
bG9zcy4gVGhlIG90aGVyIGFkdmFudGFnZSBpcyB0aGF0IGEgUVVJQyBkaWFnbm9zdGljIGNvbm5l
Y3Rpb24gY2FuIHRyaXZpYWxseSBkZXRlY3QgYSBiYWQgbWlkZGxlYm94IHRoYXQgdHJpZXMgdG8g
cmVvcmRlciB0aGUgbm9uY2UgaW4gc2VxdWVuY2UgYXMgaXQgd2lsbCBiZSBlYXNpbHkgZGlzdGlu
Z3Vpc2hhYmxlIGZyb20gYSByYW5kb20gbmV0d29yayByZW9yZGVyLg0KDQoNCg==

--_000_CY4PR21MB0630A663DA8595170C9135C1B6BE0CY4PR21MB0630namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC
My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv
ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S
RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj
b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt
LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2
ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp
Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0
ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFs
MCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9y
bWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox
MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5haXJtYWlsb24s
IGxpLmFpcm1haWxvbiwgZGl2LmFpcm1haWxvbg0KCXttc28tc3R5bGUtbmFtZTphaXJtYWlsX29u
Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5haXJtYWlsb24wLCBs
aS5haXJtYWlsb24wLCBkaXYuYWlybWFpbG9uMA0KCXttc28tc3R5bGUtbmFtZTphaXJtYWlsb247
DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBw
dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUy
MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt
dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u
MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu
aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozMjk1Mjg0NzA7DQoJbXNvLWxpc3Qt
dGVtcGxhdGUtaWRzOjExMzE2ODIwMDQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5
bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t
YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps
ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu
MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt
c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs
MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz
dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl
bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp
emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1p
ZDo4MDIxMjAyNjU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTU2ODMwOTUyO30NCkBsaXN0
IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs
MTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx
OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6
bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl
bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTps
ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2lu
LWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp
Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0
Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv
eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi
IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZndDsmZ3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiBidXQgaXQgYWxzbyBtYWtlcyBs
b3NzIGRldGVjdGlvbiB2ZXJ5IGRpZmZpY3VsdCB0byBkbyB3aXRoIGFueSBkZWdyZWUgb2YgcHJl
Y2lzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPkxvc3MgZGV0ZWN0aW9uIGlzIGFjdHVhbGx5IHN0cmFpZ2h0Zm9yd2FyZCBh
cyBsb25nIGFzIHRoZSBtaWRkbGVib3gga25vd3MgdGhlIGJhdGNoIHNpemUuIEl0IHdpbGwgbmVl
ZCB0byBsb29rIGZvciBtaXNzaW5nIHBhY2tldCBudW1iZXJzIHdpdGhpbiBhIGJhdGNoLiBSZW9y
ZGVyIGRldGVjdGlvbg0KIGlzIGhvd2V2ZXIgZXh0cmVtZWx5IGRpZmZpY3VsdCBzaW5jZSB0aGUg
c2NoZW1lIGl0c2VsZiBkb2VzIHJlb3JkZXJpbmcgb2YgdGhlIG5vbmNlLg0KPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7IDxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj4NCnlvdSBjYW4gYWxzbyBlbmNyeXB0IHBhY2tldCBudW1iZXJzIHVz
aW5nIGFuIGludGVybmFsIHByZWNvbXB1dGVkIEFFUyBkcml2ZW4gUFJORyBzdHJlPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFu
IGltcGxlbWVudGF0aW9uIGNvdWxkIGJ1dCBpdHMgbm90IGEgbXVzdC4gVGhlIHJhbmRvbSBnZW5l
cmF0aW9uIGZvciBzaHVmZmxpbmcgZG9lc27igJl0IG5lZWQgdG8gYmUgY3J5cHRvZ3JhcGhpY2Fs
bHkgc2VjdXJlLCBvbmx5IGd1YXJhbnRlZSB1bmlxdWVuZXNzLg0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPiBJIGFzc3VtZSB5b3VyIHByb3Bvc2VkIHNodWZmbGUgaXMgZnVsbHkgZGV0ZXJt
aW5pc3RpYyBhbmQgcHJlY29tcHV0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RmlzaGVyLVlhdGVzIHJlcXVpcmVzIE8obikg
c3BhY2UgY29ycmVzcG9uZGluZyB0byB0aGUgYmF0Y2ggc2l6ZSBidXQgdGhlcmUgaXMgbm8gbmVl
ZCB0byBwcmVjb21wdXRlLiBZb3UgY2FuIGdlbmVyYXRlIHRoZSBuZXh0IHJhbmRvbSBudW1iZXIg
d2l0aGluIHRoZSBiYXRjaCBhcyB5b3UgZ28gZ2VuZXJhdGluZw0KIHBhY2tldHMgb3IgeW91IGNh
biBhbHNvIGRvIGl0IHVwIGZyb250IHBlciBiYXRjaC4gRGV0ZXJtaW5pc20gZGVwZW5kcyBvbiBQ
Uk5HIGFuZCBzZWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4gYWxsIG9mIHRoZXNlIHNj
aGVtZXMgcmVxdWlyZSBleHRyYSBtZW1vcnkgcGVyIGNvbm5lY3Rpb248bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QWdyZWVkIHRo
ZXJlIGlzIG1lbW9yeSBvdmVyaGVhZCBidXQgaXRzIGNvbnN0YW50IHNpemUuIFdpdGggYSBiYXRj
aCBzaXplIG9mIDEyOCB5b3Ugd2lsbCBuZWVkIDEyOCpzaXplb2YoUE4pIGJ5dGVzLiBJbiBwcmFj
dGljZSBpZiB3ZSBkZWNpZGUgYSBtdWNoIHNtYWxsZXIgYmF0Y2ggc2l6ZSBpcw0KIHN1ZmZpY2ll
bnQgbGlrZSAzMiwgdGhlbiB0aGUgc3BhY2UgcmVxdWlyZW1lbnQgYmVjb21lcyBtdWNoIGxlc3Mg
YW5kIHdpbGwgYWxzbyByZXF1aXJlIGZld2VyIGJpdHMgZm9yIHRoZSBvZmZzZXQgdmFsdWVzIHRv
IGJlIGNvbW11bmljYXRlZCBwZXIgcGFja2V0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3M8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk
ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1p
a2tlbGZqQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDksIDIw
MTggMjo1NyBQTTxicj4NCjxiPlRvOjwvYj4gTmljayBCYW5rcyAmbHQ7bmliYW5rc0BtaWNyb3Nv
ZnQuY29tJmd0OzsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5j
b20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJFOiBTaW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9u
IHByZXZlbnRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlNvcnJ5LCB0aGUgbG9z
cyBpcyBoYW5kbGVkIGJ5IGR1cGxpY2F0aW9uIG9mIHRoZSBwYWNrZXQgbnVtYmVyIGluIHRoZSBl
bmNyeXB0ZWQgcG9ydGlvbiwgYnV0IHRoaXMgdGhlbiBwcmV2ZW50cyBpdCBmcm9tIHByb3RlY3Rp
bmcgYWdhaW5zdCBvcHRpbWlzdGljIEFDSyBhdHRhY2tzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3Bfc2lnbl8xNTIzMzEwOTIyNzk0MjUzODI0Ij4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iYWly
bWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gOSBBcHJpbCAyMDE4IGF0IDIzLjUyLjIzLCBN
aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICg8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwu
Y29tIj5taWtrZWxmakBnbWFpbC5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T0ssIHNvIHRoZSBoaWdoIGJpdHMgYXJlIGtl
cHQgLSB0aGlzIHNvbHZlcyB0aGUgbG9zcyBwcm9ibGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+QW5kIHRoZSBzZW5kZXIgZG9lcyBub3QgaGF2ZSB0byBkZWNv
ZGUgdGhlIHNodWZmbGUgYmVjYXVzZSB0aGUgcGFja2V0IG51bWJlciBpcyB0aGUgcGFja2V0IG51
bWJlciAtIHdoaWNoIG1ha2VzIHRoZSBzaHVmZmxlIG9yZGVyIG5vbi1yZWN1cnJpbmcgaW4gdGhl
IGJhdGNoLCBidXQgaXQgYWxzbw0KIG1ha2VzIGxvc3MgZGV0ZWN0aW9uIHZlcnkgZGlmZmljdWx0
IHRvIGRvIHdpdGggYW55IGRlZ3JlZSBvZiBwcmVjaXNpb24uPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj5Qcml2YWN5IGlzIGFsc28gbm90IGEgZ29hbCBoZXJlIGJl
Y2F1c2UgdGhlIGhpZ2ggYml0cyBhcmUgYW4gaW1tZWRpYXRlIGdpdmVhd2F5IGlmIHRoZSB3aW5k
b3cgaXMgc21hbGwuIEp1c3QgdGhlIGF2ZXJhZ2UgZGlzdGFuY2UgYmV0d2VlbiB0d28gMCBieXRl
cyBvbiB0aGUgbG93IHBhY2tldCBudW1iZXINCiB3b3VsZCBtYWtlIGEgc3Ryb25nIGNvcnJlbGF0
aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9t
Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5TbyBJ4oCZbSBub3QgcmVh
bGx5IHN1cmUgd2h5IC0gaWYgaXQgaXMgdG8gcHJldmVudCBtaWRkbGUgYm94ZXMgZnJvbSBhZGRp
bmcgcmVvcmRlcmluZyBsYXRlbmN5IGJ5IGJlaW5nIHVub3JnYW5pemVkLCBvbmUgaGFzIHRvIGhv
cGUgdGhhdCBhIG1pZGRsZWJveCBkb2VzIG5vdCB0cnkgdG8gcmVvcmRlcg0KIGFueXdheSwgYnV0
IG9rLCBJIHNlZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29w
X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9t
Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SeKAmW0gbm90
IGNvbnZpbmNlZC4gQnV0IHRoZSBzY2hlbWUgaGFzIGFub3RoZXIgYnJpbGxpYW50IHByb3BlcnR5
OiBpdCBzb2x2ZXMgdGhlIG9wdGltaXN0aWMgQUNLIGF0dGFjayBwcm9ibGVtIHdpdGggbmVlZGlu
ZyB0byBpbnRyb2R1Y2UgYW55IGFydGlmaWNpYWwgZ2Fwcy4gVGhpcyBjb3VsZCBiZQ0KIHVzZWZ1
bCBldmVuIGlmIHBhY2tldCBudW1iZXJzIHdlcmUgZnVsbHkgZW5jcnlwdGVkIGJlY2F1c2UgdGhl
IGF0dGFja2VyIGlzIHRoZW4gdGhlIHJlY2VpdmVyIC0gd2VyZSBpdCBub3QgZm9yIHRoZSBwcm9i
bGVtIHdpdGggbG9zcyBkZXRlY3Rpb24gYW5kIGVhcmx5IHJldHJhbnNtaXNzaW9uLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3Bfc2lnbl8xNTIzMzA5ODEwODQ0
MzA4NzM2Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gOSBBcHJpbCAyMDE4
IGF0IDIzLjMzLjA1LCBOaWNrIEJhbmtzICg8YSBocmVmPSJtYWlsdG86bmliYW5rc0BtaWNyb3Nv
ZnQuY29tIj5uaWJhbmtzQG1pY3Jvc29mdC5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPlRoZSBnb2FsIGhlcmUgd291bGQgZXNzZW50aWFsbHkganVzdCB0byBz
aHVmZmxlIHRoZSBiaXRzIGluIHRoZSBib3R0b20gYnl0ZSwganVzdCB0byBtYWtlIGV2ZXJ5dGhp
bmcgbG9vayByZW9yZGVyZWQNCiB0byB0aGUgbWlkZGxlYm94LiBZb3UgZG9u4oCZdCByZWFsbHkg
aGF2ZSB0byBwcmVjb21wdXRlIGFueXRoaW5nLCBhbmQgaXQgc2hvdWxkIGJlIGluZGVwZW5kZW50
IG9mIEJEUCBvciBsb3NzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhlcmUgaXMgYSBzbGlnaHQg
dmFyaWF0aW9uIG9uIFByYXZlZW7igJlzIHN1Z2dlc3Rpb24gKGFzc3VtZXMgdXNpbmcgZnVsbCAx
MjggcGFja2V0IGJhdGNoIHNpemUpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAg
bGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlByZWFsbG9jYXRlIGEgYnVmZmVyIG9m
IDEyOCBieXRlcyBhbmQgcHJlcG9wdWxhdGUgaXQgd2l0aCB0aGUgdmFsdWVzIG9mIDAgdG8gMTI3
LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps
MCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Rm9yIGVhY2ggcGFja2V0IHNlbnQs
IHJhbmRvbWx5IGdyYWIgYW4gaXRlbSAoaS5lLiB0aGUgb2Zmc2V0KSBmcm9tIHdoYXTigJlzIGxl
ZnQgaW4gdGhlIGJ1ZmZlciwgYW5kIHJlbW92ZSBpdCAoc3dhcCB3aXRoIGxhc3QgdmFsdWUsIGFu
ZCBkZWNyZW1lbnQgbGVuZ3RoKS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlJl
cGxhY2UgdGhlIGJvdHRvbSBieXRlIG9mIHRoZSByZWFsIHBhY2tldCBudW1iZXIgd2l0aCB0aGUg
b2Zmc2V0IGFuZCBwdXQgdGhhdCBuZXcgcGFja2V0IG51bWJlciBpbiB0aGUgY2xlYXIgdGV4dC48
bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAg
bGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlB1dCB0aGUgcmVhbCBib3R0b20gYnl0
ZSBvZiB0aGUgcmVhbCBwYWNrZXQgbnVtYmVyIGluIHRoZSBlbmNyeXB0ZWQgcG9ydGlvbi4uPG86
cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxl
dmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5FbmNyeXB0IHdpdGggdGhlIG5ldyBjbGVh
cnRleHQgcGFja2V0IG51bWJlciBhbmQgc2VuZC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPk9uY2UgdGhlIHByZWFsbG9jYXRlZCBidWZmZXIgaXMgZW1wdHksIGp1c3Qgc2V0IHRo
ZSBsZW5ndGggYmFjayB0byAxMjggYW5kIGNvbnRpbnVlIG9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv
bGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPlRoZSBzZW5kZXIgZGVjcnlwdHMgdXNpbmcgdGhlIGNsZWFydGV4dCBwYWNrZXQg
bnVtYmVyLiBUaGVuIHJlcGxhY2VzIHRoZSBib3R0b20gYnl0ZSBvZiB0aGUgcGFja2V0IG51bWJl
ciB3aXRoDQogdGhlIG9mZnNldCBmcm9tIHRoZSBlbmNyeXB0ZWQgcGF5bG9hZCB0byBnZXQgdGhl
IHRydWUgcGFja2V0IG51bWJlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4tIE5pY2s8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp
biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4gUVVJQyAmbHQ7PGEgaHJlZj0ibWFpbHRv
OnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxi
Pk9uIEJlaGFsZiBPZiA8L2I+TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjxicj4NCjxiPlNlbnQ6
PC9iPiBNb25kYXksIEFwcmlsIDksIDIwMTggMjoyMCBQTTxicj4NCjxiPlRvOjwvYj4gUHJhdmVl
biBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5j
b21AZG1hcmMuaWV0Zi5vcmciPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7
OyBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGll
dGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFNpbXBsZSB0cmFuc2Zvcm0g
Zm9yIGltcHJvdmluZyBQTiBvc3NpZmljYXRpb24gcHJldmVudGlvbjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJibG9vcF9jdXN0
b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaW5j
aWRlbnRhbGx5IGltcGxlbWVudGVkIEZpc2hlci1ZYXRlcyBhIGZldyBkYXlzIGFnb+KApjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QnV0IGlmIHlvdSBwZXJtaXQgYSB3
aW5kb3csIHlvdSBjYW4gYWxzbyBlbmNyeXB0IHBhY2tldCBudW1iZXJzIHVzaW5nIGFuIGludGVy
bmFsIHByZWNvbXB1dGVkIEFFUyBkcml2ZW4gUFJORyBzdHJlYW0NCiAtIHRoaXMgaXMgYWJvdXQg
MTZ4IGZhc3RlciB0aGFuIGRpcmVjdCBlbmNyeXB0aW9uIGJlY2F1c2Ugb25lIGJsb2NrIGNvdmVy
cyA0IHBhY2tldHMsIGFuZCBlbmNyeXB0aW9uIGNhbiBiZSBkb25lIGluIGEgcGFyYWxsZWwgcGlw
ZWxpbmUgd2l0aCBjdXJyZW50IEFFUy1OSSBoYXJkd2FyZS4gWW91IG5lZWQgdG8gbWFwIHRoZSB3
aW5kb3cgaW4gYSBoYXNoIHRhYmxlLCBhbmQgaXQgbXVzdCBiZSBzbWFsbCBvciBjYWNoZSBlZmZl
Y3RzIG1ha2VzIGl0DQogdG9vIGV4cGVuc2l2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPkhvd2V2ZXIsIGJpZyBwYWNrZXQgbG9zcyB3b3VsZCBtYWtlIHRoaXMgc2No
ZW1lIGVpdGhlciBpbmVmZmVjdGl2ZSwgb3IgY29tcGxpY2F0ZWQgd2l0aCBmYWxsYmFjayBzZWFy
Y2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21m
b250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGFzc3VtZSB5b3Vy
IHByb3Bvc2VkIHNodWZmbGUgaXMgZnVsbHkgZGV0ZXJtaW5pc3RpYyBhbmQgcHJlY29tcHV0ZWQu
IEFzaWRlIGZyb20gdGhlIHByb2JsZW1zIHdpdGggYSB3aW5kb3cgc2l6ZQ0KIHZzIGxvc3MsIHRo
aXMgbG9va3MgbGlrZSBhIHZlcnkgZ29vZCB3YXkgdG8gY29ycmVsYXRlIHBhY2tldHMgYmVjYXVz
ZSB0aGV5IG5vdyBleGhpYml0IGEgZGlzdGluY3QgcGF0dGVybiBmb3IgZWFjaCBjb25uZWN0aW9u
LiBTbyBJIGRvbuKAmXQgc2VlIHRoaXMgYXMgYmVpbmcgd29ydGh3aGlsZSwgaWYgSSB1bmRlcnN0
YW5kIHRoZSBzY2hlbWUgY29ycmVjdGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg
aWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+VGhlIHNodWZmbGUgY2FuIGFsc28gYmUgc2VlbiBhcyBhIGNsZXZlciB3YXkgdG8g
Y3JlYXRlIGEgcGVyZmVjdCBoYXNoIHRhYmxlIGZvciB0aGUgYWJvdmUgbWVudGlvbmVkIFBSTkcg
c2NoZW1lLA0KIGJ1dCBJIGRvbid0IHRoaW5rIGl0IHdvdWxkIGJlIGVmZmVjdGl2ZSBmb3IgbGFy
Z2UgZW5vdWdoIHdpbmRvd3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk
PSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxv
b3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij5GdXJ0aGVybW9yZSwgYWxsIG9mIHRoZXNlIHNjaGVtZXMgcmVxdWlyZSBleHRyYSBtZW1vcnkg
cGVyIGNvbm5lY3Rpb24gYW5kIHRoaXMgY2FuIGJlIGV4cGVuc2l2ZSBpZiB0aGVyZSBhcmUgMTBL
JiM0MzsNCiBpZGxlIGNvbm5lY3Rpb25zIHNpdHRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPi8qPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyogR2l2ZW4gYW4gdW5p
bml0aWFsaXplZCBgaW5kZXhgIG9mIGBuYCB1aW50NjRfdCBzbG90czo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7KiBQbGFjZSBhIHVuaXF1ZSB2YWx1
ZSBpbiB0aGUgcmFuZ2UgMCAuLiBuIC0gMSBpbmNsdXNpdmUgaW4gZWFjaCBzbG90PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyogdW5iaWFzZWQgcmFu
ZG9tbHkgKHdpdGhpbiB0aGUgcHJuZyBsaW1pdHMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsqPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyogQmFzZWQgb24gRmlzaGVyLVlhdGVzIHNodWZmbGUgLSBp
bnNpZGUgb3V0IHZhcmlhbnQuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBp
ZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj4mbmJzcDsqLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i
Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj5zdGF0aWMgaW5saW5lIHZvaWQgcmFuZDY0X2luaXRfc2h1ZmZsZV9iZWxvdyh1aW50NjRf
dCAqc3RhdGUsIHVpbnQ2NF90ICppbmRleCwgdWludDY0X3Qgbik8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IHVpbnQ2NF90IGksIHg7PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IGZvciAoaSA9IDA7IGkg
Jmx0OyBuOyAmIzQzOyYjNDM7aSkgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
diBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgeCA9IHJhbmQ2NF9iZWxvdyhz
dGF0ZSwgaSAmIzQzOyAxKTsgLyogdW5zaWduZWQgcmFuZG9tIHZhbHVlICgwIC4uIGkpICovPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBpbmRleFtpXSA9IGluZGV4W3hdOyAvKiBVbmluaXRpYWxpemVkIGlmIGkg
PT0geCwgd2hpY2ggaXMgb2suICovPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmRleFt4XSA9IGk7PG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgfTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj59PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWw8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uMCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPk9uIDkgQXByaWwgMjAxOCBhdCAyMi40OC40OCwgUHJhdmVlbiBCYWxhc3VicmFtYW5p
YW4gKDxhIGhyZWY9Im1haWx0bzpwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmci
PnByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4pIHdyb3RlOjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGN1cnJlbnQgYXBwcm9hY2ggaW4gdGhlIGRyYWZ0
IGZvciBwcmV2ZW50aW5nIFBOIG9zc2lmaWNhdGlvbiBpcyB0byB1c2UgYSByYW5kb20gc3RhcnRp
bmcgUE4uIEthenVobyBwb2ludGVkDQogb3V0IGEgcHJvYmxlbSB3aXRoIHRoaXMgYXBwcm9hY2gg
d2hlcmUgbWlkZGxlYm94ZXMgY291bGQgaW50ZXJwcmV0IHRoZSBQTiBhcyBhIHNlcXVlbmNlIG51
bWJlci4gQW5kIGluIGFuIGF0dGVtcHQgdG8gYmUg4oCcaGVscGZ1bOKAnSwgdGhleSBjb3VsZCBy
ZW9yZGVyIHRoZSBwYWNrZXRzIGV4YWNlcmJhdGluZyB0aGUgSG9MIGJsb2NraW5nIHByb2JsZW0g
YW5kIG1heSBjYXVzZSBpc3N1ZXMgZm9yIHVucmVsaWFibGUgc2VtYW50aWNzLg0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+SWYgdGhlIFBODQo8aT5pbiB0aGUgY2xlYXI8L2k+ICh0aGUgbm9uY2Ug
dmFsdWUpIGRpZG7igJl0IGFsd2F5cyBtb25vdG9uaWNhbGx5IGluY3JlYXNlIHRoZW4gaXQgd2ls
bCBwcmVjbHVkZSBzdWNoIGJhZCBiZWhhdmlvciBieSB0aGUgbWlkZGxlYm94ZXMuIEhlbmNlIHdl
IG5lZWQgdG8gZmluZCBhIHNpbXBsZSB0cmFuc2Zvcm0gdGhhdCBpcyBub3QgbW9ub3RvbmljYWxs
eSBpbmNyZWFzaW5nIGFuZCBhbHNvIG5vdCByZXBlYXRpbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj5SZXF1aXJlbWVudHMgZm9yIGFueSBQTiB0cmFuc2Zvcm0gaW4gdGhlIHNpbmdsZSBwYXRo
IGNhc2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSJhIj4NCjxs
aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KPHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPlRoZSBhY3R1YWwgUE4gbXVzdCBhbHdheXMgaW5jcmVtZW50IGJ5IDEgYW5kIHdp
bGwgYmUgdXNlZCBmb3IgZ2VuZXJhdGluZyBBQ0tzIGluIEFDSyBmcmFtZXMuDQo8bzpwPjwvbzpw
Pjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm
bzIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSB0cmFuc2Zvcm1lZCBQTiBpbiB0aGUgY2xlYXIg
aXMgYSBub25jZSBhbmQgbXVzdCBub3QgcmVwZWF0IG92ZXIgdGhlIGNvbm5lY3Rpb24gbGlmZXRp
bWUuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0
OmwxIGxldmVsMSBsZm8yIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWRkbGVib3hlcyBtdXN0IG5v
dCBiZSBhYmxlIHRvIGRldGVybWluZSB0aGUgYWN0dWFsIFBOLiBPbmx5IHRoZSBRVUlDIHJlY2Vp
dmVyIHNob3VsZCBiZSBhYmxlIHRvIGRvIHNvLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PlBORSBpcyBvbmUgcG9zc2libGUgdHJhbnNmb3JtIHRoYXQgbWVldHMgYWxsIHRoZXNlIHJlcXVp
cmVtZW50cyBidXQgaXQgaXMgZXhwZW5zaXZlIENQVSBjb3N0IHdpc2UgYW5kIGhhcyBpbXBsaWNh
dGlvbnMNCiBmb3IgaGFyZHdhcmUgaW1wbGVtZW50YXRpb25zLiA8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj5Gb2xsb3dpbmcgaXMgYSBwcm9wb3NhbCBmb3IgYW4gYWx0ZXJuYXRpdmUgc2ltcGxlIHRy
YW5zZm9ybSB3aXRoIGxvdyBDUFUgb3ZlcmhlYWQgd2hpY2ggc2F0aXNmaWVzIHRoZXNlIHRocmVl
IHJlcXVpcmVtZW50cy4NCiBUaGUgZ29hbCBpcyB0byBwcm9kdWNlIGEgbm9uLXJlcGVhdGluZyBz
aHVmZmxlIG9mIHRoZSBvcmlnaW5hbCBzZXQgb2YgbnVtYmVycy4gU2luY2UgdGhlIFBOIHNwYWNl
IGlzIHZlcnkgYmlnIGFuZCBlZmZpY2llbnQgc2h1ZmZsZSBhbGdvcml0aG1zIGhhdmUgTyhuKSBz
cGFjZSByZXF1aXJlbWVudCwgd2UgbmVlZCB0byBkZWZpbmUgYSDigJxyZW9yZGVyIGRlZ3JlZeKA
nSBvciBhIOKAnGJhdGNoIHNpemXigJ0gd2l0aGluIHdoaWNoIHdlIHdpbGwgc2h1ZmZsZQ0KIHRo
ZSBwYWNrZXQgbnVtYmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BcyBhbiBleGFtcGxlIGNv
bnNpZGVyIHRoYXQgdGhlIHN0YXJ0aW5nIHJhbmRvbSBQTiBpcyAxMDAuIFBlciB0aGUgY3VycmVu
dCBkcmFmdCB0aGUgYWN0dWFsIFBOIGluY3JlbWVudHMgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz
cDsmbmJzcDsmbmJzcDsgMTAwLCAxMDEsIDEwMiwgMTAzLCAxMDQsICZuYnNwOyZuYnNwOyZuYnNw
OzEwNSwgMTA2LCAxMDcsIDEwOCwgMTA5LCDigKYgYW5kIHNvIGZvcnRoPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+TGV04oCZcyBhc3N1bWUgYSDigJxiYXRjaCBzaXpl4oCdIG9mIDUuIFRoZW4gdXNp
bmcgb25lIHBvc3NpYmxlIG91dGNvbWUgb2YgdGhlIHNodWZmbGVzIHdlIGNhbiBnZW5lcmF0ZSB0
aGUgZm9sbG93aW5nDQogYXMgdGhlIGNsZWFydGV4dCBub25jZXM6PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+fCZuYnNwOyAx
MDIsIDEwNCwgMTAzLCAxMDEsIDEwMCwgfCZuYnNwOyAxMDcsIDEwNSwgMTA5LCAxMDgsIDEwNiB8
ICZuYnNwOyZuYnNwOyzigKYgYW5kIHNvIGZvcnRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGJhcnMgfCBpbmRpY2F0
ZSBiYXRjaCBib3VuZGFyaWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9mIGNvdXJzZSBzaW5j
ZSB3ZSBuZWVkIHRoZSBRVUlDIHJlY2VpdmVyIHRvIGdldCB0aGUgYWN0dWFsIFBOIGZyb20gdGhl
IGNsZWFydGV4dCB2YWx1ZSwgd2UgbmVlZCB0byBjb21tdW5pY2F0ZQ0KIHRoZSBvZmZzZXRzIGlu
IHRoZSBlbmNyeXB0ZWQgcG9ydGlvbiBvZiB0aGUgcGFja2V0LCB3aGljaCBmb3IgdGhpcyBleGFt
cGxlIHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnwmbmJzcDsgJiM0MzsyLCAmbmJzcDsmbmJzcDsmbmJzcDsm
IzQzOzMsICZuYnNwOyZuYnNwOyYjNDM7MSwgJm5ic3A7Jm5ic3A7LTIsICZuYnNwOyZuYnNwOy00
LCZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0yLCAmbmJzcDsmbmJzcDsm
IzQzOzEsICZuYnNwOyZuYnNwOy0yLCAmbmJzcDsmbmJzcDsmbmJzcDswLCAmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmIzQzOzMgJm5ic3A7Jm5ic3A7Jm5ic3A7fCwgJm5ic3A74oCmLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
Pk1pZGRsZWJveGVzIHdpbGwgbm90IGJlIGFibGUgdG8gc2VlIHRoZSBvZmZzZXQgdmFsdWVzIGlu
IHRoZSBjbGVhci4gUVVJQyByZWNlaXZlciB3aWxsIG5lZWQgdG8gZG8gYSBzaW1wbGUgYWRkDQog
b2YgYSBzaWduZWQgbnVtYmVyIHRvIGdldCB0aGUgb3JpZ2luYWwgUE4uIFRoaXMgaXMgdmVyeSBj
aGVhcCBvcGVyYXRpb24gQ1BVIGNvc3Qgd2lzZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkEg
UVVJQyBzZW5kZXIgaW1wbGVtZW50YXRpb24gY2FuIHBpY2sgYW55IHNpemUgZm9yIHRoZSByZW9y
ZGVyIGRlZ3JlZSwgdGhlIHRyYWRlLW9mZiBpcyB0aGUgc3BhY2UgY29tcGxleGl0eSBhbmQNCiBw
YWNrZXQgc3BhY2UgbmVlZGVkIHRvIGNvbW11bmljYXRlIHRoZSBvZmZzZXRzLiBBIHJlb3JkZXIg
ZGVncmVlIHdpdGhpbiAxMjggbnVtYmVycyB3aWxsIG5lZWQgYXQgbW9zdCBhbiBleHRyYSBieXRl
IGluIHRoZSBlbmNyeXB0ZWQgaGVhZGVyIHRvIGNvbW11bmljYXRlIHRoZSBzaWduZWQgb2Zmc2V0
IHZhbHVlcy4gVGhlIDEyOCBiYXRjaCBzaXplIGkuZS4gYSAxIGJ5dGUgb2Zmc2V0IHNpemUgc2hv
dWxkIGJlIG1vcmUgdGhhbiBlbm91Z2ggZW50cm9weQ0KIHRvIGRpc2NvdXJhZ2UgYSBtaWRkbGUg
Ym94IGZyb20g4oCcZml4aW5nIHJlb3JkZXJpbmfigJ0gYW5kIGluIHByYWN0aWNlIHdlIG1heSBu
ZWVkIGxlc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T25lIHBvc3NpYmxlIGFsZ29yaXRobSBm
b3IgdGhlIHNodWZmbGUgaXMgdGhlIEZpc2hlcuKAk1lhdGVzIChLbnV0aCkgc2h1ZmZsZSBhcyBk
b2N1bWVudGVkIGhlcmU6DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp
b24ub3V0bG9vay5jb20vP3VybD1odHRwczolMkYlMkZlbi53aWtpcGVkaWEub3JnJTJGd2lraSUy
RkZpc2hlciVFMiU4MCU5M1lhdGVzX3NodWZmbGUmYW1wO2RhdGE9MDIlN0MwMSU3Q25pYmFua3Ml
NDBtaWNyb3NvZnQuY29tJTdDY2IxZDJkZWFiNTUxNDE5ZmIzMjIwOGQ1OWU1ZmIwNjklN0M3MmY5
ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTg5MDU2MTkzODYyODY4
JmFtcDtzZGF0YT1JUWhOUHIxUTZTZyUyQjU0b0FDbGJ5R2hIZDZxN3Jsd3JQOWV1SDZRa1k2RVUl
M0QmYW1wO3Jlc2VydmVkPTAiPg0KaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRmlzaGVy
4oCTWWF0ZXNfc2h1ZmZsZTwvYT4gLiBQbGVhc2Ugc2VlIHRoZSDigJxNb2Rlcm4gbWV0aG9k4oCd
IHNlY3Rpb24gd2hpY2ggaXMgaW4tcGxhY2UuIFRoZSByYW5kb20gbnVtYmVyIGdlbmVyYXRvciBk
b2VzbuKAmXQgaGF2ZSB0byBiZSBhIHNlY3VyZSB2YXJpYW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPk9uZSBhZHZhbnRhZ2Ugb2Ygc3VjaCBhIHNjaGVtZSBpcyB0aGF0IHBhY2tldCBsb3NzIGNh
biBzdGlsbCBiZSBpbmZlcnJlZCBieSBsb29raW5nIGF0IGVhY2ggYmF0Y2ggc2l6ZWQgc2V0IG9m
DQogdGhlIG5vbmNlIChwYWNrZXQgbnVtYmVycykuIEZvciBleGFtcGxlIGlmIHRoZSBiYXRjaCBz
aXplIGlzIDEyOCwgdGhlbiBtaXNzaW5nIG51bWJlcnMgaW4gdGhpcyBiYXRjaCBzaXplIChvciBh
IG11bHRpcGxlKSB3aWxsIHNob3cgdGhlIGV4dGVudCBvZiBwYWNrZXQgbG9zcy4gVGhlIG90aGVy
IGFkdmFudGFnZSBpcyB0aGF0IGEgUVVJQyBkaWFnbm9zdGljIGNvbm5lY3Rpb24gY2FuIHRyaXZp
YWxseSBkZXRlY3QgYSBiYWQgbWlkZGxlYm94IHRoYXQNCiB0cmllcyB0byByZW9yZGVyIHRoZSBu
b25jZSBpbiBzZXF1ZW5jZSBhcyBpdCB3aWxsIGJlIGVhc2lseSBkaXN0aW5ndWlzaGFibGUgZnJv
bSBhIHJhbmRvbSBuZXR3b3JrIHJlb3JkZXIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_CY4PR21MB0630A663DA8595170C9135C1B6BE0CY4PR21MB0630namp_--


From nobody Tue Apr 10 00:18:25 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528ED126579 for ; Tue, 10 Apr 2018 00:18:24 -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 b9FZU5C-n4Xx for ; Tue, 10 Apr 2018 00:18:22 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FDE120454 for ; Tue, 10 Apr 2018 00:18:21 -0700 (PDT)
Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1f5nXn-0009Zo-Hk for quic@ietf.org; Tue, 10 Apr 2018 09:18:20 +0200
Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1f5nXE-0001yy-M3 for quic@ietf.org; Tue, 10 Apr 2018 03:18:15 -0400
Received: (qmail 27405 invoked from network); 10 Apr 2018 07:17:42 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.61]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Apr 2018 07:17:42 -0000
To: quic@ietf.org
References:      
From: Christian Huitema 
Openpgp: preference=signencrypt
Message-ID: <1537bdf0-c0cc-587c-bd16-39244df431d9@huitema.net>
Date: Tue, 10 Apr 2018 00:17:39 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.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: Simple transform for improving PN ossification prevention
X-Originating-IP: 168.144.250.190
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.37)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5qkf05i3xqB7yMNxm8niRpV602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVi4okXa374YtaRXoUS8acy6M7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBuzDn5j2tUhjYPVPi3bwTCB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpX1dGJ7HPnOCWRaxVuHANylF8FcHzzV3acxBudgYcInbwbsPAzRm9xw pTi7hmYLiviZ4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZXUaHqdOKLJ13TYQgD1U8MFwBl1z1+w2zS/h3e6UiVRf5Ii9QMXeDgzsK v4AYW3hVzfP/kMb+220rqmNKF5VwAWeqA47D/juB1cx4exzYk7wIdHXqmiNP5dvI77+8YOq/647l NwN4qOsSZg+fYhVZG9EQ9b9YI+9ZsqMLtlmzzH7VwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Apr 2018 07:18:25 -0000

I am not sure that I understand well the limitations of the shuffle
scheme. I am concerned that it smells like encryption, but can be
trivially broken, and if it is broken we will get ossification.

In my spare time, I have been thinking of similar schemes, but they
start with a big assumption: assume that we can encrypt short numbers.
That is, assume for example that we have a reasonable 32 bit encryption
code. I understand that the current such codes are a bit limited, and
that IPCrypt in particular may not be safe, but bear with me please
because of two reasons:

1) With 32 bit numbers, the number of permutations of a set of 2^32
values is much larger than 2**256. It is thus plausible that we can
design a symmetric encryption scheme keyed with a 256 bit or 128 bit key.=


2) Designing encryption schemes is hard, but I assume that
cryptographers can come with plausible schemes if we ask them,
especially if we do not insist too much on performance. For example,
given a 32 bit permutation, repeat in a loop "XOR with 32-bit word index
I mod N of Key, then apply permutation" enough times and you get a
pretty reasonable scheme. (IPCrypt had just 3 passes of the loop and a
final XOR; that seemed a bit optimistic; more passes would be harder to
crack; my vote would be for at least 8; it would be more than twice
slower but who really cares?)

The big issue is that the same sequence of PN would repeat after 2*32
packets, but there is an obvious fix to that: rekey after at most 2**31
packets. Bingo, we get people to actually implement key rotation...

The other downside is that packets would be encoded on 4 bytes all the
time. But that might be an OK price for those who really want hardware
acceleration.

-- Christian Huitema



From nobody Tue Apr 10 00:44:34 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD01124319 for ; Tue, 10 Apr 2018 00:44:26 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-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=fb.com header.b=lI68uRsy; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=AFyEmvcR
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb0hPCVszrmx for ; Tue, 10 Apr 2018 00:44:24 -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 EBCCE12711D for ; Tue, 10 Apr 2018 00:44:22 -0700 (PDT)
Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3A7iHd9028613; Tue, 10 Apr 2018 00:44:18 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=7+RNxSM2N2WD0fCyRc86Mu2UadLNAXsbZcOEWbpr2AM=; b=lI68uRsyfUcQn2HqPL2YeOFCsSfvWnZK3Hd4zC+3/0IcBrZQNpFh91clHnjXjZDwyvJH I0CE+sAi2OsxaWfadj+JPyWzuFGGKhaO1wxIp918FOJOmb2DNTot10i+pQG888alINPz SQGWssZO6Pt6qz++nQxgh3ZaXhcC6eflwNg= 
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2h8p848be6-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Apr 2018 00:44:18 -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.361.1; Tue, 10 Apr 2018 03:44:15 -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=7+RNxSM2N2WD0fCyRc86Mu2UadLNAXsbZcOEWbpr2AM=; b=AFyEmvcRwwYGxJhl/1MFKF3xlTu8nOJofq8602J958Tq/45Cv9BVPwLdDffzb/d4Y2SGSZ1AFq0JWYuVp9U2jn1pQ4Mgj/+nz0/+bgU/YkB8zCRnQHW9q/yGu/PFg3ziOd2oRT5cP7Yjge9ZPPOR8moWUFJFi4LTSXrbYjYwhWQ=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0151.namprd15.prod.outlook.com (10.163.64.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Tue, 10 Apr 2018 07:44:13 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::78a6:3a7a:1195:dd02]) by BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::78a6:3a7a:1195:dd02%13]) with mapi id 15.20.0653.018; Tue, 10 Apr 2018 07:44:13 +0000
From: Roberto Peon 
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Christian Huitema 
CC: "quic@ietf.org" 
Subject: Re: [Potential Spoof] Re: Getting to consensus on packet number encryption
Thread-Topic: [Potential Spoof] Re: Getting to consensus on packet number encryption
Thread-Index: AQHT0J+3yDxxFSXxnU2EEOelq+HwJw==
Date: Tue, 10 Apr 2018 07:44:12 +0000
Message-ID: <15E8D686-EF5C-40D8-A727-3099777D8F34@fb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.a.0.180210
x-originating-ip: [70.103.56.2]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0151; 7:W5W6Ua8yTLeSi+VybWpdvOyaIuRNfF8/NnTxKtru/XD0BbTsjm/jnMLlzYCPdqH8YPpZfO2+2y9SPhJ/vWYK0Rdfd7mW7xQRnzYy5BsOu4Dt8deHKXEdQ2XpAJAuufgptPvrwY7DtnuHr3DBL1r++mTHbceebFUIo885ZoBzS34QSzn63tB1M+ZH1vUG/Xl7x5XrFx4fuLpGoQ2RFwOKSDbWptT5fVAdS2HAAtbrJMoV0AxEHqukZ9ukSKB+3MSO; 20:ViJWOxPMmlU9u1642yHGLJtH/ogAQQbfb2jA7jHldhwxIPEqnvnURFyFs5/7xvhHrFf9AaVsebUsZqDEZbDE+Zb2yChA93NJLc1Mxz44ME+n2YquPlo9G+3fMgoG/XeZTDFlhWqPbgY5jY8kldoSJvBZJ06jUfildT/8kExn33g=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
X-MS-Office365-Filtering-Correlation-Id: d8ef1d57-5af5-41e0-cdf8-08d59eb6da86
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR15MB0151; 
x-ms-traffictypediagnostic: BY2PR15MB0151:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(67672495146484)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231221)(11241501184)(944501327)(52105095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BY2PR15MB0151; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0151; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(366004)(39380400002)(396003)(376002)(189003)(199004)(54014002)(25786009)(53546011)(6436002)(26005)(4326008)(5660300001)(5250100002)(8936002)(229853002)(33656002)(105586002)(486006)(82746002)(305945005)(99286004)(186003)(476003)(478600001)(81166006)(59450400001)(6486002)(83716003)(66066001)(7736002)(14454004)(2616005)(81156014)(86362001)(8676002)(97736004)(2906002)(3660700001)(110136005)(58126008)(6116002)(3846002)(6506007)(102836004)(6512007)(53936002)(316002)(68736007)(3280700002)(6246003)(2900100001)(106356001)(36756003)(427584002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0151; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: jszxl1/UImO02ALRAqcAcLk/mGzAtrTo9F2VwHMPvhQuIqs7qvt48yf4HJjZ+2o0OBKkus8b7aVq5SDq+i//QhYv149SRghA5vR3qSM2lTDAY2H1DsUM95ybCYOlblGP71/hDGewSmapgvCsxoPL8UsjGS2MPKH9shwnX43IW7y8sCWriOSr/VfWYv23rYX5LIxi/QBjKQuqjH3lie1YmFy3SGYdkhAZzdh1Aeu1/+lFD6O1t59mD9d/01M9RU4R5YrS+Pa9OCPXuOyNPWvdZ2YU+fwEpglzHPijyehQS9rQAT996sobKA3L404dIpT0Wuwmt8xM+2/h340n/FOz07ydI63ORBLuNSum4lC3H4P/9lcB2FfOe9iRNkvNTDg8I36v+sW/qQ+PrpzufFg7hF/oC8zHZncNHvldNhnfHZU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <2B68550F9B39E341881EF41D56FEEAE7@namprd15.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d8ef1d57-5af5-41e0-cdf8-08d59eb6da86
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 07:44:12.8734 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0151
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-10_03:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Apr 2018 07:44:27 -0000

SSBsb3ZlIGl0IHdoZW4gbWFpbCBpcyBkZWxpdmVyZWQgc29tZSBkYXlzIGFmdGVyIGl0IGlzIHNl
bnQuIDovDQotPVINCg0K77u/T24gNC85LzE4LCA2OjA1IFBNLCAiUVVJQyBvbiBiZWhhbGYgb2Yg
Um9iZXJ0byBQZW9uIiA8cXVpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBmZW5peEBm
Yi5jb20+IHdyb3RlOg0KDQogICAgQWRkaW5nIGFub3RoZXIgUE4gd291bGQgcHJvYmFibHkgbm90
IGJlIHN1ZmZpY2llbnQtLSBvbmUgd291bGQgbmVlZCB0byBlbnN1cmUgdGhhdCB0aGUgb3NzaWZp
ZWQgUE4gd2FzIHByZXNlbnRlZCB3aXRoIHRoZSByaWdodCBzZXF1ZW5jaW5nIGFzIHdlbGwsIHdo
aWNoIG1pZ2h0IGJlIGRpZmZpY3VsdCwgb3IgZXhwZW5zaXZlLg0KICAgIE9zc2lmaWNhdGlvbiBp
cyBzdXJwcmlzaW5nbHkgZGlmZmljdWx0IHRvIHdvcmsgYXJvdW5kIG9uY2UgaXQgc2V0cyBpbiwg
YXMgZXZlbiBmaWd1cmluZyBvdXQgaG93IGl0IGlzIGltcGFjdGluZyB5b3UgY2FuIGJlIHN1YnN0
YW50aWFsIHdvcmsuDQogICAgDQogICAgLT1SDQogICAgDQogICAgT24gNC81LzE4LCAyOjI3IEFN
LCAiUVVJQyBvbiBiZWhhbGYgb2YgTWlyamEgS8O8aGxld2luZCIgPHF1aWMtYm91bmNlc0BpZXRm
Lm9yZyBvbiBiZWhhbGYgb2YgbWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4gd3JvdGU6
DQogICAgDQogICAgICAgIExldCBtZSByZXBlYXQgYW5vdGhlciBwb3NpdGlvbiB0aGVuIGFzIHdl
bGw6DQogICAgICAgIA0KICAgICAgICA+IEFtIDA1LjA0LjIwMTggdW0gMDI6NDQgc2NocmllYiBD
aHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD46DQogICAgICAgID4gDQogICAg
ICAgID4gSWYgd2UgYXJlIGluIHRoZSBidXNpbmVzcyBvZiByZXBlYXRpbmcgb3VyIHBvc2l0aW9u
cywgc28gYmUgaXQuIEkgYW0gcHJldHR5IG11Y2ggb24gdGhlIHNhbWUgbGluZSBhcyBQYXRyaWNr
IGFuZCBvdGhlcnM6DQogICAgICAgID4gDQogICAgICAgID4gMSkgUHJpdmFjeSBpcyBub3Qgb3B0
aW9uYWwuIEFuZCB5ZXMsIHJlbW92aW5nICJsaW5rYWJpbGl0eSB0aHJvdWdoIFBOIiBpcyBpbXBv
cnRhbnQsIGJlY2F1c2Ugd2hlbiB0aGUgY29ubmVjdGlvbiBJRCBhbmQgdGhlIHNvdXJjZSBhZGRy
ZXNzIGFsc28gY2hhbmdlLCB0aGUgb25seSBvdGhlciBjdWUgZm9yIGxpbmthYmlsaXR5IGlzIHRp
bWluZy4gVGltaW5nIGNhbiBiZSBhZGRyZXNzZWQgYnkgaGF2aW5nIG92ZXJsYXBwaW5nIGNvbm5l
Y3Rpb25zLg0KICAgICAgICA+IA0KICAgICAgICBUaW1pbmcgZG9lc27igJl0IGhlbHAgaGVyZSBl
aXRoZXIgYmVjYXVzZSB5b3Ugc3RpbGwgaGF2ZSB0aGUgc2FtZSBkZXN0aW5hdGlvbiBJUCwgYm90
aCBwb3J0IG51bWJlcnMgYW5kIHRoZSBmYWN0IHRoYXQgYSBtaWdyYXRlZCBjb25uZWN0aW9uIGRv
ZXMgbm90IGhhdmUgYSBoYW5kc2hha2UuIElmIHdlIHdhbnQgdG8gYWRkcmVzcyB0aGUgbGlua2Fi
aWxpdHkgcHJvYmxlbSwgd2Ugd291bGQgbmVlZCB0byBkbyBtdWNoIG1vcmUsIHByb2JhYmx5IGJh
cmluZyBtb3JlIGhpdHMgb24gcGVyZm9ybWFuY2UuIA0KICAgICAgICANCiAgICAgICAgSSB0aG91
Z2h0IHdlIGRpc2N1c3NlZCB0aGlzIGFscmVhZHkgZW5kbGVzc2x5IGFuZCBjb25jbHVkZWQgdGhh
dCBQTkUgZG9lcyBub3QgaGVscCBsaW5rYWJpbGl0eS4NCiAgICAgICAgDQogICAgICAgIFRoZW4g
YW4gYXJndW1lbnQgZm9yIG9zc2lmaWNhdGlvbiB3YXMgYnJvYWQgdXAuIEhvd2V2ZXIsIHdlIHJl
YWxseSBjYW5ub3QgY29tcGFyZSB0aGUgc2l0dWF0aW9uIGhlcmUgd2l0aCBUQ1AuIFdpdGggVENQ
IGV2ZXJ5dGhpbmcgaXMgaW4gdGhlIGNsZWFyIGluY2wuIGFsc28gdGhlIHJldHJhbnNtaXNzaW9u
cy4gSW4gY2FzZSBvZiBNUFRDUCB0aGlzIHdhcyByYXRoZXIgdGhlIHByb2JsZW0gdGhlIHRoZSBz
ZXEjIGJlY2F1c2UgaWYgeW914oCZZCB1c2UgdGhlIHNhbWUgc2VxIyBudW1iZXIgc3BhY2Ugb24g
Ym90aCBjb25uZWN0aW9ucyBpdCB3b3VsZCBsaWtlIGxvc3MgYnV0IHdpdGhvdXQgYSByZXRyYW5z
bWlzc2lvbi4gRnVydGhlciBib3hlcyB0aGF0IHJlb3JkZXIsIHVzdWFsbHkgZG8gdGhhdCBpbiBz
aXR1YXRpb24gd2hlcmUgcGFja2V0cyB3ZXJlIHRyYW5zbWl0dGVkIGZvciBhIGtub3duIHJlYXNv
biBvdXQtb2Ygb3JkZXIgcHJldmlvdXNseSwgZS5nLiB3aGVuIG11bHRpcGxlIHBhdGhzIGFyZSB1
c2VkIGluIHRoZSBuZXR3b3JrLiBUaGUgcmVjb21tZW5kYXRpb24gd2Ugc3RpbGwgZ2l2ZSBpbiB0
aGUgSUVURiB0cmFuc3BvcnQgYXJlYSBpcyB0aGF0IGluIHN1Y2ggYSBzaXR1YXRpb24gdGhlIHNj
aGVkdWxpbmcgc2hvdWxkIG5vdCBiZSBkb25lIG9uIGEgcGVyLXBhY2tldCBsZXZlbCBidXQgcGVy
LWZsb3cuIEhvd2V2ZXIsIHRob3NlIHNjaGVtZSB0aGF0IGRvIHBlci1wYWNrZXQgc2NoZWR1bGlu
ZyB1c3VhbGx5IGFsc28gYXBwbHkgbWVjaGFuaXNtIHRvIHJlLW9yZGVyIGFmdGVyd2FyZHMuIFRo
ZXkgY2FuIGp1c3QgdXNlIHRoZSBUQ1Agc2VxIyBmb3IgdGhhdCBidXQgZm9yIG5vbi1UQ1AgdGhl
eSB3b3VsZCBzaW1wbHkgYWRkIHRoZWlyIG93biBlbmNhcHN1bGF0aW9uIHdpdGggYSBzZXEj4oCm
DQogICAgICAgIA0KICAgICAgICBQbGVhc2Uga2VlcCBpbiBtaW5kIHRoYXQgZXZlbiBpZiBhbiAo
dW5lbmNyeXB0ZWQpIFBOIGdldHMgb3NzaWZpZWQgYnkgdGhlIG5ldHdvcmssDQogICAgICAgIGlu
IGNhc2Ugb2YgUVVJQyB0aGF0IGRvZXMgbm90IG1lYW4gdGhhdCB3ZSBjYW7igJl0IGNoYW5nZSB0
aGUgdHJhbnNwb3J0IG1hY2hpbmVyeSBhbnltb3JlLiBDdXJyZW50bHkgdGhlIGV4cG9zZWQgUE4g
aXMgYWxzbyB1c2VkIGZvciBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIHJldHJhbnNtaXNzaW9uLCBo
b3dldmVyLCB3ZSBjYW4gc3RpbGwgYWRkIGFub3RoZXIgUE4gaW4gdGhlIGVuY3J5cHRlZCBwYXJ0
IGFuZCByZXNvbHZlZCB0aGUgZmFjdCB0aGF0IHRoZSBjdXJyZW50IFBOIGlzIG92ZXJsb2FkZWQg
Zm9yIGRpZmZlcmVudCBmdW5jdGlvbnMuDQogICAgICAgIA0KICAgICAgICBDdXJyZW50bHksIEkg
cmVhbGx5IHN0aWxsIGRvbuKAmXQgc2VlIHRoZSBiZW5lZml0IG9mIFBORSBidXQgb25seSBhZGRp
dGlvbmFsIGNvbXBsZXhpdHkgYW5kIGtub3duIHBlcmZvcm1hbmNlIGRlZ3JhZGF0aW9uLg0KICAg
ICAgICANCiAgICAgICAgTWlyamENCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAgICAg
ICAgDQogICAgDQogICAgDQoNCg==


From nobody Tue Apr 10 01:03:47 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E924C126BF3 for ; Tue, 10 Apr 2018 01:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61z_ecjuIjiu for ; Tue, 10 Apr 2018 01:03:44 -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 A297A1271DF for ; Tue, 10 Apr 2018 01:03:43 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id w23so12287261qtn.3 for ; Tue, 10 Apr 2018 01:03:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tB7MqBFRUzQSVR+it4aQGZmzoBD/B2Qtjc0zg1ReafI=; b=WxCKyzck/0FZP9SPnUMSzIsn/Z5+RQ3w/POdB4x0oqbbCt55XdH30ZpqzX/qvB88Fb ssiFxNNEhdB0vEEmkNT05x5b/ZXyYzL527DIpU6lueaWt5QAANvDD2nav0brbpyZCvBL mZduwzUtL6+ccvnGPxEatzuT1gE3AvgZXkkSRqxTHW5PX/Odx313erx8FHvPMrCX7CsF hhU7HHThcA6XVKjiDQlahyprptZ1cOeMuj9hsJ2/wdyV4EVyETO0N0nzniBJG9iPxOFx RvL52qyA13qvydINY5gZNPDz3vu/i/gpc1XL0uZVilseE/FoswSaX5NROH+kIKVW59jG nD7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tB7MqBFRUzQSVR+it4aQGZmzoBD/B2Qtjc0zg1ReafI=; b=h0iuDMaM1dsvLeXJ4/ZBgw+49R0+2zUOuLuv3NRF4YLabJFPqp12/F855ixRAcDbl+ 1F1ycvOhLJ3WkTWtmSixdEgqAgoWKayt6SBOzXNu89Ty8e+xyWyNAHas3mR7s/hLvyyy dFRHO07Iyc5/suESuxHwYSQAmplooeliEQmpruEnHuFiP59tjC3D679hT52y1DcPP+0a u6l2PM8z9rgWh5ypPvn1YqMAH+0BGbrwTxn7hagLb0g+3iF8pkioiAkq6iCw6fEnuj82 TCh2ZBpixg1ww4XQOkGPyl70oW1UJSaevMUNjX79mHk4BBJNSMfU+FcsJ5Q88YrcLK2Z qbhw==
X-Gm-Message-State: ALQs6tAUiEnCrbAwfhdxDjWmZ2DX9k5ujU0lnYQpi+OVmv/4N2A5Mk8o RivJiDBxSE+x68RUSBV9WKEW2PVY2j7zi8VnGQQHSg==
X-Google-Smtp-Source: AIpwx4+3cuD4TyUkkq7sonihJFVW3pDcP3Qe9s2KVpCznFvASp242EC253UdUnEgCMvfdtqyazveqLAWMGgwfbrODuU=
X-Received: by 10.200.23.213 with SMTP id r21mr56416497qtk.314.1523347422383;  Tue, 10 Apr 2018 01:03:42 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Victor Vasiliev 
Date: Tue, 10 Apr 2018 08:03:31 +0000
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Praveen Balasubramanian 
Cc: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="94eb2c04f022fb8cd6056979f52d"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 08:03:46 -0000

--94eb2c04f022fb8cd6056979f52d
Content-Type: text/plain; charset="UTF-8"

On Mon, Apr 9, 2018, 13:48 Praveen Balasubramanian  wrote:

> Requirements for any PN transform in the single path case:
>
>    1. The actual PN must always increment by 1 and will be used for
>    generating ACKs in ACK frames.
>    2. The transformed PN in the clear is a nonce and must not repeat over
>    the connection lifetime.
>    3. Middleboxes must not be able to determine the actual PN. Only the
>    QUIC receiver should be able to do so.
>
> Well, this sounds like you're requiring a block cipher.

>

--94eb2c04f022fb8cd6056979f52d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 9, 2018, 13:48 Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org>=
; wrote:


Requirements for any PN transform in the single path=
 case:


    

  1. The actual PN must always increment by 1 and will b=
e used for generating ACKs in ACK frames.

  2. The transformed PN in the clear =
is a nonce and must not repeat over the connection lifetime.<=
/li>
  3. Middleboxes must not be able to determine the a=
ctual PN. Only the QUIC receiver should be able to do so.
Well, this sounds like you're =
requiring a block cipher.









--94eb2c04f022fb8cd6056979f52d--


From nobody Tue Apr 10 01:03:57 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FF812E87F for ; Tue, 10 Apr 2018 01:03:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523347430; bh=V6FFfz3gsl7NBBJ7EMISKWHaf/D5eJWdlITkmAMCzsw=; h=References:In-Reply-To:From:Date:Subject:Cc:To; b=IqBsdSNHL2LMt8C3NKPwBADR1FINiZiQM3qrWZyBrUV5DZOOmVgdzRsLL28qDgOqv ZLR7jNdXlaNFwxvqXEtUeZlV1Bfl6EctQCgZEOprNxT767R8+hGtzDRmKfHO6ceyWs y/P0mhCPOULOnfEgyQCUwvHVV4er5UVsWKetFsKg=
X-Mailbox-Line: From vasilvv@google.com  Tue Apr 10 01:03:49 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0128012DB71 for ; Tue, 10 Apr 2018 01:03:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523347429; bh=V6FFfz3gsl7NBBJ7EMISKWHaf/D5eJWdlITkmAMCzsw=; h=References:In-Reply-To:From:Date:Subject:Cc:To; b=JVtZhed+ruHXRqNVgEvYLr+64boDnXug1WUCeeAqe7XWa31s+d7hjpAEH1WYRMnVx F5f9bkWVp4Xc0eN3LcLR+AxB1sth6au052Nlex3cDg+0ROUDyI29MSwG0yTQRXluzA aRd6K0oo4oyxCay4fzCpymzh4KfI7aoOM3W2AV4o=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D0512D95D for ; Tue, 10 Apr 2018 01:03:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 J-HSFYZfvC2v for ; Tue, 10 Apr 2018 01:03:45 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA127127333 for ; Tue, 10 Apr 2018 01:03:43 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id v11so12293952qtj.6 for ; Tue, 10 Apr 2018 01:03:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tB7MqBFRUzQSVR+it4aQGZmzoBD/B2Qtjc0zg1ReafI=; b=WxCKyzck/0FZP9SPnUMSzIsn/Z5+RQ3w/POdB4x0oqbbCt55XdH30ZpqzX/qvB88Fb ssiFxNNEhdB0vEEmkNT05x5b/ZXyYzL527DIpU6lueaWt5QAANvDD2nav0brbpyZCvBL mZduwzUtL6+ccvnGPxEatzuT1gE3AvgZXkkSRqxTHW5PX/Odx313erx8FHvPMrCX7CsF hhU7HHThcA6XVKjiDQlahyprptZ1cOeMuj9hsJ2/wdyV4EVyETO0N0nzniBJG9iPxOFx RvL52qyA13qvydINY5gZNPDz3vu/i/gpc1XL0uZVilseE/FoswSaX5NROH+kIKVW59jG nD7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tB7MqBFRUzQSVR+it4aQGZmzoBD/B2Qtjc0zg1ReafI=; b=PBvd0YI3QEL7xgCoPinNMiOGty2KAm0Vl0svG2aItIjh2FX9yUbxEFyOci41uu860c Hq7a8eiJwdsHrFs8xjUSaiRcIWZjzYTkD+lidzACcy6SJ/wLP4t+N++QxMgZavdVuQBj vymUs5EJfedlcYDNlBsTWmRYqF6NudCPDYJ8HexRgiIfid8URkev6HAfDaMWzQPnI2A1 Ct8d/9HWT0v1YkirVoavX4JNxqpUlxdXCpe9i9LgeWUnr9QX62+8KI86RPNX8RPifRwa 1ceZQA6K2dV/67qef0XX+Cu8A+LVVFOjY0h0efgL0Gy/QyZB9Pcm6sX5geKqmrSw4Yyf 7/4g==
X-Gm-Message-State: ALQs6tCoq6TZT4+51KbNA5iwpB0EaCZzdoIgnSJdnto8exzU31MG7bDe Wkgif3T+QsXkBoxwFdH8YINgzpNBVxScEZHCW7V97Y7r
X-Google-Smtp-Source: AIpwx4+3cuD4TyUkkq7sonihJFVW3pDcP3Qe9s2KVpCznFvASp242EC253UdUnEgCMvfdtqyazveqLAWMGgwfbrODuU=
X-Received: by 10.200.23.213 with SMTP id r21mr56416497qtk.314.1523347422383;  Tue, 10 Apr 2018 01:03:42 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Victor Vasiliev 
Date: Tue, 10 Apr 2018 08:03:31 +0000
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
Cc: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="94eb2c04f022fb8cd6056979f52d"
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 08:03:52 -0000

--94eb2c04f022fb8cd6056979f52d
Content-Type: text/plain; charset="UTF-8"

On Mon, Apr 9, 2018, 13:48 Praveen Balasubramanian  wrote:

> Requirements for any PN transform in the single path case:
>
>    1. The actual PN must always increment by 1 and will be used for
>    generating ACKs in ACK frames.
>    2. The transformed PN in the clear is a nonce and must not repeat over
>    the connection lifetime.
>    3. Middleboxes must not be able to determine the actual PN. Only the
>    QUIC receiver should be able to do so.
>
> Well, this sounds like you're requiring a block cipher.

>

--94eb2c04f022fb8cd6056979f52d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 9, 2018, 13:48 Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org>=
; wrote:


Requirements for any PN transform in the single path=
 case:


    

  1. The actual PN must always increment by 1 and will b=
e used for generating ACKs in ACK frames.

  2. The transformed PN in the clear =
is a nonce and must not repeat over the connection lifetime.<=
/li>
  3. Middleboxes must not be able to determine the a=
ctual PN. Only the QUIC receiver should be able to do so.
Well, this sounds like you're =
requiring a block cipher.









--94eb2c04f022fb8cd6056979f52d--


From nobody Tue Apr 10 01:35:04 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD991271DF for ; Tue, 10 Apr 2018 01:35: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, 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 lJEAHdihwXOh for ; Tue, 10 Apr 2018 01:34:59 -0700 (PDT)
Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5215E126BF3 for ; Tue, 10 Apr 2018 01:34:59 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,431,1517871600";  d="scan'208";a="7898922"
Received: from thorgal.eurecom.fr ([10.3.2.220]) by drago2i.eurecom.fr with ESMTP; 10 Apr 2018 10:34:53 +0200
Received: (from apache@localhost) by thorgal.eurecom.fr (8.14.4+Sun/8.14.4/Submit) id w3A8Yp2n024761; Tue, 10 Apr 2018 10:34:51 +0200 (CEST)
X-Authentication-Warning: thorgal.eurecom.fr: apache set sender to otilibil@eurecom.fr using -f
Received: from reverse.completel.net (reverse.completel.net [92.103.89.82]) by webmail.eurecom.fr (Horde MIME library) with HTTP; Tue, 10 Apr 2018 10:34:51 +0200
Message-ID: <20180410103451.lqblpjgrcw8gokw8@webmail.eurecom.fr>
Date: Tue, 10 Apr 2018 10:34:51 +0200
From: Ariel Otilibili Anieli 
To: Christian Huitema , "Martin J. =?utf-8?b?RMO8cnN0?=" , Mikkel =?utf-8?b?RmFobsO4ZSA=?= =?utf-8?b?SsO4cmdlbnNlbg==?= , Lucas Pardue , Martin Thomson , Jana Iyengar 
Cc: QUIC WG 
Subject: Re: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>  <0c2bbb1f-af3c-e196-3605-db9458936a42@it.aoyama.ac.jp> <20180409090233.hxlqgu1wqo0o04c0@webmail.eurecom.fr>  <7CF7F94CB496BF4FAB1676F375F9666A3BB22349@bgb01xud1012>  <20180409104208.qwe4ab3s8woowgsc@webmail.eurecom.fr> <49c3e44b-4e61-b2d8-0059-ab4310bd474a@it.aoyama.ac.jp> <20180409112405.ba37t74psgw8840w@webmail.eurecom.fr> <20ED4DA3-F688-42BE-ABD8-FDC97FC1D26D@huitema.net>
In-Reply-To: <20ED4DA3-F688-42BE-ABD8-FDC97FC1D26D@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)
X-Originating-IP: 92.103.89.82
X-Remote-Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 08:35:02 -0000

Hi all,

Herewith the pull request; it sums up the discussion on the meaning of QUIC:

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

Regards,
Ariel

Quoting Christian Huitema :

> I would drop the part about past backronym. If you repeat it, you  =20
> perpetuate it. If you want history, you have to explain the lineage  =20
> from FAST    to QUIC, and an RFC is not the place to do that.
>
> -- Christian Huitema
>
>> On Apr 9, 2018, at 2:24 AM, Ariel Otilibili Anieli  =20
>>  wrote:
>>
>> Hi all,
>>
>> Inline the pull request I will propose in the Introduction. Does  =20
>> everyone agree with it?
>>
>> Regards,
>> Ariel
>>
>> Quoting "Martin J. D=C3=BCrst" :
>>
>>>> On 2018/04/09 17:42, Ariel Otilibili Anieli wrote:
>>>>
>>>> I will propose a pull request: "QUIC used to be known as 'Quick  =20
>>>> UDP  Internet Connections', but the present RFC advises it be  =20
>>>> used no  more: QUIC does not stand for an acronym".
>>>
>>> "QUIC does not stand for an acronym" -> "QUIC is not an acronym" and/or
>>> "QUIC does not stand for anything".
>> Fixed: "QUIC is not an acronym: it does not stand for anything."
>>>
>>> Regards,   Martin.
>>
>>
>>
>> -------------------------------------------------------------------------=
------
>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>
>
>



----------------------------------------------------------------------------=
---
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


From nobody Tue Apr 10 07:32:57 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D5212D7EA for ; Tue, 10 Apr 2018 07:32:55 -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 X7k2JPgEEpli for ; Tue, 10 Apr 2018 07:32:52 -0700 (PDT)
Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 31285129C5D for ; Tue, 10 Apr 2018 07:32:51 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,432,1517871600";  d="scan'208";a="7900582"
Received: from thorgal.eurecom.fr ([10.3.2.220]) by drago2i.eurecom.fr with ESMTP; 10 Apr 2018 16:32:50 +0200
Received: (from apache@localhost) by thorgal.eurecom.fr (8.14.4+Sun/8.14.4/Submit) id w3AEWoDf026144; Tue, 10 Apr 2018 16:32:50 +0200 (CEST)
X-Authentication-Warning: thorgal.eurecom.fr: apache set sender to otilibil@eurecom.fr using -f
Received: from reverse.completel.net (reverse.completel.net [92.103.89.82]) by webmail.eurecom.fr (Horde MIME library) with HTTP; Tue, 10 Apr 2018 16:32:50 +0200
Message-ID: <20180410163250.3ixpqer5k4okkokk@webmail.eurecom.fr>
Date: Tue, 10 Apr 2018 16:32:50 +0200
From: Ariel Otilibili Anieli 
To: Martin Thomson , Jana Iyengar 
Cc: QUIC WG 
Subject: Comments draft-ietf-quic-transport-10
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)
X-Originating-IP: 92.103.89.82
X-Remote-Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 14:32:55 -0000

Hi Martin,

A comment inline. And another thing on this draft:

QUIC defines PING frames, and relies at the same time on TLS. TLS has =20
already the Heartbeat protocol (https://tools.ietf.org/html/rfc6520); =20
it provides the same functions than PING frames.

Section 8.9 should clarify: which layer dominates the other: PING =20
frames, or TLS Heartbeat?

Regards,
Ariel

Quoting Martin Thomson :

> Hi Ariel,
>
> Thanks for the input.
>
> On Mon, Apr 9, 2018 at 4:01 AM, Ariel Otilibili Anieli
>  wrote:
>> 1. The document defines QUIC, but nowhere have I come across the definiti=
on
>> of its acronym: it would help readers to get it from the abstract, or no
>> later than the introduction.
>
> QUIC is not an acronym.  You are expected to shout it ;)
Stated in https://github.com/quicwg/base-drafts/pull/1282
>
>> 2. Section 2 lays out the Conventions and Definitions, but does not state
>> the meaning of frames (though they are used many times). Section 2 should
>> also define what is a frame, and how it relates with a streams and a pack=
et.
>
> A pull request would be welcome.
>
>> 3. Some typos; the text contains abbreviations (e.g, "isn't" for "is not"=
,
>> "don't" for "do not"), and also considers technical terms as legal person=
s
>> ("QUIC's ACK frames", "TCP's retransmission"). See them in the attachment=
.
>
> I don't consider use of contractions to be typos.  I do try to avoid
> the possessive form, but I suspect that I or other contributors slip
> on occasion.  Again, a pull request is the best way to make this
> contribution.
>
>> Finally, on the QUIC version numbering: I think it would ease readers to
>> have a human-friendly representation
>
> I think that "1" is perfectly human friendly.  It's just a number.  We
> use the full, unambiguous form in a specification because we believe
> our audience is capable of handling that.  Feel free to use whatever
> numerical representation you feel suits you best.
>
> Unambiguous textual representations are not a goal here, as it is
> (unfortunately) for addresses.  If the number is presented to a human,
> I sincerely hope that they are an engineer and therefore capable of
> coping.
>



----------------------------------------------------------------------------=
---
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


From nobody Tue Apr 10 08:30:14 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC69D124B0A for ; Tue, 10 Apr 2018 08:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level: 
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWzNRtK7xcqu for ; Tue, 10 Apr 2018 08:30:06 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C848112D9FF for ; Tue, 10 Apr 2018 08:30:05 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id 141so14124857iou.12 for ; Tue, 10 Apr 2018 08:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=w/CtaGwnrkNnz5o7EDzefKnYq0QCBeFi8T2rJ09npq4=; b=O9tB+bbqTlokO6b2F9Zk6HLAq72ZVgkJfB9kW7h5tQY98kv37r0HJQmcL3o+eU5MBc XbvGJyRxXRNe7y9AvOgtaubl2IOiWsv5rj5yxh8TrhVJuqdrzNq71OWp7hfYsqbQS2E1 heInrV+2xTGL84fIDjPrkCfBVlnfaxajdsyLyOkY6+rWuFXWgoU2S6KR4wGfTJosF4Fq Ki9Jjp9feRmZngFqmOQK//9Nz2siUbQ74hsTQDqxsJS9N8cA6Q596gSDbtOLoXTWobQb fIUNf2Wd48/JGZ5RxWu6xQCO2okFcZd2eP0ZTedS5BV/k6kUlQX2UF+zDNG8sOz9T4Wz Mxiw==
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=w/CtaGwnrkNnz5o7EDzefKnYq0QCBeFi8T2rJ09npq4=; b=MPX1O7s2nVob8OohmIQMxnUtALcE7CbiL6jdnba6QBzH1yfYN+BT0+YDKbLZzxKgAU iUq7v65GeJt+S3mHOgTi+N96DgLnqdrG0eQXFtLpuKdzFs4Vp9L+wKuHPPae5BrYMjVH 2Kj7WVtG6W6/sERDEfWwQAJ16JSUbKiYioNDRAKX6JDR7XoWtKKDyndtXoamkIj4Dp9X o4y/RRG7ClXl5FZvhOeRYI1FxGO3LwzE5oMtShYsjvSKJQ62gnWXeZ5bRvXBPgyoTBuJ 37Fwufxv1V6qopfbIKMnMoT8fXzzaGLFUvUIrMa8WLAPxf17IKYXW5t/0wzFh7CX++ff /+2Q==
X-Gm-Message-State: ALQs6tBJHSpF2uFePMWdN8Q8slUjilsfeRg82gnB8r0bMuleZ1E0wdmP dqllkYYsGAx4fta5KG5dOYOeRrciRS+0t7ptyAg=
X-Google-Smtp-Source: AIpwx49n1ZifqmxZV8qEXTPyeloHCaHa1km+8dRSeqdGRl1ioKqn53yAaNLv/ziDfDyYEASTJWf7vp0bwhYoB7j6dSk=
X-Received: by 10.107.6.163 with SMTP id f35mr1002926ioi.165.1523374205151; Tue, 10 Apr 2018 08:30:05 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 10 Apr 2018 11:30:04 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: <20180410163250.3ixpqer5k4okkokk@webmail.eurecom.fr>
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>  <20180410163250.3ixpqer5k4okkokk@webmail.eurecom.fr>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 10 Apr 2018 11:30:04 -0400
Message-ID: 
Subject: Re: Comments draft-ietf-quic-transport-10
To: Martin Thomson , Ariel Otilibili Anieli ,  Jana Iyengar 
Cc: QUIC WG 
Content-Type: multipart/alternative; boundary="001a113e06a25bb10705698032f7"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 15:30:08 -0000

--001a113e06a25bb10705698032f7
Content-Type: text/plain; charset="UTF-8"

TLS is only used for handshake and for periodic rekeying.

Everything else is fully managed by QUIC, so a TLS heartbeat would not be
useful. PING also serves other purposes including asking for ACK messages
to be sent.

Even crypto is not handled by TLS after handshake although it does provide
the keys and although TLS libraries likely implement the required
functionality.

On 10 April 2018 at 16.33.02, Ariel Otilibili Anieli (otilibil@eurecom.fr)
wrote:

Hi Martin,

A comment inline. And another thing on this draft:

QUIC defines PING frames, and relies at the same time on TLS. TLS has
already the Heartbeat protocol (https://tools.ietf.org/html/rfc6520);
it provides the same functions than PING frames.

Section 8.9 should clarify: which layer dominates the other: PING
frames, or TLS Heartbeat?

Regards,
Ariel

Quoting Martin Thomson :

> Hi Ariel,
>
> Thanks for the input.
>
> On Mon, Apr 9, 2018 at 4:01 AM, Ariel Otilibili Anieli
>  wrote:
>> 1. The document defines QUIC, but nowhere have I come across the
definition
>> of its acronym: it would help readers to get it from the abstract, or no
>> later than the introduction.
>
> QUIC is not an acronym. You are expected to shout it ;)
Stated in https://github.com/quicwg/base-drafts/pull/1282
>
>> 2. Section 2 lays out the Conventions and Definitions, but does not
state
>> the meaning of frames (though they are used many times). Section 2
should
>> also define what is a frame, and how it relates with a streams and a
packet.
>
> A pull request would be welcome.
>
>> 3. Some typos; the text contains abbreviations (e.g, "isn't" for "is
not",
>> "don't" for "do not"), and also considers technical terms as legal
persons
>> ("QUIC's ACK frames", "TCP's retransmission"). See them in the
attachment..
>
> I don't consider use of contractions to be typos. I do try to avoid
> the possessive form, but I suspect that I or other contributors slip
> on occasion. Again, a pull request is the best way to make this
> contribution.
>
>> Finally, on the QUIC version numbering: I think it would ease readers to
>> have a human-friendly representation
>
> I think that "1" is perfectly human friendly. It's just a number. We
> use the full, unambiguous form in a specification because we believe
> our audience is capable of handling that. Feel free to use whatever
> numerical representation you feel suits you best.
>
> Unambiguous textual representations are not a goal here, as it is
> (unfortunately) for addresses. If the number is presented to a human,
> I sincerely hope that they are an engineer and therefore capable of
> coping.
>



-------------------------------------------------------------------------------

This message was sent using EURECOM Webmail: http://webmail.eurecom.fr

--001a113e06a25bb10705698032f7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
TLS is only used for=
 handshake and for periodic rekeying.

Everything else is fully managed by QUIC, so a TLS heartbe=
at would not be useful. PING also serves other purposes including asking fo=
r ACK messages to be sent.

Even crypto is not handled by TLS after handshake although it does pr=
ovide the keys and although TLS libraries likely implement the required fun=
ctionality.
 
On 10 April 2018 at 16.33.02,=
 Ariel Otilibili Anieli (otilibil@eu=
recom.fr) wrote:
 
Hi Martin,



A comment inline. And another thing on this draft:



QUIC defines PING frames, and relies at the same time on TLS. TLS has  =
=20

already the Heartbeat protocol (https://tools.ietf.org/html/rfc6520);  =20

it provides the same functions than PING frames.



Section 8.9 should clarify: which layer dominates the other: PING  =20

frames, or TLS Heartbeat?



Regards,

Ariel



Quoting Martin Thomson <=
martin.thomson@gmail.com>:



> Hi Ariel,

>

> Thanks for the input.

>

> On Mon, Apr 9, 2018 at 4:01 AM, Ariel Otilibili Anieli

> <otilibil@eurecom.fr=
> wrote:

>> 1. The document defines QUIC, but nowhere have I come across t=
he definition

>> of its acronym: it would help readers to get it from the abstr=
act, or no

>> later than the introduction.

>

> QUIC is not an acronym.  You are expected to shout it ;)

Stated in h=
ttps://github.com/quicwg/base-drafts/pull/1282

>

>> 2. Section 2 lays out the Conventions and Definitions, but doe=
s not state

>> the meaning of frames (though they are used many times). Secti=
on 2 should

>> also define what is a frame, and how it relates with a streams=
 and a packet.

>

> A pull request would be welcome.

>

>> 3. Some typos; the text contains abbreviations (e.g, "isn=
't" for "is not",

>> "don't" for "do not"), and also consid=
ers technical terms as legal persons

>> ("QUIC's ACK frames", "TCP's retransmis=
sion"). See them in the attachment..

>

> I don't consider use of contractions to be typos.  I do try to=
 avoid

> the possessive form, but I suspect that I or other contributors sl=
ip

> on occasion.  Again, a pull request is the best way to make this

> contribution.

>

>> Finally, on the QUIC version numbering: I think it would ease =
readers to

>> have a human-friendly representation

>

> I think that "1" is perfectly human friendly.  It's =
just a number.  We

> use the full, unambiguous form in a specification because we belie=
ve

> our audience is capable of handling that.  Feel free to use whatev=
er

> numerical representation you feel suits you best.

>

> Unambiguous textual representations are not a goal here, as it is

> (unfortunately) for addresses.  If the number is presented to a hu=
man,

> I sincerely hope that they are an engineer and therefore capable o=
f

> coping.

>







-----------------------------------------------------------------------=
--------

This message was sent using EURECOM Webmail: http://webmail.eurecom.fr





--001a113e06a25bb10705698032f7--


From nobody Tue Apr 10 09:37:51 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF6612DA04 for ; Tue, 10 Apr 2018 09:37:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 xpzyjYXMgKt5 for ; Tue, 10 Apr 2018 09:37:46 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0112.outbound.protection.outlook.com [104.47.33.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DF6126C89 for ; Tue, 10 Apr 2018 09:37: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=L0KrOMN3eogoOim1JkIgZsi2+GxyxvgPJ1fi4yxPqTE=; b=jYaa1ydKwVdlWe6O0T90RgNAbi9/3+BGLy96Re+KGjy0NHp4xk86oMpxc95KrenVQ9FPxYcIewN0WOuDvaHyPAlbQnuQjiv6EYxpxroamfDQC8ZE0jgU20BjzGvDFcaCPCpGcicDmd4rVvfe0BYJ56TyiuFeFBlgrhVbMrjemZc=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0501.namprd21.prod.outlook.com (10.172.122.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.2; Tue, 10 Apr 2018 16:37:43 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Tue, 10 Apr 2018 16:37:43 +0000
From: Praveen Balasubramanian 
To: Victor Vasiliev , Praveen Balasubramanian 
CC: IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxA=
Date: Tue, 10 Apr 2018 16:37:43 +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:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0501; 7:sD7YBiEvm+i6z7vpFgI2tdwRZWd6r/Wxg68Bv406YYHJ1KdZ5JSCgABwRN6Iaiz/jThUF9hpMSNOHP4D5PM/TgJBfHGnqXebDD4zPJozPMibCCgwCepr1eM7Wu+GZUBjhPESjBLKCxEom9YL4y3JaTh5DCnj8aqd9Vj6aXz+H3g2Avk6hCqc0E0eoeqxJqSv51QKAS7EvVBv5vmeZ0cZ0IZW7hZ1VWaN/3k2Nn98E+N5fsq03n4+SC2C8H5Hl4Uu; 20:cggMNZXz7Eljb+dh0XTvWLGwtrAkGJSxcK5ICexSLWY4A2UzeHOPT6q5gnZP29Useh9dhQfiozuPXU3pHqfqy7Ic9xBObzT7b0Sn1u3hjB+uJSpesMutzcZ0dMQwlGdvp4DdJ6guNRK1UqtlEIJ2xYXZu1xr/MIXsy53yoAYRQw=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0501; 
x-ms-traffictypediagnostic: CY4PR21MB0501:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(61425038)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(10201501046)(3231221)(944501327)(52105095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0501; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0501; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(376002)(39380400002)(396003)(189003)(199004)(6246003)(110136005)(7696005)(486006)(6436002)(8990500004)(10090500001)(236005)(9686003)(99286004)(54896002)(6306002)(25786009)(55016002)(53936002)(4326008)(2900100001)(476003)(97736004)(6506007)(11346002)(86362001)(5250100002)(53546011)(102836004)(316002)(22452003)(59450400001)(478600001)(10290500003)(76176011)(446003)(86612001)(19609705001)(46003)(106356001)(81156014)(81166006)(8936002)(7736002)(68736007)(33656002)(14454004)(229853002)(74316002)(186003)(105586002)(3280700002)(5660300001)(2906002)(3660700001)(8676002)(6116002)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0501; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 6ck6P0qyuETK8GuDOJSoHEXQoxv+BFGUsCaW26wpmqmtahs7Xxn8bklax6G6VETK5iCSv/usWTXkN/BYFmaTMkW9WzYIVUY7C8DV2B+oZ7bwyYT/FfPBAxh9GVkjmeO7iFOapRE8oH0qW++thQl7uA3cWVdjNKFr3QsqjS7fhbkcsCTfFRPbMoKFDngiQQk5SqiHQuOVY4GdHWt7FGQHPZLxfNdo8m5qlTBxkjvrVtFJGD22clVjS0sFbVVbH14Ij7mc90PAF1Y0+sb1vFw6XnKp7MjS3BZon5QLlGeOEVbqJXb52YCSP24RMKl2XdRlw46zYotWMWSaAyc7lIOAL8vAlkGqGqkCyUTnj7b3IMDWwU5FtSLqdl6WdTRw3jXbh7Vxi9Qxs3psf7Et7k6aEuPNbTslzZ3Lu8e3njbo2F0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB06300674D06468E62B98047FB6BE0CY4PR21MB0630namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 9b768464-13cb-471b-dc01-08d59f016282
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9b768464-13cb-471b-dc01-08d59f016282
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 16:37:43.8070 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0501
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 16:37:49 -0000

--_000_CY4PR21MB06300674D06468E62B98047FB6BE0CY4PR21MB0630namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUsIGlmIGEgbWlkZGxlYm94IHdhbnRzIHRvIGdvIG91dCBv
ZiBpdHMgd2F5IHRvIGRvIGFuYWx5c2lzIHRvIGJyZWFrIGEgUFJORyBhbmQgZmluZCB0aGUgcGFj
a2V0IG51bWJlciBpdCBjYW4uIFRoZSBzY2hlbWUgaXMgbm90IGV2ZW4gcmVxdWlyaW5nIGEgc2Vj
dXJlIHJhbmRvbSBudW1iZXIuIFRoZSBnb2FsIGlzIG5vdCB0byBwcm92aWRlIGFueSBzZWN1cml0
eSBhcm91bmQgUE4sIGp1c3QgcHJldmVudCBvc3NpZmljYXRpb24gYnkgZHVtYiBtaWRkbGVib3hl
cyB0aGF0IGFzc3VtZSB0aGUgbm9uY2UgaXMgYSBzZXF1ZW5jZSBudW1iZXIgYW5kIHRyeSB0byBy
ZW9yZGVyLiBJIGRvbuKAmXQgc2VlIGFueSBoYXJtIGlmIGNvc3RseSBhbmFseXNpcyBjYW4gYWxs
b3cgb24gcGF0aCBkZXRlcm1pbmF0aW9uIG9mIHBhY2tldCBudW1iZXJzLiBJIHN0YXRlZCB0aGlz
IGJlZm9yZSBidXQgdGhpcyBpcyBqdXN0IGltcHJvdmluZyBvc3NpZmljYXRpb24gcHJldmVudGlv
biwgbm90IHByb3ZpZGluZyBhbnkgc2VjdXJpdHkgb3IgdW5saW5rYWJpbGl0eSBldGMuDQoNCkZy
b206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWaWN0
b3IgVmFzaWxpZXYNClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDEwLCAyMDE4IDE6MDQgQU0NClRvOiBQ
cmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu
b3JnPg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBTaW1w
bGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24NCg0K
T24gTW9uLCBBcHIgOSwgMjAxOCwgMTM6NDggUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZi
PTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRt
YXJjLmlldGYub3JnPj4gd3JvdGU6DQpSZXF1aXJlbWVudHMgZm9yIGFueSBQTiB0cmFuc2Zvcm0g
aW4gdGhlIHNpbmdsZSBwYXRoIGNhc2U6DQoNCiAgMS4gIFRoZSBhY3R1YWwgUE4gbXVzdCBhbHdh
eXMgaW5jcmVtZW50IGJ5IDEgYW5kIHdpbGwgYmUgdXNlZCBmb3IgZ2VuZXJhdGluZyBBQ0tzIGlu
IEFDSyBmcmFtZXMuDQogIDIuICBUaGUgdHJhbnNmb3JtZWQgUE4gaW4gdGhlIGNsZWFyIGlzIGEg
bm9uY2UgYW5kIG11c3Qgbm90IHJlcGVhdCBvdmVyIHRoZSBjb25uZWN0aW9uIGxpZmV0aW1lLg0K
ICAzLiAgTWlkZGxlYm94ZXMgbXVzdCBub3QgYmUgYWJsZSB0byBkZXRlcm1pbmUgdGhlIGFjdHVh
bCBQTi4gT25seSB0aGUgUVVJQyByZWNlaXZlciBzaG91bGQgYmUgYWJsZSB0byBkbyBzby4NCldl
bGwsIHRoaXMgc291bmRzIGxpa2UgeW91J3JlIHJlcXVpcmluZyBhIGJsb2NrIGNpcGhlci4NCg==

--_000_CY4PR21MB06300674D06468E62B98047FB6BE0CY4PR21MB0630namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1MDU3
MDk5ODY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2MjExMjcxNTA7fQ0KQGxpc3QgbDA6bGV2
ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10
YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs
Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt
c3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph
bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDcN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs
cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t
OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh
dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86
aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb
ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+V2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUsIGlmIGEgbWlkZGxlYm94IHdhbnRzIHRvIGdvIG91
dCBvZiBpdHMgd2F5IHRvIGRvIGFuYWx5c2lzIHRvIGJyZWFrIGEgUFJORyBhbmQgZmluZCB0aGUg
cGFja2V0IG51bWJlciBpdCBjYW4uIFRoZSBzY2hlbWUgaXMgbm90IGV2ZW4gcmVxdWlyaW5nIGEg
c2VjdXJlIHJhbmRvbSBudW1iZXIuIFRoZSBnb2FsIGlzIG5vdCB0byBwcm92aWRlIGFueSBzZWN1
cml0eSBhcm91bmQNCiBQTiwganVzdCBwcmV2ZW50IG9zc2lmaWNhdGlvbiBieSBkdW1iIG1pZGRs
ZWJveGVzIHRoYXQgYXNzdW1lIHRoZSBub25jZSBpcyBhIHNlcXVlbmNlIG51bWJlciBhbmQgdHJ5
IHRvIHJlb3JkZXIuIEkgZG9u4oCZdCBzZWUgYW55IGhhcm0gaWYgY29zdGx5IGFuYWx5c2lzIGNh
biBhbGxvdyBvbiBwYXRoIGRldGVybWluYXRpb24gb2YgcGFja2V0IG51bWJlcnMuIEkgc3RhdGVk
IHRoaXMgYmVmb3JlIGJ1dCB0aGlzIGlzIGp1c3QgaW1wcm92aW5nIG9zc2lmaWNhdGlvbg0KIHBy
ZXZlbnRpb24sIG5vdCBwcm92aWRpbmcgYW55IHNlY3VyaXR5IG9yIHVubGlua2FiaWxpdHkgZXRj
LiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzpxdWlj
LWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPlZpY3RvciBWYXNpbGlldjxi
cj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxOCAxOjA0IEFNPGJyPg0KPGI+
VG86PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmI9NDBtaWNyb3NvZnQuY29t
QGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBRVUlDIFdHICZsdDtxdWlj
QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogU2ltcGxlIHRyYW5zZm9ybSBm
b3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXByIDksIDIwMTgsIDEzOjQ4IFBy
YXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2Yj08YSBocmVmPSJtYWlsdG86NDBtaWNyb3Nv
ZnQuY29tQGRtYXJjLmlldGYub3JnIj40MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZXF1aXJlbWVudHMgZm9yIGFueSBQTiB0cmFu
c2Zvcm0gaW4gdGhlIHNpbmdsZSBwYXRoIGNhc2U6PG86cD48L286cD48L3A+DQo8b2wgc3RhcnQ9
IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEg
bGZvMSI+DQpUaGUgYWN0dWFsIFBOIG11c3QgYWx3YXlzIGluY3JlbWVudCBieSAxIGFuZCB3aWxs
IGJlIHVzZWQgZm9yIGdlbmVyYXRpbmcgQUNLcyBpbiBBQ0sgZnJhbWVzLg0KPG86cD48L286cD48
L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhl
IHRyYW5zZm9ybWVkIFBOIGluIHRoZSBjbGVhciBpcyBhIG5vbmNlIGFuZCBtdXN0IG5vdCByZXBl
YXQgb3ZlciB0aGUgY29ubmVjdGlvbiBsaWZldGltZS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpNaWRkbGVib3hlcyBtdXN0
IG5vdCBiZSBhYmxlIHRvIGRldGVybWluZSB0aGUgYWN0dWFsIFBOLiBPbmx5IHRoZSBRVUlDIHJl
Y2VpdmVyIHNob3VsZCBiZSBhYmxlIHRvIGRvIHNvLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPldlbGwsIHRoaXMgc291bmRzIGxpa2UgeW91J3JlIHJlcXVpcmluZyBhIGJsb2NrIGNp
cGhlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_CY4PR21MB06300674D06468E62B98047FB6BE0CY4PR21MB0630namp_--


From nobody Tue Apr 10 09:38:03 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A70A012DA0C for ; Tue, 10 Apr 2018 09:37:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523378271; bh=L0KrOMN3eogoOim1JkIgZsi2+GxyxvgPJ1fi4yxPqTE=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=OZiI4MoQfFYYxJYyzZwmVi9QaypxgD8ZfhldIPi55Nygl+wYkX+M4JkVmnNl2xvxc CpwSxPA+z4dAEVaevH0CQuxinm8S67/pxpSNos7uThliBGECq1KbISkN2A8kyLt+vx NVhljfK0t85n71u5QqksGFnpA93xDpRmqcyzyxbU=
X-Mailbox-Line: From pravb@microsoft.com  Tue Apr 10 09:37:51 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 327AF12D0C3 for ; Tue, 10 Apr 2018 09:37:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523378271; bh=L0KrOMN3eogoOim1JkIgZsi2+GxyxvgPJ1fi4yxPqTE=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=OZiI4MoQfFYYxJYyzZwmVi9QaypxgD8ZfhldIPi55Nygl+wYkX+M4JkVmnNl2xvxc CpwSxPA+z4dAEVaevH0CQuxinm8S67/pxpSNos7uThliBGECq1KbISkN2A8kyLt+vx NVhljfK0t85n71u5QqksGFnpA93xDpRmqcyzyxbU=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD322126C89; Tue, 10 Apr 2018 09:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 4BPc3WXOc7vf; Tue, 10 Apr 2018 09:37:49 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe41::717]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D532112D0C3; Tue, 10 Apr 2018 09:37: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=L0KrOMN3eogoOim1JkIgZsi2+GxyxvgPJ1fi4yxPqTE=; b=jYaa1ydKwVdlWe6O0T90RgNAbi9/3+BGLy96Re+KGjy0NHp4xk86oMpxc95KrenVQ9FPxYcIewN0WOuDvaHyPAlbQnuQjiv6EYxpxroamfDQC8ZE0jgU20BjzGvDFcaCPCpGcicDmd4rVvfe0BYJ56TyiuFeFBlgrhVbMrjemZc=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0501.namprd21.prod.outlook.com (10.172.122.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.2; Tue, 10 Apr 2018 16:37:43 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Tue, 10 Apr 2018 16:37:43 +0000
From: Praveen Balasubramanian 
CC: IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxA=
Date: Tue, 10 Apr 2018 16:37:43 +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:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0501; 7:sD7YBiEvm+i6z7vpFgI2tdwRZWd6r/Wxg68Bv406YYHJ1KdZ5JSCgABwRN6Iaiz/jThUF9hpMSNOHP4D5PM/TgJBfHGnqXebDD4zPJozPMibCCgwCepr1eM7Wu+GZUBjhPESjBLKCxEom9YL4y3JaTh5DCnj8aqd9Vj6aXz+H3g2Avk6hCqc0E0eoeqxJqSv51QKAS7EvVBv5vmeZ0cZ0IZW7hZ1VWaN/3k2Nn98E+N5fsq03n4+SC2C8H5Hl4Uu; 20:cggMNZXz7Eljb+dh0XTvWLGwtrAkGJSxcK5ICexSLWY4A2UzeHOPT6q5gnZP29Useh9dhQfiozuPXU3pHqfqy7Ic9xBObzT7b0Sn1u3hjB+uJSpesMutzcZ0dMQwlGdvp4DdJ6guNRK1UqtlEIJ2xYXZu1xr/MIXsy53yoAYRQw=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0501; 
x-ms-traffictypediagnostic: CY4PR21MB0501:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(61425038)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(10201501046)(3231221)(944501327)(52105095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0501; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0501; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(376002)(39380400002)(396003)(189003)(199004)(6246003)(110136005)(7696005)(486006)(6436002)(8990500004)(10090500001)(236005)(9686003)(99286004)(54896002)(6306002)(25786009)(55016002)(53936002)(4326008)(2900100001)(476003)(97736004)(6506007)(11346002)(86362001)(5250100002)(53546011)(102836004)(316002)(22452003)(59450400001)(478600001)(10290500003)(76176011)(446003)(86612001)(19609705001)(46003)(106356001)(81156014)(81166006)(8936002)(7736002)(68736007)(33656002)(14454004)(229853002)(74316002)(186003)(105586002)(3280700002)(5660300001)(2906002)(3660700001)(8676002)(6116002)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0501; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 6ck6P0qyuETK8GuDOJSoHEXQoxv+BFGUsCaW26wpmqmtahs7Xxn8bklax6G6VETK5iCSv/usWTXkN/BYFmaTMkW9WzYIVUY7C8DV2B+oZ7bwyYT/FfPBAxh9GVkjmeO7iFOapRE8oH0qW++thQl7uA3cWVdjNKFr3QsqjS7fhbkcsCTfFRPbMoKFDngiQQk5SqiHQuOVY4GdHWt7FGQHPZLxfNdo8m5qlTBxkjvrVtFJGD22clVjS0sFbVVbH14Ij7mc90PAF1Y0+sb1vFw6XnKp7MjS3BZon5QLlGeOEVbqJXb52YCSP24RMKl2XdRlw46zYotWMWSaAyc7lIOAL8vAlkGqGqkCyUTnj7b3IMDWwU5FtSLqdl6WdTRw3jXbh7Vxi9Qxs3psf7Et7k6aEuPNbTslzZ3Lu8e3njbo2F0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB06300674D06468E62B98047FB6BE0CY4PR21MB0630namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 9b768464-13cb-471b-dc01-08d59f016282
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9b768464-13cb-471b-dc01-08d59f016282
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 16:37:43.8070 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0501
To: Victor Vasiliev 
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 16:37:55 -0000

--_000_CY4PR21MB06300674D06468E62B98047FB6BE0CY4PR21MB0630namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUsIGlmIGEgbWlkZGxlYm94IHdhbnRzIHRvIGdvIG91dCBv
ZiBpdHMgd2F5IHRvIGRvIGFuYWx5c2lzIHRvIGJyZWFrIGEgUFJORyBhbmQgZmluZCB0aGUgcGFj
a2V0IG51bWJlciBpdCBjYW4uIFRoZSBzY2hlbWUgaXMgbm90IGV2ZW4gcmVxdWlyaW5nIGEgc2Vj
dXJlIHJhbmRvbSBudW1iZXIuIFRoZSBnb2FsIGlzIG5vdCB0byBwcm92aWRlIGFueSBzZWN1cml0
eSBhcm91bmQgUE4sIGp1c3QgcHJldmVudCBvc3NpZmljYXRpb24gYnkgZHVtYiBtaWRkbGVib3hl
cyB0aGF0IGFzc3VtZSB0aGUgbm9uY2UgaXMgYSBzZXF1ZW5jZSBudW1iZXIgYW5kIHRyeSB0byBy
ZW9yZGVyLiBJIGRvbuKAmXQgc2VlIGFueSBoYXJtIGlmIGNvc3RseSBhbmFseXNpcyBjYW4gYWxs
b3cgb24gcGF0aCBkZXRlcm1pbmF0aW9uIG9mIHBhY2tldCBudW1iZXJzLiBJIHN0YXRlZCB0aGlz
IGJlZm9yZSBidXQgdGhpcyBpcyBqdXN0IGltcHJvdmluZyBvc3NpZmljYXRpb24gcHJldmVudGlv
biwgbm90IHByb3ZpZGluZyBhbnkgc2VjdXJpdHkgb3IgdW5saW5rYWJpbGl0eSBldGMuDQoNCkZy
b206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWaWN0
b3IgVmFzaWxpZXYNClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDEwLCAyMDE4IDE6MDQgQU0NClRvOiBQ
cmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu
b3JnPg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBTaW1w
bGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24NCg0K
T24gTW9uLCBBcHIgOSwgMjAxOCwgMTM6NDggUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZi
PTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRt
YXJjLmlldGYub3JnPj4gd3JvdGU6DQpSZXF1aXJlbWVudHMgZm9yIGFueSBQTiB0cmFuc2Zvcm0g
aW4gdGhlIHNpbmdsZSBwYXRoIGNhc2U6DQoNCiAgMS4gIFRoZSBhY3R1YWwgUE4gbXVzdCBhbHdh
eXMgaW5jcmVtZW50IGJ5IDEgYW5kIHdpbGwgYmUgdXNlZCBmb3IgZ2VuZXJhdGluZyBBQ0tzIGlu
IEFDSyBmcmFtZXMuDQogIDIuICBUaGUgdHJhbnNmb3JtZWQgUE4gaW4gdGhlIGNsZWFyIGlzIGEg
bm9uY2UgYW5kIG11c3Qgbm90IHJlcGVhdCBvdmVyIHRoZSBjb25uZWN0aW9uIGxpZmV0aW1lLg0K
ICAzLiAgTWlkZGxlYm94ZXMgbXVzdCBub3QgYmUgYWJsZSB0byBkZXRlcm1pbmUgdGhlIGFjdHVh
bCBQTi4gT25seSB0aGUgUVVJQyByZWNlaXZlciBzaG91bGQgYmUgYWJsZSB0byBkbyBzby4NCldl
bGwsIHRoaXMgc291bmRzIGxpa2UgeW91J3JlIHJlcXVpcmluZyBhIGJsb2NrIGNpcGhlci4NCg==

--_000_CY4PR21MB06300674D06468E62B98047FB6BE0CY4PR21MB0630namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1MDU3
MDk5ODY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2MjExMjcxNTA7fQ0KQGxpc3QgbDA6bGV2
ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10
YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs
Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt
c3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph
bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDcN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs
cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t
OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh
dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86
aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb
ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+V2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUsIGlmIGEgbWlkZGxlYm94IHdhbnRzIHRvIGdvIG91
dCBvZiBpdHMgd2F5IHRvIGRvIGFuYWx5c2lzIHRvIGJyZWFrIGEgUFJORyBhbmQgZmluZCB0aGUg
cGFja2V0IG51bWJlciBpdCBjYW4uIFRoZSBzY2hlbWUgaXMgbm90IGV2ZW4gcmVxdWlyaW5nIGEg
c2VjdXJlIHJhbmRvbSBudW1iZXIuIFRoZSBnb2FsIGlzIG5vdCB0byBwcm92aWRlIGFueSBzZWN1
cml0eSBhcm91bmQNCiBQTiwganVzdCBwcmV2ZW50IG9zc2lmaWNhdGlvbiBieSBkdW1iIG1pZGRs
ZWJveGVzIHRoYXQgYXNzdW1lIHRoZSBub25jZSBpcyBhIHNlcXVlbmNlIG51bWJlciBhbmQgdHJ5
IHRvIHJlb3JkZXIuIEkgZG9u4oCZdCBzZWUgYW55IGhhcm0gaWYgY29zdGx5IGFuYWx5c2lzIGNh
biBhbGxvdyBvbiBwYXRoIGRldGVybWluYXRpb24gb2YgcGFja2V0IG51bWJlcnMuIEkgc3RhdGVk
IHRoaXMgYmVmb3JlIGJ1dCB0aGlzIGlzIGp1c3QgaW1wcm92aW5nIG9zc2lmaWNhdGlvbg0KIHBy
ZXZlbnRpb24sIG5vdCBwcm92aWRpbmcgYW55IHNlY3VyaXR5IG9yIHVubGlua2FiaWxpdHkgZXRj
LiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzpxdWlj
LWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPlZpY3RvciBWYXNpbGlldjxi
cj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxOCAxOjA0IEFNPGJyPg0KPGI+
VG86PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmI9NDBtaWNyb3NvZnQuY29t
QGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBRVUlDIFdHICZsdDtxdWlj
QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogU2ltcGxlIHRyYW5zZm9ybSBm
b3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXByIDksIDIwMTgsIDEzOjQ4IFBy
YXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2Yj08YSBocmVmPSJtYWlsdG86NDBtaWNyb3Nv
ZnQuY29tQGRtYXJjLmlldGYub3JnIj40MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZXF1aXJlbWVudHMgZm9yIGFueSBQTiB0cmFu
c2Zvcm0gaW4gdGhlIHNpbmdsZSBwYXRoIGNhc2U6PG86cD48L286cD48L3A+DQo8b2wgc3RhcnQ9
IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEg
bGZvMSI+DQpUaGUgYWN0dWFsIFBOIG11c3QgYWx3YXlzIGluY3JlbWVudCBieSAxIGFuZCB3aWxs
IGJlIHVzZWQgZm9yIGdlbmVyYXRpbmcgQUNLcyBpbiBBQ0sgZnJhbWVzLg0KPG86cD48L286cD48
L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhl
IHRyYW5zZm9ybWVkIFBOIGluIHRoZSBjbGVhciBpcyBhIG5vbmNlIGFuZCBtdXN0IG5vdCByZXBl
YXQgb3ZlciB0aGUgY29ubmVjdGlvbiBsaWZldGltZS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpNaWRkbGVib3hlcyBtdXN0
IG5vdCBiZSBhYmxlIHRvIGRldGVybWluZSB0aGUgYWN0dWFsIFBOLiBPbmx5IHRoZSBRVUlDIHJl
Y2VpdmVyIHNob3VsZCBiZSBhYmxlIHRvIGRvIHNvLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPldlbGwsIHRoaXMgc291bmRzIGxpa2UgeW91J3JlIHJlcXVpcmluZyBhIGJsb2NrIGNp
cGhlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_CY4PR21MB06300674D06468E62B98047FB6BE0CY4PR21MB0630namp_--


From nobody Tue Apr 10 10:59:20 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7702112DA29 for ; Tue, 10 Apr 2018 10:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=evequefou.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9ujc1lEPsdn for ; Tue, 10 Apr 2018 10:59:15 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0113.outbound.protection.outlook.com [104.47.33.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E582C1250B8 for ; Tue, 10 Apr 2018 10:59:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SndjqXvnqDktRuiUUqXiAAPdz8ZCm72VQaSsiE/5K7k=; b=AblD+KHTjGZ39a/A4L7gpFpxdj1kl5+0yW52nl3NnF6WmialGRjsNriLm76iL5MBZxBMVzshFGEz3ig+aOt/8fK/yA8grroFQN2aR9xSCq7nlm0wrpXk/fAtZUztcfttXkBZaW/2WxsGvdlKv3I6P94MPhjd6xcnokgnMFo/HyI=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1919.namprd08.prod.outlook.com (10.169.39.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Tue, 10 Apr 2018 17:59:11 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0653.015; Tue, 10 Apr 2018 17:59:11 +0000
From: Mike Bishop 
To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Martin Thomson , Ariel Otilibili Anieli , Jana Iyengar 
CC: QUIC WG 
Subject: RE: Comments draft-ietf-quic-transport-10
Thread-Topic: Comments draft-ietf-quic-transport-10
Thread-Index: AQHT0NjW0TtKMWtJLEmhiiCeDzZ5Q6P6H+YAgAApfuA=
Date: Tue, 10 Apr 2018 17:59:11 +0000
Message-ID: 
References: <20180408200158.kuekyw4nk8ks4kkw@webmail.eurecom.fr>  <20180410163250.3ixpqer5k4okkokk@webmail.eurecom.fr> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; 
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1919; 7:n6hQlSV0NI4yqm0f719tZzJfsN5Vk0N3ie77YjN7gZ38V0bL6lklQBwTCz0ulOTPlxReWIu/d8hUqi0lWbipDNkgH+XCp0FnPd76cxQuWfUnw9nmQZyw1f7BN1/cAPwQ7LeRgNbGpuXQj5Ibeqm92BpcB0ReZcevp3HxkvCtp7dEAo2snGv0qFlWzDP1fngFbMLjLUsOlSVqe/oGVwn93qL3Qy3iu45WOtnE5Vr5Mb16vVxssGpVkl6V1OkyHmha
x-ms-exchange-antispam-srfa-diagnostics: SOS;
X-MS-Office365-Filtering-Correlation-Id: 32e89c3b-1cd4-4c4a-47d3-08d59f0cc3b6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1919; 
x-ms-traffictypediagnostic: SN1PR08MB1919:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(85827821059158)(15185016700835)(21748063052155)(8454915177855);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(10201501046)(3002001)(6041310)(2016111802025)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1919; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1919; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(396003)(366004)(376002)(39830400003)(51444003)(51914003)(189003)(199004)(76176011)(102836004)(6436002)(14454004)(81166006)(81156014)(3660700001)(790700001)(110136005)(8676002)(86362001)(5660300001)(3846002)(106356001)(53386004)(236005)(39060400002)(54896002)(9686003)(6306002)(6246003)(6116002)(2906002)(55016002)(26005)(316002)(966005)(59450400001)(446003)(74316002)(4326008)(19609705001)(186003)(53936002)(6506007)(11346002)(3280700002)(8936002)(93886005)(566704002)(2900100001)(478600001)(99286004)(5890100001)(97736004)(486006)(476003)(5250100002)(229853002)(33656002)(105586002)(74482002)(7696005)(68736007)(53546011)(66066001)(606006)(25786009)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1919; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: FWp4F4o9nn6d/t7/s/P9IDvQEaWBGrOVjO6BzMaUJOB/koqdUeEUB1+kSIXLit6xhZNx4l9CCJTBlfoFU5IzSl1cu2T8o/SNHEK6vOZeY6Qd35nIhmb9cx8jVYYP1lLCjcKsUJ83aGSVFuJq9lGs7ukqWjCQLonHO59LLUictlGum6ZUHaSyZpfzqBaEqlN5eBmsydSR1Nf1qrHpGvuJl1i9+CPdkcijPwtx1vF0JkrbxJITNQu9EzMCWwPTpItjtHGi+mMDGbQ4dZ3kwf5hIRNmg/PgEg0Oy0F6OfDrMp4Nj4NUAomaxna6OCedMtKWG9glq/DYo4089vhLNL3mOxga/vuqG32vzmzNcKCMlHjF5FIhRqH+s93QW1sWsQCAhaAgtEvSNtaYnvq2GH2p7RuA6vyAdi24xMyWAZGDfzc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR08MB18546646E989D5B3FB3985A0DABE0SN1PR08MB1854namp_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 32e89c3b-1cd4-4c4a-47d3-08d59f0cc3b6
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 17:59:11.3313 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1919
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 17:59:19 -0000

--_000_SN1PR08MB18546646E989D5B3FB3985A0DABE0SN1PR08MB1854namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SXTigJlzIG5vdCBldmVuIHVzZWQgZm9yIHJla2V5aW5nIGFueSBtb3JlIOKAkyB0aGF04oCZcyBk
b25lIGF0IHRoZSBRVUlDIGxheWVyIGFzIHdlbGwuICBUaGUgb25seSBwb3N0LWhhbmRzaGFrZSB1
c2Ugb2YgVExTIGlzIHRoZSBOZXdTZXNzaW9uVGlja2V0IG1lc3NhZ2UuDQoNCkZyb206IFFVSUMg
W21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtrZWwgRmFobsO4
ZSBKw7hyZ2Vuc2VuDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxOCA4OjMwIEFNDQpUbzog
TWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IEFyaWVsIE90aWxpYmls
aSBBbmllbGkgPG90aWxpYmlsQGV1cmVjb20uZnI+OyBKYW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdt
YWlsLmNvbT4NCkNjOiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IENvbW1l
bnRzIGRyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQtMTANCg0KVExTIGlzIG9ubHkgdXNlZCBmb3Ig
aGFuZHNoYWtlIGFuZCBmb3IgcGVyaW9kaWMgcmVrZXlpbmcuDQoNCkV2ZXJ5dGhpbmcgZWxzZSBp
cyBmdWxseSBtYW5hZ2VkIGJ5IFFVSUMsIHNvIGEgVExTIGhlYXJ0YmVhdCB3b3VsZCBub3QgYmUg
dXNlZnVsLiBQSU5HIGFsc28gc2VydmVzIG90aGVyIHB1cnBvc2VzIGluY2x1ZGluZyBhc2tpbmcg
Zm9yIEFDSyBtZXNzYWdlcyB0byBiZSBzZW50Lg0KDQpFdmVuIGNyeXB0byBpcyBub3QgaGFuZGxl
ZCBieSBUTFMgYWZ0ZXIgaGFuZHNoYWtlIGFsdGhvdWdoIGl0IGRvZXMgcHJvdmlkZSB0aGUga2V5
cyBhbmQgYWx0aG91Z2ggVExTIGxpYnJhcmllcyBsaWtlbHkgaW1wbGVtZW50IHRoZSByZXF1aXJl
ZCBmdW5jdGlvbmFsaXR5Lg0KDQoNCk9uIDEwIEFwcmlsIDIwMTggYXQgMTYuMzMuMDIsIEFyaWVs
IE90aWxpYmlsaSBBbmllbGkgKG90aWxpYmlsQGV1cmVjb20uZnI8bWFpbHRvOm90aWxpYmlsQGV1
cmVjb20uZnI+KSB3cm90ZToNCkhpIE1hcnRpbiwNCg0KQSBjb21tZW50IGlubGluZS4gQW5kIGFu
b3RoZXIgdGhpbmcgb24gdGhpcyBkcmFmdDoNCg0KUVVJQyBkZWZpbmVzIFBJTkcgZnJhbWVzLCBh
bmQgcmVsaWVzIGF0IHRoZSBzYW1lIHRpbWUgb24gVExTLiBUTFMgaGFzDQphbHJlYWR5IHRoZSBI
ZWFydGJlYXQgcHJvdG9jb2wgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTIwKTsN
Cml0IHByb3ZpZGVzIHRoZSBzYW1lIGZ1bmN0aW9ucyB0aGFuIFBJTkcgZnJhbWVzLg0KDQpTZWN0
aW9uIDguOSBzaG91bGQgY2xhcmlmeTogd2hpY2ggbGF5ZXIgZG9taW5hdGVzIHRoZSBvdGhlcjog
UElORw0KZnJhbWVzLCBvciBUTFMgSGVhcnRiZWF0Pw0KDQpSZWdhcmRzLA0KQXJpZWwNCg0KUXVv
dGluZyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0
aW4udGhvbXNvbkBnbWFpbC5jb20+PjoNCg0KPiBIaSBBcmllbCwNCj4NCj4gVGhhbmtzIGZvciB0
aGUgaW5wdXQuDQo+DQo+IE9uIE1vbiwgQXByIDksIDIwMTggYXQgNDowMSBBTSwgQXJpZWwgT3Rp
bGliaWxpIEFuaWVsaQ0KPiA8b3RpbGliaWxAZXVyZWNvbS5mcjxtYWlsdG86b3RpbGliaWxAZXVy
ZWNvbS5mcj4+IHdyb3RlOg0KPj4gMS4gVGhlIGRvY3VtZW50IGRlZmluZXMgUVVJQywgYnV0IG5v
d2hlcmUgaGF2ZSBJIGNvbWUgYWNyb3NzIHRoZSBkZWZpbml0aW9uDQo+PiBvZiBpdHMgYWNyb255
bTogaXQgd291bGQgaGVscCByZWFkZXJzIHRvIGdldCBpdCBmcm9tIHRoZSBhYnN0cmFjdCwgb3Ig
bm8NCj4+IGxhdGVyIHRoYW4gdGhlIGludHJvZHVjdGlvbi4NCj4NCj4gUVVJQyBpcyBub3QgYW4g
YWNyb255bS4gWW91IGFyZSBleHBlY3RlZCB0byBzaG91dCBpdCA7KQ0KU3RhdGVkIGluIGh0dHBz
Oi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8xMjgyDQo+DQo+PiAyLiBTZWN0
aW9uIDIgbGF5cyBvdXQgdGhlIENvbnZlbnRpb25zIGFuZCBEZWZpbml0aW9ucywgYnV0IGRvZXMg
bm90IHN0YXRlDQo+PiB0aGUgbWVhbmluZyBvZiBmcmFtZXMgKHRob3VnaCB0aGV5IGFyZSB1c2Vk
IG1hbnkgdGltZXMpLiBTZWN0aW9uIDIgc2hvdWxkDQo+PiBhbHNvIGRlZmluZSB3aGF0IGlzIGEg
ZnJhbWUsIGFuZCBob3cgaXQgcmVsYXRlcyB3aXRoIGEgc3RyZWFtcyBhbmQgYSBwYWNrZXQuDQo+
DQo+IEEgcHVsbCByZXF1ZXN0IHdvdWxkIGJlIHdlbGNvbWUuDQo+DQo+PiAzLiBTb21lIHR5cG9z
OyB0aGUgdGV4dCBjb250YWlucyBhYmJyZXZpYXRpb25zIChlLmcsICJpc24ndCIgZm9yICJpcyBu
b3QiLA0KPj4gImRvbid0IiBmb3IgImRvIG5vdCIpLCBhbmQgYWxzbyBjb25zaWRlcnMgdGVjaG5p
Y2FsIHRlcm1zIGFzIGxlZ2FsIHBlcnNvbnMNCj4+ICgiUVVJQydzIEFDSyBmcmFtZXMiLCAiVENQ
J3MgcmV0cmFuc21pc3Npb24iKS4gU2VlIHRoZW0gaW4gdGhlIGF0dGFjaG1lbnQuLg0KPg0KPiBJ
IGRvbid0IGNvbnNpZGVyIHVzZSBvZiBjb250cmFjdGlvbnMgdG8gYmUgdHlwb3MuIEkgZG8gdHJ5
IHRvIGF2b2lkDQo+IHRoZSBwb3NzZXNzaXZlIGZvcm0sIGJ1dCBJIHN1c3BlY3QgdGhhdCBJIG9y
IG90aGVyIGNvbnRyaWJ1dG9ycyBzbGlwDQo+IG9uIG9jY2FzaW9uLiBBZ2FpbiwgYSBwdWxsIHJl
cXVlc3QgaXMgdGhlIGJlc3Qgd2F5IHRvIG1ha2UgdGhpcw0KPiBjb250cmlidXRpb24uDQo+DQo+
PiBGaW5hbGx5LCBvbiB0aGUgUVVJQyB2ZXJzaW9uIG51bWJlcmluZzogSSB0aGluayBpdCB3b3Vs
ZCBlYXNlIHJlYWRlcnMgdG8NCj4+IGhhdmUgYSBodW1hbi1mcmllbmRseSByZXByZXNlbnRhdGlv
bg0KPg0KPiBJIHRoaW5rIHRoYXQgIjEiIGlzIHBlcmZlY3RseSBodW1hbiBmcmllbmRseS4gSXQn
cyBqdXN0IGEgbnVtYmVyLiBXZQ0KPiB1c2UgdGhlIGZ1bGwsIHVuYW1iaWd1b3VzIGZvcm0gaW4g
YSBzcGVjaWZpY2F0aW9uIGJlY2F1c2Ugd2UgYmVsaWV2ZQ0KPiBvdXIgYXVkaWVuY2UgaXMgY2Fw
YWJsZSBvZiBoYW5kbGluZyB0aGF0LiBGZWVsIGZyZWUgdG8gdXNlIHdoYXRldmVyDQo+IG51bWVy
aWNhbCByZXByZXNlbnRhdGlvbiB5b3UgZmVlbCBzdWl0cyB5b3UgYmVzdC4NCj4NCj4gVW5hbWJp
Z3VvdXMgdGV4dHVhbCByZXByZXNlbnRhdGlvbnMgYXJlIG5vdCBhIGdvYWwgaGVyZSwgYXMgaXQg
aXMNCj4gKHVuZm9ydHVuYXRlbHkpIGZvciBhZGRyZXNzZXMuIElmIHRoZSBudW1iZXIgaXMgcHJl
c2VudGVkIHRvIGEgaHVtYW4sDQo+IEkgc2luY2VyZWx5IGhvcGUgdGhhdCB0aGV5IGFyZSBhbiBl
bmdpbmVlciBhbmQgdGhlcmVmb3JlIGNhcGFibGUgb2YNCj4gY29waW5nLg0KPg0KDQoNCg0KLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIHdhcyBzZW50IHVzaW5nIEVVUkVDT00g
V2VibWFpbDogaHR0cDovL3dlYm1haWwuZXVyZWNvbS5mcg0K

--_000_SN1PR08MB18546646E989D5B3FB3985A0DABE0SN1PR08MB1854namp_
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
Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl04oCZ
cyBub3QgZXZlbiB1c2VkIGZvciByZWtleWluZyBhbnkgbW9yZSDigJMgdGhhdOKAmXMgZG9uZSBh
dCB0aGUgUVVJQyBsYXllciBhcyB3ZWxsLiZuYnNwOyBUaGUgb25seSBwb3N0LWhhbmRzaGFrZSB1
c2Ugb2YgVExTIGlzIHRoZSBOZXdTZXNzaW9uVGlja2V0IG1lc3NhZ2UuPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu
ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4g
UVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+
TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJp
bCAxMCwgMjAxOCA4OjMwIEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFy
dGluLnRob21zb25AZ21haWwuY29tJmd0OzsgQXJpZWwgT3RpbGliaWxpIEFuaWVsaSAmbHQ7b3Rp
bGliaWxAZXVyZWNvbS5mciZndDs7IEphbmEgSXllbmdhciAmbHQ7anJpLmlldGZAZ21haWwuY29t
Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8
Yj5TdWJqZWN0OjwvYj4gUmU6IENvbW1lbnRzIGRyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQtMTA8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRMUyBpcyBvbmx5IHVzZWQgZm9yIGhhbmRz
aGFrZSBhbmQgZm9yIHBlcmlvZGljIHJla2V5aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5FdmVyeXRoaW5nIGVsc2UgaXMgZnVsbHkgbWFuYWdlZCBieSBRVUlDLCBzbyBh
IFRMUyBoZWFydGJlYXQgd291bGQgbm90IGJlIHVzZWZ1bC4gUElORyBhbHNvIHNlcnZlcyBvdGhl
ciBwdXJwb3NlcyBpbmNsdWRpbmcgYXNraW5nIGZvciBBQ0sgbWVzc2FnZXMgdG8gYmUgc2VudC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RXZlbiBjcnlwdG8gaXMgbm90IGhh
bmRsZWQgYnkgVExTIGFmdGVyIGhhbmRzaGFrZSBhbHRob3VnaCBpdCBkb2VzIHByb3ZpZGUgdGhl
IGtleXMgYW5kIGFsdGhvdWdoIFRMUyBsaWJyYXJpZXMgbGlrZWx5IGltcGxlbWVudCB0aGUgcmVx
dWlyZWQgZnVuY3Rpb25hbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMTAgQXBy
aWwgMjAxOCBhdCAxNi4zMy4wMiwgQXJpZWwgT3RpbGliaWxpIEFuaWVsaSAoPGEgaHJlZj0ibWFp
bHRvOm90aWxpYmlsQGV1cmVjb20uZnIiPm90aWxpYmlsQGV1cmVjb20uZnI8L2E+KSB3cm90ZTo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SGkgTWFy
dGluLA0KPGJyPg0KPGJyPg0KQSBjb21tZW50IGlubGluZS4gQW5kIGFub3RoZXIgdGhpbmcgb24g
dGhpcyBkcmFmdDogPGJyPg0KPGJyPg0KUVVJQyBkZWZpbmVzIFBJTkcgZnJhbWVzLCBhbmQgcmVs
aWVzIGF0IHRoZSBzYW1lIHRpbWUgb24gVExTLiBUTFMgaGFzIDxicj4NCmFscmVhZHkgdGhlIEhl
YXJ0YmVhdCBwcm90b2NvbCAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm
YzY1MjAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTIwPC9hPik7DQo8YnI+DQpp
dCBwcm92aWRlcyB0aGUgc2FtZSBmdW5jdGlvbnMgdGhhbiBQSU5HIGZyYW1lcy4gPGJyPg0KPGJy
Pg0KU2VjdGlvbiA4Ljkgc2hvdWxkIGNsYXJpZnk6IHdoaWNoIGxheWVyIGRvbWluYXRlcyB0aGUg
b3RoZXI6IFBJTkcgPGJyPg0KZnJhbWVzLCBvciBUTFMgSGVhcnRiZWF0PyA8YnI+DQo8YnI+DQpS
ZWdhcmRzLCA8YnI+DQpBcmllbCA8YnI+DQo8YnI+DQpRdW90aW5nIE1hcnRpbiBUaG9tc29uICZs
dDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5tYXJ0aW4udGhvbXNv
bkBnbWFpbC5jb208L2E+Jmd0OzoNCjxicj4NCjxicj4NCiZndDsgSGkgQXJpZWwsIDxicj4NCiZn
dDsgPGJyPg0KJmd0OyBUaGFua3MgZm9yIHRoZSBpbnB1dC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IE9uIE1vbiwgQXByIDksIDIwMTggYXQgNDowMSBBTSwgQXJpZWwgT3RpbGliaWxpIEFuaWVsaSA8
YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b3RpbGliaWxAZXVyZWNvbS5mciI+b3RpbGli
aWxAZXVyZWNvbS5mcjwvYT4mZ3Q7IHdyb3RlOiA8YnI+DQomZ3Q7Jmd0OyAxLiBUaGUgZG9jdW1l
bnQgZGVmaW5lcyBRVUlDLCBidXQgbm93aGVyZSBoYXZlIEkgY29tZSBhY3Jvc3MgdGhlIGRlZmlu
aXRpb24gPGJyPg0KJmd0OyZndDsgb2YgaXRzIGFjcm9ueW06IGl0IHdvdWxkIGhlbHAgcmVhZGVy
cyB0byBnZXQgaXQgZnJvbSB0aGUgYWJzdHJhY3QsIG9yIG5vIDxicj4NCiZndDsmZ3Q7IGxhdGVy
IHRoYW4gdGhlIGludHJvZHVjdGlvbi4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFFVSUMgaXMgbm90
IGFuIGFjcm9ueW0uIFlvdSBhcmUgZXhwZWN0ZWQgdG8gc2hvdXQgaXQgOykgPGJyPg0KU3RhdGVk
IGluIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8x
MjgyIj5odHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMTI4MjwvYT4N
Cjxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgMi4gU2VjdGlvbiAyIGxheXMgb3V0IHRoZSBDb252
ZW50aW9ucyBhbmQgRGVmaW5pdGlvbnMsIGJ1dCBkb2VzIG5vdCBzdGF0ZSA8YnI+DQomZ3Q7Jmd0
OyB0aGUgbWVhbmluZyBvZiBmcmFtZXMgKHRob3VnaCB0aGV5IGFyZSB1c2VkIG1hbnkgdGltZXMp
LiBTZWN0aW9uIDIgc2hvdWxkIDxicj4NCiZndDsmZ3Q7IGFsc28gZGVmaW5lIHdoYXQgaXMgYSBm
cmFtZSwgYW5kIGhvdyBpdCByZWxhdGVzIHdpdGggYSBzdHJlYW1zIGFuZCBhIHBhY2tldC4gPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IEEgcHVsbCByZXF1ZXN0IHdvdWxkIGJlIHdlbGNvbWUuIDxicj4N
CiZndDsgPGJyPg0KJmd0OyZndDsgMy4gU29tZSB0eXBvczsgdGhlIHRleHQgY29udGFpbnMgYWJi
cmV2aWF0aW9ucyAoZS5nLCAmcXVvdDtpc24ndCZxdW90OyBmb3IgJnF1b3Q7aXMgbm90JnF1b3Q7
LCA8YnI+DQomZ3Q7Jmd0OyAmcXVvdDtkb24ndCZxdW90OyBmb3IgJnF1b3Q7ZG8gbm90JnF1b3Q7
KSwgYW5kIGFsc28gY29uc2lkZXJzIHRlY2huaWNhbCB0ZXJtcyBhcyBsZWdhbCBwZXJzb25zIDxi
cj4NCiZndDsmZ3Q7ICgmcXVvdDtRVUlDJ3MgQUNLIGZyYW1lcyZxdW90OywgJnF1b3Q7VENQJ3Mg
cmV0cmFuc21pc3Npb24mcXVvdDspLiBTZWUgdGhlbSBpbiB0aGUgYXR0YWNobWVudC4uIDxicj4N
CiZndDsgPGJyPg0KJmd0OyBJIGRvbid0IGNvbnNpZGVyIHVzZSBvZiBjb250cmFjdGlvbnMgdG8g
YmUgdHlwb3MuIEkgZG8gdHJ5IHRvIGF2b2lkIDxicj4NCiZndDsgdGhlIHBvc3Nlc3NpdmUgZm9y
bSwgYnV0IEkgc3VzcGVjdCB0aGF0IEkgb3Igb3RoZXIgY29udHJpYnV0b3JzIHNsaXAgPGJyPg0K
Jmd0OyBvbiBvY2Nhc2lvbi4gQWdhaW4sIGEgcHVsbCByZXF1ZXN0IGlzIHRoZSBiZXN0IHdheSB0
byBtYWtlIHRoaXMgPGJyPg0KJmd0OyBjb250cmlidXRpb24uIDxicj4NCiZndDsgPGJyPg0KJmd0
OyZndDsgRmluYWxseSwgb24gdGhlIFFVSUMgdmVyc2lvbiBudW1iZXJpbmc6IEkgdGhpbmsgaXQg
d291bGQgZWFzZSByZWFkZXJzIHRvIDxicj4NCiZndDsmZ3Q7IGhhdmUgYSBodW1hbi1mcmllbmRs
eSByZXByZXNlbnRhdGlvbiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB0aGluayB0aGF0ICZxdW90
OzEmcXVvdDsgaXMgcGVyZmVjdGx5IGh1bWFuIGZyaWVuZGx5LiBJdCdzIGp1c3QgYSBudW1iZXIu
IFdlIDxicj4NCiZndDsgdXNlIHRoZSBmdWxsLCB1bmFtYmlndW91cyBmb3JtIGluIGEgc3BlY2lm
aWNhdGlvbiBiZWNhdXNlIHdlIGJlbGlldmUgPGJyPg0KJmd0OyBvdXIgYXVkaWVuY2UgaXMgY2Fw
YWJsZSBvZiBoYW5kbGluZyB0aGF0LiBGZWVsIGZyZWUgdG8gdXNlIHdoYXRldmVyIDxicj4NCiZn
dDsgbnVtZXJpY2FsIHJlcHJlc2VudGF0aW9uIHlvdSBmZWVsIHN1aXRzIHlvdSBiZXN0LiA8YnI+
DQomZ3Q7IDxicj4NCiZndDsgVW5hbWJpZ3VvdXMgdGV4dHVhbCByZXByZXNlbnRhdGlvbnMgYXJl
IG5vdCBhIGdvYWwgaGVyZSwgYXMgaXQgaXMgPGJyPg0KJmd0OyAodW5mb3J0dW5hdGVseSkgZm9y
IGFkZHJlc3Nlcy4gSWYgdGhlIG51bWJlciBpcyBwcmVzZW50ZWQgdG8gYSBodW1hbiwgPGJyPg0K
Jmd0OyBJIHNpbmNlcmVseSBob3BlIHRoYXQgdGhleSBhcmUgYW4gZW5naW5lZXIgYW5kIHRoZXJl
Zm9yZSBjYXBhYmxlIG9mIDxicj4NCiZndDsgY29waW5nLiA8YnI+DQomZ3Q7IDxicj4NCjxicj4N
Cjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhpcyBtZXNzYWdlIHdh
cyBzZW50IHVzaW5nIEVVUkVDT00gV2VibWFpbDogPGEgaHJlZj0iaHR0cDovL3dlYm1haWwuZXVy
ZWNvbS5mciI+DQpodHRwOi8vd2VibWFpbC5ldXJlY29tLmZyPC9hPiA8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_SN1PR08MB18546646E989D5B3FB3985A0DABE0SN1PR08MB1854namp_--


From nobody Tue Apr 10 13:19:37 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E680612D7E4 for ; Tue, 10 Apr 2018 13:19:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523391575; bh=5HDvmiixsoQ8UuEblABKrM+ugpEszw3LgJQYvH1EkvY=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=en5kSxB3S7Qalck+8AgZG3UV/AJJoOcRsZsem7DP1rF/IoIojUtsOVxWhMBfjS/9N DtcxzMfogGyDlADwaqWzx/qx14ocB0kw53VkNwjZBAY7AcyxzOKN1kXthWNEuqWlEv RP331c3WvioHrcxmyr9nTxKCDkYcXnxL8efh5Ut0=
X-Mailbox-Line: From rch@google.com  Tue Apr 10 13:19:35 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A92E51272E1; Tue, 10 Apr 2018 13:19:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523391575; bh=A3uHd6d3vdRzKDMfZJc3JIR0NyyzrfC4JcFO+ZfvmHU=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=MKaLTpX4h44U5Sy52ydDzmayzqelPCd5WurvcN72HaBTtzNygh5AdQs+aXbI5oYHe J8dHqSVLMFEbZOPZYWUaGweD5rz162pIUXDntGT5sKqBQFPV03dpYFxmGK58YBvdul 9LCUv9GwP0sBBd+o7cme35wDatO0yaXF5FdcPbZM=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848C212D77B for ; Tue, 10 Apr 2018 13:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level: 
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0IsF_ewC2N1 for ; Tue, 10 Apr 2018 13:19:34 -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 D718F1272E1 for ; Tue, 10 Apr 2018 13:19:33 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id c20so4464052ywa.2 for ; Tue, 10 Apr 2018 13:19: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=A3uHd6d3vdRzKDMfZJc3JIR0NyyzrfC4JcFO+ZfvmHU=; b=TpXs9Fh26uPGyGNN+htrxKzi9ecGpwyNOQh8/f5JHSr35fqc795Ew+TS/rUxGqAVnF Q9E31Sz/9u9suvlKUp7LMGIWcgPy4xstj2ct/vuRewHZEwDa6RYuWoCyqJM86U7Dj6DZ e8uHBwO/u+0ga8U7h8xST99fyM53rU+jqzhvWxhT/WayoF8z1wvG8WgxweQi8P+oipvc PfIE7BDWBL8N6Z8k3uxzd2Fx6ht3RVAYg2gPgq2pyXcR2fxgqyLjskIeynmA2MUB2ys1 sD8PJjOWD+WBE2yCoxGA18II07+W9H+ZzWTTywLeAYGMGVOk9csTYXkpi8xD4IQvpUxO g3CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=A3uHd6d3vdRzKDMfZJc3JIR0NyyzrfC4JcFO+ZfvmHU=; b=ss2J98giPUTtCeepS40wkiCgiPH7ZryogsaJ0eIhSPLgZgr8FQeN1jiI56JoQL05vk pNuQWUe+qnfmlD61iPc1Q2rdM1jXxr95FHXYhO+gORfAa+dxjFD0jGd9D8wT/IKibGEY +XGQyqCkBtWi+wXtIKU3jsW5niiwf8Y9skfojz5nSBqq5oEabf+l0aHZSXx3iDPO6cEZ S9/iGm7diiBsZJU03jazOebbZP/svcGsHoQOQAmHSWNi/l3NrDkd/00O5/t+SRVdPIHs 1v8V6sEDrfwzgXvsbLuRN25wfWDlKkAePPwnJpxmAbEyZGh/+Hxg2Hw1Clo4jf0jJm+7 cDyA==
X-Gm-Message-State: ALQs6tDH2bol1SbHMnPnrz+9apyA4vdQTlWU4nKVmxKqJ1ZpZmpJzSXE b7NLlEAwZJiPX7HhqFvUMeyLLkIz4i7xda/JKDSaRw==
X-Google-Smtp-Source: AIpwx4+UOe9r8s5JjoqbxyJ0M+BiGrkZGeLX0Dgkyzv6YXjYqJkkIDoCVbIeGoRVlYPlZtgjXCj8tsTYScDt7QXQqA8=
X-Received: by 10.129.81.151 with SMTP id f145mr1161393ywb.496.1523391572588;  Tue, 10 Apr 2018 13:19:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:98c5:0:0:0:0:0 with HTTP; Tue, 10 Apr 2018 13:19:31 -0700 (PDT)
In-Reply-To: 
References:   
From: Ryan Hamilton 
Date: Tue, 10 Apr 2018 13:19:31 -0700
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
Content-Type: multipart/alternative; boundary="001a1145696a8a66250569843dae"
To: Praveen Balasubramanian 
Cc: Victor Vasiliev 
Cc: IETF QUIC WG 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 20:19:36 -0000

--001a1145696a8a66250569843dae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 10, 2018 at 9:37 AM, Praveen Balasubramanian <
pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

> With the shuffle scheme, if a middlebox wants to go out of its way to do
> analysis to break a PRNG and find the packet number it can. The scheme is
> not even requiring a secure random number. The goal is not to provide any
> security around PN, just prevent ossification by dumb middleboxes that
> assume the nonce is a sequence number and try to reorder. I don=E2=80=99t=
 see any
> harm if costly analysis can allow on path determination of packet numbers=
..
>

Are you concerned about "helpful" middlebox which are willing to expend the
resources to do costly analysis in order to "repair" packet reorder (and
consequently introduce HOL blocking)

--001a1145696a8a66250569843dae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Tue, Apr 1=
0, 2018 at 9:37 AM, Praveen Balasubramanian <pravb=3D40microsoft=
..com@dmarc.ietf.org> wrote:











With the shuffle scheme, if a middlebox wants to go =
out of its way to do analysis to break a PRNG and find the packet number it=
 can. The scheme is not even requiring a secure random number. The goal is =
not to provide any security around
 PN, just prevent ossification by dumb middleboxes that assume the nonce is=
 a sequence number and try to reorder. I don=E2=80=99t see any harm if cost=
ly analysis can allow on path determination of packet numbers.

Are you concerned about &qu=
ot;helpful" middlebox which are willing to expend the resources to do =
costly analysis in order to "repair" packet reorder (and conseque=
ntly introduce HOL blocking)



--001a1145696a8a66250569843dae--


From nobody Tue Apr 10 13:19:42 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BF712895E for ; Tue, 10 Apr 2018 13:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level: 
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 UvTtMjLzPPWF for ; Tue, 10 Apr 2018 13:19:34 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D596E124217 for ; Tue, 10 Apr 2018 13:19:33 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id r29so4455518ywa.12 for ; Tue, 10 Apr 2018 13:19: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=A3uHd6d3vdRzKDMfZJc3JIR0NyyzrfC4JcFO+ZfvmHU=; b=TpXs9Fh26uPGyGNN+htrxKzi9ecGpwyNOQh8/f5JHSr35fqc795Ew+TS/rUxGqAVnF Q9E31Sz/9u9suvlKUp7LMGIWcgPy4xstj2ct/vuRewHZEwDa6RYuWoCyqJM86U7Dj6DZ e8uHBwO/u+0ga8U7h8xST99fyM53rU+jqzhvWxhT/WayoF8z1wvG8WgxweQi8P+oipvc PfIE7BDWBL8N6Z8k3uxzd2Fx6ht3RVAYg2gPgq2pyXcR2fxgqyLjskIeynmA2MUB2ys1 sD8PJjOWD+WBE2yCoxGA18II07+W9H+ZzWTTywLeAYGMGVOk9csTYXkpi8xD4IQvpUxO g3CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=A3uHd6d3vdRzKDMfZJc3JIR0NyyzrfC4JcFO+ZfvmHU=; b=e/qmqF7H0cYSpZFSw31sSf0RAW4cxOmGXUONbVLEyVEQSn76h2k6U8Nqfw0faQe/bM BNtoun6kOmI8Lwn+RlOhM2VG5DUQNy4ywA7swrA9vnSwXkI8GLMrPssv1ywZU7Of8CTW Xx0CFyL4GD3uvl+so4S4tq5miHij7dDFq1fPb2LlxCntXelpWvVvhirnSG+oXNl2icG+ MjW1/8ig2jn3ipaFyCdk4qtIRFfcfwYqVKdLvUo7UGd6lFp8r13sQK4RlLNTqNFKmtD8 ZoRQHceTmhtjuiZ07jbBDEl+d691haYvWMfniXan9k9NvIYBk1TkOswPxEP3ydkVIZlf UySg==
X-Gm-Message-State: ALQs6tClLixaAn3yotudocXs1MnWkQOpaiJuwMCtsIyMRrIa+1QdpHXs deQzdFDsiTqOLCcZlxL5PZfbdLT5CPr4zLnvpc1QxA==
X-Google-Smtp-Source: AIpwx4+UOe9r8s5JjoqbxyJ0M+BiGrkZGeLX0Dgkyzv6YXjYqJkkIDoCVbIeGoRVlYPlZtgjXCj8tsTYScDt7QXQqA8=
X-Received: by 10.129.81.151 with SMTP id f145mr1161393ywb.496.1523391572588;  Tue, 10 Apr 2018 13:19:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:98c5:0:0:0:0:0 with HTTP; Tue, 10 Apr 2018 13:19:31 -0700 (PDT)
In-Reply-To: 
References:   
From: Ryan Hamilton 
Date: Tue, 10 Apr 2018 13:19:31 -0700
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG 
Content-Type: multipart/alternative; boundary="001a1145696a8a66250569843dae"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 20:19:36 -0000

--001a1145696a8a66250569843dae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 10, 2018 at 9:37 AM, Praveen Balasubramanian <
pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

> With the shuffle scheme, if a middlebox wants to go out of its way to do
> analysis to break a PRNG and find the packet number it can. The scheme is
> not even requiring a secure random number. The goal is not to provide any
> security around PN, just prevent ossification by dumb middleboxes that
> assume the nonce is a sequence number and try to reorder. I don=E2=80=99t=
 see any
> harm if costly analysis can allow on path determination of packet numbers=
.
>

Are you concerned about "helpful" middlebox which are willing to expend the
resources to do costly analysis in order to "repair" packet reorder (and
consequently introduce HOL blocking)

--001a1145696a8a66250569843dae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Tue, Apr 1=
0, 2018 at 9:37 AM, Praveen Balasubramanian <pravb=3D40microsoft=
.com@dmarc.ietf.org> wrote:











With the shuffle scheme, if a middlebox wants to go =
out of its way to do analysis to break a PRNG and find the packet number it=
 can. The scheme is not even requiring a secure random number. The goal is =
not to provide any security around
 PN, just prevent ossification by dumb middleboxes that assume the nonce is=
 a sequence number and try to reorder. I don=E2=80=99t see any harm if cost=
ly analysis can allow on path determination of packet numbers.

Are you concerned about &qu=
ot;helpful" middlebox which are willing to expend the resources to do =
costly analysis in order to "repair" packet reorder (and conseque=
ntly introduce HOL blocking)



--001a1145696a8a66250569843dae--


From nobody Tue Apr 10 13:19:49 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF22312D7E4 for ; Tue, 10 Apr 2018 13:19:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523391576; bh=5HDvmiixsoQ8UuEblABKrM+ugpEszw3LgJQYvH1EkvY=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=oBpPaUJB0TQ4X8SH311FgCjYzmyFekWK/95y5Ozy6amJqxuWOBhqMWaiHVbrtuSYW ge0JYyrkMhATA/yJb5/eRleuIMcQnn25K8F566DNwJhivayIEJaSzoAlU+bSilK8Tp gcezreRr0BByAxJl1EFd+hp4CV8D9H9/wN6hx8ww=
X-Mailbox-Line: From rch@google.com  Tue Apr 10 13:19:36 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B74124217; Tue, 10 Apr 2018 13:19:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523391576; bh=A3uHd6d3vdRzKDMfZJc3JIR0NyyzrfC4JcFO+ZfvmHU=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=wLqYzJu8VDQuBgQbzOGWLF6NUthQL1HBMbMTNzPD5eM8uNZb5YNg3EOJcsZtZS+ui UOI+BONdi73PfXdt9+4IuqHEU7JXn76L3VtjnWLM9JDOyVwRfTRLji70NvsPceyBPe afshhoEvuVYeiohS41LJBVqBCIBC0RX7ekTPJYZk=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779731272E1 for ; Tue, 10 Apr 2018 13:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level: 
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 0jR99VrKzQHb for ; Tue, 10 Apr 2018 13:19:35 -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 F37A112895E for ; Tue, 10 Apr 2018 13:19:33 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id q12so4465728ywj.0 for ; Tue, 10 Apr 2018 13:19: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=A3uHd6d3vdRzKDMfZJc3JIR0NyyzrfC4JcFO+ZfvmHU=; b=TpXs9Fh26uPGyGNN+htrxKzi9ecGpwyNOQh8/f5JHSr35fqc795Ew+TS/rUxGqAVnF Q9E31Sz/9u9suvlKUp7LMGIWcgPy4xstj2ct/vuRewHZEwDa6RYuWoCyqJM86U7Dj6DZ e8uHBwO/u+0ga8U7h8xST99fyM53rU+jqzhvWxhT/WayoF8z1wvG8WgxweQi8P+oipvc PfIE7BDWBL8N6Z8k3uxzd2Fx6ht3RVAYg2gPgq2pyXcR2fxgqyLjskIeynmA2MUB2ys1 sD8PJjOWD+WBE2yCoxGA18II07+W9H+ZzWTTywLeAYGMGVOk9csTYXkpi8xD4IQvpUxO g3CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=A3uHd6d3vdRzKDMfZJc3JIR0NyyzrfC4JcFO+ZfvmHU=; b=KgMxfPGjR/8yKjcR+dqOlyGz4TwKT1UD51QHjKssH2ma6I3XicyzGIZ9Lv6IMNycq9 t5e+FTkzoBqExrpkJePXTnTQTEGzUaUGxheXcOjO9baVeReGntS06ZdtvJgOjDH0NFO4 crpJq0+1FNF7HFdXahyajICCU91blx4fQDgDImeMsES1V1rQAFaQIUt1VQBwgdkTeIP8 YoF5TjIq0w4TNvX9kYpfzA8B/vU/klb1wZDYAPIVwvMMy0V2oNQvWVgGBVpJvmR4BHVM FmrLgqkjc2b0LKRR6nbzHI7jqDFG1ZDvwzri7Si1Xu6L3fO5v8rgtOTTplVy3GFKk6D/ MuEA==
X-Gm-Message-State: ALQs6tDhz+49ocpu/aygi/c/eN6iKBIp8rFtMlijjWgt09hmosyqF6nW DR3SMtsNy4GBtafQQ6G9amj7wq0ICYL+ufU5twfhkV0O
X-Google-Smtp-Source: AIpwx4+UOe9r8s5JjoqbxyJ0M+BiGrkZGeLX0Dgkyzv6YXjYqJkkIDoCVbIeGoRVlYPlZtgjXCj8tsTYScDt7QXQqA8=
X-Received: by 10.129.81.151 with SMTP id f145mr1161393ywb.496.1523391572588;  Tue, 10 Apr 2018 13:19:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:98c5:0:0:0:0:0 with HTTP; Tue, 10 Apr 2018 13:19:31 -0700 (PDT)
In-Reply-To: 
References:   
From: Ryan Hamilton 
Date: Tue, 10 Apr 2018 13:19:31 -0700
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
Content-Type: multipart/alternative; boundary="001a1145696a8a66250569843dae"
To: Praveen Balasubramanian 
Cc: Victor Vasiliev 
Cc: IETF QUIC WG 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 20:19:37 -0000

--001a1145696a8a66250569843dae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 10, 2018 at 9:37 AM, Praveen Balasubramanian <
pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

> With the shuffle scheme, if a middlebox wants to go out of its way to do
> analysis to break a PRNG and find the packet number it can. The scheme is
> not even requiring a secure random number. The goal is not to provide any
> security around PN, just prevent ossification by dumb middleboxes that
> assume the nonce is a sequence number and try to reorder. I don=E2=80=99t=
 see any
> harm if costly analysis can allow on path determination of packet numbers=
..
>

Are you concerned about "helpful" middlebox which are willing to expend the
resources to do costly analysis in order to "repair" packet reorder (and
consequently introduce HOL blocking)

--001a1145696a8a66250569843dae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Tue, Apr 1=
0, 2018 at 9:37 AM, Praveen Balasubramanian <pravb=3D40microsoft=
..com@dmarc.ietf.org> wrote:











With the shuffle scheme, if a middlebox wants to go =
out of its way to do analysis to break a PRNG and find the packet number it=
 can. The scheme is not even requiring a secure random number. The goal is =
not to provide any security around
 PN, just prevent ossification by dumb middleboxes that assume the nonce is=
 a sequence number and try to reorder. I don=E2=80=99t see any harm if cost=
ly analysis can allow on path determination of packet numbers.

Are you concerned about &qu=
ot;helpful" middlebox which are willing to expend the resources to do =
costly analysis in order to "repair" packet reorder (and conseque=
ntly introduce HOL blocking)



--001a1145696a8a66250569843dae--


From nobody Tue Apr 10 15:36:32 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF2412D7F7 for ; Tue, 10 Apr 2018 15:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523399791; bh=UFGATFo3TwO0ad1x6csU6VvCC3MGL3fMX4yB7RHTBzg=; h=From:CC:Subject:Date:References:In-Reply-To:To; b=p69/3lKZCrJiaB06ipBmg+yrdQiz44/XpAimsk2NSvFq+/lP0t9LlZ42OAGpyLhkt evTGHseXBihG2GwqR7W10jMp531lquVpdD2QfQ2AVUMlX/JOxyvjgsJEAoGRG0TooJ FN2dUMQa9vAQD6ea5TiArC2U3AchTUCla48a8kug=
X-Mailbox-Line: From pravb@microsoft.com  Tue Apr 10 15:36:31 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6160212D7F5; Tue, 10 Apr 2018 15:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523399791; bh=UFGATFo3TwO0ad1x6csU6VvCC3MGL3fMX4yB7RHTBzg=; h=From:CC:Subject:Date:References:In-Reply-To:To; b=p69/3lKZCrJiaB06ipBmg+yrdQiz44/XpAimsk2NSvFq+/lP0t9LlZ42OAGpyLhkt evTGHseXBihG2GwqR7W10jMp531lquVpdD2QfQ2AVUMlX/JOxyvjgsJEAoGRG0TooJ FN2dUMQa9vAQD6ea5TiArC2U3AchTUCla48a8kug=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4090612421A for ; Tue, 10 Apr 2018 15:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 RW7qugvW30tw for ; Tue, 10 Apr 2018 15:36:28 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe41::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CB512D7F5 for ; Tue, 10 Apr 2018 15:36:28 -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=UFGATFo3TwO0ad1x6csU6VvCC3MGL3fMX4yB7RHTBzg=; b=jP4vKaDAB1KblXV1sQfowpRJqBtOZBCDyEXcTSFmgiy5HzRkff0xHzfQSqMuHQ2R75EdUQw16xw3Eqi3jZcTWUjhrJ6gbl7IDhBzcMUkloignc/uVaL65g+NY3BhRDqalXNmz6hwNhjIlrFCOoOyRwRw6MDR0dcW3LG40X/6g6w=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0629.namprd21.prod.outlook.com (10.175.115.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Tue, 10 Apr 2018 22:36:26 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Tue, 10 Apr 2018 22:36:26 +0000
From: Praveen Balasubramanian 
CC: Victor Vasiliev , IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQ
Date: Tue, 10 Apr 2018 22:36:25 +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:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0629; 7:mFnhJVD1h0+7Qd9OpRjKmYrZ0wOUjHZBk4qeGo3PKPF+hmZ3dfoqLrC79eTlDmT4rPEFLgnzuRQXh0UOejb+QMZluGsPm81YIhOv+NxJz0wHrl4dg4zqxi7gZBgqhhsu8LZyl28B154lZIkgr0O3kC6n3ACbNxqMJggkN+FQFKD5DLjYcIN+8FLs4yL1XfyfmMc1EIz2tiRv/CIBVlp9C3B33w9YDPhEpelo8qVMzewvUSv3Lbxn67wAF8r7/PoA; 20:L2b43bCLZEJoYd5GY80CX/OQtMh0TO0DY4hKEggEJeiep0d0qlvoSYw/f6IJlbnY3y4Npj4YGwr1JYKBKv8EEtK/Jvnm3bRlNjTHCaLWzknhJKLXUiUZeC1gH8Rs0frbSWaV30BpwhhTLJWLTX33tEpZlDbCT9QSrQht6DtmDXw=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(3008032)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0629; 
x-ms-traffictypediagnostic: CY4PR21MB0629:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(192374486261705)(211936372134217)(153496737603132)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0629; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0629; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(39860400002)(376002)(346002)(396003)(199004)(189003)(97736004)(86362001)(46003)(11346002)(446003)(68736007)(476003)(316002)(22452003)(54906003)(93886005)(19609705001)(186003)(86612001)(2900100001)(486006)(106356001)(105586002)(14454004)(4326008)(8990500004)(25786009)(10090500001)(5250100002)(33656002)(478600001)(10290500003)(53546011)(6506007)(59450400001)(229853002)(102836004)(7736002)(7696005)(76176011)(5660300001)(6436002)(8676002)(8936002)(54896002)(53936002)(81156014)(81166006)(74316002)(6246003)(55016002)(3660700001)(790700001)(6306002)(6116002)(3280700002)(9686003)(236005)(2906002)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0629; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: UtrAI11sVQ+sIegVYj6bAx8W6s8QgzJMAFeT7WL+QgAislbzhv7eQpKrik5hb71YjVO6rcQVCo44Bj2d0+TaP6VRJZXG7eYaTAMTkI6rMJoB7vx9QAEElHpGRtDSkE1ZS8vHpmzqEgUI0A5MMbcUjxMukh9NbhoMsAPYoYsIUXhWPlAYtRjNgUnuXzv9FhQdzJ//sU2AhEvGtdpuwoQsB9XchYJ4oZuICvxNF1DXRdLDq90wu10Sm1ZXuqCRlL0AjS8cd2mqiqQRN3hCO+W/FB/UaktU8gHm3tFT1KxX7uCW6g2gcq/3E4zHiYFXWlKY07420NIBQLbQMLh11/GO6rajgWdNSKO6JSpfFup+L4nzFDINCchbpuHPma3qds0Xn/ocxi7XC08iNnbiHJZ3o2NXykL2/zuT/lzuj8UMRkk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630BDFEB41698AFBE1F8105B6BE0CY4PR21MB0630namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 355e25f6-e47c-40e1-e831-08d59f337ec3
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 355e25f6-e47c-40e1-e831-08d59f337ec3
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 22:36:26.0616 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0629
To: Ryan Hamilton 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 22:36:32 -0000

--_000_CY4PR21MB0630BDFEB41698AFBE1F8105B6BE0CY4PR21MB0630namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Tm8gSSBhbSBub3QgY29uY2VybmVkLiBBbHNvIGl0IGlzIHNwZWN1bGF0aW9uIHRoYXQgYSBtaWRk
bGVib3ggY2FuIGFjdHVhbGx5IGRvIHRoaXMgd2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUgd2hlcmUg
ZWFjaCBpbXBsZW1lbnRhdGlvbiBpcyBmcmVlIHRvIHBpY2sgdGhlIFBSTkcsIHRoZSBzaHVmZmxl
IGFsZ29yaXRobSwgYW5kIGNoYW5nZSBpdCBvdmVyIHRpbWUuIEltcGxlbWVudGF0aW9ucyBjYW4g
YWxzbyBzZWVkIHRoZSBQUk5HIGZvciBlYWNoIGNvbm5lY3Rpb24uDQoNCk1pZGRsZWJveGVzIG5l
ZWQgdG8gb3BlcmF0ZSBhdCBsaW5lIHJhdGUgYW5kIGNhbm5vdCBkbyBhbnkgZXhwZW5zaXZlIG9w
ZXJhdGlvbnMgYW5kIGFueSBndWVzc2VkIHJlb3JkZXJpbmcgd2lsbCBtYWtlIHRoaW5ncyBldmVu
IHdvcnNlIHBlcmZvcm1hbmNlIHdpc2UuIEFuIG9ibm94aW91cyBtaWRkbGVib3ggY2FuIGFsd2F5
cyBkcm9wIGFsbCBRVUlDIHRyYWZmaWMgYW5kIGZvcmNlIGZhbGxiYWNrIHRvIFRDUC4gT25lIGNh
biBjb25zdHJ1Y3QgYmFkIG1pZGRsZWJveCBiZWhhdmlvciBvbiBhIHdpZGUgc3BlY3RydW0uIE9u
ZSBjYW4gYWxzbyBkZXNpZ24gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24gc29sdXRpb25zIHRoYXQg
bWFrZSBlbmRwb2ludHMgZG8gZWl0aGVyIHZlcnkgbGl0dGxlIHdvcmsgb3IgYSBsb3Qgb2Ygd29y
ay4gVGhlcmUgYXJlIHRyYWRlLW9mZnMuDQoNClRoZSBnb2FsIGhlcmUgd2FzIHRvIGV4cGxvcmUg
YSBsb3cgQ1BVIGNvc3QgdHJhbnNmb3JtIHRoYXQgY2FuIGRvIGJldHRlciBncmVhc2luZyBvZiB0
aGUgZmllbGQgd2l0aCBubyBtb25vdG9uaWMgaW5jcmVhc2UsIHNwZWNpZmljYWxseSB0byBwcmV2
ZW50IGR1bWIgbWlkZGxlYm94ZXMgZnJvbSB0cmVhdGluZyB0aGUgbm9uY2UgYXMgYSBzZXF1ZW5j
ZSBudW1iZXIuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBSeWFuIEhhbWlsdG9uDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxOCAx
OjIwIFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+
DQpDYzogVmljdG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBJRVRGIFFVSUMgV0cg
PHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92
aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uDQoNCk9uIFR1ZSwgQXByIDEwLCAyMDE4IGF0
IDk6MzcgQU0sIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC4uLmNv
bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86cHJhdmI9NDBtaWNyb3NvZnQuLi5jb21AZG1hcmMuaWV0
Zi5vcmc+PiB3cm90ZToNCldpdGggdGhlIHNodWZmbGUgc2NoZW1lLCBpZiBhIG1pZGRsZWJveCB3
YW50cyB0byBnbyBvdXQgb2YgaXRzIHdheSB0byBkbyBhbmFseXNpcyB0byBicmVhayBhIFBSTkcg
YW5kIGZpbmQgdGhlIHBhY2tldCBudW1iZXIgaXQgY2FuLiBUaGUgc2NoZW1lIGlzIG5vdCBldmVu
IHJlcXVpcmluZyBhIHNlY3VyZSByYW5kb20gbnVtYmVyLiBUaGUgZ29hbCBpcyBub3QgdG8gcHJv
dmlkZSBhbnkgc2VjdXJpdHkgYXJvdW5kIFBOLCBqdXN0IHByZXZlbnQgb3NzaWZpY2F0aW9uIGJ5
IGR1bWIgbWlkZGxlYm94ZXMgdGhhdCBhc3N1bWUgdGhlIG5vbmNlIGlzIGEgc2VxdWVuY2UgbnVt
YmVyIGFuZCB0cnkgdG8gcmVvcmRlci4gSSBkb27igJl0IHNlZSBhbnkgaGFybSBpZiBjb3N0bHkg
YW5hbHlzaXMgY2FuIGFsbG93IG9uIHBhdGggZGV0ZXJtaW5hdGlvbiBvZiBwYWNrZXQgbnVtYmVy
cy4NCg0KQXJlIHlvdSBjb25jZXJuZWQgYWJvdXQgImhlbHBmdWwiIG1pZGRsZWJveCB3aGljaCBh
cmUgd2lsbGluZyB0byBleHBlbmQgdGhlIHJlc291cmNlcyB0byBkbyBjb3N0bHkgYW5hbHlzaXMg
aW4gb3JkZXIgdG8gInJlcGFpciIgcGFja2V0IHJlb3JkZXIgKGFuZCBjb25zZXF1ZW50bHkgaW50
cm9kdWNlIEhPTCBibG9ja2luZykNCg0K

--_000_CY4PR21MB0630BDFEB41698AFBE1F8105B6BE0CY4PR21MB0630namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIjsNCglwYW5vc2Ut
MToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O
b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu
bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h
bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow
aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv
bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh
bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5
bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN
Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h
cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6
V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k
aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp
dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48
L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl
IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5ObyBJIGFtIG5vdCBjb25jZXJuZWQuIEFsc28gaXQgaXMgc3BlY3VsYXRpb24g
dGhhdCBhIG1pZGRsZWJveCBjYW4gYWN0dWFsbHkgZG8gdGhpcyB3aXRoIHRoZSBzaHVmZmxlIHNj
aGVtZSB3aGVyZSBlYWNoIGltcGxlbWVudGF0aW9uIGlzIGZyZWUgdG8gcGljayB0aGUgUFJORywg
dGhlIHNodWZmbGUgYWxnb3JpdGhtLCBhbmQgY2hhbmdlIGl0IG92ZXIgdGltZS4gSW1wbGVtZW50
YXRpb25zIGNhbiBhbHNvIHNlZWQNCiB0aGUgUFJORyBmb3IgZWFjaCBjb25uZWN0aW9uLiA8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlkZGxlYm94ZXMgbmVlZCB0byBvcGVyYXRlIGF0IGxpbmUg
cmF0ZSBhbmQgY2Fubm90IGRvIGFueSBleHBlbnNpdmUgb3BlcmF0aW9ucyBhbmQgYW55IGd1ZXNz
ZWQgcmVvcmRlcmluZyB3aWxsIG1ha2UgdGhpbmdzIGV2ZW4gd29yc2UgcGVyZm9ybWFuY2Ugd2lz
ZS4gQW4gb2Jub3hpb3VzIG1pZGRsZWJveCBjYW4gYWx3YXlzIGRyb3AgYWxsIFFVSUMgdHJhZmZp
YyBhbmQgZm9yY2UgZmFsbGJhY2sgdG8gVENQLg0KIE9uZSBjYW4gY29uc3RydWN0IGJhZCBtaWRk
bGVib3ggYmVoYXZpb3Igb24gYSB3aWRlIHNwZWN0cnVtLiBPbmUgY2FuIGFsc28gZGVzaWduIG9z
c2lmaWNhdGlvbiBwcmV2ZW50aW9uIHNvbHV0aW9ucyB0aGF0IG1ha2UgZW5kcG9pbnRzIGRvIGVp
dGhlciB2ZXJ5IGxpdHRsZSB3b3JrIG9yIGEgbG90IG9mIHdvcmsuIFRoZXJlIGFyZSB0cmFkZS1v
ZmZzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZ29hbCBoZXJlIHdhcyB0byBleHBsb3Jl
IGEgbG93IENQVSBjb3N0IHRyYW5zZm9ybSB0aGF0IGNhbiBkbyBiZXR0ZXIgZ3JlYXNpbmcgb2Yg
dGhlIGZpZWxkIHdpdGggbm8gbW9ub3RvbmljIGluY3JlYXNlLCBzcGVjaWZpY2FsbHkgdG8gcHJl
dmVudCBkdW1iIG1pZGRsZWJveGVzIGZyb20gdHJlYXRpbmcgdGhlIG5vbmNlIGFzIGEgc2VxdWVu
Y2UgbnVtYmVyLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFtt
YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5SeWFuIEhh
bWlsdG9uPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDEwLCAyMDE4IDE6MjAgUE08
YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3Nv
ZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gVmljdG9yIFZhc2lsaWV2ICZsdDt2YXNpbHZ2QGdv
b2dsZS5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJlOiBTaW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZp
Y2F0aW9uIHByZXZlbnRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+T24g
VHVlLCBBcHIgMTAsIDIwMTggYXQgOTozNyBBTSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0
OzxhIGhyZWY9Im1haWx0bzpwcmF2Yj00MG1pY3Jvc29mdC4uLmNvbUBkbWFyYy5pZXRmLm9yZyIg
dGFyZ2V0PSJfYmxhbmsiPnByYXZiPTQwbWljcm9zb2Z0Li4uY29tQGRtYXJjLmlldGYub3JnPC9h
PiZndDsgd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNo
ZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6
NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+V2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUsIGlmIGEgbWlkZGxlYm94IHdhbnRzIHRvIGdv
IG91dCBvZiBpdHMgd2F5IHRvIGRvIGFuYWx5c2lzIHRvIGJyZWFrIGEgUFJORyBhbmQgZmluZCB0
aGUgcGFja2V0IG51bWJlciBpdCBjYW4uIFRoZSBzY2hlbWUgaXMgbm90IGV2ZW4gcmVxdWlyaW5n
IGEgc2VjdXJlIHJhbmRvbQ0KIG51bWJlci4gVGhlIGdvYWwgaXMgbm90IHRvIHByb3ZpZGUgYW55
IHNlY3VyaXR5IGFyb3VuZCBQTiwganVzdCBwcmV2ZW50IG9zc2lmaWNhdGlvbiBieSBkdW1iIG1p
ZGRsZWJveGVzIHRoYXQgYXNzdW1lIHRoZSBub25jZSBpcyBhIHNlcXVlbmNlIG51bWJlciBhbmQg
dHJ5IHRvIHJlb3JkZXIuIEkgZG9u4oCZdCBzZWUgYW55IGhhcm0gaWYgY29zdGx5IGFuYWx5c2lz
IGNhbiBhbGxvdyBvbiBwYXRoIGRldGVybWluYXRpb24gb2YgcGFja2V0IG51bWJlcnMuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVi
dWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+QXJlIHlvdSBjb25jZXJuZWQgYWJvdXQgJnF1b3Q7
aGVscGZ1bCZxdW90OyBtaWRkbGVib3ggd2hpY2ggYXJlIHdpbGxpbmcgdG8gZXhwZW5kIHRoZSBy
ZXNvdXJjZXMgdG8gZG8gY29zdGx5IGFuYWx5c2lzIGluIG9yZGVyIHRvICZxdW90O3JlcGFpciZx
dW90OyBwYWNrZXQgcmVvcmRlciAoYW5kIGNvbnNlcXVlbnRseSBpbnRyb2R1Y2UgSE9MIGJsb2Nr
aW5nKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_CY4PR21MB0630BDFEB41698AFBE1F8105B6BE0CY4PR21MB0630namp_--


From nobody Tue Apr 10 15:36:45 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6871612D7F5 for ; Tue, 10 Apr 2018 15:36:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 c32TXZ1G33wl for ; Tue, 10 Apr 2018 15:36:29 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0097.outbound.protection.outlook.com [104.47.33.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC3112D7EF for ; Tue, 10 Apr 2018 15:36:28 -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=UFGATFo3TwO0ad1x6csU6VvCC3MGL3fMX4yB7RHTBzg=; b=jP4vKaDAB1KblXV1sQfowpRJqBtOZBCDyEXcTSFmgiy5HzRkff0xHzfQSqMuHQ2R75EdUQw16xw3Eqi3jZcTWUjhrJ6gbl7IDhBzcMUkloignc/uVaL65g+NY3BhRDqalXNmz6hwNhjIlrFCOoOyRwRw6MDR0dcW3LG40X/6g6w=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0629.namprd21.prod.outlook.com (10.175.115.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Tue, 10 Apr 2018 22:36:26 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Tue, 10 Apr 2018 22:36:26 +0000
From: Praveen Balasubramanian 
To: Ryan Hamilton 
CC: Victor Vasiliev , IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQ
Date: Tue, 10 Apr 2018 22:36:25 +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:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0629; 7:mFnhJVD1h0+7Qd9OpRjKmYrZ0wOUjHZBk4qeGo3PKPF+hmZ3dfoqLrC79eTlDmT4rPEFLgnzuRQXh0UOejb+QMZluGsPm81YIhOv+NxJz0wHrl4dg4zqxi7gZBgqhhsu8LZyl28B154lZIkgr0O3kC6n3ACbNxqMJggkN+FQFKD5DLjYcIN+8FLs4yL1XfyfmMc1EIz2tiRv/CIBVlp9C3B33w9YDPhEpelo8qVMzewvUSv3Lbxn67wAF8r7/PoA; 20:L2b43bCLZEJoYd5GY80CX/OQtMh0TO0DY4hKEggEJeiep0d0qlvoSYw/f6IJlbnY3y4Npj4YGwr1JYKBKv8EEtK/Jvnm3bRlNjTHCaLWzknhJKLXUiUZeC1gH8Rs0frbSWaV30BpwhhTLJWLTX33tEpZlDbCT9QSrQht6DtmDXw=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(3008032)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0629; 
x-ms-traffictypediagnostic: CY4PR21MB0629:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(192374486261705)(211936372134217)(153496737603132)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0629; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0629; 
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(39860400002)(376002)(346002)(396003)(199004)(189003)(97736004)(86362001)(46003)(11346002)(446003)(68736007)(476003)(316002)(22452003)(54906003)(93886005)(19609705001)(186003)(86612001)(2900100001)(486006)(106356001)(105586002)(14454004)(4326008)(8990500004)(25786009)(10090500001)(5250100002)(33656002)(478600001)(10290500003)(53546011)(6506007)(59450400001)(229853002)(102836004)(7736002)(7696005)(76176011)(5660300001)(6436002)(8676002)(8936002)(54896002)(53936002)(81156014)(81166006)(74316002)(6246003)(55016002)(3660700001)(790700001)(6306002)(6116002)(3280700002)(9686003)(236005)(2906002)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0629; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: UtrAI11sVQ+sIegVYj6bAx8W6s8QgzJMAFeT7WL+QgAislbzhv7eQpKrik5hb71YjVO6rcQVCo44Bj2d0+TaP6VRJZXG7eYaTAMTkI6rMJoB7vx9QAEElHpGRtDSkE1ZS8vHpmzqEgUI0A5MMbcUjxMukh9NbhoMsAPYoYsIUXhWPlAYtRjNgUnuXzv9FhQdzJ//sU2AhEvGtdpuwoQsB9XchYJ4oZuICvxNF1DXRdLDq90wu10Sm1ZXuqCRlL0AjS8cd2mqiqQRN3hCO+W/FB/UaktU8gHm3tFT1KxX7uCW6g2gcq/3E4zHiYFXWlKY07420NIBQLbQMLh11/GO6rajgWdNSKO6JSpfFup+L4nzFDINCchbpuHPma3qds0Xn/ocxi7XC08iNnbiHJZ3o2NXykL2/zuT/lzuj8UMRkk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630BDFEB41698AFBE1F8105B6BE0CY4PR21MB0630namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 355e25f6-e47c-40e1-e831-08d59f337ec3
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 355e25f6-e47c-40e1-e831-08d59f337ec3
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 22:36:26.0616 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0629
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Apr 2018 22:36:32 -0000

--_000_CY4PR21MB0630BDFEB41698AFBE1F8105B6BE0CY4PR21MB0630namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Tm8gSSBhbSBub3QgY29uY2VybmVkLiBBbHNvIGl0IGlzIHNwZWN1bGF0aW9uIHRoYXQgYSBtaWRk
bGVib3ggY2FuIGFjdHVhbGx5IGRvIHRoaXMgd2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUgd2hlcmUg
ZWFjaCBpbXBsZW1lbnRhdGlvbiBpcyBmcmVlIHRvIHBpY2sgdGhlIFBSTkcsIHRoZSBzaHVmZmxl
IGFsZ29yaXRobSwgYW5kIGNoYW5nZSBpdCBvdmVyIHRpbWUuIEltcGxlbWVudGF0aW9ucyBjYW4g
YWxzbyBzZWVkIHRoZSBQUk5HIGZvciBlYWNoIGNvbm5lY3Rpb24uDQoNCk1pZGRsZWJveGVzIG5l
ZWQgdG8gb3BlcmF0ZSBhdCBsaW5lIHJhdGUgYW5kIGNhbm5vdCBkbyBhbnkgZXhwZW5zaXZlIG9w
ZXJhdGlvbnMgYW5kIGFueSBndWVzc2VkIHJlb3JkZXJpbmcgd2lsbCBtYWtlIHRoaW5ncyBldmVu
IHdvcnNlIHBlcmZvcm1hbmNlIHdpc2UuIEFuIG9ibm94aW91cyBtaWRkbGVib3ggY2FuIGFsd2F5
cyBkcm9wIGFsbCBRVUlDIHRyYWZmaWMgYW5kIGZvcmNlIGZhbGxiYWNrIHRvIFRDUC4gT25lIGNh
biBjb25zdHJ1Y3QgYmFkIG1pZGRsZWJveCBiZWhhdmlvciBvbiBhIHdpZGUgc3BlY3RydW0uIE9u
ZSBjYW4gYWxzbyBkZXNpZ24gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24gc29sdXRpb25zIHRoYXQg
bWFrZSBlbmRwb2ludHMgZG8gZWl0aGVyIHZlcnkgbGl0dGxlIHdvcmsgb3IgYSBsb3Qgb2Ygd29y
ay4gVGhlcmUgYXJlIHRyYWRlLW9mZnMuDQoNClRoZSBnb2FsIGhlcmUgd2FzIHRvIGV4cGxvcmUg
YSBsb3cgQ1BVIGNvc3QgdHJhbnNmb3JtIHRoYXQgY2FuIGRvIGJldHRlciBncmVhc2luZyBvZiB0
aGUgZmllbGQgd2l0aCBubyBtb25vdG9uaWMgaW5jcmVhc2UsIHNwZWNpZmljYWxseSB0byBwcmV2
ZW50IGR1bWIgbWlkZGxlYm94ZXMgZnJvbSB0cmVhdGluZyB0aGUgbm9uY2UgYXMgYSBzZXF1ZW5j
ZSBudW1iZXIuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBSeWFuIEhhbWlsdG9uDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxOCAx
OjIwIFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+
DQpDYzogVmljdG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBJRVRGIFFVSUMgV0cg
PHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92
aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uDQoNCk9uIFR1ZSwgQXByIDEwLCAyMDE4IGF0
IDk6MzcgQU0sIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC4uLmNv
bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86cHJhdmI9NDBtaWNyb3NvZnQuLi5jb21AZG1hcmMuaWV0
Zi5vcmc+PiB3cm90ZToNCldpdGggdGhlIHNodWZmbGUgc2NoZW1lLCBpZiBhIG1pZGRsZWJveCB3
YW50cyB0byBnbyBvdXQgb2YgaXRzIHdheSB0byBkbyBhbmFseXNpcyB0byBicmVhayBhIFBSTkcg
YW5kIGZpbmQgdGhlIHBhY2tldCBudW1iZXIgaXQgY2FuLiBUaGUgc2NoZW1lIGlzIG5vdCBldmVu
IHJlcXVpcmluZyBhIHNlY3VyZSByYW5kb20gbnVtYmVyLiBUaGUgZ29hbCBpcyBub3QgdG8gcHJv
dmlkZSBhbnkgc2VjdXJpdHkgYXJvdW5kIFBOLCBqdXN0IHByZXZlbnQgb3NzaWZpY2F0aW9uIGJ5
IGR1bWIgbWlkZGxlYm94ZXMgdGhhdCBhc3N1bWUgdGhlIG5vbmNlIGlzIGEgc2VxdWVuY2UgbnVt
YmVyIGFuZCB0cnkgdG8gcmVvcmRlci4gSSBkb27igJl0IHNlZSBhbnkgaGFybSBpZiBjb3N0bHkg
YW5hbHlzaXMgY2FuIGFsbG93IG9uIHBhdGggZGV0ZXJtaW5hdGlvbiBvZiBwYWNrZXQgbnVtYmVy
cy4NCg0KQXJlIHlvdSBjb25jZXJuZWQgYWJvdXQgImhlbHBmdWwiIG1pZGRsZWJveCB3aGljaCBh
cmUgd2lsbGluZyB0byBleHBlbmQgdGhlIHJlc291cmNlcyB0byBkbyBjb3N0bHkgYW5hbHlzaXMg
aW4gb3JkZXIgdG8gInJlcGFpciIgcGFja2V0IHJlb3JkZXIgKGFuZCBjb25zZXF1ZW50bHkgaW50
cm9kdWNlIEhPTCBibG9ja2luZykNCg0K

--_000_CY4PR21MB0630BDFEB41698AFBE1F8105B6BE0CY4PR21MB0630namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIjsNCglwYW5vc2Ut
MToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O
b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu
bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h
bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow
aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv
bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh
bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5
bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN
Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h
cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6
V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k
aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp
dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48
L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl
IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5ObyBJIGFtIG5vdCBjb25jZXJuZWQuIEFsc28gaXQgaXMgc3BlY3VsYXRpb24g
dGhhdCBhIG1pZGRsZWJveCBjYW4gYWN0dWFsbHkgZG8gdGhpcyB3aXRoIHRoZSBzaHVmZmxlIHNj
aGVtZSB3aGVyZSBlYWNoIGltcGxlbWVudGF0aW9uIGlzIGZyZWUgdG8gcGljayB0aGUgUFJORywg
dGhlIHNodWZmbGUgYWxnb3JpdGhtLCBhbmQgY2hhbmdlIGl0IG92ZXIgdGltZS4gSW1wbGVtZW50
YXRpb25zIGNhbiBhbHNvIHNlZWQNCiB0aGUgUFJORyBmb3IgZWFjaCBjb25uZWN0aW9uLiA8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlkZGxlYm94ZXMgbmVlZCB0byBvcGVyYXRlIGF0IGxpbmUg
cmF0ZSBhbmQgY2Fubm90IGRvIGFueSBleHBlbnNpdmUgb3BlcmF0aW9ucyBhbmQgYW55IGd1ZXNz
ZWQgcmVvcmRlcmluZyB3aWxsIG1ha2UgdGhpbmdzIGV2ZW4gd29yc2UgcGVyZm9ybWFuY2Ugd2lz
ZS4gQW4gb2Jub3hpb3VzIG1pZGRsZWJveCBjYW4gYWx3YXlzIGRyb3AgYWxsIFFVSUMgdHJhZmZp
YyBhbmQgZm9yY2UgZmFsbGJhY2sgdG8gVENQLg0KIE9uZSBjYW4gY29uc3RydWN0IGJhZCBtaWRk
bGVib3ggYmVoYXZpb3Igb24gYSB3aWRlIHNwZWN0cnVtLiBPbmUgY2FuIGFsc28gZGVzaWduIG9z
c2lmaWNhdGlvbiBwcmV2ZW50aW9uIHNvbHV0aW9ucyB0aGF0IG1ha2UgZW5kcG9pbnRzIGRvIGVp
dGhlciB2ZXJ5IGxpdHRsZSB3b3JrIG9yIGEgbG90IG9mIHdvcmsuIFRoZXJlIGFyZSB0cmFkZS1v
ZmZzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZ29hbCBoZXJlIHdhcyB0byBleHBsb3Jl
IGEgbG93IENQVSBjb3N0IHRyYW5zZm9ybSB0aGF0IGNhbiBkbyBiZXR0ZXIgZ3JlYXNpbmcgb2Yg
dGhlIGZpZWxkIHdpdGggbm8gbW9ub3RvbmljIGluY3JlYXNlLCBzcGVjaWZpY2FsbHkgdG8gcHJl
dmVudCBkdW1iIG1pZGRsZWJveGVzIGZyb20gdHJlYXRpbmcgdGhlIG5vbmNlIGFzIGEgc2VxdWVu
Y2UgbnVtYmVyLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFtt
YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5SeWFuIEhh
bWlsdG9uPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDEwLCAyMDE4IDE6MjAgUE08
YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3Nv
ZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gVmljdG9yIFZhc2lsaWV2ICZsdDt2YXNpbHZ2QGdv
b2dsZS5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJlOiBTaW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZp
Y2F0aW9uIHByZXZlbnRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+T24g
VHVlLCBBcHIgMTAsIDIwMTggYXQgOTozNyBBTSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0
OzxhIGhyZWY9Im1haWx0bzpwcmF2Yj00MG1pY3Jvc29mdC4uLmNvbUBkbWFyYy5pZXRmLm9yZyIg
dGFyZ2V0PSJfYmxhbmsiPnByYXZiPTQwbWljcm9zb2Z0Li4uY29tQGRtYXJjLmlldGYub3JnPC9h
PiZndDsgd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNo
ZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6
NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+V2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUsIGlmIGEgbWlkZGxlYm94IHdhbnRzIHRvIGdv
IG91dCBvZiBpdHMgd2F5IHRvIGRvIGFuYWx5c2lzIHRvIGJyZWFrIGEgUFJORyBhbmQgZmluZCB0
aGUgcGFja2V0IG51bWJlciBpdCBjYW4uIFRoZSBzY2hlbWUgaXMgbm90IGV2ZW4gcmVxdWlyaW5n
IGEgc2VjdXJlIHJhbmRvbQ0KIG51bWJlci4gVGhlIGdvYWwgaXMgbm90IHRvIHByb3ZpZGUgYW55
IHNlY3VyaXR5IGFyb3VuZCBQTiwganVzdCBwcmV2ZW50IG9zc2lmaWNhdGlvbiBieSBkdW1iIG1p
ZGRsZWJveGVzIHRoYXQgYXNzdW1lIHRoZSBub25jZSBpcyBhIHNlcXVlbmNlIG51bWJlciBhbmQg
dHJ5IHRvIHJlb3JkZXIuIEkgZG9u4oCZdCBzZWUgYW55IGhhcm0gaWYgY29zdGx5IGFuYWx5c2lz
IGNhbiBhbGxvdyBvbiBwYXRoIGRldGVybWluYXRpb24gb2YgcGFja2V0IG51bWJlcnMuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVi
dWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+QXJlIHlvdSBjb25jZXJuZWQgYWJvdXQgJnF1b3Q7
aGVscGZ1bCZxdW90OyBtaWRkbGVib3ggd2hpY2ggYXJlIHdpbGxpbmcgdG8gZXhwZW5kIHRoZSBy
ZXNvdXJjZXMgdG8gZG8gY29zdGx5IGFuYWx5c2lzIGluIG9yZGVyIHRvICZxdW90O3JlcGFpciZx
dW90OyBwYWNrZXQgcmVvcmRlciAoYW5kIGNvbnNlcXVlbnRseSBpbnRyb2R1Y2UgSE9MIGJsb2Nr
aW5nKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_CY4PR21MB0630BDFEB41698AFBE1F8105B6BE0CY4PR21MB0630namp_--


From nobody Tue Apr 10 17:02:50 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0F012D944 for ; Tue, 10 Apr 2018 17:02:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523404968; bh=ANkyi2qrDYmsGJNd6VgO66D1d1XbKVo9/jK8gk0+5Ys=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=SJC5B4xVrvel9sEY/H8pfu/4ntQTbBmiN7REU26k5wRhdQvQU8xMGBpmeEGyWMgKe aUz6oBQrJFea+16u6jhum/cIDlqfgbGhcwD93gQ0/xGU+mL6Rkepobs5vvFPGasBuW 0AT7Y4qdr+BR4HIMOv6WqXUZ7zjEUQYvvrMULFHA=
X-Mailbox-Line: From mbishop@evequefou.be  Tue Apr 10 17:02:48 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 745B812D94E; Tue, 10 Apr 2018 17:02:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523404968; bh=ANkyi2qrDYmsGJNd6VgO66D1d1XbKVo9/jK8gk0+5Ys=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=SJC5B4xVrvel9sEY/H8pfu/4ntQTbBmiN7REU26k5wRhdQvQU8xMGBpmeEGyWMgKe aUz6oBQrJFea+16u6jhum/cIDlqfgbGhcwD93gQ0/xGU+mL6Rkepobs5vvFPGasBuW 0AT7Y4qdr+BR4HIMOv6WqXUZ7zjEUQYvvrMULFHA=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B1012D944 for ; Tue, 10 Apr 2018 17:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=evequefou.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YMDKspEZaHr for ; Tue, 10 Apr 2018 17:02:46 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on070d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe41::70d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CAA412D94E for ; Tue, 10 Apr 2018 17:02:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ANkyi2qrDYmsGJNd6VgO66D1d1XbKVo9/jK8gk0+5Ys=; b=dcGvBg/YAQx8Uz1KlaPKFFHCPyyhEQcx2CJ3GpsuyKpv1urvuc6+JwPvzuYxiyYzLxx7KN1kTtQUpzv6tBhh872me7Jocaph5V5bnsAvf2y2IoOpoHIgQaq+rX6ki3ZG3ZWJaZ95o2JtSUf9lCFzNja5aIArvmAmCYUmioAEmDc=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1677.namprd08.prod.outlook.com (10.162.133.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Wed, 11 Apr 2018 00:02:41 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0653.015; Wed, 11 Apr 2018 00:02:41 +0000
From: Mike Bishop 
CC: Victor Vasiliev , IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAbB0nA=
Date: Wed, 11 Apr 2018 00:02:41 +0000
Message-ID: 
References:     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; 
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1677; 7:UDv1jzpqiAQNBLNCbMrBgDrPadofCYaq98m1sTPXt5jcbsBsL3Jy+OO0UCfyMKmtlbQT1C5GdVLLXBp92bsYgbvZxdo/JV6kDiDxl0h4QJ+SICs9Txu50w8i4HhJIEYQvUYTWHrX1fKi1hiIeAzNcy+QpMdti5UYnTV3o5ZPjJkXXNVNm+q/wY2+RbHon7fEKac5p+nOk1373UiTAO9KBzH0q3/Gt5dv02LkjXF/v10gcEqOzOh3UbQ7qMzWOPBr
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1677; 
x-ms-traffictypediagnostic: SN1PR08MB1677:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(192374486261705)(211936372134217)(153496737603132)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231221)(944501327)(52105095)(93006095)(93001095)(6041310)(20161123562045)(20161123560045)(20161123564045)(2016111802025)(20161123558120)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1677; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1677; 
x-forefront-prvs: 0639027A9E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39380400002)(39830400003)(396003)(346002)(189003)(199004)(229853002)(45080400002)(76176011)(97736004)(7696005)(105586002)(99286004)(55016002)(5250100002)(790700001)(8676002)(86362001)(9686003)(236005)(14454004)(6436002)(53936002)(19609705001)(478600001)(54896002)(6306002)(66066001)(106356001)(74482002)(11346002)(5660300001)(8936002)(81166006)(81156014)(2906002)(74316002)(3660700001)(7736002)(4326008)(33656002)(3280700002)(446003)(3846002)(102836004)(68736007)(486006)(476003)(53546011)(93886005)(6116002)(54906003)(6506007)(110136005)(59450400001)(316002)(26005)(186003)(2900100001)(25786009)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1677; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: OGwAu+A0r2PkddlvsxODSTWSlLemK6Ec3eXtggi2v0ReB70Kq+9Yc9hXZ9jAKLeFiybizXg5gZJEXjz47xdur2zKTiGAQNRAlNS28hLlORUZ2dMljIa5n8oq+8HrFFuxcbGQ32Ye4Lf6TtQdrY3MkKM8V+Osg64HTZq5/u3x6Pjm65/pIw/gV2qRtHWWqYDWeOsjhlCH/l/0/skY0VSdYAAi+R6h+kjktGyAq0VqMSwUtm+p/wAjQllx2afqx+fswMAokyFkzUpYERYHrS8oxiJ5/XhVeTgaeoldgckkRRYE0QZlNWc1eEEhNTZhU9/N6atPQbIveScuqwvFwJqZV8cPUNQh4/qrNgDypIQCRA1F0Ai8EVH8AiYvTr4PPVrKwkkMJTN2iuayinOgpH9vGR4pI2igXpkejXkkpdNDbyE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR08MB1854F4E5FC3A8EE2E00767EBDABD0SN1PR08MB1854namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: a4122bbd-d101-4ed8-27fd-08d59f3f8b83
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: a4122bbd-d101-4ed8-27fd-08d59f3f8b83
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 00:02:41.3771 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1677
To: Praveen Balasubramanian 
To: Ryan Hamilton 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 00:02:49 -0000

--_000_SN1PR08MB1854F4E5FC3A8EE2E00767EBDABD0SN1PR08MB1854namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2hpbGUg4oCcaGVscGZ1bOKAnSBtaWRkbGVib3hlcyBhcmUgb25lIHRoaW5nIHdlIHdhbnQgdG8g
YXZvaWQsIGFuZCBhIHNodWZmbGUgbWlnaHQgcmVkdWNlIHRoZWlyIGluY2VudGl2ZXMsIHdlIGFs
c28gd2FudCB0byBwcmVzZXJ2ZSBvdXIgb3B0aW9ucyBmb3IgYSBmdXR1cmUgdmVyc2lvbiBpbiB3
aGljaCBRVUlDIGlzIG11bHRpcGF0aC4gIFRoYXQgbWVhbnMgZGlmZmVyZW50IHBhY2tldHMgd2ls
bCB0YWtlIGRpZmZlcmVudCBwYXRocy4NCg0KVG8gbWUsIHRoZXJlIGFyZSB0d28gb3B0aW9ucyB0
aGF0IHdvdWxkIGdldCB1cyBpbiB0aGF0IHNwYWNlOg0KDQogICogICBQZXItcGF0aCBwYWNrZXQg
bnVtYmVyIHNwYWNlcyBwbHVzIGEgc2h1ZmZsZS1zdHlsZSBvcGVyYXRpb24gZm9yIHRoZSBudW1i
ZXJzIG9uIGVhY2ggcGF0aA0KICAqICAgRW5jcnlwdGlvbiBvZiB0aGUgcGFja2V0IG51bWJlcnMN
Cg0KSeKAmW0gY29uY2VybmVkIHRoYXQgdGhlIGZpcnN0IG9wdGlvbiBtaWdodCBzdGlsbCBsZWF2
ZSBlbm91Z2ggb2YgYSBob2xlIGZvciBvc3NpZmljYXRpb24gdG8gZGV2ZWxvcC4gIFlvdXIgb3du
IGNvbW1lbnQgb24gdGhpcyB0aHJlYWQgdGhhdCDigJxsb3NzIGRldGVjdGlvbiBpcyBhY3R1YWxs
eSBzdHJhaWdodGZvcndhcmTigJ0gYnkgbG9va2luZyBmb3IgbWlzc2luZyBwYWNrZXQgbnVtYmVy
cyBpcyBhbiBleGNlbGxlbnQgZXhhbXBsZSBvZiB0aGUgb3NzaWZ5aW5nIGFzc3VtcHRpb25zIHdl
4oCZcmUgdHJ5aW5nIHRvIG1ha2UgaXQgZGlmZmljdWx0L2ltcG9zc2libGUgZm9yIG1pZGRsZWJv
eGVzIHRvIGdyb3cuICBUaGF04oCZcyB0cnVlIG9ubHkgaWYgdGhlcmXigJlzIGEgc2luZ2xlIHBh
dGggb3IgaWYgZXZlcnkgcGF0aCBoYXMgaXRzIG93biBwYWNrZXQgbnVtYmVyIHNwYWNlLg0KDQpG
cm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUHJh
dmVlbiBCYWxhc3VicmFtYW5pYW4NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDEwLCAyMDE4IDM6MzYg
UE0NClRvOiBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xlLmNvbT4NCkNjOiBWaWN0b3IgVmFzaWxp
ZXYgPHZhc2lsdnZAZ29vZ2xlLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1
YmplY3Q6IFJFOiBTaW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9u
IHByZXZlbnRpb24NCg0KTm8gSSBhbSBub3QgY29uY2VybmVkLiBBbHNvIGl0IGlzIHNwZWN1bGF0
aW9uIHRoYXQgYSBtaWRkbGVib3ggY2FuIGFjdHVhbGx5IGRvIHRoaXMgd2l0aCB0aGUgc2h1ZmZs
ZSBzY2hlbWUgd2hlcmUgZWFjaCBpbXBsZW1lbnRhdGlvbiBpcyBmcmVlIHRvIHBpY2sgdGhlIFBS
TkcsIHRoZSBzaHVmZmxlIGFsZ29yaXRobSwgYW5kIGNoYW5nZSBpdCBvdmVyIHRpbWUuIEltcGxl
bWVudGF0aW9ucyBjYW4gYWxzbyBzZWVkIHRoZSBQUk5HIGZvciBlYWNoIGNvbm5lY3Rpb24uDQoN
Ck1pZGRsZWJveGVzIG5lZWQgdG8gb3BlcmF0ZSBhdCBsaW5lIHJhdGUgYW5kIGNhbm5vdCBkbyBh
bnkgZXhwZW5zaXZlIG9wZXJhdGlvbnMgYW5kIGFueSBndWVzc2VkIHJlb3JkZXJpbmcgd2lsbCBt
YWtlIHRoaW5ncyBldmVuIHdvcnNlIHBlcmZvcm1hbmNlIHdpc2UuIEFuIG9ibm94aW91cyBtaWRk
bGVib3ggY2FuIGFsd2F5cyBkcm9wIGFsbCBRVUlDIHRyYWZmaWMgYW5kIGZvcmNlIGZhbGxiYWNr
IHRvIFRDUC4gT25lIGNhbiBjb25zdHJ1Y3QgYmFkIG1pZGRsZWJveCBiZWhhdmlvciBvbiBhIHdp
ZGUgc3BlY3RydW0uIE9uZSBjYW4gYWxzbyBkZXNpZ24gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24g
c29sdXRpb25zIHRoYXQgbWFrZSBlbmRwb2ludHMgZG8gZWl0aGVyIHZlcnkgbGl0dGxlIHdvcmsg
b3IgYSBsb3Qgb2Ygd29yay4gVGhlcmUgYXJlIHRyYWRlLW9mZnMuDQoNClRoZSBnb2FsIGhlcmUg
d2FzIHRvIGV4cGxvcmUgYSBsb3cgQ1BVIGNvc3QgdHJhbnNmb3JtIHRoYXQgY2FuIGRvIGJldHRl
ciBncmVhc2luZyBvZiB0aGUgZmllbGQgd2l0aCBubyBtb25vdG9uaWMgaW5jcmVhc2UsIHNwZWNp
ZmljYWxseSB0byBwcmV2ZW50IGR1bWIgbWlkZGxlYm94ZXMgZnJvbSB0cmVhdGluZyB0aGUgbm9u
Y2UgYXMgYSBzZXF1ZW5jZSBudW1iZXIuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSeWFuIEhhbWlsdG9uDQpTZW50OiBUdWVzZGF5LCBB
cHJpbCAxMCwgMjAxOCAxOjIwIFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZi
QG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFZpY3RvciBW
YXNpbGlldiA8dmFzaWx2dkBnb29nbGUuY29tPG1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20+Pjsg
SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1Ympl
Y3Q6IFJlOiBTaW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHBy
ZXZlbnRpb24NCg0KT24gVHVlLCBBcHIgMTAsIDIwMTggYXQgOTozNyBBTSwgUHJhdmVlbiBCYWxh
c3VicmFtYW5pYW4gPHByYXZiPTQwbWljcm9zb2Z0Li4uY29tQGRtYXJjLmlldGYub3JnPG1haWx0
bzpwcmF2Yj00MG1pY3Jvc29mdC4uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KV2l0aCB0
aGUgc2h1ZmZsZSBzY2hlbWUsIGlmIGEgbWlkZGxlYm94IHdhbnRzIHRvIGdvIG91dCBvZiBpdHMg
d2F5IHRvIGRvIGFuYWx5c2lzIHRvIGJyZWFrIGEgUFJORyBhbmQgZmluZCB0aGUgcGFja2V0IG51
bWJlciBpdCBjYW4uIFRoZSBzY2hlbWUgaXMgbm90IGV2ZW4gcmVxdWlyaW5nIGEgc2VjdXJlIHJh
bmRvbSBudW1iZXIuIFRoZSBnb2FsIGlzIG5vdCB0byBwcm92aWRlIGFueSBzZWN1cml0eSBhcm91
bmQgUE4sIGp1c3QgcHJldmVudCBvc3NpZmljYXRpb24gYnkgZHVtYiBtaWRkbGVib3hlcyB0aGF0
IGFzc3VtZSB0aGUgbm9uY2UgaXMgYSBzZXF1ZW5jZSBudW1iZXIgYW5kIHRyeSB0byByZW9yZGVy
LiBJIGRvbuKAmXQgc2VlIGFueSBoYXJtIGlmIGNvc3RseSBhbmFseXNpcyBjYW4gYWxsb3cgb24g
cGF0aCBkZXRlcm1pbmF0aW9uIG9mIHBhY2tldCBudW1iZXJzLg0KDQpBcmUgeW91IGNvbmNlcm5l
ZCBhYm91dCAiaGVscGZ1bCIgbWlkZGxlYm94IHdoaWNoIGFyZSB3aWxsaW5nIHRvIGV4cGVuZCB0
aGUgcmVzb3VyY2VzIHRvIGRvIGNvc3RseSBhbmFseXNpcyBpbiBvcmRlciB0byAicmVwYWlyIiBw
YWNrZXQgcmVvcmRlciAoYW5kIGNvbnNlcXVlbnRseSBpbnRyb2R1Y2UgSE9MIGJsb2NraW5nKQ0K
DQo=

--_000_SN1PR08MB1854F4E5FC3A8EE2E00767EBDABD0SN1PR08MB1854namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQg
TVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp
b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp
bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu
aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp
b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYu
TXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDow
aW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVm
dDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y
bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t
YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3
aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N
Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6
ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h
cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6
V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s
aXN0LWlkOjE3NTAxNTE5MzU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt
cGxhdGUtaWRzOjExMzUyMzgwMTAgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg
Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6
bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K
QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww
OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz
O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p
bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv
bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv
bTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw
MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv
Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu
Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl
Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIOKAnGhlbHBmdWzigJ0gbWlkZGxl
Ym94ZXMgYXJlIG9uZSB0aGluZyB3ZSB3YW50IHRvIGF2b2lkLCBhbmQgYSBzaHVmZmxlIG1pZ2h0
IHJlZHVjZSB0aGVpciBpbmNlbnRpdmVzLCB3ZSBhbHNvIHdhbnQgdG8gcHJlc2VydmUgb3VyIG9w
dGlvbnMgZm9yIGEgZnV0dXJlIHZlcnNpb24gaW4gd2hpY2ggUVVJQyBpcyBtdWx0aXBhdGguJm5i
c3A7IFRoYXQgbWVhbnMgZGlmZmVyZW50IHBhY2tldHMgd2lsbCB0YWtlIGRpZmZlcmVudA0KIHBh
dGhzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBtZSwgdGhlcmUgYXJlIHR3byBvcHRpb25z
IHRoYXQgd291bGQgZ2V0IHVzIGluIHRoYXQgc3BhY2U6PG86cD48L286cD48L3A+DQo8dWwgc3R5
bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn
cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+UGVy
LXBhdGggcGFja2V0IG51bWJlciBzcGFjZXMNCjxiPnBsdXM8L2I+IGEgc2h1ZmZsZS1zdHlsZSBv
cGVyYXRpb24gZm9yIHRoZSBudW1iZXJzIG9uIGVhY2ggcGF0aDxvOnA+PC9vOnA+PC9saT48bGkg
Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6
bDAgbGV2ZWwxIGxmbzEiPkVuY3J5cHRpb24gb2YgdGhlIHBhY2tldCBudW1iZXJzPG86cD48L286
cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIGNvbmNlcm5lZCB0aGF0IHRoZSBmaXJzdCBvcHRp
b24gbWlnaHQgc3RpbGwgbGVhdmUgZW5vdWdoIG9mIGEgaG9sZSBmb3Igb3NzaWZpY2F0aW9uIHRv
IGRldmVsb3AuJm5ic3A7IFlvdXIgb3duIGNvbW1lbnQgb24gdGhpcyB0aHJlYWQgdGhhdCDigJxs
b3NzIGRldGVjdGlvbiBpcyBhY3R1YWxseSBzdHJhaWdodGZvcndhcmTigJ0gYnkgbG9va2luZyBm
b3IgbWlzc2luZyBwYWNrZXQgbnVtYmVycyBpcyBhbiBleGNlbGxlbnQNCiBleGFtcGxlIG9mIHRo
ZSBvc3NpZnlpbmcgYXNzdW1wdGlvbnMgd2XigJlyZSB0cnlpbmcgdG8gbWFrZSBpdCBkaWZmaWN1
bHQvaW1wb3NzaWJsZSBmb3IgbWlkZGxlYm94ZXMgdG8gZ3Jvdy4mbmJzcDsgVGhhdOKAmXMgdHJ1
ZSBvbmx5IGlmIHRoZXJl4oCZcyBhIHNpbmdsZSBwYXRoIG9yIGlmIGV2ZXJ5IHBhdGggaGFzIGl0
cyBvd24gcGFja2V0IG51bWJlciBzcGFjZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVp
Yy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5QcmF2ZWVuIEJhbGFzdWJy
YW1hbmlhbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxOCAzOjM2IFBN
PGJyPg0KPGI+VG86PC9iPiBSeWFuIEhhbWlsdG9uICZsdDtyY2hAZ29vZ2xlLmNvbSZndDs8YnI+
DQo8Yj5DYzo8L2I+IFZpY3RvciBWYXNpbGlldiAmbHQ7dmFzaWx2dkBnb29nbGUuY29tJmd0Ozsg
SUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS
RTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50
aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBJIGFtIG5vdCBj
b25jZXJuZWQuIEFsc28gaXQgaXMgc3BlY3VsYXRpb24gdGhhdCBhIG1pZGRsZWJveCBjYW4gYWN0
dWFsbHkgZG8gdGhpcyB3aXRoIHRoZSBzaHVmZmxlIHNjaGVtZSB3aGVyZSBlYWNoIGltcGxlbWVu
dGF0aW9uIGlzIGZyZWUgdG8gcGljayB0aGUgUFJORywgdGhlIHNodWZmbGUgYWxnb3JpdGhtLCBh
bmQgY2hhbmdlIGl0IG92ZXIgdGltZS4gSW1wbGVtZW50YXRpb25zIGNhbiBhbHNvIHNlZWQNCiB0
aGUgUFJORyBmb3IgZWFjaCBjb25uZWN0aW9uLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlk
ZGxlYm94ZXMgbmVlZCB0byBvcGVyYXRlIGF0IGxpbmUgcmF0ZSBhbmQgY2Fubm90IGRvIGFueSBl
eHBlbnNpdmUgb3BlcmF0aW9ucyBhbmQgYW55IGd1ZXNzZWQgcmVvcmRlcmluZyB3aWxsIG1ha2Ug
dGhpbmdzIGV2ZW4gd29yc2UgcGVyZm9ybWFuY2Ugd2lzZS4gQW4gb2Jub3hpb3VzIG1pZGRsZWJv
eCBjYW4gYWx3YXlzIGRyb3AgYWxsIFFVSUMgdHJhZmZpYyBhbmQgZm9yY2UgZmFsbGJhY2sgdG8g
VENQLg0KIE9uZSBjYW4gY29uc3RydWN0IGJhZCBtaWRkbGVib3ggYmVoYXZpb3Igb24gYSB3aWRl
IHNwZWN0cnVtLiBPbmUgY2FuIGFsc28gZGVzaWduIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uIHNv
bHV0aW9ucyB0aGF0IG1ha2UgZW5kcG9pbnRzIGRvIGVpdGhlciB2ZXJ5IGxpdHRsZSB3b3JrIG9y
IGEgbG90IG9mIHdvcmsuIFRoZXJlIGFyZSB0cmFkZS1vZmZzLjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5UaGUgZ29hbCBoZXJlIHdhcyB0byBleHBsb3JlIGEgbG93IENQVSBjb3N0IHRyYW5zZm9y
bSB0aGF0IGNhbiBkbyBiZXR0ZXIgZ3JlYXNpbmcgb2YgdGhlIGZpZWxkIHdpdGggbm8gbW9ub3Rv
bmljIGluY3JlYXNlLCBzcGVjaWZpY2FsbHkgdG8gcHJldmVudCBkdW1iIG1pZGRsZWJveGVzIGZy
b20gdHJlYXRpbmcgdGhlIG5vbmNlIGFzIGEgc2VxdWVuY2UgbnVtYmVyLg0KPG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3Vu
Y2VzQGlldGYub3JnIj5tYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJl
aGFsZiBPZiA8L2I+UnlhbiBIYW1pbHRvbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJp
bCAxMCwgMjAxOCAxOjIwIFBNPGJyPg0KPGI+VG86PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh
biAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iPnByYXZiQG1pY3Jvc29m
dC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gVmljdG9yIFZhc2lsaWV2ICZsdDs8YSBocmVm
PSJtYWlsdG86dmFzaWx2dkBnb29nbGUuY29tIj52YXNpbHZ2QGdvb2dsZS5jb208L2E+Jmd0Ozsg
SUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRm
Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBTaW1wbGUgdHJhbnNmb3JtIGZv
ciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZlbnRpb248bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZiI+T24gVHVlLCBBcHIgMTAsIDIwMTggYXQgOTozNyBBTSwgUHJhdmVl
biBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2Yj00MG1pY3Jvc29mdC4u
LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiPTQwbWljcm9zb2Z0Li4u
Y29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6
MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPldpdGggdGhlIHNodWZmbGUgc2NoZW1lLCBpZiBhIG1pZGRsZWJveCB3YW50cyB0byBn
byBvdXQgb2YgaXRzIHdheSB0byBkbyBhbmFseXNpcyB0byBicmVhayBhIFBSTkcgYW5kIGZpbmQg
dGhlIHBhY2tldCBudW1iZXIgaXQgY2FuLiBUaGUgc2NoZW1lIGlzIG5vdCBldmVuIHJlcXVpcmlu
ZyBhIHNlY3VyZSByYW5kb20NCiBudW1iZXIuIFRoZSBnb2FsIGlzIG5vdCB0byBwcm92aWRlIGFu
eSBzZWN1cml0eSBhcm91bmQgUE4sIGp1c3QgcHJldmVudCBvc3NpZmljYXRpb24gYnkgZHVtYiBt
aWRkbGVib3hlcyB0aGF0IGFzc3VtZSB0aGUgbm9uY2UgaXMgYSBzZXF1ZW5jZSBudW1iZXIgYW5k
IHRyeSB0byByZW9yZGVyLiBJIGRvbuKAmXQgc2VlIGFueSBoYXJtIGlmIGNvc3RseSBhbmFseXNp
cyBjYW4gYWxsb3cgb24gcGF0aCBkZXRlcm1pbmF0aW9uIG9mIHBhY2tldCBudW1iZXJzLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJl
YnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkFyZSB5b3UgY29uY2VybmVkIGFib3V0ICZxdW90
O2hlbHBmdWwmcXVvdDsgbWlkZGxlYm94IHdoaWNoIGFyZSB3aWxsaW5nIHRvIGV4cGVuZCB0aGUg
cmVzb3VyY2VzIHRvIGRvIGNvc3RseSBhbmFseXNpcyBpbiBvcmRlciB0byAmcXVvdDtyZXBhaXIm
cXVvdDsgcGFja2V0IHJlb3JkZXIgKGFuZCBjb25zZXF1ZW50bHkgaW50cm9kdWNlIEhPTCBibG9j
a2luZyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_SN1PR08MB1854F4E5FC3A8EE2E00767EBDABD0SN1PR08MB1854namp_--


From nobody Tue Apr 10 17:03:04 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8154412D944 for ; Tue, 10 Apr 2018 17:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnSWzqbCGyXu for ; Tue, 10 Apr 2018 17:02:45 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA4512D876 for ; Tue, 10 Apr 2018 17:02:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ANkyi2qrDYmsGJNd6VgO66D1d1XbKVo9/jK8gk0+5Ys=; b=dcGvBg/YAQx8Uz1KlaPKFFHCPyyhEQcx2CJ3GpsuyKpv1urvuc6+JwPvzuYxiyYzLxx7KN1kTtQUpzv6tBhh872me7Jocaph5V5bnsAvf2y2IoOpoHIgQaq+rX6ki3ZG3ZWJaZ95o2JtSUf9lCFzNja5aIArvmAmCYUmioAEmDc=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1677.namprd08.prod.outlook.com (10.162.133.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Wed, 11 Apr 2018 00:02:41 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0653.015; Wed, 11 Apr 2018 00:02:41 +0000
From: Mike Bishop 
To: Praveen Balasubramanian , "Ryan Hamilton" 
CC: Victor Vasiliev , IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAbB0nA=
Date: Wed, 11 Apr 2018 00:02:41 +0000
Message-ID: 
References:     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; 
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1677; 7:UDv1jzpqiAQNBLNCbMrBgDrPadofCYaq98m1sTPXt5jcbsBsL3Jy+OO0UCfyMKmtlbQT1C5GdVLLXBp92bsYgbvZxdo/JV6kDiDxl0h4QJ+SICs9Txu50w8i4HhJIEYQvUYTWHrX1fKi1hiIeAzNcy+QpMdti5UYnTV3o5ZPjJkXXNVNm+q/wY2+RbHon7fEKac5p+nOk1373UiTAO9KBzH0q3/Gt5dv02LkjXF/v10gcEqOzOh3UbQ7qMzWOPBr
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1677; 
x-ms-traffictypediagnostic: SN1PR08MB1677:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(192374486261705)(211936372134217)(153496737603132)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231221)(944501327)(52105095)(93006095)(93001095)(6041310)(20161123562045)(20161123560045)(20161123564045)(2016111802025)(20161123558120)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1677; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1677; 
x-forefront-prvs: 0639027A9E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39380400002)(39830400003)(396003)(346002)(189003)(199004)(229853002)(45080400002)(76176011)(97736004)(7696005)(105586002)(99286004)(55016002)(5250100002)(790700001)(8676002)(86362001)(9686003)(236005)(14454004)(6436002)(53936002)(19609705001)(478600001)(54896002)(6306002)(66066001)(106356001)(74482002)(11346002)(5660300001)(8936002)(81166006)(81156014)(2906002)(74316002)(3660700001)(7736002)(4326008)(33656002)(3280700002)(446003)(3846002)(102836004)(68736007)(486006)(476003)(53546011)(93886005)(6116002)(54906003)(6506007)(110136005)(59450400001)(316002)(26005)(186003)(2900100001)(25786009)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1677; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: OGwAu+A0r2PkddlvsxODSTWSlLemK6Ec3eXtggi2v0ReB70Kq+9Yc9hXZ9jAKLeFiybizXg5gZJEXjz47xdur2zKTiGAQNRAlNS28hLlORUZ2dMljIa5n8oq+8HrFFuxcbGQ32Ye4Lf6TtQdrY3MkKM8V+Osg64HTZq5/u3x6Pjm65/pIw/gV2qRtHWWqYDWeOsjhlCH/l/0/skY0VSdYAAi+R6h+kjktGyAq0VqMSwUtm+p/wAjQllx2afqx+fswMAokyFkzUpYERYHrS8oxiJ5/XhVeTgaeoldgckkRRYE0QZlNWc1eEEhNTZhU9/N6atPQbIveScuqwvFwJqZV8cPUNQh4/qrNgDypIQCRA1F0Ai8EVH8AiYvTr4PPVrKwkkMJTN2iuayinOgpH9vGR4pI2igXpkejXkkpdNDbyE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR08MB1854F4E5FC3A8EE2E00767EBDABD0SN1PR08MB1854namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: a4122bbd-d101-4ed8-27fd-08d59f3f8b83
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: a4122bbd-d101-4ed8-27fd-08d59f3f8b83
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 00:02:41.3771 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1677
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 00:02:49 -0000

--_000_SN1PR08MB1854F4E5FC3A8EE2E00767EBDABD0SN1PR08MB1854namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2hpbGUg4oCcaGVscGZ1bOKAnSBtaWRkbGVib3hlcyBhcmUgb25lIHRoaW5nIHdlIHdhbnQgdG8g
YXZvaWQsIGFuZCBhIHNodWZmbGUgbWlnaHQgcmVkdWNlIHRoZWlyIGluY2VudGl2ZXMsIHdlIGFs
c28gd2FudCB0byBwcmVzZXJ2ZSBvdXIgb3B0aW9ucyBmb3IgYSBmdXR1cmUgdmVyc2lvbiBpbiB3
aGljaCBRVUlDIGlzIG11bHRpcGF0aC4gIFRoYXQgbWVhbnMgZGlmZmVyZW50IHBhY2tldHMgd2ls
bCB0YWtlIGRpZmZlcmVudCBwYXRocy4NCg0KVG8gbWUsIHRoZXJlIGFyZSB0d28gb3B0aW9ucyB0
aGF0IHdvdWxkIGdldCB1cyBpbiB0aGF0IHNwYWNlOg0KDQogICogICBQZXItcGF0aCBwYWNrZXQg
bnVtYmVyIHNwYWNlcyBwbHVzIGEgc2h1ZmZsZS1zdHlsZSBvcGVyYXRpb24gZm9yIHRoZSBudW1i
ZXJzIG9uIGVhY2ggcGF0aA0KICAqICAgRW5jcnlwdGlvbiBvZiB0aGUgcGFja2V0IG51bWJlcnMN
Cg0KSeKAmW0gY29uY2VybmVkIHRoYXQgdGhlIGZpcnN0IG9wdGlvbiBtaWdodCBzdGlsbCBsZWF2
ZSBlbm91Z2ggb2YgYSBob2xlIGZvciBvc3NpZmljYXRpb24gdG8gZGV2ZWxvcC4gIFlvdXIgb3du
IGNvbW1lbnQgb24gdGhpcyB0aHJlYWQgdGhhdCDigJxsb3NzIGRldGVjdGlvbiBpcyBhY3R1YWxs
eSBzdHJhaWdodGZvcndhcmTigJ0gYnkgbG9va2luZyBmb3IgbWlzc2luZyBwYWNrZXQgbnVtYmVy
cyBpcyBhbiBleGNlbGxlbnQgZXhhbXBsZSBvZiB0aGUgb3NzaWZ5aW5nIGFzc3VtcHRpb25zIHdl
4oCZcmUgdHJ5aW5nIHRvIG1ha2UgaXQgZGlmZmljdWx0L2ltcG9zc2libGUgZm9yIG1pZGRsZWJv
eGVzIHRvIGdyb3cuICBUaGF04oCZcyB0cnVlIG9ubHkgaWYgdGhlcmXigJlzIGEgc2luZ2xlIHBh
dGggb3IgaWYgZXZlcnkgcGF0aCBoYXMgaXRzIG93biBwYWNrZXQgbnVtYmVyIHNwYWNlLg0KDQpG
cm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUHJh
dmVlbiBCYWxhc3VicmFtYW5pYW4NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDEwLCAyMDE4IDM6MzYg
UE0NClRvOiBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xlLmNvbT4NCkNjOiBWaWN0b3IgVmFzaWxp
ZXYgPHZhc2lsdnZAZ29vZ2xlLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1
YmplY3Q6IFJFOiBTaW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9u
IHByZXZlbnRpb24NCg0KTm8gSSBhbSBub3QgY29uY2VybmVkLiBBbHNvIGl0IGlzIHNwZWN1bGF0
aW9uIHRoYXQgYSBtaWRkbGVib3ggY2FuIGFjdHVhbGx5IGRvIHRoaXMgd2l0aCB0aGUgc2h1ZmZs
ZSBzY2hlbWUgd2hlcmUgZWFjaCBpbXBsZW1lbnRhdGlvbiBpcyBmcmVlIHRvIHBpY2sgdGhlIFBS
TkcsIHRoZSBzaHVmZmxlIGFsZ29yaXRobSwgYW5kIGNoYW5nZSBpdCBvdmVyIHRpbWUuIEltcGxl
bWVudGF0aW9ucyBjYW4gYWxzbyBzZWVkIHRoZSBQUk5HIGZvciBlYWNoIGNvbm5lY3Rpb24uDQoN
Ck1pZGRsZWJveGVzIG5lZWQgdG8gb3BlcmF0ZSBhdCBsaW5lIHJhdGUgYW5kIGNhbm5vdCBkbyBh
bnkgZXhwZW5zaXZlIG9wZXJhdGlvbnMgYW5kIGFueSBndWVzc2VkIHJlb3JkZXJpbmcgd2lsbCBt
YWtlIHRoaW5ncyBldmVuIHdvcnNlIHBlcmZvcm1hbmNlIHdpc2UuIEFuIG9ibm94aW91cyBtaWRk
bGVib3ggY2FuIGFsd2F5cyBkcm9wIGFsbCBRVUlDIHRyYWZmaWMgYW5kIGZvcmNlIGZhbGxiYWNr
IHRvIFRDUC4gT25lIGNhbiBjb25zdHJ1Y3QgYmFkIG1pZGRsZWJveCBiZWhhdmlvciBvbiBhIHdp
ZGUgc3BlY3RydW0uIE9uZSBjYW4gYWxzbyBkZXNpZ24gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24g
c29sdXRpb25zIHRoYXQgbWFrZSBlbmRwb2ludHMgZG8gZWl0aGVyIHZlcnkgbGl0dGxlIHdvcmsg
b3IgYSBsb3Qgb2Ygd29yay4gVGhlcmUgYXJlIHRyYWRlLW9mZnMuDQoNClRoZSBnb2FsIGhlcmUg
d2FzIHRvIGV4cGxvcmUgYSBsb3cgQ1BVIGNvc3QgdHJhbnNmb3JtIHRoYXQgY2FuIGRvIGJldHRl
ciBncmVhc2luZyBvZiB0aGUgZmllbGQgd2l0aCBubyBtb25vdG9uaWMgaW5jcmVhc2UsIHNwZWNp
ZmljYWxseSB0byBwcmV2ZW50IGR1bWIgbWlkZGxlYm94ZXMgZnJvbSB0cmVhdGluZyB0aGUgbm9u
Y2UgYXMgYSBzZXF1ZW5jZSBudW1iZXIuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSeWFuIEhhbWlsdG9uDQpTZW50OiBUdWVzZGF5LCBB
cHJpbCAxMCwgMjAxOCAxOjIwIFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZi
QG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFZpY3RvciBW
YXNpbGlldiA8dmFzaWx2dkBnb29nbGUuY29tPG1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20+Pjsg
SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1Ympl
Y3Q6IFJlOiBTaW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHBy
ZXZlbnRpb24NCg0KT24gVHVlLCBBcHIgMTAsIDIwMTggYXQgOTozNyBBTSwgUHJhdmVlbiBCYWxh
c3VicmFtYW5pYW4gPHByYXZiPTQwbWljcm9zb2Z0Li4uY29tQGRtYXJjLmlldGYub3JnPG1haWx0
bzpwcmF2Yj00MG1pY3Jvc29mdC4uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KV2l0aCB0
aGUgc2h1ZmZsZSBzY2hlbWUsIGlmIGEgbWlkZGxlYm94IHdhbnRzIHRvIGdvIG91dCBvZiBpdHMg
d2F5IHRvIGRvIGFuYWx5c2lzIHRvIGJyZWFrIGEgUFJORyBhbmQgZmluZCB0aGUgcGFja2V0IG51
bWJlciBpdCBjYW4uIFRoZSBzY2hlbWUgaXMgbm90IGV2ZW4gcmVxdWlyaW5nIGEgc2VjdXJlIHJh
bmRvbSBudW1iZXIuIFRoZSBnb2FsIGlzIG5vdCB0byBwcm92aWRlIGFueSBzZWN1cml0eSBhcm91
bmQgUE4sIGp1c3QgcHJldmVudCBvc3NpZmljYXRpb24gYnkgZHVtYiBtaWRkbGVib3hlcyB0aGF0
IGFzc3VtZSB0aGUgbm9uY2UgaXMgYSBzZXF1ZW5jZSBudW1iZXIgYW5kIHRyeSB0byByZW9yZGVy
LiBJIGRvbuKAmXQgc2VlIGFueSBoYXJtIGlmIGNvc3RseSBhbmFseXNpcyBjYW4gYWxsb3cgb24g
cGF0aCBkZXRlcm1pbmF0aW9uIG9mIHBhY2tldCBudW1iZXJzLg0KDQpBcmUgeW91IGNvbmNlcm5l
ZCBhYm91dCAiaGVscGZ1bCIgbWlkZGxlYm94IHdoaWNoIGFyZSB3aWxsaW5nIHRvIGV4cGVuZCB0
aGUgcmVzb3VyY2VzIHRvIGRvIGNvc3RseSBhbmFseXNpcyBpbiBvcmRlciB0byAicmVwYWlyIiBw
YWNrZXQgcmVvcmRlciAoYW5kIGNvbnNlcXVlbnRseSBpbnRyb2R1Y2UgSE9MIGJsb2NraW5nKQ0K
DQo=

--_000_SN1PR08MB1854F4E5FC3A8EE2E00767EBDABD0SN1PR08MB1854namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQg
TVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp
b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp
bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu
aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp
b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYu
TXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDow
aW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVm
dDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y
bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t
YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3
aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N
Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6
ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h
cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6
V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s
aXN0LWlkOjE3NTAxNTE5MzU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt
cGxhdGUtaWRzOjExMzUyMzgwMTAgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg
Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6
bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K
QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww
OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz
O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p
bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv
bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv
bTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw
MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv
Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu
Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl
Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIOKAnGhlbHBmdWzigJ0gbWlkZGxl
Ym94ZXMgYXJlIG9uZSB0aGluZyB3ZSB3YW50IHRvIGF2b2lkLCBhbmQgYSBzaHVmZmxlIG1pZ2h0
IHJlZHVjZSB0aGVpciBpbmNlbnRpdmVzLCB3ZSBhbHNvIHdhbnQgdG8gcHJlc2VydmUgb3VyIG9w
dGlvbnMgZm9yIGEgZnV0dXJlIHZlcnNpb24gaW4gd2hpY2ggUVVJQyBpcyBtdWx0aXBhdGguJm5i
c3A7IFRoYXQgbWVhbnMgZGlmZmVyZW50IHBhY2tldHMgd2lsbCB0YWtlIGRpZmZlcmVudA0KIHBh
dGhzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBtZSwgdGhlcmUgYXJlIHR3byBvcHRpb25z
IHRoYXQgd291bGQgZ2V0IHVzIGluIHRoYXQgc3BhY2U6PG86cD48L286cD48L3A+DQo8dWwgc3R5
bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn
cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+UGVy
LXBhdGggcGFja2V0IG51bWJlciBzcGFjZXMNCjxiPnBsdXM8L2I+IGEgc2h1ZmZsZS1zdHlsZSBv
cGVyYXRpb24gZm9yIHRoZSBudW1iZXJzIG9uIGVhY2ggcGF0aDxvOnA+PC9vOnA+PC9saT48bGkg
Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6
bDAgbGV2ZWwxIGxmbzEiPkVuY3J5cHRpb24gb2YgdGhlIHBhY2tldCBudW1iZXJzPG86cD48L286
cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIGNvbmNlcm5lZCB0aGF0IHRoZSBmaXJzdCBvcHRp
b24gbWlnaHQgc3RpbGwgbGVhdmUgZW5vdWdoIG9mIGEgaG9sZSBmb3Igb3NzaWZpY2F0aW9uIHRv
IGRldmVsb3AuJm5ic3A7IFlvdXIgb3duIGNvbW1lbnQgb24gdGhpcyB0aHJlYWQgdGhhdCDigJxs
b3NzIGRldGVjdGlvbiBpcyBhY3R1YWxseSBzdHJhaWdodGZvcndhcmTigJ0gYnkgbG9va2luZyBm
b3IgbWlzc2luZyBwYWNrZXQgbnVtYmVycyBpcyBhbiBleGNlbGxlbnQNCiBleGFtcGxlIG9mIHRo
ZSBvc3NpZnlpbmcgYXNzdW1wdGlvbnMgd2XigJlyZSB0cnlpbmcgdG8gbWFrZSBpdCBkaWZmaWN1
bHQvaW1wb3NzaWJsZSBmb3IgbWlkZGxlYm94ZXMgdG8gZ3Jvdy4mbmJzcDsgVGhhdOKAmXMgdHJ1
ZSBvbmx5IGlmIHRoZXJl4oCZcyBhIHNpbmdsZSBwYXRoIG9yIGlmIGV2ZXJ5IHBhdGggaGFzIGl0
cyBvd24gcGFja2V0IG51bWJlciBzcGFjZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVp
Yy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5QcmF2ZWVuIEJhbGFzdWJy
YW1hbmlhbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxOCAzOjM2IFBN
PGJyPg0KPGI+VG86PC9iPiBSeWFuIEhhbWlsdG9uICZsdDtyY2hAZ29vZ2xlLmNvbSZndDs8YnI+
DQo8Yj5DYzo8L2I+IFZpY3RvciBWYXNpbGlldiAmbHQ7dmFzaWx2dkBnb29nbGUuY29tJmd0Ozsg
SUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS
RTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50
aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBJIGFtIG5vdCBj
b25jZXJuZWQuIEFsc28gaXQgaXMgc3BlY3VsYXRpb24gdGhhdCBhIG1pZGRsZWJveCBjYW4gYWN0
dWFsbHkgZG8gdGhpcyB3aXRoIHRoZSBzaHVmZmxlIHNjaGVtZSB3aGVyZSBlYWNoIGltcGxlbWVu
dGF0aW9uIGlzIGZyZWUgdG8gcGljayB0aGUgUFJORywgdGhlIHNodWZmbGUgYWxnb3JpdGhtLCBh
bmQgY2hhbmdlIGl0IG92ZXIgdGltZS4gSW1wbGVtZW50YXRpb25zIGNhbiBhbHNvIHNlZWQNCiB0
aGUgUFJORyBmb3IgZWFjaCBjb25uZWN0aW9uLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlk
ZGxlYm94ZXMgbmVlZCB0byBvcGVyYXRlIGF0IGxpbmUgcmF0ZSBhbmQgY2Fubm90IGRvIGFueSBl
eHBlbnNpdmUgb3BlcmF0aW9ucyBhbmQgYW55IGd1ZXNzZWQgcmVvcmRlcmluZyB3aWxsIG1ha2Ug
dGhpbmdzIGV2ZW4gd29yc2UgcGVyZm9ybWFuY2Ugd2lzZS4gQW4gb2Jub3hpb3VzIG1pZGRsZWJv
eCBjYW4gYWx3YXlzIGRyb3AgYWxsIFFVSUMgdHJhZmZpYyBhbmQgZm9yY2UgZmFsbGJhY2sgdG8g
VENQLg0KIE9uZSBjYW4gY29uc3RydWN0IGJhZCBtaWRkbGVib3ggYmVoYXZpb3Igb24gYSB3aWRl
IHNwZWN0cnVtLiBPbmUgY2FuIGFsc28gZGVzaWduIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uIHNv
bHV0aW9ucyB0aGF0IG1ha2UgZW5kcG9pbnRzIGRvIGVpdGhlciB2ZXJ5IGxpdHRsZSB3b3JrIG9y
IGEgbG90IG9mIHdvcmsuIFRoZXJlIGFyZSB0cmFkZS1vZmZzLjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5UaGUgZ29hbCBoZXJlIHdhcyB0byBleHBsb3JlIGEgbG93IENQVSBjb3N0IHRyYW5zZm9y
bSB0aGF0IGNhbiBkbyBiZXR0ZXIgZ3JlYXNpbmcgb2YgdGhlIGZpZWxkIHdpdGggbm8gbW9ub3Rv
bmljIGluY3JlYXNlLCBzcGVjaWZpY2FsbHkgdG8gcHJldmVudCBkdW1iIG1pZGRsZWJveGVzIGZy
b20gdHJlYXRpbmcgdGhlIG5vbmNlIGFzIGEgc2VxdWVuY2UgbnVtYmVyLg0KPG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3Vu
Y2VzQGlldGYub3JnIj5tYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJl
aGFsZiBPZiA8L2I+UnlhbiBIYW1pbHRvbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJp
bCAxMCwgMjAxOCAxOjIwIFBNPGJyPg0KPGI+VG86PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh
biAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iPnByYXZiQG1pY3Jvc29m
dC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gVmljdG9yIFZhc2lsaWV2ICZsdDs8YSBocmVm
PSJtYWlsdG86dmFzaWx2dkBnb29nbGUuY29tIj52YXNpbHZ2QGdvb2dsZS5jb208L2E+Jmd0Ozsg
SUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRm
Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBTaW1wbGUgdHJhbnNmb3JtIGZv
ciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZlbnRpb248bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZiI+T24gVHVlLCBBcHIgMTAsIDIwMTggYXQgOTozNyBBTSwgUHJhdmVl
biBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2Yj00MG1pY3Jvc29mdC4u
LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiPTQwbWljcm9zb2Z0Li4u
Y29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6
MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPldpdGggdGhlIHNodWZmbGUgc2NoZW1lLCBpZiBhIG1pZGRsZWJveCB3YW50cyB0byBn
byBvdXQgb2YgaXRzIHdheSB0byBkbyBhbmFseXNpcyB0byBicmVhayBhIFBSTkcgYW5kIGZpbmQg
dGhlIHBhY2tldCBudW1iZXIgaXQgY2FuLiBUaGUgc2NoZW1lIGlzIG5vdCBldmVuIHJlcXVpcmlu
ZyBhIHNlY3VyZSByYW5kb20NCiBudW1iZXIuIFRoZSBnb2FsIGlzIG5vdCB0byBwcm92aWRlIGFu
eSBzZWN1cml0eSBhcm91bmQgUE4sIGp1c3QgcHJldmVudCBvc3NpZmljYXRpb24gYnkgZHVtYiBt
aWRkbGVib3hlcyB0aGF0IGFzc3VtZSB0aGUgbm9uY2UgaXMgYSBzZXF1ZW5jZSBudW1iZXIgYW5k
IHRyeSB0byByZW9yZGVyLiBJIGRvbuKAmXQgc2VlIGFueSBoYXJtIGlmIGNvc3RseSBhbmFseXNp
cyBjYW4gYWxsb3cgb24gcGF0aCBkZXRlcm1pbmF0aW9uIG9mIHBhY2tldCBudW1iZXJzLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJl
YnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkFyZSB5b3UgY29uY2VybmVkIGFib3V0ICZxdW90
O2hlbHBmdWwmcXVvdDsgbWlkZGxlYm94IHdoaWNoIGFyZSB3aWxsaW5nIHRvIGV4cGVuZCB0aGUg
cmVzb3VyY2VzIHRvIGRvIGNvc3RseSBhbmFseXNpcyBpbiBvcmRlciB0byAmcXVvdDtyZXBhaXIm
cXVvdDsgcGFja2V0IHJlb3JkZXIgKGFuZCBjb25zZXF1ZW50bHkgaW50cm9kdWNlIEhPTCBibG9j
a2luZyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_SN1PR08MB1854F4E5FC3A8EE2E00767EBDABD0SN1PR08MB1854namp_--


From nobody Tue Apr 10 18:03:43 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5644B12D875 for ; Tue, 10 Apr 2018 18:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCfNmhh3I-58 for ; Tue, 10 Apr 2018 18:03:38 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0113.outbound.protection.outlook.com [104.47.34.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98B51241F8 for ; Tue, 10 Apr 2018 18:03:38 -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=pZHRkvjyTsxBqduBDPAdrkQgyZNGyrnNII0n/K1SEJQ=; b=HaZFe85XYNkGltck8oHA++0u5kt8cP2U3wAzD5bC+1ZOF7JaqpIfl2i7QE2kZtD3TDnXVBNGDDEFK0JS+tNgNsxgxGwdxoAgwsHCgF6EjjLW+RORLJjzs0+YWxXPWKJsPe3v0dAyUq8ICy1EcWKkDCdTr8vXjDoEUJ82stSR3u4=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0821.namprd21.prod.outlook.com (10.173.192.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.3; Wed, 11 Apr 2018 01:03:37 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.003; Wed, 11 Apr 2018 01:03:37 +0000
From: Praveen Balasubramanian 
To: Mike Bishop , Ryan Hamilton 
CC: Victor Vasiliev , IETF QUIC WG 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAbB0nAAAoG0MA==
Date: Wed, 11 Apr 2018 01:03:37 +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:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0821; 7:lQQsYNYO3oG0Y7fc7ViZc0ERnl/4azJ7jXcoomQqkOAn3diLR4DPAzhOusMaURW6pxmEAhwSVsR+A/wf1/LiUAJD2pDYsU4+jN/5L6SxGRMH+ORLBFOK404cwjKcIjmX/4Aoo2armwzmEIcZ5nVEnx2Cziro2T1FoB7zP15Jo0AE11tvsp51biEJOSdqAa9zEpk4kX2+WKmFWBaz8OkQkQnfcml2Er5hkiGiHsuIcloYaoRSImfJlvncaZIx1PBq; 20:/l6j8U/5e9d+cjR8tqSqHHL/F7ST1fImKXLbA0cKDkFK3cema5hzoN0UeVsoMgNev+Te+J1pGclJnFT/wG3/TDN6i2LOhEuKEuudN6wi7RPEMMOXzi6jZtGwrswqRxmKuUU/kobrD2fd3Kr9n9dbCTEmkLeTHgwZkVJ1C4wfDjs=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0821; 
x-ms-traffictypediagnostic: CY4PR21MB0821:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(192374486261705)(211936372134217)(100405760836317)(153496737603132)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0821; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0821; 
x-forefront-prvs: 0639027A9E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(376002)(396003)(39380400002)(346002)(199004)(189003)(110136005)(7696005)(8936002)(4326008)(99286004)(9686003)(6246003)(97736004)(76176011)(93886005)(54906003)(6306002)(68736007)(54896002)(236005)(5660300001)(53936002)(186003)(33656002)(229853002)(25786009)(19609705001)(81166006)(46003)(59450400001)(5250100002)(55016002)(316002)(3280700002)(2906002)(446003)(11346002)(81156014)(476003)(10090500001)(6436002)(22452003)(86362001)(3660700001)(53546011)(6116002)(790700001)(86612001)(74316002)(6506007)(486006)(8676002)(2900100001)(7736002)(14454004)(106356001)(478600001)(102836004)(8990500004)(105586002)(10290500003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0821; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Ajn/dbpi8BuTQx1wZg6lhFZq0imyxo64KypHfD1dMtobZrXBUW/AEYYEJ51cyxB0LRAW/noH4CFuqnYBh+C8qOrpsvbFceXQ1r898LjTmOS6pu2A1wgx+8RSPcWe8egIf9Qi/ExnLfs+gxW7YEdeHknS3epNLHaH4g0EnnYXa7NhihOFek7KNyF1ZBU81jLHXPwgtHT43YoStAalMowqJmDgFmltkqhSuIPT2hf9268XXtsj5GzPnuhXtdoGr1vcGHA/0BEgy47HOVNqo8DR21Tc9txEVbCE8BgmuFxR/DKxrc6MY3I12WcepnPvnuKBOe9TpWJWdtlTKFsrOc484EQp3uh7Htpl7EMPV2CJQoHy4eTi/g7j+w8oKUnwTkrcQ1cwn+yGHuDhKVkOIy6w2C5kvoaG7osMf7v3HGyBS98=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630D05F9D83A38A8DF9679CB6BD0CY4PR21MB0630namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 0a453680-2883-4ed8-c108-08d59f480e8b
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a453680-2883-4ed8-c108-08d59f480e8b
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 01:03:37.1732 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0821
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 01:03:42 -0000

--_000_CY4PR21MB0630D05F9D83A38A8DF9679CB6BD0CY4PR21MB0630namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

WWVzIHRoZSBzaHVmZmxlIHNjaGVtZSBkb2VzbuKAmXQgYXR0ZW1wdCB0byBwcmV2ZW50IGxvc3Mg
ZGV0ZWN0aW9uLiBCdXQgbG9zcyBkZXRlY3Rpb24gaXMgYSBwYXNzaXZlIG9wZXJhdGlvbiBhbmQg
aXMgdmVyeSBkaWZmZXJlbnQgZnJvbSByZW9yZGVyaW5nLiBJdCBkb2VzIG5vdCBodXJ0IGVuZCB0
byBlbmQgYmVoYXZpb3Igb3IgcGVyZm9ybWFuY2UuIFNpbmNlIFBOIGlzIG5vdCBwYXJ0IG9mIGlu
dmFyaWFudHMsIGlmIHRoZSBQTiBmaWVsZCBzaXplIGNoYW5nZXMsIG9yIHRoZSB3YXkgaXRzIGVu
Y29kZWQgY2hhbmdlcywgdGhlbiB0aGUgbWlkZGxlYm94IGxvZ2ljIGZvciBsb3NzIGRldGVjdGlv
biB3aWxsIGJyZWFrIGFuZCBJIGRvbuKAmXQgc2VlIHRoYXQgYXMgYSBwcm9ibGVtLg0KDQpUaGF0
IHNhaWQgSW4gdGhlIGNsb3VkIHdlIG1lYXN1cmUgVENQIGxvc3MgYW5kIFJUVCB2YXJpYW5jZSBv
biBiZWhhbGYgb2YgSWFhUyBWTeKAmXMgYXMgaW5kaWNhdG9ycyBvZiBwZXJmb3JtYW5jZSBpc3N1
ZXMuIEl0IHdvdWxkIGJlIG5pY2UgdG8gYmUgYWJsZSB0byBkbyB0aGF0IHdpdGggUVVJQy4gSU1P
IHRoZXJlIGFyZSB0aHJlZSB0aGluZ3MgdGhhdCBhcmUgdXNlZnVsIHRvIG1pZGRsZWJveGVzIGFz
IHBhc3NpdmUgaW5mb3JtYXRpb24g4oCTIFJUVCwgbG9zcywgYW5kIGNvbm5lY3Rpb24gY2xvc3Vy
ZSBzaWduYWwgLS0gYW5kIEkgZG9u4oCZdCBoYXZlIGEgcHJvYmxlbSB3aXRoIGV4cG9zaW5nIHRo
b3NlLCBlc3BlY2lhbGx5IGlmIGl0IG1lYW5zIG1vcmUgc2NlbmFyaW9zIHdvcmsgYmV0dGVyIGFu
ZCBsZXNzIG5ldHdvcmtzIGJsb2NrIFFVSUMuDQoNCkkgY29tcGxldGVseSBhZ3JlZSB3aXRoIHlv
dXIgc3VtbWFyeS4gRXhwYW5kaW5nIG9uIGl0IHNvbWV3aGF0IGZ1cnRoZXI6DQoNCg0KMS4gRm9y
IGNvbm5lY3Rpb25zIGd1YXJhbnRlZWQgdG8gYmUgb24gYSBzaW5nbGUgcGF0aCwgdGhlcmUgYXJl
IG5vIGxpbmthYmlsaXR5IGNvbmNlcm5zLiBJbiB0aGlzIGNhc2UgaXQgd291bGQgYmUgbmljZSB0
byBzb2x2ZSB0aGUgb3NzaWZpY2F0aW9uIHByb2JsZW0uIFRoZSBzaHVmZmxlIHNjaGVtZSBhaW1z
IHRvIHByZXZlbnQg4oCcaGVscGZ1bOKAnSByZW9yZGVyaW5nIGJ1dCBkb2VzbuKAmXQgcHJvbWlz
ZSBtdWNoIGVsc2UuIEl0IGFsc28gZG9lcyBncmVhc2luZyBvZiB0aGUgZmllbGQuIFBORSB3aWxs
IGFjaGlldmUgZXZlbiBiZXR0ZXIgZ3JlYXNpbmcgYnV0IGl0IGhhcyBtdWNoIGhpZ2hlciBDUFUg
Y29zdHMgYW5kIGhhcmR3YXJlIGltcGxpY2F0aW9ucy4gVGhlcmUgaXMgbGlrbGV5IGEgc3BlY3Ry
dW0gb2Ygc2NoZW1lcyAoaW5jbHVkaW5nIGNoZWFwZXIgZW5jcnlwdGlvbikgaGVyZSB3aXRoIGRp
ZmZlcmVudCB0cmFkZS1vZmZzLiBJIGFtIG5vdCBtYXJyaWVkIHRvIGFueSBzY2hlbWUgYnV0IEkg
d2lsbCBzdHJvbmdseSBwcmVmZXIgc2NoZW1lcyB0aGF0IGFyZSBjaGVhcCBDUFUgY29zdCB3aXNl
IGJlY2F1c2Ugd2UgYXJlIG5vdCBhZGRpbmcgYW55IHVzZXIgdmFsdWUsIGFuZCBvbmx5IHByZXZl
bnRpbmcgb3NzaWZpY2F0aW9uIChpLmUuIHRoaXMgaXMgYW4gaW50ZXJuYWwgcHJvdG9jb2wgZXZv
bHV0aW9uIHByb2JsZW0gd2hpY2ggd29ya2xvYWQgb3duZXJzIHdvbuKAmXQgY2FyZSBtdWNoIGFi
b3V0KS4NCg0KDQoyLiBGb3IgY29ubmVjdGlvbnMgb24gbXVsdGlwbGUgcGF0aHMgKGdyYXR1aXRv
dXMgbWlncmF0aW9uLCBvciB0cnVlIG11bHRpIHBhdGgpLCB1bmxpbmthYmlsaXR5IGhhcyBiZWVu
IHByb3Bvc2VkIGFzIGEgZ29hbCBidXQgbm90IGV2ZXJ5b25lIHNlZW1zIHRvIGFncmVlIGlmIGl0
cyBuZWVkZWQgb3IgYWNoaWV2YWJsZS4gSWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRoYXQgd2UgbmVl
ZCB1bmxpbmthYmlsaXR5IGFuZCBpdCBjYW4gYWN0dWFsbHkgYmUgYWNoaWV2ZWQsIHRoZW4gUE5F
IGlzIGEgZ29vZCBvcHRpb24sIGFnYWluIHdpdGggb3ZlcmhlYWRzLiBUaGUgb3RoZXIgYWx0ZXJu
YXRpdmUgaXMgZGlmZmVyZW50IFBOIHNwYWNlcyBhbmQga2V5cyBwZXIgcGF0aCAod2l0aCBzaHVm
Zmxpbmcgb3Igb3RoZXIgbG93IGNvc3QgZ3JlYXNpbmcgYWxnb3JpdGhtcykgd2hpY2ggaGFzIG5v
dCB5ZXQgYmVlbiBkZXNpZ25lZC4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0Bp
ZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pa2UgQmlzaG9wDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAx
MCwgMjAxOCA1OjAzIFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jv
c29mdC5jb20+OyBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xlLmNvbT4NCkNjOiBWaWN0b3IgVmFz
aWxpZXYgPHZhc2lsdnZAZ29vZ2xlLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4N
ClN1YmplY3Q6IFJFOiBTaW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0
aW9uIHByZXZlbnRpb24NCg0KV2hpbGUg4oCcaGVscGZ1bOKAnSBtaWRkbGVib3hlcyBhcmUgb25l
IHRoaW5nIHdlIHdhbnQgdG8gYXZvaWQsIGFuZCBhIHNodWZmbGUgbWlnaHQgcmVkdWNlIHRoZWly
IGluY2VudGl2ZXMsIHdlIGFsc28gd2FudCB0byBwcmVzZXJ2ZSBvdXIgb3B0aW9ucyBmb3IgYSBm
dXR1cmUgdmVyc2lvbiBpbiB3aGljaCBRVUlDIGlzIG11bHRpcGF0aC4gIFRoYXQgbWVhbnMgZGlm
ZmVyZW50IHBhY2tldHMgd2lsbCB0YWtlIGRpZmZlcmVudCBwYXRocy4NCg0KVG8gbWUsIHRoZXJl
IGFyZSB0d28gb3B0aW9ucyB0aGF0IHdvdWxkIGdldCB1cyBpbiB0aGF0IHNwYWNlOg0KDQogICog
ICBQZXItcGF0aCBwYWNrZXQgbnVtYmVyIHNwYWNlcyBwbHVzIGEgc2h1ZmZsZS1zdHlsZSBvcGVy
YXRpb24gZm9yIHRoZSBudW1iZXJzIG9uIGVhY2ggcGF0aA0KICAqICAgRW5jcnlwdGlvbiBvZiB0
aGUgcGFja2V0IG51bWJlcnMNCg0KSeKAmW0gY29uY2VybmVkIHRoYXQgdGhlIGZpcnN0IG9wdGlv
biBtaWdodCBzdGlsbCBsZWF2ZSBlbm91Z2ggb2YgYSBob2xlIGZvciBvc3NpZmljYXRpb24gdG8g
ZGV2ZWxvcC4gIFlvdXIgb3duIGNvbW1lbnQgb24gdGhpcyB0aHJlYWQgdGhhdCDigJxsb3NzIGRl
dGVjdGlvbiBpcyBhY3R1YWxseSBzdHJhaWdodGZvcndhcmTigJ0gYnkgbG9va2luZyBmb3IgbWlz
c2luZyBwYWNrZXQgbnVtYmVycyBpcyBhbiBleGNlbGxlbnQgZXhhbXBsZSBvZiB0aGUgb3NzaWZ5
aW5nIGFzc3VtcHRpb25zIHdl4oCZcmUgdHJ5aW5nIHRvIG1ha2UgaXQgZGlmZmljdWx0L2ltcG9z
c2libGUgZm9yIG1pZGRsZWJveGVzIHRvIGdyb3cuICBUaGF04oCZcyB0cnVlIG9ubHkgaWYgdGhl
cmXigJlzIGEgc2luZ2xlIHBhdGggb3IgaWYgZXZlcnkgcGF0aCBoYXMgaXRzIG93biBwYWNrZXQg
bnVtYmVyIHNwYWNlLg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn
XSBPbiBCZWhhbGYgT2YgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4NClNlbnQ6IFR1ZXNkYXksIEFw
cmlsIDEwLCAyMDE4IDM6MzYgUE0NClRvOiBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xlLmNvbTxt
YWlsdG86cmNoQGdvb2dsZS5jb20+Pg0KQ2M6IFZpY3RvciBWYXNpbGlldiA8dmFzaWx2dkBnb29n
bGUuY29tPG1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20+PjsgSUVURiBRVUlDIFdHIDxxdWljQGll
dGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBTaW1wbGUgdHJhbnNm
b3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24NCg0KTm8gSSBhbSBu
b3QgY29uY2VybmVkLiBBbHNvIGl0IGlzIHNwZWN1bGF0aW9uIHRoYXQgYSBtaWRkbGVib3ggY2Fu
IGFjdHVhbGx5IGRvIHRoaXMgd2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUgd2hlcmUgZWFjaCBpbXBs
ZW1lbnRhdGlvbiBpcyBmcmVlIHRvIHBpY2sgdGhlIFBSTkcsIHRoZSBzaHVmZmxlIGFsZ29yaXRo
bSwgYW5kIGNoYW5nZSBpdCBvdmVyIHRpbWUuIEltcGxlbWVudGF0aW9ucyBjYW4gYWxzbyBzZWVk
IHRoZSBQUk5HIGZvciBlYWNoIGNvbm5lY3Rpb24uDQoNCk1pZGRsZWJveGVzIG5lZWQgdG8gb3Bl
cmF0ZSBhdCBsaW5lIHJhdGUgYW5kIGNhbm5vdCBkbyBhbnkgZXhwZW5zaXZlIG9wZXJhdGlvbnMg
YW5kIGFueSBndWVzc2VkIHJlb3JkZXJpbmcgd2lsbCBtYWtlIHRoaW5ncyBldmVuIHdvcnNlIHBl
cmZvcm1hbmNlIHdpc2UuIEFuIG9ibm94aW91cyBtaWRkbGVib3ggY2FuIGFsd2F5cyBkcm9wIGFs
bCBRVUlDIHRyYWZmaWMgYW5kIGZvcmNlIGZhbGxiYWNrIHRvIFRDUC4gT25lIGNhbiBjb25zdHJ1
Y3QgYmFkIG1pZGRsZWJveCBiZWhhdmlvciBvbiBhIHdpZGUgc3BlY3RydW0uIE9uZSBjYW4gYWxz
byBkZXNpZ24gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24gc29sdXRpb25zIHRoYXQgbWFrZSBlbmRw
b2ludHMgZG8gZWl0aGVyIHZlcnkgbGl0dGxlIHdvcmsgb3IgYSBsb3Qgb2Ygd29yay4gVGhlcmUg
YXJlIHRyYWRlLW9mZnMuDQoNClRoZSBnb2FsIGhlcmUgd2FzIHRvIGV4cGxvcmUgYSBsb3cgQ1BV
IGNvc3QgdHJhbnNmb3JtIHRoYXQgY2FuIGRvIGJldHRlciBncmVhc2luZyBvZiB0aGUgZmllbGQg
d2l0aCBubyBtb25vdG9uaWMgaW5jcmVhc2UsIHNwZWNpZmljYWxseSB0byBwcmV2ZW50IGR1bWIg
bWlkZGxlYm94ZXMgZnJvbSB0cmVhdGluZyB0aGUgbm9uY2UgYXMgYSBzZXF1ZW5jZSBudW1iZXIu
DQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP
ZiBSeWFuIEhhbWlsdG9uDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxOCAxOjIwIFBNDQpU
bzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnBy
YXZiQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFZpY3RvciBWYXNpbGlldiA8dmFzaWx2dkBnb29nbGUu
Y29tPG1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20+PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYu
b3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBTaW1wbGUgdHJhbnNmb3Jt
IGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24NCg0KT24gVHVlLCBBcHIg
MTAsIDIwMTggYXQgOTozNyBBTSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiPTQwbWlj
cm9zb2Z0Li4uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpwcmF2Yj00MG1pY3Jvc29mdC4uLmNv
bUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KV2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUsIGlmIGEg
bWlkZGxlYm94IHdhbnRzIHRvIGdvIG91dCBvZiBpdHMgd2F5IHRvIGRvIGFuYWx5c2lzIHRvIGJy
ZWFrIGEgUFJORyBhbmQgZmluZCB0aGUgcGFja2V0IG51bWJlciBpdCBjYW4uIFRoZSBzY2hlbWUg
aXMgbm90IGV2ZW4gcmVxdWlyaW5nIGEgc2VjdXJlIHJhbmRvbSBudW1iZXIuIFRoZSBnb2FsIGlz
IG5vdCB0byBwcm92aWRlIGFueSBzZWN1cml0eSBhcm91bmQgUE4sIGp1c3QgcHJldmVudCBvc3Np
ZmljYXRpb24gYnkgZHVtYiBtaWRkbGVib3hlcyB0aGF0IGFzc3VtZSB0aGUgbm9uY2UgaXMgYSBz
ZXF1ZW5jZSBudW1iZXIgYW5kIHRyeSB0byByZW9yZGVyLiBJIGRvbuKAmXQgc2VlIGFueSBoYXJt
IGlmIGNvc3RseSBhbmFseXNpcyBjYW4gYWxsb3cgb24gcGF0aCBkZXRlcm1pbmF0aW9uIG9mIHBh
Y2tldCBudW1iZXJzLg0KDQpBcmUgeW91IGNvbmNlcm5lZCBhYm91dCAiaGVscGZ1bCIgbWlkZGxl
Ym94IHdoaWNoIGFyZSB3aWxsaW5nIHRvIGV4cGVuZCB0aGUgcmVzb3VyY2VzIHRvIGRvIGNvc3Rs
eSBhbmFseXNpcyBpbiBvcmRlciB0byAicmVwYWlyIiBwYWNrZXQgcmVvcmRlciAoYW5kIGNvbnNl
cXVlbnRseSBpbnRyb2R1Y2UgSE9MIGJsb2NraW5nKQ0KDQo=

--_000_CY4PR21MB0630D05F9D83A38A8DF9679CB6BD0CY4PR21MB0630namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQg
TVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp
b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp
bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu
aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp
b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWlu
VGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRl
eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xp
c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ
e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6
MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs
MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn
aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h
bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0
O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUy
Mg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l
OiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K
c3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N
c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox
MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp
bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y
ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0
LWlkOjE3NTAxNTE5MzU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh
dGUtaWRzOjExMzUyMzgwMTAgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2
OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2
ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp
c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp
ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv
bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs
LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl
dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N
CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6
U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt
ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3Qt
aWQ6MjAzMDgzODAyNjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTI5NzI3MTIwODt9DQpAbGlz
dCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl
bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVp
bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs
aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z
by1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u
dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz
LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N
CkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K
CW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv
cDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s
O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N
Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6
ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2
OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t
LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMg
dGhlIHNodWZmbGUgc2NoZW1lIGRvZXNu4oCZdCBhdHRlbXB0IHRvIHByZXZlbnQgbG9zcyBkZXRl
Y3Rpb24uIEJ1dCBsb3NzIGRldGVjdGlvbiBpcyBhIHBhc3NpdmUgb3BlcmF0aW9uIGFuZCBpcyB2
ZXJ5IGRpZmZlcmVudCBmcm9tIHJlb3JkZXJpbmcuIEl0IGRvZXMgbm90IGh1cnQgZW5kIHRvIGVu
ZCBiZWhhdmlvciBvciBwZXJmb3JtYW5jZS4gU2luY2UgUE4gaXMgbm90IHBhcnQgb2YgaW52YXJp
YW50cywNCiBpZiB0aGUgUE4gZmllbGQgc2l6ZSBjaGFuZ2VzLCBvciB0aGUgd2F5IGl0cyBlbmNv
ZGVkIGNoYW5nZXMsIHRoZW4gdGhlIG1pZGRsZWJveCBsb2dpYyBmb3IgbG9zcyBkZXRlY3Rpb24g
d2lsbCBicmVhayBhbmQgSSBkb27igJl0IHNlZSB0aGF0IGFzIGEgcHJvYmxlbS4NCjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5UaGF0IHNhaWQgSW4gdGhlIGNsb3VkIHdlIG1lYXN1cmUgVENQIGxv
c3MgYW5kIFJUVCB2YXJpYW5jZSBvbiBiZWhhbGYgb2YgSWFhUyBWTeKAmXMgYXMgaW5kaWNhdG9y
cyBvZiBwZXJmb3JtYW5jZSBpc3N1ZXMuIEl0IHdvdWxkIGJlIG5pY2UgdG8gYmUgYWJsZSB0byBk
byB0aGF0IHdpdGggUVVJQy4gSU1PIHRoZXJlIGFyZSB0aHJlZSB0aGluZ3MgdGhhdCBhcmUgdXNl
ZnVsIHRvIG1pZGRsZWJveGVzIGFzIHBhc3NpdmUNCiBpbmZvcm1hdGlvbiDigJMgUlRULCBsb3Nz
LCBhbmQgY29ubmVjdGlvbiBjbG9zdXJlIHNpZ25hbCAtLSBhbmQgSSBkb27igJl0IGhhdmUgYSBw
cm9ibGVtIHdpdGggZXhwb3NpbmcgdGhvc2UsIGVzcGVjaWFsbHkgaWYgaXQgbWVhbnMgbW9yZSBz
Y2VuYXJpb3Mgd29yayBiZXR0ZXIgYW5kIGxlc3MgbmV0d29ya3MgYmxvY2sgUVVJQy4NCjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCB5b3VyIHN1bW1hcnku
IEV4cGFuZGluZyBvbiBpdCBzb21ld2hhdCBmdXJ0aGVyOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij4xLiBGb3IgY29ubmVjdGlvbnMgZ3VhcmFudGVlZCB0byBiZSBvbiBhIHNpbmdsZSBwYXRo
LCB0aGVyZSBhcmUgbm8gbGlua2FiaWxpdHkgY29uY2VybnMuIEluIHRoaXMgY2FzZSBpdCB3b3Vs
ZCBiZSBuaWNlIHRvIHNvbHZlIHRoZSBvc3NpZmljYXRpb24gcHJvYmxlbS4gVGhlIHNodWZmbGUg
c2NoZW1lIGFpbXMgdG8gcHJldmVudCDigJxoZWxwZnVs4oCdIHJlb3JkZXJpbmcgYnV0IGRvZXNu
4oCZdCBwcm9taXNlIG11Y2gNCiBlbHNlLiBJdCBhbHNvIGRvZXMgZ3JlYXNpbmcgb2YgdGhlIGZp
ZWxkLiBQTkUgd2lsbCBhY2hpZXZlIGV2ZW4gYmV0dGVyIGdyZWFzaW5nIGJ1dCBpdCBoYXMgbXVj
aCBoaWdoZXIgQ1BVIGNvc3RzIGFuZCBoYXJkd2FyZSBpbXBsaWNhdGlvbnMuIFRoZXJlIGlzIGxp
a2xleSBhIHNwZWN0cnVtIG9mIHNjaGVtZXMgKGluY2x1ZGluZyBjaGVhcGVyIGVuY3J5cHRpb24p
IGhlcmUgd2l0aCBkaWZmZXJlbnQgdHJhZGUtb2Zmcy4gSSBhbSBub3QgbWFycmllZA0KIHRvIGFu
eSBzY2hlbWUgYnV0IEkgd2lsbCBzdHJvbmdseSBwcmVmZXIgc2NoZW1lcyB0aGF0IGFyZSBjaGVh
cCBDUFUgY29zdCB3aXNlIGJlY2F1c2Ugd2UgYXJlIG5vdCBhZGRpbmcgYW55IHVzZXIgdmFsdWUs
IGFuZCBvbmx5IHByZXZlbnRpbmcgb3NzaWZpY2F0aW9uIChpLmUuIHRoaXMgaXMgYW4gaW50ZXJu
YWwgcHJvdG9jb2wgZXZvbHV0aW9uIHByb2JsZW0gd2hpY2ggd29ya2xvYWQgb3duZXJzIHdvbuKA
mXQgY2FyZSBtdWNoIGFib3V0KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gRm9yIGNv
bm5lY3Rpb25zIG9uIG11bHRpcGxlIHBhdGhzIChncmF0dWl0b3VzIG1pZ3JhdGlvbiwgb3IgdHJ1
ZSBtdWx0aSBwYXRoKSwgdW5saW5rYWJpbGl0eSBoYXMgYmVlbiBwcm9wb3NlZCBhcyBhIGdvYWwg
YnV0IG5vdCBldmVyeW9uZSBzZWVtcyB0byBhZ3JlZSBpZiBpdHMgbmVlZGVkIG9yIGFjaGlldmFi
bGUuIElmIHRoZXJlIGlzIGNvbnNlbnN1cyB0aGF0IHdlIG5lZWQgdW5saW5rYWJpbGl0eSBhbmQN
CiBpdCBjYW4gYWN0dWFsbHkgYmUgYWNoaWV2ZWQsIHRoZW4gUE5FIGlzIGEgZ29vZCBvcHRpb24s
IGFnYWluIHdpdGggb3ZlcmhlYWRzLiBUaGUgb3RoZXIgYWx0ZXJuYXRpdmUgaXMgZGlmZmVyZW50
IFBOIHNwYWNlcyBhbmQga2V5cyBwZXIgcGF0aCAod2l0aCBzaHVmZmxpbmcgb3Igb3RoZXIgbG93
IGNvc3QgZ3JlYXNpbmcgYWxnb3JpdGhtcykgd2hpY2ggaGFzIG5vdCB5ZXQgYmVlbiBkZXNpZ25l
ZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux
RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5P
biBCZWhhbGYgT2YNCjwvYj5NaWtlIEJpc2hvcDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBB
cHJpbCAxMCwgMjAxOCA1OjAzIFBNPGJyPg0KPGI+VG86PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1h
bmlhbiAmbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZndDs7IFJ5YW4gSGFtaWx0b24gJmx0O3JjaEBn
b29nbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gVmljdG9yIFZhc2lsaWV2ICZsdDt2YXNpbHZ2
QGdvb2dsZS5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0K
PGI+U3ViamVjdDo8L2I+IFJFOiBTaW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3Nz
aWZpY2F0aW9uIHByZXZlbnRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPldoaWxlIOKAnGhlbHBmdWzigJ0gbWlkZGxlYm94ZXMgYXJlIG9uZSB0aGluZyB3ZSB3YW50
IHRvIGF2b2lkLCBhbmQgYSBzaHVmZmxlIG1pZ2h0IHJlZHVjZSB0aGVpciBpbmNlbnRpdmVzLCB3
ZSBhbHNvIHdhbnQgdG8gcHJlc2VydmUgb3VyIG9wdGlvbnMgZm9yIGEgZnV0dXJlIHZlcnNpb24g
aW4gd2hpY2ggUVVJQyBpcyBtdWx0aXBhdGguJm5ic3A7IFRoYXQgbWVhbnMgZGlmZmVyZW50IHBh
Y2tldHMgd2lsbCB0YWtlIGRpZmZlcmVudA0KIHBhdGhzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UbyBtZSwgdGhlcmUgYXJlIHR3byBvcHRpb25zIHRoYXQgd291bGQgZ2V0IHVzIGluIHRoYXQg
c3BhY2U6PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJk
aXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxm
bzMiPlBlci1wYXRoIHBhY2tldCBudW1iZXIgc3BhY2VzDQo8Yj5wbHVzPC9iPiBhIHNodWZmbGUt
c3R5bGUgb3BlcmF0aW9uIGZvciB0aGUgbnVtYmVycyBvbiBlYWNoIHBhdGg8bzpwPjwvbzpwPjwv
bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+
RW5jcnlwdGlvbiBvZiB0aGUgcGFja2V0IG51bWJlcnM8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SeKAmW0gY29uY2VybmVkIHRoYXQgdGhlIGZpcnN0IG9wdGlvbiBtaWdodCBzdGlsbCBs
ZWF2ZSBlbm91Z2ggb2YgYSBob2xlIGZvciBvc3NpZmljYXRpb24gdG8gZGV2ZWxvcC4mbmJzcDsg
WW91ciBvd24gY29tbWVudCBvbiB0aGlzIHRocmVhZCB0aGF0IOKAnGxvc3MgZGV0ZWN0aW9uIGlz
IGFjdHVhbGx5IHN0cmFpZ2h0Zm9yd2FyZOKAnSBieSBsb29raW5nIGZvciBtaXNzaW5nIHBhY2tl
dCBudW1iZXJzIGlzIGFuIGV4Y2VsbGVudA0KIGV4YW1wbGUgb2YgdGhlIG9zc2lmeWluZyBhc3N1
bXB0aW9ucyB3ZeKAmXJlIHRyeWluZyB0byBtYWtlIGl0IGRpZmZpY3VsdC9pbXBvc3NpYmxlIGZv
ciBtaWRkbGVib3hlcyB0byBncm93LiZuYnNwOyBUaGF04oCZcyB0cnVlIG9ubHkgaWYgdGhlcmXi
gJlzIGEgc2luZ2xlIHBhdGggb3IgaWYgZXZlcnkgcGF0aCBoYXMgaXRzIG93biBwYWNrZXQgbnVt
YmVyIHNwYWNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz
b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgWzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5j
ZXNAaWV0Zi5vcmciPm1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo
YWxmIE9mIDwvYj5QcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz
ZGF5LCBBcHJpbCAxMCwgMjAxOCAzOjM2IFBNPGJyPg0KPGI+VG86PC9iPiBSeWFuIEhhbWlsdG9u
ICZsdDs8YSBocmVmPSJtYWlsdG86cmNoQGdvb2dsZS5jb20iPnJjaEBnb29nbGUuY29tPC9hPiZn
dDs8YnI+DQo8Yj5DYzo8L2I+IFZpY3RvciBWYXNpbGlldiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZh
c2lsdnZAZ29vZ2xlLmNvbSI+dmFzaWx2dkBnb29nbGUuY29tPC9hPiZndDs7IElFVEYgUVVJQyBX
RyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0
Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5n
IFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5ObyBJIGFtIG5vdCBjb25jZXJuZWQuIEFsc28gaXQgaXMgc3BlY3VsYXRpb24g
dGhhdCBhIG1pZGRsZWJveCBjYW4gYWN0dWFsbHkgZG8gdGhpcyB3aXRoIHRoZSBzaHVmZmxlIHNj
aGVtZSB3aGVyZSBlYWNoIGltcGxlbWVudGF0aW9uIGlzIGZyZWUgdG8gcGljayB0aGUgUFJORywg
dGhlIHNodWZmbGUgYWxnb3JpdGhtLCBhbmQgY2hhbmdlIGl0IG92ZXIgdGltZS4gSW1wbGVtZW50
YXRpb25zIGNhbiBhbHNvIHNlZWQNCiB0aGUgUFJORyBmb3IgZWFjaCBjb25uZWN0aW9uLiA8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlkZGxlYm94ZXMgbmVlZCB0byBvcGVyYXRlIGF0IGxpbmUg
cmF0ZSBhbmQgY2Fubm90IGRvIGFueSBleHBlbnNpdmUgb3BlcmF0aW9ucyBhbmQgYW55IGd1ZXNz
ZWQgcmVvcmRlcmluZyB3aWxsIG1ha2UgdGhpbmdzIGV2ZW4gd29yc2UgcGVyZm9ybWFuY2Ugd2lz
ZS4gQW4gb2Jub3hpb3VzIG1pZGRsZWJveCBjYW4gYWx3YXlzIGRyb3AgYWxsIFFVSUMgdHJhZmZp
YyBhbmQgZm9yY2UgZmFsbGJhY2sgdG8gVENQLg0KIE9uZSBjYW4gY29uc3RydWN0IGJhZCBtaWRk
bGVib3ggYmVoYXZpb3Igb24gYSB3aWRlIHNwZWN0cnVtLiBPbmUgY2FuIGFsc28gZGVzaWduIG9z
c2lmaWNhdGlvbiBwcmV2ZW50aW9uIHNvbHV0aW9ucyB0aGF0IG1ha2UgZW5kcG9pbnRzIGRvIGVp
dGhlciB2ZXJ5IGxpdHRsZSB3b3JrIG9yIGEgbG90IG9mIHdvcmsuIFRoZXJlIGFyZSB0cmFkZS1v
ZmZzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZ29hbCBoZXJlIHdhcyB0byBleHBsb3Jl
IGEgbG93IENQVSBjb3N0IHRyYW5zZm9ybSB0aGF0IGNhbiBkbyBiZXR0ZXIgZ3JlYXNpbmcgb2Yg
dGhlIGZpZWxkIHdpdGggbm8gbW9ub3RvbmljIGluY3JlYXNlLCBzcGVjaWZpY2FsbHkgdG8gcHJl
dmVudCBkdW1iIG1pZGRsZWJveGVzIGZyb20gdHJlYXRpbmcgdGhlIG5vbmNlIGFzIGEgc2VxdWVu
Y2UgbnVtYmVyLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFs8
YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cXVpYy1ib3VuY2Vz
QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UnlhbiBIYW1pbHRvbjxicj4NCjxi
PlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxOCAxOjIwIFBNPGJyPg0KPGI+VG86PC9i
PiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jv
c29mdC5jb20iPnByYXZiQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gVmlj
dG9yIFZhc2lsaWV2ICZsdDs8YSBocmVmPSJtYWlsdG86dmFzaWx2dkBnb29nbGUuY29tIj52YXNp
bHZ2QGdvb2dsZS5jb208L2E+Jmd0OzsgSUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86
cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+
IFJlOiBTaW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZl
bnRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+T24gVHVlLCBBcHIgMTAs
IDIwMTggYXQgOTozNyBBTSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1h
aWx0bzpwcmF2Yj00MG1pY3Jvc29mdC4uLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiPnByYXZiPTQwbWljcm9zb2Z0Li4uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldpdGggdGhlIHNodWZmbGUgc2NoZW1lLCBp
ZiBhIG1pZGRsZWJveCB3YW50cyB0byBnbyBvdXQgb2YgaXRzIHdheSB0byBkbyBhbmFseXNpcyB0
byBicmVhayBhIFBSTkcgYW5kIGZpbmQgdGhlIHBhY2tldCBudW1iZXIgaXQgY2FuLiBUaGUgc2No
ZW1lIGlzIG5vdCBldmVuIHJlcXVpcmluZyBhIHNlY3VyZSByYW5kb20NCiBudW1iZXIuIFRoZSBn
b2FsIGlzIG5vdCB0byBwcm92aWRlIGFueSBzZWN1cml0eSBhcm91bmQgUE4sIGp1c3QgcHJldmVu
dCBvc3NpZmljYXRpb24gYnkgZHVtYiBtaWRkbGVib3hlcyB0aGF0IGFzc3VtZSB0aGUgbm9uY2Ug
aXMgYSBzZXF1ZW5jZSBudW1iZXIgYW5kIHRyeSB0byByZW9yZGVyLiBJIGRvbuKAmXQgc2VlIGFu
eSBoYXJtIGlmIGNvc3RseSBhbmFseXNpcyBjYW4gYWxsb3cgb24gcGF0aCBkZXRlcm1pbmF0aW9u
IG9mIHBhY2tldCBudW1iZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkFyZSB5
b3UgY29uY2VybmVkIGFib3V0ICZxdW90O2hlbHBmdWwmcXVvdDsgbWlkZGxlYm94IHdoaWNoIGFy
ZSB3aWxsaW5nIHRvIGV4cGVuZCB0aGUgcmVzb3VyY2VzIHRvIGRvIGNvc3RseSBhbmFseXNpcyBp
biBvcmRlciB0byAmcXVvdDtyZXBhaXImcXVvdDsgcGFja2V0IHJlb3JkZXIgKGFuZCBjb25zZXF1
ZW50bHkgaW50cm9kdWNlIEhPTCBibG9ja2luZyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_CY4PR21MB0630D05F9D83A38A8DF9679CB6BD0CY4PR21MB0630namp_--


From nobody Tue Apr 10 18:55:44 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6886D12D95B for ; Tue, 10 Apr 2018 18:55: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, 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 etCbFwPpYv9K for ; Tue, 10 Apr 2018 18:55:41 -0700 (PDT)
Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::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 48CB8120227 for ; Tue, 10 Apr 2018 18:55:41 -0700 (PDT)
Received: by mail-pl0-x232.google.com with SMTP id e22-v6so194724plj.12 for ; Tue, 10 Apr 2018 18:55: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=GKvm2rQCCE93l6rTktApHWRecI/vOIBAVEijdBRQBmw=; b=LFzZCTkNbORDjGGDxNd9UJ4QdSYStu1bUpHNbEzRxWs03Zfxtkz/I6e9rb+4rnFWsk n7AiFzGpqQ83PnKBALvvGxJ9IaArBZtd56gE0OYQgGx7ZFJmOzzN2ViP1yiyuVrAKbkz jEFqjzV72/vRVtmvyIF5yplXXrcAMz+pHNlbtzlnCCRtAtgblAqlFhCHjYq4ZtQ8rp+r 41YIyPC/ZWz41vhScRflqf1ziVXN9o0kvG5rhVTINb1xgYeGitYLx0jlgL0bWS1Re0uR DMLsdcFuevRiQMTe0t6u04OSkzByIwXeHssxtgAZGLTB/SZFYoa0eH16A1OnRAwohOYY spmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=GKvm2rQCCE93l6rTktApHWRecI/vOIBAVEijdBRQBmw=; b=dadUC9EXjeJLjf2U8M4DpLwm65rYkQykBcIprcdWyocg1BiQHWev7/9xoo5xtQLCY6 3W+L23u2ymazgK0m4OL678QFz8DttDeyD+l3bsL/nA+8abGo14G5WXCmiTj3gg7I1l5b WUPiqucgr8yz8liTFjwLqWdd2isYtuOwglaDJTNGxfItj33zoHvOB84cyWdYWmTI//KV lFpyhrYUxIEWaqPFh8cmVvug0+o84Tj0cP85J7LgCiXrH2PwI2U0RrWZyotLh1w+LXWq 2p+lvThyqgjdUVTZAdrx8gKBycmgyzgemyvsw5xS9MdtK8Ap+vPVCPKQMBrr64khXk+L S8mA==
X-Gm-Message-State: ALQs6tC5QoV8zgepzxHHlm6hMhaAIugZ8yCsNmu0nypRwBeLCQ/io3Uo 44l/K6jMug0zHVD2qDyHrX9JslHe2v6y63FX2H/XIA==
X-Google-Smtp-Source: AIpwx4+3oyPwPw7EF5bkQ/HOmD6RrG33jnPcG/tHB43/HoxkgIgvCCBPrcc+jJ2hX1p0/yyce7TLMXruDbpniU96n+8=
X-Received: by 2002:a17:902:228:: with SMTP id 37-v6mr2873200plc.141.1523411740847;  Tue, 10 Apr 2018 18:55:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Tue, 10 Apr 2018 18:55:40 -0700 (PDT)
In-Reply-To: 
References:     
From: Kazuho Oku 
Date: Wed, 11 Apr 2018 10:55:40 +0900
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Praveen Balasubramanian 
Cc: Ryan Hamilton , Victor Vasiliev , 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: Wed, 11 Apr 2018 01:55:43 -0000

2018-04-11 7:36 GMT+09:00 Praveen Balasubramanian
:
> No I am not concerned. Also it is speculation that a middlebox can actual=
ly
> do this with the shuffle scheme where each implementation is free to pick
> the PRNG, the shuffle algorithm, and change it over time. Implementations
> can also seed the PRNG for each connection.
>
>
>
> Middleboxes need to operate at line rate and cannot do any expensive
> operations and any guessed reordering will make things even worse
> performance wise.

I am not sure if that assumption is correct.

IIUC, there is a strong incentive to create a middlebox that reduces
retransmissions in the mobile networks, since it enables mobile
operators to have more customers connected to each base station. For
example, https://www.sandvine.com/hubfs/downloads/archive/whitepaper-tcp-op=
timization-opportunities-kpis-and-considerations.pdf
p. 13 claims 5% network efficiency gain by middleboxes intervening TCP
retransmissions.

It makes me understand that there is certain amount of money on table
that could be enough to do complicated things in the middlebox.

Note also that people working on such optimizations have the incentive
to take advantage of every aspect of how the majority of the QUIC
traffic they see look like, rather than respecting what the senders
are theoretically allowed to do.

> An obnoxious middlebox can always drop all QUIC traffic
> and force fallback to TCP.

Yes.

I believe that the signal that we need to send to people interesting
in "optimizing" QUIC in the middle is that they should either decide
not to (by possibly dropping QUIC entirely), or to cooperate with the
protocol designers in optimizing QUIC for their needs without causing
ossification.

IMO PNE is a good signal in that respect.

> One can construct bad middlebox behavior on a
> wide spectrum. One can also design ossification prevention solutions that
> make endpoints do either very little work or a lot of work. There are
> trade-offs.
>
>
>
> The goal here was to explore a low CPU cost transform that can do better
> greasing of the field with no monotonic increase, specifically to prevent
> dumb middleboxes from treating the nonce as a sequence number.
>
>
>
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ryan Hamilton
> Sent: Tuesday, April 10, 2018 1:20 PM
> To: Praveen Balasubramanian 
> Cc: Victor Vasiliev ; IETF QUIC WG 
> Subject: Re: Simple transform for improving PN ossification prevention
>
>
>
> On Tue, Apr 10, 2018 at 9:37 AM, Praveen Balasubramanian
>  wrote:
>
> With the shuffle scheme, if a middlebox wants to go out of its way to do
> analysis to break a PRNG and find the packet number it can. The scheme is
> not even requiring a secure random number. The goal is not to provide any
> security around PN, just prevent ossification by dumb middleboxes that
> assume the nonce is a sequence number and try to reorder. I don=E2=80=99t=
 see any
> harm if costly analysis can allow on path determination of packet numbers=
.
>
>
>
> Are you concerned about "helpful" middlebox which are willing to expend t=
he
> resources to do costly analysis in order to "repair" packet reorder (and
> consequently introduce HOL blocking)
>
>



--=20
Kazuho Oku


From nobody Tue Apr 10 18:55:50 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1629112D96B for ; Tue, 10 Apr 2018 18:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523411745; bh=ElQMnq/1TIjbywYM3y95XQEuEe/olY+ZyQU3dDD0pIc=; h=In-Reply-To:References:From:Date:Subject:Cc:To; b=igzLk0slsuhrmGJcnuH2dS/kvkWHaA8cGRjqok5QzPNpnzckruOUybMmAWKmYNzsL 5A6o6yxve5wd5QcdeJtlM2T414uqx8jFeTacKYQOgg26JBvt5eEtkgIu3PiLtq6UC4 N3RLN6QVwAzBge+TOJfj1RpMn7OCI4LnVTJ4Nu0c=
X-Mailbox-Line: From kazuhooku@gmail.com  Tue Apr 10 18:55:44 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8E612D95C; Tue, 10 Apr 2018 18:55:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523411744; bh=GKvm2rQCCE93l6rTktApHWRecI/vOIBAVEijdBRQBmw=; h=In-Reply-To:References:From:Date:Subject:Cc:To; b=WBUvuj8O94UzTV9ZZ6MfbwmI1kU/f5EtRZSWKZlOgjxI74Sl/ZqqpqXLf9ZCbteZS O6TpffaIhNJGoTiEkBM9x0EufsILIU6HZ12d+KYF5jEUuccCth4JxDla67pTRQf5rt IgqnMGpWpwkAzU+YT33KMuecLrpEaj4Y73GacROg=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CA412D95B for ; Tue, 10 Apr 2018 18:55:44 -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=unavailable 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 fXxrcKV5Vfod for ; Tue, 10 Apr 2018 18:55:41 -0700 (PDT)
Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::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 98E5212D95C for ; Tue, 10 Apr 2018 18:55:41 -0700 (PDT)
Received: by mail-pl0-x231.google.com with SMTP id bj1-v6so198569plb.8 for ; Tue, 10 Apr 2018 18:55: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=GKvm2rQCCE93l6rTktApHWRecI/vOIBAVEijdBRQBmw=; b=LFzZCTkNbORDjGGDxNd9UJ4QdSYStu1bUpHNbEzRxWs03Zfxtkz/I6e9rb+4rnFWsk n7AiFzGpqQ83PnKBALvvGxJ9IaArBZtd56gE0OYQgGx7ZFJmOzzN2ViP1yiyuVrAKbkz jEFqjzV72/vRVtmvyIF5yplXXrcAMz+pHNlbtzlnCCRtAtgblAqlFhCHjYq4ZtQ8rp+r 41YIyPC/ZWz41vhScRflqf1ziVXN9o0kvG5rhVTINb1xgYeGitYLx0jlgL0bWS1Re0uR DMLsdcFuevRiQMTe0t6u04OSkzByIwXeHssxtgAZGLTB/SZFYoa0eH16A1OnRAwohOYY spmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=GKvm2rQCCE93l6rTktApHWRecI/vOIBAVEijdBRQBmw=; b=tngxM4ZUF/CxTQsDLMCxQjk46HwSHckD/qISBdwjd/P7iiMGlZOxV4cANBNJIvvz87 1T95wRTa7b+yj2P5KWqqfLIPyOTR4fwZ1bROgZRZji1qcSIn6xTrOM8VaYWpfw7MARAQ EkBSnHQNFnrxwKc051YJqSOHwwYLkB5LJE5wWztJe224xJOBwXSUPAyo4xymC0sRgIlf S5i2S7NTjJcmr2oK4OfkiHyRrlr+9lUwCsrt+TXdCdY9u0HUUdZJOvgNqifTlTFr0/KM 9KaKeVu64U+USo7X9KxYisBNIcIQOxZLeDZid4R2CHzBZrBW15x7AAlylqNKDTs4rIXd urFQ==
X-Gm-Message-State: ALQs6tAx/VUS5IzbJmqizG5Qdth+cRkC7b9VTS6nLHvaezQrDcef5+6r hqhjOysiYyeoG2+UBfNSBQfTwBEYVMYN+FSuPi6maA==
X-Google-Smtp-Source: AIpwx4+3oyPwPw7EF5bkQ/HOmD6RrG33jnPcG/tHB43/HoxkgIgvCCBPrcc+jJ2hX1p0/yyce7TLMXruDbpniU96n+8=
X-Received: by 2002:a17:902:228:: with SMTP id 37-v6mr2873200plc.141.1523411740847;  Tue, 10 Apr 2018 18:55:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Tue, 10 Apr 2018 18:55:40 -0700 (PDT)
In-Reply-To: 
References:     
From: Kazuho Oku 
Date: Wed, 11 Apr 2018 10:55:40 +0900
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
Cc: Ryan Hamilton , Victor Vasiliev , IETF QUIC WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 01:55:45 -0000

2018-04-11 7:36 GMT+09:00 Praveen Balasubramanian
:
> No I am not concerned. Also it is speculation that a middlebox can actual=
ly
> do this with the shuffle scheme where each implementation is free to pick
> the PRNG, the shuffle algorithm, and change it over time. Implementations
> can also seed the PRNG for each connection.
>
>
>
> Middleboxes need to operate at line rate and cannot do any expensive
> operations and any guessed reordering will make things even worse
> performance wise.

I am not sure if that assumption is correct.

IIUC, there is a strong incentive to create a middlebox that reduces
retransmissions in the mobile networks, since it enables mobile
operators to have more customers connected to each base station. For
example, https://www.sandvine.com/hubfs/downloads/archive/whitepaper-tcp-op=
timization-opportunities-kpis-and-considerations.pdf
p. 13 claims 5% network efficiency gain by middleboxes intervening TCP
retransmissions.

It makes me understand that there is certain amount of money on table
that could be enough to do complicated things in the middlebox.

Note also that people working on such optimizations have the incentive
to take advantage of every aspect of how the majority of the QUIC
traffic they see look like, rather than respecting what the senders
are theoretically allowed to do.

> An obnoxious middlebox can always drop all QUIC traffic
> and force fallback to TCP.

Yes.

I believe that the signal that we need to send to people interesting
in "optimizing" QUIC in the middle is that they should either decide
not to (by possibly dropping QUIC entirely), or to cooperate with the
protocol designers in optimizing QUIC for their needs without causing
ossification.

IMO PNE is a good signal in that respect.

> One can construct bad middlebox behavior on a
> wide spectrum. One can also design ossification prevention solutions that
> make endpoints do either very little work or a lot of work. There are
> trade-offs.
>
>
>
> The goal here was to explore a low CPU cost transform that can do better
> greasing of the field with no monotonic increase, specifically to prevent
> dumb middleboxes from treating the nonce as a sequence number.
>
>
>
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ryan Hamilton
> Sent: Tuesday, April 10, 2018 1:20 PM
> To: Praveen Balasubramanian 
> Cc: Victor Vasiliev ; IETF QUIC WG 
> Subject: Re: Simple transform for improving PN ossification prevention
>
>
>
> On Tue, Apr 10, 2018 at 9:37 AM, Praveen Balasubramanian
>  wrote:
>
> With the shuffle scheme, if a middlebox wants to go out of its way to do
> analysis to break a PRNG and find the packet number it can. The scheme is
> not even requiring a secure random number. The goal is not to provide any
> security around PN, just prevent ossification by dumb middleboxes that
> assume the nonce is a sequence number and try to reorder. I don=E2=80=99t=
 see any
> harm if costly analysis can allow on path determination of packet numbers=
..
>
>
>
> Are you concerned about "helpful" middlebox which are willing to expend t=
he
> resources to do costly analysis in order to "repair" packet reorder (and
> consequently introduce HOL blocking)
>
>



--=20
Kazuho Oku


From nobody Wed Apr 11 00:16:32 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED641270FC for ; Wed, 11 Apr 2018 00:16:31 -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 ZjGoGBC52f3Z for ; Wed, 11 Apr 2018 00:16:28 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4E61205F0 for ; Wed, 11 Apr 2018 00:16:28 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 44F82340EE6; Wed, 11 Apr 2018 09:16:27 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.6115);  Wed, 11 Apr 2018 09:16:27 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 11 Apr 2018 09:16:27 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 51308046; Wed, 11 Apr 2018 09:16:27 +0200
From: "Brian Trammell (IETF)" 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_F71600AD-54FD-464E-997B-3A14774A39C7"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Simple transform for improving PN ossification prevention
Date: Wed, 11 Apr 2018 09:16:26 +0200
In-Reply-To: 
Cc: Praveen Balasubramanian , Victor Vasiliev , IETF QUIC WG , Ryan Hamilton 
To: Kazuho Oku 
References:      
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 07:16:31 -0000

--Apple-Mail=_F71600AD-54FD-464E-997B-3A14774A39C7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

hi Kazuho, all,

> On 11 Apr 2018, at 03:55, Kazuho Oku  wrote:
>=20
> 2018-04-11 7:36 GMT+09:00 Praveen Balasubramanian
> :
>> No I am not concerned. Also it is speculation that a middlebox can =
actually
>> do this with the shuffle scheme where each implementation is free to =
pick
>> the PRNG, the shuffle algorithm, and change it over time. =
Implementations
>> can also seed the PRNG for each connection.
>>=20
>>=20
>>=20
>> Middleboxes need to operate at line rate and cannot do any expensive
>> operations and any guessed reordering will make things even worse
>> performance wise.
>=20
> I am not sure if that assumption is correct.
>=20
> IIUC, there is a strong incentive to create a middlebox that reduces
> retransmissions in the mobile networks, since it enables mobile
> operators to have more customers connected to each base station. For
> example, =
https://www.sandvine.com/hubfs/downloads/archive/whitepaper-tcp-optimizati=
on-opportunities-kpis-and-considerations.pdf
> p. 13 claims 5% network efficiency gain by middleboxes intervening TCP
> retransmissions.

That such middleboxes will emerge for QUIC, though, is an assumption =
that is (1) not testable and (2) IMO not credible. The analogy to TCP =
ossification is a compelling one, but one must remember that *all* of =
these features emerged to operate on TCP traffic because they improved =
performance in the cases for which they were deployed. The problem only =
emerges because (1) the Internet is global, and paths may also contain =
links for which the optimizations are harmful to performance or correct =
operation and/or (2) they interfere with attempts to change the stack at =
the endpoints.

> It makes me understand that there is certain amount of money on table
> that could be enough to do complicated things in the middlebox.
>=20
> Note also that people working on such optimizations have the incentive
> to take advantage of every aspect of how the majority of the QUIC
> traffic they see look like, rather than respecting what the senders
> are theoretically allowed to do.

The assumption that such middleboxes will emerge for QUIC requires that =
there be an in-network operation that a middlebox can do involving =
manipulating the packet stream based on the packet number that will =
improve performance in local testing under some network conditions. If =
that is the case, we have not designed the protocol correctly. I don't =
think it will be: reordering-correction causes HoL, which shows up in =
the performance numbers. Attempts at ACK coalescing will reduce total =
throughput by inducing lost frames. So even in initial prototyping these =
functions will appear locally inferior.

If people want to deploy stuff on their networks that reduces =
performance for their customers, we as protocol designers cannot stop =
them. But here I think local (networks that work) and global (networks =
that aren't ossified) interests align nicely... IOW the "minority" of =
flows that packet stream manipulation will noticeably degrade is a big =
enough minority that it gets noticed.

IMO the only credible packet stream modification function which could =
emerge based on a packet number with known semantics is "window =
correction"; i.e. an attempt to reject UDP garbage that looks kind of =
like QUIC by analyzing the "window" of allowable packet numbers, and =
dropping packets outside that window. Packet number discontinuities =
would break this one, too, but I can see that "feature" making it past =
the alpha stage, at least. If that's the failure model, I'll note that =
schemes that permute the low bits while keeping the high bits won't =
defend well against it...

>> An obnoxious middlebox can always drop all QUIC traffic
>> and force fallback to TCP.
>=20
> Yes.
>=20
> I believe that the signal that we need to send to people interesting
> in "optimizing" QUIC in the middle is that they should either decide
> not to (by possibly dropping QUIC entirely), or to cooperate with the
> protocol designers in optimizing QUIC for their needs without causing
> ossification.

I agree with this statement completely.

> IMO PNE is a good signal in that respect.

If the signal you mean here is "hello middlebox, the packet number is =
not for you", then I tend to agree. I think we should find the best =
tradeoff between implementation/runtime/deployability cost and ability =
to send that signal.

Cheers,

Brian


--Apple-Mail=_F71600AD-54FD-464E-997B-3A14774A39C7
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-----

iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlrNtkoACgkQihK3vwvq
RqOJrBAAuLBcr8pNxU1TjUmY2S0mDrogKM6TMHyBbVg4gDJxAzniPabpstnLjrxg
FNRyPTF+/RaiJHaEFCxVzwQPuNKye+5pKbGWhzXYc9GENc9qhHvJcio1Ei2tPGre
muY+r7nYbp2MYus6b6RzN7w4yjyk0bkIHVEhovRivztqsxV8Xf6A9c2+LbdbVkor
gHLEyOhiDtDL8wMnvbTYmRsAw4Ud2GYS0K7tG6TW03cT3qpkTnk4b1amGrtzFgFf
WFi2Zv5WjvG3NWo9edF43YlZV24/Pu5q6I3siNvkWH1HbsNt3pv7mr6mMKIkzv7r
STWth2YpdacYbhbTX73jVny1zdnXrxABiZFPjaqox+hojkq9BbLrdodsKInipZ4k
3o5NxQAjbWop8NVdm8MLHCNMVd85/7fqlJ1W7c7FRgOkRXSv+7O32GFg7Wx09HiL
Nc1nr7SDS7f7MzaMashdC8skD/3qCXoA3GN27WOHa4WGocIrz69iaQlE0DZjswUH
dxAl4wRE9gbtwrswk0ixnnk60SK/IboccfUl84QMshPZkhLjKApHN6VDzXt4qWuA
XI+G6GrRBCGiuJ/tVg03wUZWyRhnxbX/7KrDjQBZrT+nD/HaGTJr3AHjVawiDz34
Kx5i4Lh2OkM0QqaAGhUTXEcNxBiqS1z3Nwgbuf1g1gDUqCp5DVg=
=J4yF
-----END PGP SIGNATURE-----

--Apple-Mail=_F71600AD-54FD-464E-997B-3A14774A39C7--


From nobody Wed Apr 11 00:52:57 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66096128D2E for ; Wed, 11 Apr 2018 00:52:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523433175; bh=AE7KAAXudRw8Q3jGYoamaW9UZtDtrwmrKrK8ijmqPdo=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=SA+RJNAtGy9p/4saysCJ3G+SVscyojB+X/pCadVU/VoxYEMKMFWcX2Et8iLYm/aLZ dLqe4bEinD4C3kGSeEJ1Xh5B1KZfkFQQT6hnnTL+Pnfx7VHWtvYD1QMA0doyVHCJQI pTN08/e/r7tsM21kSnvRIQrYD5okkqMunoXOArOY=
X-Mailbox-Line: From fenix@fb.com  Wed Apr 11 00:52:55 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A513124235; Wed, 11 Apr 2018 00:52:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523433175; bh=AE7KAAXudRw8Q3jGYoamaW9UZtDtrwmrKrK8ijmqPdo=; h=From:CC:Subject:Date:References:In-Reply-To:To:To; b=SA+RJNAtGy9p/4saysCJ3G+SVscyojB+X/pCadVU/VoxYEMKMFWcX2Et8iLYm/aLZ dLqe4bEinD4C3kGSeEJ1Xh5B1KZfkFQQT6hnnTL+Pnfx7VHWtvYD1QMA0doyVHCJQI pTN08/e/r7tsM21kSnvRIQrYD5okkqMunoXOArOY=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E464412778E for ; Wed, 11 Apr 2018 00:52:54 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=KPF7jj/x; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=KQUnXnvb
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5RAWb5uRZto for ; Wed, 11 Apr 2018 00:52:52 -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 E669C124235 for ; Wed, 11 Apr 2018 00:52:52 -0700 (PDT)
Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3B7mKTq024521; Wed, 11 Apr 2018 00:52:52 -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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=AE7KAAXudRw8Q3jGYoamaW9UZtDtrwmrKrK8ijmqPdo=; b=KPF7jj/x2aCUm7ip2klKUlwTEGArEAv04iKeGLclRfs/zsfp/DPL9SQuomiVNizwE+Ku lcN1XcD645KQ5uEIfmWV5KKReoM08NLF8rkg7c5aq4ysDggb+JJfo2ESZOTrr1uwz1Hg YMZjeog+48tksajGUnpQIjJ5OIDqs7ot4so= 
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2h9dtsr26t-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Apr 2018 00:52:52 -0700
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.19) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 11 Apr 2018 00:52:50 -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=AE7KAAXudRw8Q3jGYoamaW9UZtDtrwmrKrK8ijmqPdo=; b=KQUnXnvb/XlToW4GYmvx3WMk7N/5/pbYGI/SKg0MLT6aKTetg/PUamRPi8BhX+Ar/tmJrseASR2w2AIgQ6y4OV/EHkAxf01pKgI3nMBFzNx7C/hW17iXnz6LBT5G7ajy0ev2lVTejpHrm6VOLiyBsRMyOGPmmDEVMqAYZRE5OPU=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0424.namprd15.prod.outlook.com (10.163.109.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Wed, 11 Apr 2018 07:52:47 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::78a6:3a7a:1195:dd02]) by BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::78a6:3a7a:1195:dd02%13]) with mapi id 15.20.0653.018; Wed, 11 Apr 2018 07:52:47 +0000
From: Roberto Peon 
CC: Victor Vasiliev , IETF QUIC WG , "Ryan Hamilton" 
Subject: Re: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAuyyQD//+5tAA==
Date: Wed, 11 Apr 2018 07:52:47 +0000
Message-ID: <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
References:      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.a.0.180210
x-originating-ip: [70.103.56.2]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0424; 7:tvDPvLElJr7zCIpZWNaNWAh/XL0GANRNko0IshJhfIGSKD9ZCk+magaRFy7rVCymdvMSaasMx48aT6Kt+n8hJu0cRM5f5MaQXjw8h/aWEEjbwHJuN77dPb5fYTbmmpsThZTIo9Z/bk2f8D5WOfUm+pieh7Q6dso/piZcvj/JSwXzTpBDerzFSl+xTkTrA5Vatqy+eQjvSCPJT3CVmS8A2EVepzWg49CRrHKEZJX35wc0U3LA2ZlfXhgW8K29yGBc; 20:R9PlbdaOJ11I/9iQqnPWv/lma2ixH7Ee5AI7cq4C+FnsLtJIULPmKRvMrK+wgtXHzftIMw7Z2/ybqCgg5vL/j/aLwuo+2yjslFbzilTbiEnHGpaBDqt8mayJqJ4O2kiaUGZjf+rs87qrZKGw0RmVpxM4DUM36RdMg03YTXVTTXk=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR15MB0424; 
x-ms-traffictypediagnostic: BY2PR15MB0424:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(89211679590171)(192374486261705)(85827821059158)(15185016700835)(211936372134217)(153496737603132);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231221)(11241501184)(944501327)(52105095)(93006095)(93001095)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:BY2PR15MB0424; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0424; 
x-forefront-prvs: 0639027A9E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(39860400002)(366004)(346002)(376002)(377424004)(189003)(199004)(39060400002)(5250100002)(33656002)(6116002)(66066001)(6306002)(6512007)(53936002)(97736004)(6486002)(229853002)(25786009)(4326008)(6506007)(59450400001)(102836004)(110136005)(76176011)(6246003)(478600001)(99286004)(186003)(6436002)(54906003)(26005)(58126008)(5660300001)(476003)(316002)(7736002)(8676002)(2906002)(83716003)(81156014)(446003)(2616005)(486006)(93886005)(105586002)(36756003)(106356001)(3660700001)(81166006)(82746002)(305945005)(2900100001)(3280700002)(3846002)(575784001)(68736007)(966005)(86362001)(11346002)(14454004)(53546011)(8936002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0424; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 9oEhUlWcKu+beuIwsLXZiZkundnYniBgdUEJ0eBHGyCYn/N4RKsefEG8H8xWrbTzN76aQfAKX/lkqqmdXUx3S7hLar3+RBIyFvDTCxLOC2KWPWQ+1dXBPjwj38b/H/984054GUFKHt0G5Jb9NiMEIOyasf6yR2qkYOz2PBUDdutQ7+1t2Na5Rjr1if8Xa53eicvaK77TAmmPTkJjWe0JxNLxaYtr+7mv0l00LKlMJi8xvTWeUiXWDYeznXAHOz3zICEvOC6H8nRR15FYJnceygzGdWsLwmHhYyXCLVdhgk80pTqFygonJCkU6vffqz4z/04Aj8WTs+G5W2rZmnTessSo/2CygOpSLtUmJ8sror2m5HckZ6WB5p6UzjjFUrnC9Tf/wafTToEVo8WT71xDyKc6QfzxTAnveM5snGiHb1E=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <2B75F8B6AF923948B2D89FFC27793227@namprd15.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 3e6ada80-47bf-4005-3a00-08d59f8137db
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e6ada80-47bf-4005-3a00-08d59f8137db
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 07:52:47.7786 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0424
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_04:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
To: Kazuho Oku 
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 07:52:55 -0000

DQorKyBLYXp1aG8ncyBvYnNlcnZhdGlvbiB0aGF0IHRoZXJlIGlzIGluY2VudGl2ZSB0byBiZSBo
ZWxwZnVsLiBJIGNhbid0IHRoaW5rIG9mIGFueSBvZiB0aGUgb3NzaWZpY2F0aW9uIHdlIHJhbiBp
bnRvIHdpdGggVENQIHRoYXQgd2Fzbid0IGRvbmUgd2l0aCB0aGUgaW50ZW50IHRvIGJlIGhlbHBm
dWwvcHJvdmlkZSB2YWx1ZS4gSXQgcHJvYmFibHkgZGlkIGFjaGlldmUgdGhhdCBzaG9ydC10ZXJt
LCBhdCB0aGUgY29zdCBvZiBtdWNoIGxvbmctdGVybSB2YWx1ZS4NCi09Ug0KDQrvu79PbiA0LzEw
LzE4LCA2OjU2IFBNLCAiUVVJQyBvbiBiZWhhbGYgb2YgS2F6dWhvIE9rdSIgPHF1aWMtYm91bmNl
c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga2F6dWhvb2t1QGdtYWlsLmNvbT4gd3JvdGU6DQoNCiAg
ICAyMDE4LTA0LTExIDc6MzYgR01UKzA5OjAwIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQogICAg
PHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz46DQogICAgPiBObyBJIGFtIG5v
dCBjb25jZXJuZWQuIEFsc28gaXQgaXMgc3BlY3VsYXRpb24gdGhhdCBhIG1pZGRsZWJveCBjYW4g
YWN0dWFsbHkNCiAgICA+IGRvIHRoaXMgd2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUgd2hlcmUgZWFj
aCBpbXBsZW1lbnRhdGlvbiBpcyBmcmVlIHRvIHBpY2sNCiAgICA+IHRoZSBQUk5HLCB0aGUgc2h1
ZmZsZSBhbGdvcml0aG0sIGFuZCBjaGFuZ2UgaXQgb3ZlciB0aW1lLiBJbXBsZW1lbnRhdGlvbnMN
CiAgICA+IGNhbiBhbHNvIHNlZWQgdGhlIFBSTkcgZm9yIGVhY2ggY29ubmVjdGlvbi4NCiAgICA+
DQogICAgPg0KICAgID4NCiAgICA+IE1pZGRsZWJveGVzIG5lZWQgdG8gb3BlcmF0ZSBhdCBsaW5l
IHJhdGUgYW5kIGNhbm5vdCBkbyBhbnkgZXhwZW5zaXZlDQogICAgPiBvcGVyYXRpb25zIGFuZCBh
bnkgZ3Vlc3NlZCByZW9yZGVyaW5nIHdpbGwgbWFrZSB0aGluZ3MgZXZlbiB3b3JzZQ0KICAgID4g
cGVyZm9ybWFuY2Ugd2lzZS4NCiAgICANCiAgICBJIGFtIG5vdCBzdXJlIGlmIHRoYXQgYXNzdW1w
dGlvbiBpcyBjb3JyZWN0Lg0KICAgIA0KICAgIElJVUMsIHRoZXJlIGlzIGEgc3Ryb25nIGluY2Vu
dGl2ZSB0byBjcmVhdGUgYSBtaWRkbGVib3ggdGhhdCByZWR1Y2VzDQogICAgcmV0cmFuc21pc3Np
b25zIGluIHRoZSBtb2JpbGUgbmV0d29ya3MsIHNpbmNlIGl0IGVuYWJsZXMgbW9iaWxlDQogICAg
b3BlcmF0b3JzIHRvIGhhdmUgbW9yZSBjdXN0b21lcnMgY29ubmVjdGVkIHRvIGVhY2ggYmFzZSBz
dGF0aW9uLiBGb3INCiAgICBleGFtcGxlLCBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5zYW5kdmluZS5jb21faHViZnNfZG93bmxvYWRzX2Fy
Y2hpdmVfd2hpdGVwYXBlci0yRHRjcC0yRG9wdGltaXphdGlvbi0yRG9wcG9ydHVuaXRpZXMtMkRr
cGlzLTJEYW5kLTJEY29uc2lkZXJhdGlvbnMucGRmJmQ9RHdJRmFRJmM9NVZEMFJUdE5sVGgzeWNk
NDFiM01VdyZyPUMwc1VvLUxGTkJhWWZ5b2FDc2Y2VEEmbT1lNmdONUhNWFA3SDFqdmN3dkxiR1VQ
amN2OG9ETXFhZDh4YS1YMHFodkt3JnM9c2hlNzhCTWVPd0s0ZXFSM0lEVWRaRHNTN0oxRTU1Q216
OUxtUjhURE1kbyZlPQ0KICAgIHAuIDEzIGNsYWltcyA1JSBuZXR3b3JrIGVmZmljaWVuY3kgZ2Fp
biBieSBtaWRkbGVib3hlcyBpbnRlcnZlbmluZyBUQ1ANCiAgICByZXRyYW5zbWlzc2lvbnMuDQog
ICAgDQogICAgSXQgbWFrZXMgbWUgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGlzIGNlcnRhaW4gYW1v
dW50IG9mIG1vbmV5IG9uIHRhYmxlDQogICAgdGhhdCBjb3VsZCBiZSBlbm91Z2ggdG8gZG8gY29t
cGxpY2F0ZWQgdGhpbmdzIGluIHRoZSBtaWRkbGVib3guDQogICAgDQogICAgTm90ZSBhbHNvIHRo
YXQgcGVvcGxlIHdvcmtpbmcgb24gc3VjaCBvcHRpbWl6YXRpb25zIGhhdmUgdGhlIGluY2VudGl2
ZQ0KICAgIHRvIHRha2UgYWR2YW50YWdlIG9mIGV2ZXJ5IGFzcGVjdCBvZiBob3cgdGhlIG1ham9y
aXR5IG9mIHRoZSBRVUlDDQogICAgdHJhZmZpYyB0aGV5IHNlZSBsb29rIGxpa2UsIHJhdGhlciB0
aGFuIHJlc3BlY3Rpbmcgd2hhdCB0aGUgc2VuZGVycw0KICAgIGFyZSB0aGVvcmV0aWNhbGx5IGFs
bG93ZWQgdG8gZG8uDQogICAgDQogICAgPiBBbiBvYm5veGlvdXMgbWlkZGxlYm94IGNhbiBhbHdh
eXMgZHJvcCBhbGwgUVVJQyB0cmFmZmljDQogICAgPiBhbmQgZm9yY2UgZmFsbGJhY2sgdG8gVENQ
Lg0KICAgIA0KICAgIFllcy4NCiAgICANCiAgICBJIGJlbGlldmUgdGhhdCB0aGUgc2lnbmFsIHRo
YXQgd2UgbmVlZCB0byBzZW5kIHRvIHBlb3BsZSBpbnRlcmVzdGluZw0KICAgIGluICJvcHRpbWl6
aW5nIiBRVUlDIGluIHRoZSBtaWRkbGUgaXMgdGhhdCB0aGV5IHNob3VsZCBlaXRoZXIgZGVjaWRl
DQogICAgbm90IHRvIChieSBwb3NzaWJseSBkcm9wcGluZyBRVUlDIGVudGlyZWx5KSwgb3IgdG8g
Y29vcGVyYXRlIHdpdGggdGhlDQogICAgcHJvdG9jb2wgZGVzaWduZXJzIGluIG9wdGltaXppbmcg
UVVJQyBmb3IgdGhlaXIgbmVlZHMgd2l0aG91dCBjYXVzaW5nDQogICAgb3NzaWZpY2F0aW9uLg0K
ICAgIA0KICAgIElNTyBQTkUgaXMgYSBnb29kIHNpZ25hbCBpbiB0aGF0IHJlc3BlY3QuDQogICAg
DQogICAgPiBPbmUgY2FuIGNvbnN0cnVjdCBiYWQgbWlkZGxlYm94IGJlaGF2aW9yIG9uIGENCiAg
ICA+IHdpZGUgc3BlY3RydW0uIE9uZSBjYW4gYWxzbyBkZXNpZ24gb3NzaWZpY2F0aW9uIHByZXZl
bnRpb24gc29sdXRpb25zIHRoYXQNCiAgICA+IG1ha2UgZW5kcG9pbnRzIGRvIGVpdGhlciB2ZXJ5
IGxpdHRsZSB3b3JrIG9yIGEgbG90IG9mIHdvcmsuIFRoZXJlIGFyZQ0KICAgID4gdHJhZGUtb2Zm
cy4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+IFRoZSBnb2FsIGhlcmUgd2FzIHRvIGV4cGxv
cmUgYSBsb3cgQ1BVIGNvc3QgdHJhbnNmb3JtIHRoYXQgY2FuIGRvIGJldHRlcg0KICAgID4gZ3Jl
YXNpbmcgb2YgdGhlIGZpZWxkIHdpdGggbm8gbW9ub3RvbmljIGluY3JlYXNlLCBzcGVjaWZpY2Fs
bHkgdG8gcHJldmVudA0KICAgID4gZHVtYiBtaWRkbGVib3hlcyBmcm9tIHRyZWF0aW5nIHRoZSBu
b25jZSBhcyBhIHNlcXVlbmNlIG51bWJlci4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+IEZy
b206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSeWFu
IEhhbWlsdG9uDQogICAgPiBTZW50OiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxOCAxOjIwIFBNDQog
ICAgPiBUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+DQog
ICAgPiBDYzogVmljdG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBJRVRGIFFVSUMg
V0cgPHF1aWNAaWV0Zi5vcmc+DQogICAgPiBTdWJqZWN0OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBm
b3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uDQogICAgPg0KICAgID4NCiAg
ICA+DQogICAgPiBPbiBUdWUsIEFwciAxMCwgMjAxOCBhdCA5OjM3IEFNLCBQcmF2ZWVuIEJhbGFz
dWJyYW1hbmlhbg0KICAgID4gPHByYXZiPTQwbWljcm9zb2Z0Li4uY29tQGRtYXJjLmlldGYub3Jn
PiB3cm90ZToNCiAgICA+DQogICAgPiBXaXRoIHRoZSBzaHVmZmxlIHNjaGVtZSwgaWYgYSBtaWRk
bGVib3ggd2FudHMgdG8gZ28gb3V0IG9mIGl0cyB3YXkgdG8gZG8NCiAgICA+IGFuYWx5c2lzIHRv
IGJyZWFrIGEgUFJORyBhbmQgZmluZCB0aGUgcGFja2V0IG51bWJlciBpdCBjYW4uIFRoZSBzY2hl
bWUgaXMNCiAgICA+IG5vdCBldmVuIHJlcXVpcmluZyBhIHNlY3VyZSByYW5kb20gbnVtYmVyLiBU
aGUgZ29hbCBpcyBub3QgdG8gcHJvdmlkZSBhbnkNCiAgICA+IHNlY3VyaXR5IGFyb3VuZCBQTiwg
anVzdCBwcmV2ZW50IG9zc2lmaWNhdGlvbiBieSBkdW1iIG1pZGRsZWJveGVzIHRoYXQNCiAgICA+
IGFzc3VtZSB0aGUgbm9uY2UgaXMgYSBzZXF1ZW5jZSBudW1iZXIgYW5kIHRyeSB0byByZW9yZGVy
LiBJIGRvbuKAmXQgc2VlIGFueQ0KICAgID4gaGFybSBpZiBjb3N0bHkgYW5hbHlzaXMgY2FuIGFs
bG93IG9uIHBhdGggZGV0ZXJtaW5hdGlvbiBvZiBwYWNrZXQgbnVtYmVycy4uDQogICAgPg0KICAg
ID4NCiAgICA+DQogICAgPiBBcmUgeW91IGNvbmNlcm5lZCBhYm91dCAiaGVscGZ1bCIgbWlkZGxl
Ym94IHdoaWNoIGFyZSB3aWxsaW5nIHRvIGV4cGVuZCB0aGUNCiAgICA+IHJlc291cmNlcyB0byBk
byBjb3N0bHkgYW5hbHlzaXMgaW4gb3JkZXIgdG8gInJlcGFpciIgcGFja2V0IHJlb3JkZXIgKGFu
ZA0KICAgID4gY29uc2VxdWVudGx5IGludHJvZHVjZSBIT0wgYmxvY2tpbmcpDQogICAgPg0KICAg
ID4NCiAgICANCiAgICANCiAgICANCiAgICAtLSANCiAgICBLYXp1aG8gT2t1DQogICAgDQogICAg
DQoNCg==


From nobody Wed Apr 11 00:53:06 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2515C12D948 for ; Wed, 11 Apr 2018 00:52:57 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=KPF7jj/x; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=KQUnXnvb
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UG9lPeF7e1rP for ; Wed, 11 Apr 2018 00:52:55 -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 911C4124235 for ; Wed, 11 Apr 2018 00:52:55 -0700 (PDT)
Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3B7mKTq024521; Wed, 11 Apr 2018 00:52:52 -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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=AE7KAAXudRw8Q3jGYoamaW9UZtDtrwmrKrK8ijmqPdo=; b=KPF7jj/x2aCUm7ip2klKUlwTEGArEAv04iKeGLclRfs/zsfp/DPL9SQuomiVNizwE+Ku lcN1XcD645KQ5uEIfmWV5KKReoM08NLF8rkg7c5aq4ysDggb+JJfo2ESZOTrr1uwz1Hg YMZjeog+48tksajGUnpQIjJ5OIDqs7ot4so= 
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2h9dtsr26t-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Apr 2018 00:52:52 -0700
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.19) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 11 Apr 2018 00:52:50 -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=AE7KAAXudRw8Q3jGYoamaW9UZtDtrwmrKrK8ijmqPdo=; b=KQUnXnvb/XlToW4GYmvx3WMk7N/5/pbYGI/SKg0MLT6aKTetg/PUamRPi8BhX+Ar/tmJrseASR2w2AIgQ6y4OV/EHkAxf01pKgI3nMBFzNx7C/hW17iXnz6LBT5G7ajy0ev2lVTejpHrm6VOLiyBsRMyOGPmmDEVMqAYZRE5OPU=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0424.namprd15.prod.outlook.com (10.163.109.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Wed, 11 Apr 2018 07:52:47 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::78a6:3a7a:1195:dd02]) by BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::78a6:3a7a:1195:dd02%13]) with mapi id 15.20.0653.018; Wed, 11 Apr 2018 07:52:47 +0000
From: Roberto Peon 
To: Kazuho Oku , Praveen Balasubramanian 
CC: Victor Vasiliev , IETF QUIC WG , "Ryan Hamilton" 
Subject: Re: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAuyyQD//+5tAA==
Date: Wed, 11 Apr 2018 07:52:47 +0000
Message-ID: <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
References:      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.a.0.180210
x-originating-ip: [70.103.56.2]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0424; 7:tvDPvLElJr7zCIpZWNaNWAh/XL0GANRNko0IshJhfIGSKD9ZCk+magaRFy7rVCymdvMSaasMx48aT6Kt+n8hJu0cRM5f5MaQXjw8h/aWEEjbwHJuN77dPb5fYTbmmpsThZTIo9Z/bk2f8D5WOfUm+pieh7Q6dso/piZcvj/JSwXzTpBDerzFSl+xTkTrA5Vatqy+eQjvSCPJT3CVmS8A2EVepzWg49CRrHKEZJX35wc0U3LA2ZlfXhgW8K29yGBc; 20:R9PlbdaOJ11I/9iQqnPWv/lma2ixH7Ee5AI7cq4C+FnsLtJIULPmKRvMrK+wgtXHzftIMw7Z2/ybqCgg5vL/j/aLwuo+2yjslFbzilTbiEnHGpaBDqt8mayJqJ4O2kiaUGZjf+rs87qrZKGw0RmVpxM4DUM36RdMg03YTXVTTXk=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR15MB0424; 
x-ms-traffictypediagnostic: BY2PR15MB0424:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(89211679590171)(192374486261705)(85827821059158)(15185016700835)(211936372134217)(153496737603132);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231221)(11241501184)(944501327)(52105095)(93006095)(93001095)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:BY2PR15MB0424; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0424; 
x-forefront-prvs: 0639027A9E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(39860400002)(366004)(346002)(376002)(377424004)(189003)(199004)(39060400002)(5250100002)(33656002)(6116002)(66066001)(6306002)(6512007)(53936002)(97736004)(6486002)(229853002)(25786009)(4326008)(6506007)(59450400001)(102836004)(110136005)(76176011)(6246003)(478600001)(99286004)(186003)(6436002)(54906003)(26005)(58126008)(5660300001)(476003)(316002)(7736002)(8676002)(2906002)(83716003)(81156014)(446003)(2616005)(486006)(93886005)(105586002)(36756003)(106356001)(3660700001)(81166006)(82746002)(305945005)(2900100001)(3280700002)(3846002)(575784001)(68736007)(966005)(86362001)(11346002)(14454004)(53546011)(8936002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0424; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 9oEhUlWcKu+beuIwsLXZiZkundnYniBgdUEJ0eBHGyCYn/N4RKsefEG8H8xWrbTzN76aQfAKX/lkqqmdXUx3S7hLar3+RBIyFvDTCxLOC2KWPWQ+1dXBPjwj38b/H/984054GUFKHt0G5Jb9NiMEIOyasf6yR2qkYOz2PBUDdutQ7+1t2Na5Rjr1if8Xa53eicvaK77TAmmPTkJjWe0JxNLxaYtr+7mv0l00LKlMJi8xvTWeUiXWDYeznXAHOz3zICEvOC6H8nRR15FYJnceygzGdWsLwmHhYyXCLVdhgk80pTqFygonJCkU6vffqz4z/04Aj8WTs+G5W2rZmnTessSo/2CygOpSLtUmJ8sror2m5HckZ6WB5p6UzjjFUrnC9Tf/wafTToEVo8WT71xDyKc6QfzxTAnveM5snGiHb1E=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <2B75F8B6AF923948B2D89FFC27793227@namprd15.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 3e6ada80-47bf-4005-3a00-08d59f8137db
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e6ada80-47bf-4005-3a00-08d59f8137db
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 07:52:47.7786 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0424
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_04:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Apr 2018 07:52:58 -0000

DQorKyBLYXp1aG8ncyBvYnNlcnZhdGlvbiB0aGF0IHRoZXJlIGlzIGluY2VudGl2ZSB0byBiZSBo
ZWxwZnVsLiBJIGNhbid0IHRoaW5rIG9mIGFueSBvZiB0aGUgb3NzaWZpY2F0aW9uIHdlIHJhbiBp
bnRvIHdpdGggVENQIHRoYXQgd2Fzbid0IGRvbmUgd2l0aCB0aGUgaW50ZW50IHRvIGJlIGhlbHBm
dWwvcHJvdmlkZSB2YWx1ZS4gSXQgcHJvYmFibHkgZGlkIGFjaGlldmUgdGhhdCBzaG9ydC10ZXJt
LCBhdCB0aGUgY29zdCBvZiBtdWNoIGxvbmctdGVybSB2YWx1ZS4NCi09Ug0KDQrvu79PbiA0LzEw
LzE4LCA2OjU2IFBNLCAiUVVJQyBvbiBiZWhhbGYgb2YgS2F6dWhvIE9rdSIgPHF1aWMtYm91bmNl
c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga2F6dWhvb2t1QGdtYWlsLmNvbT4gd3JvdGU6DQoNCiAg
ICAyMDE4LTA0LTExIDc6MzYgR01UKzA5OjAwIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQogICAg
PHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz46DQogICAgPiBObyBJIGFtIG5v
dCBjb25jZXJuZWQuIEFsc28gaXQgaXMgc3BlY3VsYXRpb24gdGhhdCBhIG1pZGRsZWJveCBjYW4g
YWN0dWFsbHkNCiAgICA+IGRvIHRoaXMgd2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUgd2hlcmUgZWFj
aCBpbXBsZW1lbnRhdGlvbiBpcyBmcmVlIHRvIHBpY2sNCiAgICA+IHRoZSBQUk5HLCB0aGUgc2h1
ZmZsZSBhbGdvcml0aG0sIGFuZCBjaGFuZ2UgaXQgb3ZlciB0aW1lLiBJbXBsZW1lbnRhdGlvbnMN
CiAgICA+IGNhbiBhbHNvIHNlZWQgdGhlIFBSTkcgZm9yIGVhY2ggY29ubmVjdGlvbi4NCiAgICA+
DQogICAgPg0KICAgID4NCiAgICA+IE1pZGRsZWJveGVzIG5lZWQgdG8gb3BlcmF0ZSBhdCBsaW5l
IHJhdGUgYW5kIGNhbm5vdCBkbyBhbnkgZXhwZW5zaXZlDQogICAgPiBvcGVyYXRpb25zIGFuZCBh
bnkgZ3Vlc3NlZCByZW9yZGVyaW5nIHdpbGwgbWFrZSB0aGluZ3MgZXZlbiB3b3JzZQ0KICAgID4g
cGVyZm9ybWFuY2Ugd2lzZS4NCiAgICANCiAgICBJIGFtIG5vdCBzdXJlIGlmIHRoYXQgYXNzdW1w
dGlvbiBpcyBjb3JyZWN0Lg0KICAgIA0KICAgIElJVUMsIHRoZXJlIGlzIGEgc3Ryb25nIGluY2Vu
dGl2ZSB0byBjcmVhdGUgYSBtaWRkbGVib3ggdGhhdCByZWR1Y2VzDQogICAgcmV0cmFuc21pc3Np
b25zIGluIHRoZSBtb2JpbGUgbmV0d29ya3MsIHNpbmNlIGl0IGVuYWJsZXMgbW9iaWxlDQogICAg
b3BlcmF0b3JzIHRvIGhhdmUgbW9yZSBjdXN0b21lcnMgY29ubmVjdGVkIHRvIGVhY2ggYmFzZSBz
dGF0aW9uLiBGb3INCiAgICBleGFtcGxlLCBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5zYW5kdmluZS5jb21faHViZnNfZG93bmxvYWRzX2Fy
Y2hpdmVfd2hpdGVwYXBlci0yRHRjcC0yRG9wdGltaXphdGlvbi0yRG9wcG9ydHVuaXRpZXMtMkRr
cGlzLTJEYW5kLTJEY29uc2lkZXJhdGlvbnMucGRmJmQ9RHdJRmFRJmM9NVZEMFJUdE5sVGgzeWNk
NDFiM01VdyZyPUMwc1VvLUxGTkJhWWZ5b2FDc2Y2VEEmbT1lNmdONUhNWFA3SDFqdmN3dkxiR1VQ
amN2OG9ETXFhZDh4YS1YMHFodkt3JnM9c2hlNzhCTWVPd0s0ZXFSM0lEVWRaRHNTN0oxRTU1Q216
OUxtUjhURE1kbyZlPQ0KICAgIHAuIDEzIGNsYWltcyA1JSBuZXR3b3JrIGVmZmljaWVuY3kgZ2Fp
biBieSBtaWRkbGVib3hlcyBpbnRlcnZlbmluZyBUQ1ANCiAgICByZXRyYW5zbWlzc2lvbnMuDQog
ICAgDQogICAgSXQgbWFrZXMgbWUgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGlzIGNlcnRhaW4gYW1v
dW50IG9mIG1vbmV5IG9uIHRhYmxlDQogICAgdGhhdCBjb3VsZCBiZSBlbm91Z2ggdG8gZG8gY29t
cGxpY2F0ZWQgdGhpbmdzIGluIHRoZSBtaWRkbGVib3guDQogICAgDQogICAgTm90ZSBhbHNvIHRo
YXQgcGVvcGxlIHdvcmtpbmcgb24gc3VjaCBvcHRpbWl6YXRpb25zIGhhdmUgdGhlIGluY2VudGl2
ZQ0KICAgIHRvIHRha2UgYWR2YW50YWdlIG9mIGV2ZXJ5IGFzcGVjdCBvZiBob3cgdGhlIG1ham9y
aXR5IG9mIHRoZSBRVUlDDQogICAgdHJhZmZpYyB0aGV5IHNlZSBsb29rIGxpa2UsIHJhdGhlciB0
aGFuIHJlc3BlY3Rpbmcgd2hhdCB0aGUgc2VuZGVycw0KICAgIGFyZSB0aGVvcmV0aWNhbGx5IGFs
bG93ZWQgdG8gZG8uDQogICAgDQogICAgPiBBbiBvYm5veGlvdXMgbWlkZGxlYm94IGNhbiBhbHdh
eXMgZHJvcCBhbGwgUVVJQyB0cmFmZmljDQogICAgPiBhbmQgZm9yY2UgZmFsbGJhY2sgdG8gVENQ
Lg0KICAgIA0KICAgIFllcy4NCiAgICANCiAgICBJIGJlbGlldmUgdGhhdCB0aGUgc2lnbmFsIHRo
YXQgd2UgbmVlZCB0byBzZW5kIHRvIHBlb3BsZSBpbnRlcmVzdGluZw0KICAgIGluICJvcHRpbWl6
aW5nIiBRVUlDIGluIHRoZSBtaWRkbGUgaXMgdGhhdCB0aGV5IHNob3VsZCBlaXRoZXIgZGVjaWRl
DQogICAgbm90IHRvIChieSBwb3NzaWJseSBkcm9wcGluZyBRVUlDIGVudGlyZWx5KSwgb3IgdG8g
Y29vcGVyYXRlIHdpdGggdGhlDQogICAgcHJvdG9jb2wgZGVzaWduZXJzIGluIG9wdGltaXppbmcg
UVVJQyBmb3IgdGhlaXIgbmVlZHMgd2l0aG91dCBjYXVzaW5nDQogICAgb3NzaWZpY2F0aW9uLg0K
ICAgIA0KICAgIElNTyBQTkUgaXMgYSBnb29kIHNpZ25hbCBpbiB0aGF0IHJlc3BlY3QuDQogICAg
DQogICAgPiBPbmUgY2FuIGNvbnN0cnVjdCBiYWQgbWlkZGxlYm94IGJlaGF2aW9yIG9uIGENCiAg
ICA+IHdpZGUgc3BlY3RydW0uIE9uZSBjYW4gYWxzbyBkZXNpZ24gb3NzaWZpY2F0aW9uIHByZXZl
bnRpb24gc29sdXRpb25zIHRoYXQNCiAgICA+IG1ha2UgZW5kcG9pbnRzIGRvIGVpdGhlciB2ZXJ5
IGxpdHRsZSB3b3JrIG9yIGEgbG90IG9mIHdvcmsuIFRoZXJlIGFyZQ0KICAgID4gdHJhZGUtb2Zm
cy4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+IFRoZSBnb2FsIGhlcmUgd2FzIHRvIGV4cGxv
cmUgYSBsb3cgQ1BVIGNvc3QgdHJhbnNmb3JtIHRoYXQgY2FuIGRvIGJldHRlcg0KICAgID4gZ3Jl
YXNpbmcgb2YgdGhlIGZpZWxkIHdpdGggbm8gbW9ub3RvbmljIGluY3JlYXNlLCBzcGVjaWZpY2Fs
bHkgdG8gcHJldmVudA0KICAgID4gZHVtYiBtaWRkbGVib3hlcyBmcm9tIHRyZWF0aW5nIHRoZSBu
b25jZSBhcyBhIHNlcXVlbmNlIG51bWJlci4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+IEZy
b206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSeWFu
IEhhbWlsdG9uDQogICAgPiBTZW50OiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxOCAxOjIwIFBNDQog
ICAgPiBUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+DQog
ICAgPiBDYzogVmljdG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBJRVRGIFFVSUMg
V0cgPHF1aWNAaWV0Zi5vcmc+DQogICAgPiBTdWJqZWN0OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBm
b3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uDQogICAgPg0KICAgID4NCiAg
ICA+DQogICAgPiBPbiBUdWUsIEFwciAxMCwgMjAxOCBhdCA5OjM3IEFNLCBQcmF2ZWVuIEJhbGFz
dWJyYW1hbmlhbg0KICAgID4gPHByYXZiPTQwbWljcm9zb2Z0Li4uY29tQGRtYXJjLmlldGYub3Jn
PiB3cm90ZToNCiAgICA+DQogICAgPiBXaXRoIHRoZSBzaHVmZmxlIHNjaGVtZSwgaWYgYSBtaWRk
bGVib3ggd2FudHMgdG8gZ28gb3V0IG9mIGl0cyB3YXkgdG8gZG8NCiAgICA+IGFuYWx5c2lzIHRv
IGJyZWFrIGEgUFJORyBhbmQgZmluZCB0aGUgcGFja2V0IG51bWJlciBpdCBjYW4uIFRoZSBzY2hl
bWUgaXMNCiAgICA+IG5vdCBldmVuIHJlcXVpcmluZyBhIHNlY3VyZSByYW5kb20gbnVtYmVyLiBU
aGUgZ29hbCBpcyBub3QgdG8gcHJvdmlkZSBhbnkNCiAgICA+IHNlY3VyaXR5IGFyb3VuZCBQTiwg
anVzdCBwcmV2ZW50IG9zc2lmaWNhdGlvbiBieSBkdW1iIG1pZGRsZWJveGVzIHRoYXQNCiAgICA+
IGFzc3VtZSB0aGUgbm9uY2UgaXMgYSBzZXF1ZW5jZSBudW1iZXIgYW5kIHRyeSB0byByZW9yZGVy
LiBJIGRvbuKAmXQgc2VlIGFueQ0KICAgID4gaGFybSBpZiBjb3N0bHkgYW5hbHlzaXMgY2FuIGFs
bG93IG9uIHBhdGggZGV0ZXJtaW5hdGlvbiBvZiBwYWNrZXQgbnVtYmVycy4uDQogICAgPg0KICAg
ID4NCiAgICA+DQogICAgPiBBcmUgeW91IGNvbmNlcm5lZCBhYm91dCAiaGVscGZ1bCIgbWlkZGxl
Ym94IHdoaWNoIGFyZSB3aWxsaW5nIHRvIGV4cGVuZCB0aGUNCiAgICA+IHJlc291cmNlcyB0byBk
byBjb3N0bHkgYW5hbHlzaXMgaW4gb3JkZXIgdG8gInJlcGFpciIgcGFja2V0IHJlb3JkZXIgKGFu
ZA0KICAgID4gY29uc2VxdWVudGx5IGludHJvZHVjZSBIT0wgYmxvY2tpbmcpDQogICAgPg0KICAg
ID4NCiAgICANCiAgICANCiAgICANCiAgICAtLSANCiAgICBLYXp1aG8gT2t1DQogICAgDQogICAg
DQoNCg==


From nobody Wed Apr 11 01:09:26 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9B9126D85 for ; Wed, 11 Apr 2018 01:09:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 ZndwAW5ixymZ for ; Wed, 11 Apr 2018 01:09:23 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20137.outbound.protection.outlook.com [40.107.2.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 99EBE126B6D for ; Wed, 11 Apr 2018 01:09:22 -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=gxFCJHqHZ8CwIri9QdeT2em5tHlu8ZPAN9/3fu5oCVo=; b=SwbfxJWQ2XTmuqtjJzJExRfjVnl3K5k9vzW65WBKJ2/xjKyX5OqsouE7ZxXgRGD4fAI+kDkklKGJjoXynHjaar9CNoOgIPH6zJ+L1vGkHJp+vJ86oePW7R4yCva4somJSvTWO4LDvkapY9lAeilEcTkjCoJm1Oc9dLPLKKenV6s=
Received: from DB3PR07MB0747.eurprd07.prod.outlook.com (10.160.53.12) by DB3PR07MB0506.eurprd07.prod.outlook.com (10.160.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.4; Wed, 11 Apr 2018 08:09:18 +0000
Received: from DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::f0d7:f43d:bd5b:ab9e]) by DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::f0d7:f43d:bd5b:ab9e%6]) with mapi id 15.20.0675.009; Wed, 11 Apr 2018 08:09:18 +0000
From: "Fossati, Thomas (Nokia - GB/Cambridge)" 
To: Roberto Peon , Kazuho Oku , Praveen Balasubramanian 
CC: Victor Vasiliev , IETF QUIC WG , Ryan Hamilton , "Fossati, Thomas (Nokia - GB/Cambridge)" 
Subject: Re: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAuyyQD//+5tAIAAipkA
Date: Wed, 11 Apr 2018 08:09:15 +0000
Message-ID: 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
In-Reply-To: <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-originating-ip: [92.18.194.109]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB3PR07MB0506; 7:WMNOxYRhHP8YHTHZDf9bATRksMh7+LLjB/zvsmM1pUT7BRVOHrk3PU5LQBQX9i2MmKNXgiUwG/io962nGJdGFZbuA/XalNhNMQgLt4IeJiT7J26u1y7HPIfhkFfTgDMrnH2+EzQa4lJamM1vF3JyS0JvJsA2/rS/zIbB80osD6kP9K0WIs9sys5OFUjWiyvWY2gqNGSJRcAeES2rgAbugVTcWC84XoToOUDgzOcIKDECnOTMB1zvWcx7IeydjOH+
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:DB3PR07MB0506; 
x-ms-traffictypediagnostic: DB3PR07MB0506:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(89211679590171)(192374486261705)(85827821059158)(15185016700835)(67672495146484)(211936372134217)(153496737603132);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231221)(11241501184)(806099)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB3PR07MB0506; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB0506; 
x-forefront-prvs: 0639027A9E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39380400002)(366004)(396003)(39860400002)(346002)(377424004)(189003)(199004)(83716003)(446003)(8666007)(110136005)(316002)(1511001)(3846002)(54906003)(36756003)(102836004)(66066001)(476003)(39060400002)(81166006)(53546011)(6246003)(4326008)(33656002)(5660300001)(58126008)(2616005)(7736002)(107886003)(305945005)(25786009)(97736004)(81156014)(8676002)(6506007)(6306002)(6116002)(11346002)(6512007)(966005)(76176011)(99286004)(6486002)(26005)(478600001)(59450400001)(6436002)(8936002)(93886005)(82746002)(3280700002)(53936002)(186003)(2906002)(2900100001)(3660700001)(105586002)(86362001)(575784001)(14454004)(229853002)(5250100002)(68736007)(106356001)(486006)(6666003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0506; H:DB3PR07MB0747.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: b/n47Gh//Nr2z26rx4LYwPVpO0se0NMutx0f2ZnhAlDbogFnSHU6EwAzg9BtThTPeSf8XfVaypfEch18exB928mYXAxu6aUPlBI2pSIzGNAnhtNgNPqwUI7zpGw19PWl15i0sBWiBOYIiPtZbdPu12Y41LpfYsgckOzXgJruZAGgw6RwvjryDeBgSdbJaI+RIQE0LSCpe3xLKpjj5GVtM1T6BNlO9NKy0LE6QAGfKN4a0LzTlTXdvblgWkYKCu2v2wymsz6RnpgOOUyM8w+jyg094Jiz5/5ivVZ+RSukKzmNpZaqQSldXmMybYt1G7bt/vFBBMhLyiX6j7K2c4ttL5mmydApi3/8A606MJ6PRAsB+ZCY3/Gzng8cO/4rOWC7sVaJKye1fDymOvjDkUXeuqTl08Z92kQs+nv01od3k1XB6z7pHBuHcZPV7+rs0IJ4sagSfKawsxMFXd6YSjCoqw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 4e437ef6-0e52-40fb-dd09-08d59f838647
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4e437ef6-0e52-40fb-dd09-08d59f838647
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 08:09:15.2746 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0506
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 08:09:25 -0000

U3VyZSwgQnJpYW4gaGFzIGEgdmVyeSBnb29kIHBvaW50IHRob3VnaDogd2l0aCBpbnRlZ3JpdHkg
cHJvdGVjdGlvbiBhbGwgb3ZlciB0aGUgcGxhY2UsIGFuICJ1c2VmdWwiIG1pZGRsZS1ib3ggaGFz
IHZlcnkgbGltaXRlZCByb29tIGZvciBtYW5vZXV2cmUuICBUYWtlIGEgbG9vayBhdCBSRkMgMzQ0
OSBhbmQgc2VhcmNoIGZvciAiSVBzZWMgQUgiIHRvIGdldCBhbiBpZGVhIG9mIHRoZSBpbXBhY3Qg
b24gdGhlIGFiaWxpdHkgdG8gaW1wbGVtZW50ICJ1c2VmdWwgZmVhdHVyZXMiIGluIHRoZSBtaWRk
bGUgd2hlbiB0aGUgc3RyZWFtcyBhcmUgaW50ZWdyaXR5IHByb3RlY3RlZCAtIGxldCBhbG9uZSB3
aGVuIHRoZXkgYXJlIGVuY3J5cHRlZC4NCk9zc2lmaWNhdGlvbi13aXNlIHRoZSBhZHZhbnRhZ2Ug
d2UgZ2V0IGZyb20gUE5FIHNlZW1zIG1hcmdpbmFsICh+MD8pIG92ZXIgdGhlIGJpZyB3aW4gd2hp
Y2ggYWxyZWFkeSBjb21lcyBmcm9tIEFFQUQuDQoNCg0KDQrvu79PbiAxMS8wNC8yMDE4LCAwODo1
MywgIlFVSUMgb24gYmVoYWxmIG9mIFJvYmVydG8gUGVvbiIgPHF1aWMtYm91bmNlc0BpZXRmLm9y
ZyBvbiBiZWhhbGYgb2YgZmVuaXhAZmIuY29tPiB3cm90ZToNCg0KDQorKyBLYXp1aG8ncyBvYnNl
cnZhdGlvbiB0aGF0IHRoZXJlIGlzIGluY2VudGl2ZSB0byBiZSBoZWxwZnVsLiBJIGNhbid0IHRo
aW5rIG9mIGFueSBvZiB0aGUgb3NzaWZpY2F0aW9uIHdlIHJhbiBpbnRvIHdpdGggVENQIHRoYXQg
d2Fzbid0IGRvbmUgd2l0aCB0aGUgaW50ZW50IHRvIGJlIGhlbHBmdWwvcHJvdmlkZSB2YWx1ZS4g
SXQgcHJvYmFibHkgZGlkIGFjaGlldmUgdGhhdCBzaG9ydC10ZXJtLCBhdCB0aGUgY29zdCBvZiBt
dWNoIGxvbmctdGVybSB2YWx1ZS4NCi09Ug0KDQpPbiA0LzEwLzE4LCA2OjU2IFBNLCAiUVVJQyBv
biBiZWhhbGYgb2YgS2F6dWhvIE9rdSIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg
b2Yga2F6dWhvb2t1QGdtYWlsLmNvbT4gd3JvdGU6DQoNCiAgICAyMDE4LTA0LTExIDc6MzYgR01U
KzA5OjAwIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQogICAgPHByYXZiPTQwbWljcm9zb2Z0LmNv
bUBkbWFyYy5pZXRmLm9yZz46DQogICAgPiBObyBJIGFtIG5vdCBjb25jZXJuZWQuIEFsc28gaXQg
aXMgc3BlY3VsYXRpb24gdGhhdCBhIG1pZGRsZWJveCBjYW4gYWN0dWFsbHkNCiAgICA+IGRvIHRo
aXMgd2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUgd2hlcmUgZWFjaCBpbXBsZW1lbnRhdGlvbiBpcyBm
cmVlIHRvIHBpY2sNCiAgICA+IHRoZSBQUk5HLCB0aGUgc2h1ZmZsZSBhbGdvcml0aG0sIGFuZCBj
aGFuZ2UgaXQgb3ZlciB0aW1lLiBJbXBsZW1lbnRhdGlvbnMNCiAgICA+IGNhbiBhbHNvIHNlZWQg
dGhlIFBSTkcgZm9yIGVhY2ggY29ubmVjdGlvbi4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+
IE1pZGRsZWJveGVzIG5lZWQgdG8gb3BlcmF0ZSBhdCBsaW5lIHJhdGUgYW5kIGNhbm5vdCBkbyBh
bnkgZXhwZW5zaXZlDQogICAgPiBvcGVyYXRpb25zIGFuZCBhbnkgZ3Vlc3NlZCByZW9yZGVyaW5n
IHdpbGwgbWFrZSB0aGluZ3MgZXZlbiB3b3JzZQ0KICAgID4gcGVyZm9ybWFuY2Ugd2lzZS4NCiAg
ICANCiAgICBJIGFtIG5vdCBzdXJlIGlmIHRoYXQgYXNzdW1wdGlvbiBpcyBjb3JyZWN0Lg0KICAg
IA0KICAgIElJVUMsIHRoZXJlIGlzIGEgc3Ryb25nIGluY2VudGl2ZSB0byBjcmVhdGUgYSBtaWRk
bGVib3ggdGhhdCByZWR1Y2VzDQogICAgcmV0cmFuc21pc3Npb25zIGluIHRoZSBtb2JpbGUgbmV0
d29ya3MsIHNpbmNlIGl0IGVuYWJsZXMgbW9iaWxlDQogICAgb3BlcmF0b3JzIHRvIGhhdmUgbW9y
ZSBjdXN0b21lcnMgY29ubmVjdGVkIHRvIGVhY2ggYmFzZSBzdGF0aW9uLiBGb3INCiAgICBleGFt
cGxlLCBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff
X3d3dy5zYW5kdmluZS5jb21faHViZnNfZG93bmxvYWRzX2FyY2hpdmVfd2hpdGVwYXBlci0yRHRj
cC0yRG9wdGltaXphdGlvbi0yRG9wcG9ydHVuaXRpZXMtMkRrcGlzLTJEYW5kLTJEY29uc2lkZXJh
dGlvbnMucGRmJmQ9RHdJRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPUMwc1VvLUxGTkJh
WWZ5b2FDc2Y2VEEmbT1lNmdONUhNWFA3SDFqdmN3dkxiR1VQamN2OG9ETXFhZDh4YS1YMHFodkt3
JnM9c2hlNzhCTWVPd0s0ZXFSM0lEVWRaRHNTN0oxRTU1Q216OUxtUjhURE1kbyZlPQ0KICAgIHAu
IDEzIGNsYWltcyA1JSBuZXR3b3JrIGVmZmljaWVuY3kgZ2FpbiBieSBtaWRkbGVib3hlcyBpbnRl
cnZlbmluZyBUQ1ANCiAgICByZXRyYW5zbWlzc2lvbnMuDQogICAgDQogICAgSXQgbWFrZXMgbWUg
dW5kZXJzdGFuZCB0aGF0IHRoZXJlIGlzIGNlcnRhaW4gYW1vdW50IG9mIG1vbmV5IG9uIHRhYmxl
DQogICAgdGhhdCBjb3VsZCBiZSBlbm91Z2ggdG8gZG8gY29tcGxpY2F0ZWQgdGhpbmdzIGluIHRo
ZSBtaWRkbGVib3guDQogICAgDQogICAgTm90ZSBhbHNvIHRoYXQgcGVvcGxlIHdvcmtpbmcgb24g
c3VjaCBvcHRpbWl6YXRpb25zIGhhdmUgdGhlIGluY2VudGl2ZQ0KICAgIHRvIHRha2UgYWR2YW50
YWdlIG9mIGV2ZXJ5IGFzcGVjdCBvZiBob3cgdGhlIG1ham9yaXR5IG9mIHRoZSBRVUlDDQogICAg
dHJhZmZpYyB0aGV5IHNlZSBsb29rIGxpa2UsIHJhdGhlciB0aGFuIHJlc3BlY3Rpbmcgd2hhdCB0
aGUgc2VuZGVycw0KICAgIGFyZSB0aGVvcmV0aWNhbGx5IGFsbG93ZWQgdG8gZG8uDQogICAgDQog
ICAgPiBBbiBvYm5veGlvdXMgbWlkZGxlYm94IGNhbiBhbHdheXMgZHJvcCBhbGwgUVVJQyB0cmFm
ZmljDQogICAgPiBhbmQgZm9yY2UgZmFsbGJhY2sgdG8gVENQLg0KICAgIA0KICAgIFllcy4NCiAg
ICANCiAgICBJIGJlbGlldmUgdGhhdCB0aGUgc2lnbmFsIHRoYXQgd2UgbmVlZCB0byBzZW5kIHRv
IHBlb3BsZSBpbnRlcmVzdGluZw0KICAgIGluICJvcHRpbWl6aW5nIiBRVUlDIGluIHRoZSBtaWRk
bGUgaXMgdGhhdCB0aGV5IHNob3VsZCBlaXRoZXIgZGVjaWRlDQogICAgbm90IHRvIChieSBwb3Nz
aWJseSBkcm9wcGluZyBRVUlDIGVudGlyZWx5KSwgb3IgdG8gY29vcGVyYXRlIHdpdGggdGhlDQog
ICAgcHJvdG9jb2wgZGVzaWduZXJzIGluIG9wdGltaXppbmcgUVVJQyBmb3IgdGhlaXIgbmVlZHMg
d2l0aG91dCBjYXVzaW5nDQogICAgb3NzaWZpY2F0aW9uLg0KICAgIA0KICAgIElNTyBQTkUgaXMg
YSBnb29kIHNpZ25hbCBpbiB0aGF0IHJlc3BlY3QuDQogICAgDQogICAgPiBPbmUgY2FuIGNvbnN0
cnVjdCBiYWQgbWlkZGxlYm94IGJlaGF2aW9yIG9uIGENCiAgICA+IHdpZGUgc3BlY3RydW0uIE9u
ZSBjYW4gYWxzbyBkZXNpZ24gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24gc29sdXRpb25zIHRoYXQN
CiAgICA+IG1ha2UgZW5kcG9pbnRzIGRvIGVpdGhlciB2ZXJ5IGxpdHRsZSB3b3JrIG9yIGEgbG90
IG9mIHdvcmsuIFRoZXJlIGFyZQ0KICAgID4gdHJhZGUtb2Zmcy4NCiAgICA+DQogICAgPg0KICAg
ID4NCiAgICA+IFRoZSBnb2FsIGhlcmUgd2FzIHRvIGV4cGxvcmUgYSBsb3cgQ1BVIGNvc3QgdHJh
bnNmb3JtIHRoYXQgY2FuIGRvIGJldHRlcg0KICAgID4gZ3JlYXNpbmcgb2YgdGhlIGZpZWxkIHdp
dGggbm8gbW9ub3RvbmljIGluY3JlYXNlLCBzcGVjaWZpY2FsbHkgdG8gcHJldmVudA0KICAgID4g
ZHVtYiBtaWRkbGVib3hlcyBmcm9tIHRyZWF0aW5nIHRoZSBub25jZSBhcyBhIHNlcXVlbmNlIG51
bWJlci4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+IEZyb206IFFVSUMgW21haWx0bzpxdWlj
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSeWFuIEhhbWlsdG9uDQogICAgPiBTZW50
OiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxOCAxOjIwIFBNDQogICAgPiBUbzogUHJhdmVlbiBCYWxh
c3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+DQogICAgPiBDYzogVmljdG9yIFZhc2ls
aWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQog
ICAgPiBTdWJqZWN0OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lm
aWNhdGlvbiBwcmV2ZW50aW9uDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPiBPbiBUdWUsIEFw
ciAxMCwgMjAxOCBhdCA5OjM3IEFNLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KICAgID4gPHBy
YXZiPTQwbWljcm9zb2Z0Li4uY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCiAgICA+DQogICAg
PiBXaXRoIHRoZSBzaHVmZmxlIHNjaGVtZSwgaWYgYSBtaWRkbGVib3ggd2FudHMgdG8gZ28gb3V0
IG9mIGl0cyB3YXkgdG8gZG8NCiAgICA+IGFuYWx5c2lzIHRvIGJyZWFrIGEgUFJORyBhbmQgZmlu
ZCB0aGUgcGFja2V0IG51bWJlciBpdCBjYW4uIFRoZSBzY2hlbWUgaXMNCiAgICA+IG5vdCBldmVu
IHJlcXVpcmluZyBhIHNlY3VyZSByYW5kb20gbnVtYmVyLiBUaGUgZ29hbCBpcyBub3QgdG8gcHJv
dmlkZSBhbnkNCiAgICA+IHNlY3VyaXR5IGFyb3VuZCBQTiwganVzdCBwcmV2ZW50IG9zc2lmaWNh
dGlvbiBieSBkdW1iIG1pZGRsZWJveGVzIHRoYXQNCiAgICA+IGFzc3VtZSB0aGUgbm9uY2UgaXMg
YSBzZXF1ZW5jZSBudW1iZXIgYW5kIHRyeSB0byByZW9yZGVyLiBJIGRvbuKAmXQgc2VlIGFueQ0K
ICAgID4gaGFybSBpZiBjb3N0bHkgYW5hbHlzaXMgY2FuIGFsbG93IG9uIHBhdGggZGV0ZXJtaW5h
dGlvbiBvZiBwYWNrZXQgbnVtYmVycy4uDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPiBBcmUg
eW91IGNvbmNlcm5lZCBhYm91dCAiaGVscGZ1bCIgbWlkZGxlYm94IHdoaWNoIGFyZSB3aWxsaW5n
IHRvIGV4cGVuZCB0aGUNCiAgICA+IHJlc291cmNlcyB0byBkbyBjb3N0bHkgYW5hbHlzaXMgaW4g
b3JkZXIgdG8gInJlcGFpciIgcGFja2V0IHJlb3JkZXIgKGFuZA0KICAgID4gY29uc2VxdWVudGx5
IGludHJvZHVjZSBIT0wgYmxvY2tpbmcpDQogICAgPg0KICAgID4NCiAgICANCiAgICANCiAgICAN
CiAgICAtLSANCiAgICBLYXp1aG8gT2t1DQogICAgDQogICAgDQoNCg0K


From nobody Wed Apr 11 01:41:22 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2399127078 for ; Wed, 11 Apr 2018 01:41:20 -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 ab4rmm4c-OWr for ; Wed, 11 Apr 2018 01:41:18 -0700 (PDT)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78E77126FB3 for ; Wed, 11 Apr 2018 01:41:18 -0700 (PDT)
Received: by mail-pg0-x229.google.com with SMTP id i194so454496pgd.0 for ; Wed, 11 Apr 2018 01:41:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7B1uDKTgPziiG3h1Ugw/WDhalTmat3pqSoFDqtfTuPU=; b=vcKy3GLdSwzl4Am0QPJINGQ3robcWjM0w8ueoo4zZXFSX0NdbzYXeFUnDEVIFV00fH srBIHgvqbMHs9IoSVx23la0ofYMYmW+BRdVETuS409nFq8MdsbJ3K08jv1ymUiq3SxPO 88J2YoHNYt7hA0C8hpSi/F8AR7e5khQHBFJ80cfDTME3+i8zAQY2ePfefu5W4Df7Snva WBG9Px/8pC4FifhGUOxJAEiag2uKbGy74g6NrLnyG0H/nZrsqDe8cJnorvVIpIX0+TQf GgJFQpGr4BtvMU5xdKfz7vw1YdEsDzPRLNAg8KdaNWcbXGcmimUvWMVG0FQuFXtQD9zU Snlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=7B1uDKTgPziiG3h1Ugw/WDhalTmat3pqSoFDqtfTuPU=; b=F79lGhat7yKp+W6hPQiJ15MYx+9dw/EJpLFvLaP49vxCh2x0QlNDHzLGGUrmze+TKE p6eMISUf1wQUJ7FfpR26o84jzofNhHfveRZi5mhgwsrf/39ltKjVsP2VTCwBrUBQ9szT aFg5G/JrsK4TERxEg469Z3fakYoSejv50kQEUVVDBvshQ+KOnnU0nPCaCDQmex58M9V/ rrpChciNRLnSDnKdEueGnEHcLQsgIAzI2f8cPLAnAh7/uK9w3i0MrM8qFnjp9Oc2cj/Z oIrHYMEd03WxNwlx8RGKnEzAg4Fo3lSBoyVGZmQFKHvOIbq/c9HTtHjl8kC3FEewNLPo WCkw==
X-Gm-Message-State: ALQs6tDvyIzoik0CwyYGn3j32U8rIuz9Iemb9F7WcX9zj6MJwvQ3PYUW Ccj2862twa7TOWZ57QLJUuoCxNefJX4OXAG+wbr2Gw==
X-Google-Smtp-Source: AIpwx49RFGjnHA/U+qHKLZuBH5imMP+34CzlurjJq1tmCCaczLoAAk/AJPurLhllXyEEkp8xlcKAl299iOcaBGCO4VU=
X-Received: by 10.99.112.70 with SMTP id a6mr2771248pgn.294.1523436077813; Wed, 11 Apr 2018 01:41:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Wed, 11 Apr 2018 01:41:17 -0700 (PDT)
In-Reply-To: 
References:       
From: Kazuho Oku 
Date: Wed, 11 Apr 2018 17:41:17 +0900
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: "Brian Trammell (IETF)" 
Cc: Praveen Balasubramanian , Victor Vasiliev ,  IETF QUIC WG , Ryan Hamilton 
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, 11 Apr 2018 08:41:21 -0000

Brian,

Thank you for your response. My comments inline.

2018-04-11 16:16 GMT+09:00 Brian Trammell (IETF) :
> hi Kazuho, all,
>
>> On 11 Apr 2018, at 03:55, Kazuho Oku  wrote:
>>
>> 2018-04-11 7:36 GMT+09:00 Praveen Balasubramanian
>> :
>>> No I am not concerned. Also it is speculation that a middlebox can actu=
ally
>>> do this with the shuffle scheme where each implementation is free to pi=
ck
>>> the PRNG, the shuffle algorithm, and change it over time. Implementatio=
ns
>>> can also seed the PRNG for each connection.
>>>
>>>
>>>
>>> Middleboxes need to operate at line rate and cannot do any expensive
>>> operations and any guessed reordering will make things even worse
>>> performance wise.
>>
>> I am not sure if that assumption is correct.
>>
>> IIUC, there is a strong incentive to create a middlebox that reduces
>> retransmissions in the mobile networks, since it enables mobile
>> operators to have more customers connected to each base station. For
>> example, https://www.sandvine.com/hubfs/downloads/archive/whitepaper-tcp=
-optimization-opportunities-kpis-and-considerations.pdf
>> p. 13 claims 5% network efficiency gain by middleboxes intervening TCP
>> retransmissions.
>
> That such middleboxes will emerge for QUIC, though, is an assumption that=
 is (1) not testable and (2) IMO not credible.

I agree that it's not testable nor credible.

What I am arguing is that it is probable.

And assuming that it is probable, let's have PNE.

If we implement PNE, there would be no probability of PN becoming an
ossification point. Then, we will have the chance to reconsider.
However, if we decide not to have PNE and then see ossification, we
will no longer be able to change the protocol.

> The analogy to TCP ossification is a compelling one, but one must remembe=
r that *all* of these features emerged to operate on TCP traffic because th=
ey improved performance in the cases for which they were deployed.

What I am arguing is that the KPI of the middleboxes that optimize TCP
are not only the end-user-percieved performance, but also how
efficient the bandwidth is used.

It's true that with QUIC there will be much less "optimizations" that
middleboxes can make. But the bandwidth efficiency could still be
improvable, and mobile network operators will have the incentive to do
so since, as I stated, it helps them cram more users into each base
station.

And PN will likely be the vector being used for such optimizations
unless we encrypt it.

> The problem only emerges because (1) the Internet is global, and paths ma=
y also contain links for which the optimizations are harmful to performance=
 or correct operation and/or (2) they interfere with attempts to change the=
 stack at the endpoints.
>
>> It makes me understand that there is certain amount of money on table
>> that could be enough to do complicated things in the middlebox.
>>
>> Note also that people working on such optimizations have the incentive
>> to take advantage of every aspect of how the majority of the QUIC
>> traffic they see look like, rather than respecting what the senders
>> are theoretically allowed to do.
>
> The assumption that such middleboxes will emerge for QUIC requires that t=
here be an in-network operation that a middlebox can do involving manipulat=
ing the packet stream based on the packet number that will improve performa=
nce in local testing under some network conditions. If that is the case, we=
 have not designed the protocol correctly. I don't think it will be: reorde=
ring-correction causes HoL, which shows up in the performance numbers. Atte=
mpts at ACK coalescing will reduce total throughput by inducing lost frames=
. So even in initial prototyping these functions will appear locally inferi=
or.
>
> If people want to deploy stuff on their networks that reduces performance=
 for their customers, we as protocol designers cannot stop them. But here I=
 think local (networks that work) and global (networks that aren't ossified=
) interests align nicely... IOW the "minority" of flows that packet stream =
manipulation will noticeably degrade is a big enough minority that it gets =
noticed.
>
> IMO the only credible packet stream modification function which could eme=
rge based on a packet number with known semantics is "window correction"; i=
.e. an attempt to reject UDP garbage that looks kind of like QUIC by analyz=
ing the "window" of allowable packet numbers, and dropping packets outside =
that window. Packet number discontinuities would break this one, too, but I=
 can see that "feature" making it past the alpha stage, at least. If that's=
 the failure model, I'll note that schemes that permute the low bits while =
keeping the high bits won't defend well against it...
>
>>> An obnoxious middlebox can always drop all QUIC traffic
>>> and force fallback to TCP.
>>
>> Yes.
>>
>> I believe that the signal that we need to send to people interesting
>> in "optimizing" QUIC in the middle is that they should either decide
>> not to (by possibly dropping QUIC entirely), or to cooperate with the
>> protocol designers in optimizing QUIC for their needs without causing
>> ossification.
>
> I agree with this statement completely.
>
>> IMO PNE is a good signal in that respect.
>
> If the signal you mean here is "hello middlebox, the packet number is not=
 for you", then I tend to agree. I think we should find the best tradeoff b=
etween implementation/runtime/deployability cost and ability to send that s=
ignal.

I agree.

> Cheers,
>
> Brian
>



--=20
Kazuho Oku


From nobody Wed Apr 11 01:42:12 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910DC1200C5 for ; Wed, 11 Apr 2018 01:42:10 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=auJQgduG; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=eoMDGXCv
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1h5ld4_E7q10 for ; Wed, 11 Apr 2018 01:42:08 -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 8F6A712EAF1 for ; Wed, 11 Apr 2018 01:41:59 -0700 (PDT)
Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3B8ftGk011576; Wed, 11 Apr 2018 01:41:55 -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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=BtyBmDhR/AjeGhEKI7nDtOjy0kDC6pF8vElQt3HNqzY=; b=auJQgduGohAidk6tbe7BpT27c7+c9ph9ffH0QHx1XgbErKuUK4PVhrdfAPp6WZt9Kj3y jqef8eCfCMNua3iy4xTVIbI4rnP9Jv1rUr7jUuaxKlUBXGCq0kLFEuW+HpV/qaYTGJDZ 4Rwwv54gB1S+15Q6+AQ6ASL03JIoIUpriNU= 
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 2h9e7rg339-2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Apr 2018 01:41:55 -0700
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.13) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 11 Apr 2018 01:41:54 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;  bh=BtyBmDhR/AjeGhEKI7nDtOjy0kDC6pF8vElQt3HNqzY=; b=eoMDGXCvFJG5newEg3Y4lpdbzpKru+MJQq3ka8VOCskQ7qjbbG+frpU5xlagpD2owt6EVWsy0YuU/eXYK8Dmf8tmqPGZP7iyDoA4bbzJPsCtD6Bb3+Fxwzuf74Zm55rPH/YLFQvqNYrypanDjCrIl9Bx5uZGkoIdoWrOPGrXFTU=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0487.namprd15.prod.outlook.com (10.163.110.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Wed, 11 Apr 2018 08:41:52 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::78a6:3a7a:1195:dd02]) by BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::78a6:3a7a:1195:dd02%13]) with mapi id 15.20.0653.018; Wed, 11 Apr 2018 08:41:52 +0000
From: Roberto Peon 
To: "Fossati, Thomas (Nokia - GB/Cambridge)" , Kazuho Oku , Praveen Balasubramanian 
CC: Victor Vasiliev , IETF QUIC WG , "Ryan Hamilton" 
Subject: Re: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAuyyQD//+5tAIAAipkA//+DHAA=
Date: Wed, 11 Apr 2018 08:41:51 +0000
Message-ID: <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.a.0.180210
x-originating-ip: [70.103.56.2]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0487; 7:yMgui5pQ1V+Yk870NYJDg+Z9xPxyr/a43Zsrs5hJXd/qFfV/2XMzC/IZr9GXFAqBY6SMTij2gGmbXJHR4qwOBI5EdLelYFFiiURu0kasRzRQX7gSg6sDyfHJdWxp2GWHHzDAIYUqD5gtzjJlhd/Nc2bKz60cVdpOIuJYpFoH3PJWWALwjUulym2YB9yvfSdsmKB1Lw7QEOmbKOlqqYdfI+VubPphqdVp4A8eDHI+xYgXMoCXD56nZTdXfMJ+b5bi; 20:OmE6PW6FaT1W5Kj/IkqTh5feg2RJJyK9zPcXrwgZEj8NGA1ThKXI3y/RFULOLkjEz/yr3CC+NUxN6TJKpY+QSu0sD8OFGxIFK7OqGRr7dNcCSZjHncjw9fuXQke9S0XlH3tC1z2w2fS+Xu2/xMs46gMs3kMNvq/u7C8PO0/W1MU=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR15MB0487; 
x-ms-traffictypediagnostic: BY2PR15MB0487:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(89211679590171)(192374486261705)(82608151540597)(85827821059158)(15185016700835)(67672495146484)(211936372134217)(153496737603132);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231221)(11241501184)(944501327)(52105095)(93006095)(93001095)(6041310)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:BY2PR15MB0487; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0487; 
x-forefront-prvs: 0639027A9E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(366004)(396003)(376002)(346002)(199004)(189003)(377424004)(58126008)(8676002)(8656006)(102836004)(2616005)(8936002)(36756003)(81166006)(81156014)(486006)(54906003)(110136005)(82746002)(99286004)(93886005)(2906002)(305945005)(5660300001)(83716003)(39060400002)(106356001)(33656002)(59450400001)(6486002)(6436002)(6506007)(575784001)(86362001)(966005)(76176011)(53546011)(26005)(11346002)(186003)(229853002)(105586002)(3280700002)(4326008)(2900100001)(7736002)(3660700001)(476003)(1511001)(8666007)(6512007)(25786009)(6246003)(6306002)(53936002)(6116002)(446003)(3846002)(66066001)(68736007)(14454004)(478600001)(5250100002)(316002)(97736004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0487; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: pBYYbm6YaGMx1gUUKhqJMZIpmfrJ2Ob1zQnwij2cq3et6NSyOwPptRFDvlUG6hS+wb2ApFefuoQ0pAFD2anAH69NQS9nAop8AdYxakGyNtvUY2NyB6xacWhFVHPW72MgN3bSpVjZ3v+BPLT44rXnABnIiaBSULpj+jdMzglVcJIbHYfRZ3ItBcPLQtVPd42grxlZ6qiKK0jGZpxxP4R8taJ4gZTIXUjVO4270wpHKLF4APgwUzn7LnMWycSkG0tRlWPXGj61EXdtK1KPJbmRhNrcch7JFnSvom/z2Pum0ACNii3mBkVgjmm2Scm+MY67i8I0eNpfv+D3jcI9csY0nikFAzwZeHz10PvjYAvY8pG43N7eVV0tv7S8vQenVUAU5Hxmx7CsrexAeJWo4g/3gbWxO6ApdzifFDgElhNq0SU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 827dfe2a-554c-4d81-3589-08d59f8812bd
X-MS-Exchange-CrossTenant-Network-Message-Id: 827dfe2a-554c-4d81-3589-08d59f8812bd
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 08:41:52.0145 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0487
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_04:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Apr 2018 08:42:11 -0000

Im9idmlvdXMiIGF2ZW51ZXMgb2YgKG1pcyl1c2U6IHJlb3JkZXIsIGJsb2NrLCBkZWxheSwgaW5m
b3JtIE5BVCBtYXBwaW5ncywgZXRjLiANCg0KV2hpbGUgSSdkIGhvcGUgdGhhdCBtYW55IG9mIG5v
dCBhbGwgb2YgdGhlc2Ugd291bGQgbm90IGJlIGRvbmUsIEkgaGF2ZSBsaXR0bGUgY29uZmlkZW5j
ZSB0aGF0IHRoZXkgd2lsbCBub3QgYmUgc2hvd24gdG8gaGF2ZSBzb21lIGltcHJvdmVtZW50IGZv
ciBzb21lIHNjZW5hcmlvcy4gTkFUIG1hcHBpbmcgaW4gcGFydGljdWxhciBzZWVtcyBhIHBvaW50
IG9mIHBvdGVudGlhbCAib3B0aW1pemF0aW9uIiB0aGF0IGxlYXZlcyBtZSBmZWVsaW5nIHdvcnJp
ZWQuDQoNCldoYXQgYWJvdXQgcm91dGVycyB3aGljaCBtYXkgYmUgYXR0ZW1wdGluZyB0byBwcm92
aWRlICJzZWN1cml0eSIgYnkgZXhhbWluaW5nIHRoZSBQTnMgKHN1Y2gsIGlmIHRoZXkgZG9uJ3Qg
dHJ1c3QgdGhlIGltcGxlbWVudGF0aW9uIHNob3VsZCByZXNvcnQgdG8gb3RoZXIgb3B0aW9ucyBp
bnN0ZWFkKSB0byBmaW5nZXJwcmludCB0aGluZ3MgKGhvdyByYW5kb20gYXJlIHlvdXIgc2h1ZmZs
ZXM/IFdoZXJlIGRvIHlvdSBzdGFydCBmcm9tPyBIb3cgbWFueSBiaXQpLCBldGMuDQoNClRCSCwg
SSdtIG1vcmUgd29ycmllZCBhYm91dCB0aGUgdGhpbmdzIHdlIGNhbid0IHRoaW5rIG9mLiBDUklN
RSB3YXMgYSBnb29kIGV4YW1wbGUgb2YgYSBmYWlsdXJlIG9mIGltYWdpbmF0aW9uIG9uIG91ciBw
YXJ0LCBhbmQgSSB0aGluayB3ZSBzaG91bGQgaGVlZCBpdHMgbGVzc29uOiBUaGUgc2lkZSBjaGFu
bmVscyBtYXR0ZXIgdG9vLCBhbmQgUE4gaXMgYXJndWFibGUgYSBzaWRlIGNoYW5uZWwuDQotPVIN
Cg0KDQrvu79PbiA0LzExLzE4LCAxOjA5IEFNLCAiUVVJQyBvbiBiZWhhbGYgb2YgRm9zc2F0aSwg
VGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSkiIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmcgb24g
YmVoYWxmIG9mIHRob21hcy5mb3NzYXRpQG5va2lhLmNvbT4gd3JvdGU6DQoNCiAgICBTdXJlLCBC
cmlhbiBoYXMgYSB2ZXJ5IGdvb2QgcG9pbnQgdGhvdWdoOiB3aXRoIGludGVncml0eSBwcm90ZWN0
aW9uIGFsbCBvdmVyIHRoZSBwbGFjZSwgYW4gInVzZWZ1bCIgbWlkZGxlLWJveCBoYXMgdmVyeSBs
aW1pdGVkIHJvb20gZm9yIG1hbm9ldXZyZS4gIFRha2UgYSBsb29rIGF0IFJGQyAzNDQ5IGFuZCBz
ZWFyY2ggZm9yICJJUHNlYyBBSCIgdG8gZ2V0IGFuIGlkZWEgb2YgdGhlIGltcGFjdCBvbiB0aGUg
YWJpbGl0eSB0byBpbXBsZW1lbnQgInVzZWZ1bCBmZWF0dXJlcyIgaW4gdGhlIG1pZGRsZSB3aGVu
IHRoZSBzdHJlYW1zIGFyZSBpbnRlZ3JpdHkgcHJvdGVjdGVkIC0gbGV0IGFsb25lIHdoZW4gdGhl
eSBhcmUgZW5jcnlwdGVkLg0KICAgIE9zc2lmaWNhdGlvbi13aXNlIHRoZSBhZHZhbnRhZ2Ugd2Ug
Z2V0IGZyb20gUE5FIHNlZW1zIG1hcmdpbmFsICh+MD8pIG92ZXIgdGhlIGJpZyB3aW4gd2hpY2gg
YWxyZWFkeSBjb21lcyBmcm9tIEFFQUQuDQogICAgDQogICAgDQogICAgDQogICAgT24gMTEvMDQv
MjAxOCwgMDg6NTMsICJRVUlDIG9uIGJlaGFsZiBvZiBSb2JlcnRvIFBlb24iIDxxdWljLWJvdW5j
ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGZlbml4QGZiLmNvbT4gd3JvdGU6DQogICAgDQogICAg
DQogICAgKysgS2F6dWhvJ3Mgb2JzZXJ2YXRpb24gdGhhdCB0aGVyZSBpcyBpbmNlbnRpdmUgdG8g
YmUgaGVscGZ1bC4gSSBjYW4ndCB0aGluayBvZiBhbnkgb2YgdGhlIG9zc2lmaWNhdGlvbiB3ZSBy
YW4gaW50byB3aXRoIFRDUCB0aGF0IHdhc24ndCBkb25lIHdpdGggdGhlIGludGVudCB0byBiZSBo
ZWxwZnVsL3Byb3ZpZGUgdmFsdWUuIEl0IHByb2JhYmx5IGRpZCBhY2hpZXZlIHRoYXQgc2hvcnQt
dGVybSwgYXQgdGhlIGNvc3Qgb2YgbXVjaCBsb25nLXRlcm0gdmFsdWUuDQogICAgLT1SDQogICAg
DQogICAgT24gNC8xMC8xOCwgNjo1NiBQTSwgIlFVSUMgb24gYmVoYWxmIG9mIEthenVobyBPa3Ui
IDxxdWljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGthenVob29rdUBnbWFpbC5jb20+
IHdyb3RlOg0KICAgIA0KICAgICAgICAyMDE4LTA0LTExIDc6MzYgR01UKzA5OjAwIFByYXZlZW4g
QmFsYXN1YnJhbWFuaWFuDQogICAgICAgIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0
Zi5vcmc+Og0KICAgICAgICA+IE5vIEkgYW0gbm90IGNvbmNlcm5lZC4gQWxzbyBpdCBpcyBzcGVj
dWxhdGlvbiB0aGF0IGEgbWlkZGxlYm94IGNhbiBhY3R1YWxseQ0KICAgICAgICA+IGRvIHRoaXMg
d2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUgd2hlcmUgZWFjaCBpbXBsZW1lbnRhdGlvbiBpcyBmcmVl
IHRvIHBpY2sNCiAgICAgICAgPiB0aGUgUFJORywgdGhlIHNodWZmbGUgYWxnb3JpdGhtLCBhbmQg
Y2hhbmdlIGl0IG92ZXIgdGltZS4gSW1wbGVtZW50YXRpb25zDQogICAgICAgID4gY2FuIGFsc28g
c2VlZCB0aGUgUFJORyBmb3IgZWFjaCBjb25uZWN0aW9uLg0KICAgICAgICA+DQogICAgICAgID4N
CiAgICAgICAgPg0KICAgICAgICA+IE1pZGRsZWJveGVzIG5lZWQgdG8gb3BlcmF0ZSBhdCBsaW5l
IHJhdGUgYW5kIGNhbm5vdCBkbyBhbnkgZXhwZW5zaXZlDQogICAgICAgID4gb3BlcmF0aW9ucyBh
bmQgYW55IGd1ZXNzZWQgcmVvcmRlcmluZyB3aWxsIG1ha2UgdGhpbmdzIGV2ZW4gd29yc2UNCiAg
ICAgICAgPiBwZXJmb3JtYW5jZSB3aXNlLg0KICAgICAgICANCiAgICAgICAgSSBhbSBub3Qgc3Vy
ZSBpZiB0aGF0IGFzc3VtcHRpb24gaXMgY29ycmVjdC4NCiAgICAgICAgDQogICAgICAgIElJVUMs
IHRoZXJlIGlzIGEgc3Ryb25nIGluY2VudGl2ZSB0byBjcmVhdGUgYSBtaWRkbGVib3ggdGhhdCBy
ZWR1Y2VzDQogICAgICAgIHJldHJhbnNtaXNzaW9ucyBpbiB0aGUgbW9iaWxlIG5ldHdvcmtzLCBz
aW5jZSBpdCBlbmFibGVzIG1vYmlsZQ0KICAgICAgICBvcGVyYXRvcnMgdG8gaGF2ZSBtb3JlIGN1
c3RvbWVycyBjb25uZWN0ZWQgdG8gZWFjaCBiYXNlIHN0YXRpb24uIEZvcg0KICAgICAgICBleGFt
cGxlLCBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff
X3d3dy5zYW5kdmluZS5jb21faHViZnNfZG93bmxvYWRzX2FyY2hpdmVfd2hpdGVwYXBlci0yRHRj
cC0yRG9wdGltaXphdGlvbi0yRG9wcG9ydHVuaXRpZXMtMkRrcGlzLTJEYW5kLTJEY29uc2lkZXJh
dGlvbnMucGRmJmQ9RHdJRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPUMwc1VvLUxGTkJh
WWZ5b2FDc2Y2VEEmbT1lNmdONUhNWFA3SDFqdmN3dkxiR1VQamN2OG9ETXFhZDh4YS1YMHFodkt3
JnM9c2hlNzhCTWVPd0s0ZXFSM0lEVWRaRHNTN0oxRTU1Q216OUxtUjhURE1kbyZlPQ0KICAgICAg
ICBwLiAxMyBjbGFpbXMgNSUgbmV0d29yayBlZmZpY2llbmN5IGdhaW4gYnkgbWlkZGxlYm94ZXMg
aW50ZXJ2ZW5pbmcgVENQDQogICAgICAgIHJldHJhbnNtaXNzaW9ucy4NCiAgICAgICAgDQogICAg
ICAgIEl0IG1ha2VzIG1lIHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBpcyBjZXJ0YWluIGFtb3VudCBv
ZiBtb25leSBvbiB0YWJsZQ0KICAgICAgICB0aGF0IGNvdWxkIGJlIGVub3VnaCB0byBkbyBjb21w
bGljYXRlZCB0aGluZ3MgaW4gdGhlIG1pZGRsZWJveC4NCiAgICAgICAgDQogICAgICAgIE5vdGUg
YWxzbyB0aGF0IHBlb3BsZSB3b3JraW5nIG9uIHN1Y2ggb3B0aW1pemF0aW9ucyBoYXZlIHRoZSBp
bmNlbnRpdmUNCiAgICAgICAgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgZXZlcnkgYXNwZWN0IG9mIGhv
dyB0aGUgbWFqb3JpdHkgb2YgdGhlIFFVSUMNCiAgICAgICAgdHJhZmZpYyB0aGV5IHNlZSBsb29r
IGxpa2UsIHJhdGhlciB0aGFuIHJlc3BlY3Rpbmcgd2hhdCB0aGUgc2VuZGVycw0KICAgICAgICBh
cmUgdGhlb3JldGljYWxseSBhbGxvd2VkIHRvIGRvLg0KICAgICAgICANCiAgICAgICAgPiBBbiBv
Ym5veGlvdXMgbWlkZGxlYm94IGNhbiBhbHdheXMgZHJvcCBhbGwgUVVJQyB0cmFmZmljDQogICAg
ICAgID4gYW5kIGZvcmNlIGZhbGxiYWNrIHRvIFRDUC4NCiAgICAgICAgDQogICAgICAgIFllcy4N
CiAgICAgICAgDQogICAgICAgIEkgYmVsaWV2ZSB0aGF0IHRoZSBzaWduYWwgdGhhdCB3ZSBuZWVk
IHRvIHNlbmQgdG8gcGVvcGxlIGludGVyZXN0aW5nDQogICAgICAgIGluICJvcHRpbWl6aW5nIiBR
VUlDIGluIHRoZSBtaWRkbGUgaXMgdGhhdCB0aGV5IHNob3VsZCBlaXRoZXIgZGVjaWRlDQogICAg
ICAgIG5vdCB0byAoYnkgcG9zc2libHkgZHJvcHBpbmcgUVVJQyBlbnRpcmVseSksIG9yIHRvIGNv
b3BlcmF0ZSB3aXRoIHRoZQ0KICAgICAgICBwcm90b2NvbCBkZXNpZ25lcnMgaW4gb3B0aW1pemlu
ZyBRVUlDIGZvciB0aGVpciBuZWVkcyB3aXRob3V0IGNhdXNpbmcNCiAgICAgICAgb3NzaWZpY2F0
aW9uLg0KICAgICAgICANCiAgICAgICAgSU1PIFBORSBpcyBhIGdvb2Qgc2lnbmFsIGluIHRoYXQg
cmVzcGVjdC4NCiAgICAgICAgDQogICAgICAgID4gT25lIGNhbiBjb25zdHJ1Y3QgYmFkIG1pZGRs
ZWJveCBiZWhhdmlvciBvbiBhDQogICAgICAgID4gd2lkZSBzcGVjdHJ1bS4gT25lIGNhbiBhbHNv
IGRlc2lnbiBvc3NpZmljYXRpb24gcHJldmVudGlvbiBzb2x1dGlvbnMgdGhhdA0KICAgICAgICA+
IG1ha2UgZW5kcG9pbnRzIGRvIGVpdGhlciB2ZXJ5IGxpdHRsZSB3b3JrIG9yIGEgbG90IG9mIHdv
cmsuIFRoZXJlIGFyZQ0KICAgICAgICA+IHRyYWRlLW9mZnMuDQogICAgICAgID4NCiAgICAgICAg
Pg0KICAgICAgICA+DQogICAgICAgID4gVGhlIGdvYWwgaGVyZSB3YXMgdG8gZXhwbG9yZSBhIGxv
dyBDUFUgY29zdCB0cmFuc2Zvcm0gdGhhdCBjYW4gZG8gYmV0dGVyDQogICAgICAgID4gZ3JlYXNp
bmcgb2YgdGhlIGZpZWxkIHdpdGggbm8gbW9ub3RvbmljIGluY3JlYXNlLCBzcGVjaWZpY2FsbHkg
dG8gcHJldmVudA0KICAgICAgICA+IGR1bWIgbWlkZGxlYm94ZXMgZnJvbSB0cmVhdGluZyB0aGUg
bm9uY2UgYXMgYSBzZXF1ZW5jZSBudW1iZXIuDQogICAgICAgID4NCiAgICAgICAgPg0KICAgICAg
ICA+DQogICAgICAgID4gRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10g
T24gQmVoYWxmIE9mIFJ5YW4gSGFtaWx0b24NCiAgICAgICAgPiBTZW50OiBUdWVzZGF5LCBBcHJp
bCAxMCwgMjAxOCAxOjIwIFBNDQogICAgICAgID4gVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFu
IDxwcmF2YkBtaWNyb3NvZnQuY29tPg0KICAgICAgICA+IENjOiBWaWN0b3IgVmFzaWxpZXYgPHZh
c2lsdnZAZ29vZ2xlLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NCiAgICAgICAg
PiBTdWJqZWN0OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lmaWNh
dGlvbiBwcmV2ZW50aW9uDQogICAgICAgID4NCiAgICAgICAgPg0KICAgICAgICA+DQogICAgICAg
ID4gT24gVHVlLCBBcHIgMTAsIDIwMTggYXQgOTozNyBBTSwgUHJhdmVlbiBCYWxhc3VicmFtYW5p
YW4NCiAgICAgICAgPiA8cHJhdmI9NDBtaWNyb3NvZnQuLi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdy
b3RlOg0KICAgICAgICA+DQogICAgICAgID4gV2l0aCB0aGUgc2h1ZmZsZSBzY2hlbWUsIGlmIGEg
bWlkZGxlYm94IHdhbnRzIHRvIGdvIG91dCBvZiBpdHMgd2F5IHRvIGRvDQogICAgICAgID4gYW5h
bHlzaXMgdG8gYnJlYWsgYSBQUk5HIGFuZCBmaW5kIHRoZSBwYWNrZXQgbnVtYmVyIGl0IGNhbi4g
VGhlIHNjaGVtZSBpcw0KICAgICAgICA+IG5vdCBldmVuIHJlcXVpcmluZyBhIHNlY3VyZSByYW5k
b20gbnVtYmVyLiBUaGUgZ29hbCBpcyBub3QgdG8gcHJvdmlkZSBhbnkNCiAgICAgICAgPiBzZWN1
cml0eSBhcm91bmQgUE4sIGp1c3QgcHJldmVudCBvc3NpZmljYXRpb24gYnkgZHVtYiBtaWRkbGVi
b3hlcyB0aGF0DQogICAgICAgID4gYXNzdW1lIHRoZSBub25jZSBpcyBhIHNlcXVlbmNlIG51bWJl
ciBhbmQgdHJ5IHRvIHJlb3JkZXIuIEkgZG9u4oCZdCBzZWUgYW55DQogICAgICAgID4gaGFybSBp
ZiBjb3N0bHkgYW5hbHlzaXMgY2FuIGFsbG93IG9uIHBhdGggZGV0ZXJtaW5hdGlvbiBvZiBwYWNr
ZXQgbnVtYmVycy4uDQogICAgICAgID4NCiAgICAgICAgPg0KICAgICAgICA+DQogICAgICAgID4g
QXJlIHlvdSBjb25jZXJuZWQgYWJvdXQgImhlbHBmdWwiIG1pZGRsZWJveCB3aGljaCBhcmUgd2ls
bGluZyB0byBleHBlbmQgdGhlDQogICAgICAgID4gcmVzb3VyY2VzIHRvIGRvIGNvc3RseSBhbmFs
eXNpcyBpbiBvcmRlciB0byAicmVwYWlyIiBwYWNrZXQgcmVvcmRlciAoYW5kDQogICAgICAgID4g
Y29uc2VxdWVudGx5IGludHJvZHVjZSBIT0wgYmxvY2tpbmcpDQogICAgICAgID4NCiAgICAgICAg
Pg0KICAgICAgICANCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICAtLSANCiAgICAgICAgS2F6
dWhvIE9rdQ0KICAgICAgICANCiAgICAgICAgDQogICAgDQogICAgDQogICAgDQoNCg==


From nobody Wed Apr 11 01:56:29 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE25112EA90 for ; Wed, 11 Apr 2018 01:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 G3N-KOpS7PNV for ; Wed, 11 Apr 2018 01:56:14 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0E712E865 for ; Wed, 11 Apr 2018 01:56:13 -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=nVsotU7kaJQgdZREdi0BPRteodwOD78wFskR5PY54EQ=; b=ZEbYLxckJLA7B1CZST6DWk3nNf+Iiq9HNVjaSKelgPFmbJfKR7kw+fRORhrLT8HpjFomDtwbf8fC8S7PBXzh/YT29QetoQaNH97Me9UbZyFP1M7iCbl0CNSyjSmRzWIGkwrCsXOxZfBEYTW5bjNBMD0jE7N2nho5PKkzXRG9fkg=
Received: from DB3PR07MB0747.eurprd07.prod.outlook.com (10.160.53.12) by DB3PR07MB172.eurprd07.prod.outlook.com (10.242.132.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.4; Wed, 11 Apr 2018 08:56:10 +0000
Received: from DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::f0d7:f43d:bd5b:ab9e]) by DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::f0d7:f43d:bd5b:ab9e%6]) with mapi id 15.20.0675.009; Wed, 11 Apr 2018 08:56:02 +0000
From: "Fossati, Thomas (Nokia - GB/Cambridge)" 
To: Kazuho Oku , "Brian Trammell (IETF)" 
CC: Praveen Balasubramanian , IETF QUIC WG , Ryan Hamilton , Victor Vasiliev , "Fossati, Thomas (Nokia - GB/Cambridge)" 
Subject: Re: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAuyyQAACzPhAAAC9p6AAAKcBQA=
Date: Wed, 11 Apr 2018 08:56:02 +0000
Message-ID: <60955AE8-7637-4CC4-9FD8-56201685EE03@nokia.com>
References:        
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; 
x-originating-ip: [81.134.152.4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB3PR07MB172; 7:JwsYnpY/Bfnqe/M20HNwUFp4gCeq5MnslGJ0Eb/JmoiWfyMx4OY33cATrp0r7BysA2YxClPtqVK+Zhc4LB0m+5SPZCs9iSvSrcLfDZzve86F/DzJcCKL4qLH4SbJoooMo226gTf4xT58mn4kMsZUR/B38lqPHow53SqKnwSgLkAtuX0rcpZUDNMhRp3U7MeRJ3xUesHPm4+KT5oPbUqjVemRojT9nl0fb29r0dajm+spBbyEEHf3CRIPNhr3CxFN
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(376002)(366004)(39380400002)(346002)(396003)(199004)(189003)(36756003)(99286004)(8936002)(316002)(81166006)(81156014)(6246003)(39060400002)(107886003)(6116002)(58126008)(6506007)(110136005)(53936002)(93886005)(446003)(3846002)(486006)(5660300001)(86362001)(2616005)(76176011)(83716003)(14454004)(11346002)(3280700002)(186003)(66066001)(2906002)(68736007)(26005)(3660700001)(102836004)(229853002)(105586002)(8676002)(305945005)(106356001)(33656002)(476003)(4326008)(97736004)(6486002)(7736002)(6436002)(5250100002)(478600001)(6512007)(25786009)(2900100001)(82746002)(54906003)(8666007); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB172; H:DB3PR07MB0747.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:DB3PR07MB172; 
x-ms-traffictypediagnostic: DB3PR07MB172:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(85827821059158);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231221)(11241501184)(806099)(944501327)(52105095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:DB3PR07MB172; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB172; 
x-forefront-prvs: 0639027A9E
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: ikwY+jo6LoxE5G6MlGxUKm/uj2w9sliS2u5Ij/Bx1bKzhlbe5ZkthJfXGJxHHeDHTV+4jUfGAwN9iU4zAXQPNObeuQ0E7KAdpCMYJNRotkTck8A48vy95rV6JkH4mbuMGlUA79bkerdnda6UImD3ByUmkRFg2NTomnrry95Ajp9WqHZQWMdMZEkThOCW57POsSj0NR2DMZclYcu3MGmKLQfuDLk7kkJ4d7MZO7/dKd0xJsrW1VDkkh39Nee3J2tTYGQMaHuGusSxPTJlwPxZkzrfU/bRLpxQHqql0AKGpZlyfdiRHjIqpv3U8Ga2j8kXgpCjjT5s/mjU0xFOWNQgx6ObKExFcq6K2J8YFLDeWaW7bLf+MCOCAJNFO3j5Ju2O+QQY0dX638+UMjXeHLNEvUWSLfmjVBlTUQerJPuxYVWXa6H+7fnSei3H9mc07dQRScnd7GwgSsU9LhyEydzWaQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <52FE610533A3D946A475AF0EE80A7E2E@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 06a679a6-a84d-444d-8de5-08d59f8a0d90
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 06a679a6-a84d-444d-8de5-08d59f8a0d90
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 08:56:02.1841 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB172
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 08:56:28 -0000

SGkgS2F6dWhvDQoNCu+7v09uIDExLzA0LzIwMTgsIDA5OjQxLCAiUVVJQyBvbiBiZWhhbGYgb2Yg
S2F6dWhvIE9rdSIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga2F6dWhvb2t1
QGdtYWlsLmNvbT4gd3JvdGU6DQo+IFdoYXQgSSBhbSBhcmd1aW5nIGlzIHRoYXQgdGhlIEtQSSBv
ZiB0aGUgbWlkZGxlYm94ZXMgdGhhdCBvcHRpbWl6ZSBUQ1ANCj4gYXJlIG5vdCBvbmx5IHRoZSBl
bmQtdXNlci1wZXJjaWV2ZWQgcGVyZm9ybWFuY2UsIGJ1dCBhbHNvIGhvdw0KPiBlZmZpY2llbnQg
dGhlIGJhbmR3aWR0aCBpcyB1c2VkLg0KPiANCj4gSXQncyB0cnVlIHRoYXQgd2l0aCBRVUlDIHRo
ZXJlIHdpbGwgYmUgbXVjaCBsZXNzICJvcHRpbWl6YXRpb25zIiB0aGF0DQo+IG1pZGRsZWJveGVz
IGNhbiBtYWtlLiBCdXQgdGhlIGJhbmR3aWR0aCBlZmZpY2llbmN5IGNvdWxkIHN0aWxsIGJlDQo+
IGltcHJvdmFibGUsIGFuZCBtb2JpbGUgbmV0d29yayBvcGVyYXRvcnMgd2lsbCBoYXZlIHRoZSBp
bmNlbnRpdmUgdG8gZG8NCj4gc28gc2luY2UsIGFzIEkgc3RhdGVkLCBpdCBoZWxwcyB0aGVtIGNy
YW0gbW9yZSB1c2VycyBpbnRvIGVhY2ggYmFzZQ0KPiBzdGF0aW9uLg0KPiANCj4gQW5kIFBOIHdp
bGwgbGlrZWx5IGJlIHRoZSB2ZWN0b3IgYmVpbmcgdXNlZCBmb3Igc3VjaCBvcHRpbWl6YXRpb25z
DQo+IHVubGVzcyB3ZSBlbmNyeXB0IGl0Lg0KDQpJJ20gbm90IGF3YXJlIG9mIGFueSB0ZWNobmlx
dWUgdGhhdCB1c2VzIGFuIHVudGFtcGVyYWJsZSBQTiB0byBhY2hpZXZlDQpiYW5kd2lkdGggb3B0
aW1pc2F0aW9uLiAgVGhlIG1pZGRsZWJveCBuZWVkcyB0byBiZSBhYmxlIHRvIGFjdGl2ZWx5DQpt
YW5pcHVsYXRlIHRoZSBTRVEvQUNLIHNwYWNlIC0gYW5kIG1heWJlIG90aGVyIHRoaW5ncyAtIHRv
IGRvIHRoYXQuDQpBbmQgdGhpcyBpcyBhbHJlYWR5IG5vdCBwb3NzaWJsZSBpbiBRVUlDLCB3aGlj
aCBpcyB3aHkgbmV0d29yayBlcXVpcG1lbnQNCnZlbmRvcnMgYXJlIG1haW5seSBsb29raW5nIGF0
IEFRTS1iYXNlZCBzb2x1dGlvbnMuDQoNCg==


From nobody Wed Apr 11 02:43:59 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774A3126B7E for ; Wed, 11 Apr 2018 02:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIgt-UyN4ARB for ; Wed, 11 Apr 2018 02:43:56 -0700 (PDT)
Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31D7E1200A0 for ; Wed, 11 Apr 2018 02:43:56 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,435,1517904000";  d="asc'?scan'208";a="250975755"
Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx144-out.netapp.com with ESMTP; 11 Apr 2018 02:43:55 -0700
Received: from VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 11 Apr 2018 02:43:55 -0700
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 11 Apr 2018 02:43:55 -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=HUbyWBpNPdCzb3AV8R5I0BVCqN9Zr5GFABpK+eRYQK8=; b=qqvHpYSu/zGRhgd6VuIdOQvEXg39TmdN2QLv7jWJ0ZYWHEAWYfRVvTU7TXFD7Vafi2kaZ9HneWdlqRTuvBXojT4hxuqKj9zR/XOG1tpfRqJlk5Xz/CUJNbYB6weLkm1kENcGcmAbzD03yoyiONG9ywEM5hUEFaZGVL+0cVMaVho=
Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB514.namprd06.prod.outlook.com (10.141.204.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.9; Wed, 11 Apr 2018 09:43:52 +0000
Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::5520:2312:30a8:6bd2]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::5520:2312:30a8:6bd2%6]) with mapi id 15.20.0675.009; Wed, 11 Apr 2018 09:43:52 +0000
From: "Eggert, Lars" 
To: Kazuho Oku 
CC: Brian Trammell , Praveen Balasubramanian , IETF QUIC WG , Ryan Hamilton , Victor Vasiliev 
Subject: Re: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAuyyQAACzPhAAAC9p6AAAIvPQA=
Date: Wed, 11 Apr 2018 09:43:52 +0000
Message-ID: <763E9A51-0CA8-4ED5-97C0-E30842F7AA9F@netapp.com>
References:        
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.6.18)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; 
x-originating-ip: [62.237.32.50]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR06MB514; 7:W/ghnfwBOgd5a0gNjBgTU9Rn2qBm5pdNPBYIIvrrAGYqAApTQAoQC5+yWxEXZWryZYRh2Mkis7uSTUStbFWZ0a4uWCKywMzRAHe9ROuFaZ4bA90HpQwcbBzx/1fagVddHJgbWziquG9Gt3bcpoaMs/wQ03ygjZPdRK6efS/Ftnm71HNYaZqyryWTcn/72G3L0Tm9U73fpzYEbnJS4RD1yV2j8cdLswepsUb8+gDuRR36XNoZkt6CAf4M1JkzD1IZ
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(49563074)(7193020); SRVR:BLUPR06MB514; 
x-ms-traffictypediagnostic: BLUPR06MB514:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(85827821059158);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:BLUPR06MB514; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB514; 
x-forefront-prvs: 0639027A9E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39380400002)(366004)(376002)(39860400002)(396003)(199004)(189003)(377424004)(4001150100001)(478600001)(2616005)(486006)(476003)(2906002)(5250100002)(36756003)(446003)(105586002)(11346002)(82746002)(86362001)(68736007)(3660700001)(1411001)(97736004)(53546011)(83716003)(3280700002)(6486002)(81156014)(81166006)(102836004)(99286004)(99936001)(8666007)(26005)(2900100001)(93886005)(57306001)(14454004)(106356001)(8676002)(66066001)(316002)(6506007)(53936002)(6116002)(3846002)(8936002)(76176011)(6436002)(6916009)(54906003)(186003)(4326008)(305945005)(6512007)(7736002)(50226002)(33656002)(5660300001)(25786009)(229853002)(39060400002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB514; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: TuXv3LnmHJ/SpocgdgOCgCjeaBdMtF9PZsUszFgGD2ZVNdYrP1s+2Fp9lghfDJPMd4bw82Vc0ofnkr13OjkbXDbt8fuA6RCXjawg5hdjKnxdqenFycnH/rASgRzfmEOSkoNsCu3SDBZ++RXSdg0T+Ybj4JrKUfSmuxQdDWhSBgPgWnA26ml8d+GpbreQ0g5Toi5Xmypm6UpiCXEFdSb7Hg0RJrCBfyeQTPa5bDexiwc7ACGGZdT4UaDpEGo9lZcB9wDdEIN7G6WISP/Qqtz5ke+Ew1UeUNaMDByrwkoXGy8STVm18bbNX3BifX82a14Af7uGaBpW3/sPVGLEgDVE62Pa9OWU/QW/NZvjH40kmmr+JtNRWqoTC0xgOTP3nZY0ODOeh4iQxSVvVS7FYZriY3KJfaWc6pXgsxL5Tb5sGAk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_468D4A55-0D82-4270-8400-D219B3AB04E9"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: e57d1a91-72a7-4535-5239-08d59f90bc43
X-MS-Exchange-CrossTenant-Network-Message-Id: e57d1a91-72a7-4535-5239-08d59f90bc43
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 09:43:52.3553 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB514
X-OriginatorOrg: netapp.com
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Apr 2018 09:43:58 -0000

--Apple-Mail=_468D4A55-0D82-4270-8400-D219B3AB04E9
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Hi,

(chair hat off)

On 2018-4-11, at 11:41, Kazuho Oku  wrote:
> If we implement PNE, there would be no probability of PN becoming an
> ossification point. Then, we will have the chance to reconsider.
> However, if we decide not to have PNE and then see ossification, we
> will no longer be able to change the protocol.

this nicely sums up my personal standpoint on why we should do PNE in v1.

Lars

--Apple-Mail=_468D4A55-0D82-4270-8400-D219B3AB04E9
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-----

iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlrN2NYACgkQVLXDCb9w
wVd1lRAAj36iYKSWDGatpQdSBbzR4/gCpexL57PLTyNjrmXr3KNDNRscob8QUKya
lxV8olO5A8tXZeCZTIIwBiC4ELbXqtDrtxJkafII4r6Y1+4wa7Xe6x8izU6NP23Y
8wfCK6NNYh0kXyLUsTC6Wl5mkNwbP9N8bRPNdZJ6SXuDXYRmdSvLodzLLzVwJIrI
yfdO459k9QaGeJ5LEbyUCZjy6+PgAWuPMnPwFFH+LWVwzyyhiOKm+bsM4zP9LDe4
x7hkZTLdjWzUn975WEqeNP0sbtP3cVNsy7W+Cu0HAVmVs5F9jKy+3L9JYazTFKQw
UQTBdAtoe4DYxaDkSqLYZ89QzsjaPW1+S5IxNI/ye+wpnGtwJUk2Ee8FUojxFjOF
rGi7HM6Z1KfIU886ndHcXLcieZjhljA6E50YYisHtUjOljUfzsIKEWWZ4WTAXhtF
ngP9QLmNtXl2+yikMUWvagvVJ3Z15saiA4sJsmQ8l6y2hD+fbeWJtsnRnTc8hJ2z
PfRazuv+P760vH58Oq9J72Gg7vmdang32eD4isp95WR2UqyQHXh4Z0KACigTWghK
Dp+yIaPmrh6kvD3z4OFrVO1AS4sqq5lPTVb2RfmnfMxE3Vpy1gtJKVZBqFrqyRex
IARjF1KZS1zT2JvuMlT0VyHGzkmIeRdDgW63xpnh6s2zfnF7TYc=
=pJmd
-----END PGP SIGNATURE-----

--Apple-Mail=_468D4A55-0D82-4270-8400-D219B3AB04E9--


From nobody Wed Apr 11 02:58:44 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9237D1200A0 for ; Wed, 11 Apr 2018 02:58:43 -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 (2048-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 jGoVWHIhReY2 for ; Wed, 11 Apr 2018 02:58:40 -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 9ADD912420B for ; Wed, 11 Apr 2018 02:58:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1523440717; s=strato-dkim-0002; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Date:Message-ID: From:References:To:Subject:X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject: Sender; bh=urHeJFJF3jB1gXMx+YtA3s0pPGVEzh9Y/dQg1XefYpc=; b=MTXuRURGi4YdeVQfvSCCV1rUuNrTLAX0eJC0xhuZVCL+MsvzHpmsPc/GUm63shCUTw 5j9hcMv1l5qiouo18tahpUKkv6454MZhOOJ3hijM4O6Mzq0WdxGqeDLnOTu7p5ASIi6r uxEcj2Ev2DMG4nTkOT8ZQxB6HX6p9DqK0STdCnBPbNvuX/HGaiSHkqyHCDf5jo/19lNb AuUPvg7zHWmvHQI1RA0XVU+MNEoCSJaKvs1sDtxeACoaDC6t3AKMIwNuD1mZ4tXCZ5Pq 8tIhHtBeRftqv5sUYG6D1ONkxMq4xPiGAYdYnpmKSFqhUCSkNn1MsxK6AN/UR8YzySBC QSnQ==
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1YaZ2OgvlDQJHaO3tQ==
X-RZG-CLASS-ID: mo00
Received: from [10.10.10.94] by smtp.strato.de (RZmta 43.2 DYNA|AUTH) with ESMTPSA id 302523u3B9wa06j (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 ; Wed, 11 Apr 2018 11:58:36 +0200 (CEST)
Subject: Re: Simple transform for improving PN ossification prevention
To: quic@ietf.org
References:       
From: Roland Zink 
Message-ID: 
Date: Wed, 11 Apr 2018 11:58:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; 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: Wed, 11 Apr 2018 09:58:44 -0000

Am 11.04.2018 um 09:16 schrieb Brian Trammell (IETF):
 > hi Kazuho, all,
 >


>> in "optimizing" QUIC in the middle is that they should either decide
>> not to (by possibly dropping QUIC entirely), or to cooperate with the
>> protocol designers in optimizing QUIC for their needs without causing
>> ossification.
> I agree with this statement completely.
May this lead to network ossification in order to avoid protocol 
ossification? If it would be only protocol designers it would be nice 
but there will be many existing protocol implementations and they will 
not change. New networks have to support it or they will fail.

Regards,
Roland


From nobody Wed Apr 11 08:21:37 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCD61241F3 for ; Wed, 11 Apr 2018 08:21:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMeAoHsgBztW for ; Wed, 11 Apr 2018 08:21:33 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8901200F1 for ; Wed, 11 Apr 2018 08:21:33 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w3BFJvCb016512; Wed, 11 Apr 2018 16:21:29 +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=bNdn/Ein3GrSslae0fitxYP/7Qq7ucn71ndrYXaVimY=; b=RtwiTXvIYTwnoC5+MFqD0DWCdkB39ldPRS3X8m18KRYB99RUThMwkH1Juy4FGuicdbyj +LRmCMVNZLAv/IBK0dT1bp8hfMP8qY+B5mZo1g5sZp3YSMaZwzByva40Q0x2Y8EUtxgm ALSTQk567YLK/CwV+8iqIgAAqisKk/9McybkvsRweAi1kaMpAwfwKw/EeBe0fO1DclzM EwtCeJY8jt6r7rv/s33Le2ywxrq6cYN0slYpYuowhKWu5u5wL3sAtKTCGEgvYUuFVBrS K1ehpXot0Uvs6bk540/M1XuM4jYIImUgs7hAWfseF/6HhBcWrBz1ceex7eY0EurFQwFQ vg== 
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2h6ty6cpvg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 16:21:29 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3BFGipB012537; Wed, 11 Apr 2018 11:21:27 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2h6sauqs1b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 11:21:27 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 11 Apr 2018 11:21:26 -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.1365.000; Wed, 11 Apr 2018 11:21:26 -0400
From: "Lubashev, Igor" 
To: Roberto Peon , "Fossati, Thomas (Nokia - GB/Cambridge)" , Kazuho Oku , "Praveen Balasubramanian" 
CC: Victor Vasiliev , IETF QUIC WG , "Ryan Hamilton" 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAgCbeAABH1ToAAB78MgAAEx/uAAAb1bwAADHjfgAAAkzqAAAEjd4AABEmfIA==
Date: Wed, 11 Apr 2018 15:21:25 +0000
Message-ID: <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
In-Reply-To: <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.33.243]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110143
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=996 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110143
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 15:21:35 -0000

PiBmaW5nZXJwcmludCB0aGluZ3MNCg0KVGhlcmUgYXJlIG1hbnkgc291cmNlcyBvZiBzaWduYWwg
Zm9yIGZpbmdlcnByaW50aW5nIHcvbyBQTiAob2JzZXJ2YWJsZSBjb25nZXN0aW9uIGNvbnRyb2wg
YWxnbyBhbmQgc2V0dGluZ3MsIHBhY2tldCBwYWNpbmcsIHRpbWluZ3MgYW5kIHBhY2tldCBzaXpl
IGFydGlmYWN0cywgaGFuZHNoYWtlIHBhY2tldCBzaXplcywgZXRjLikuICBXZSBzaG91bGQgbm90
IGFzc3VtZSB0aGF0IGp1c3QgYnkgaW1wcm92aW5nIG9uIFBOIHlvdSBtb3ZlIHRoZSBuZWVkbGUg
YSBsb3QuICBZb3UgZG8gbW92ZSBpdCBhIGxpdHRsZS4gIFNvIHRoZSBxdWVzdGlvbiBtdXN0IGFs
d2F5cyBiZTogImF0IHdoYXQgY29zdD8iDQoNCg0KSSBhbSB3b3JyaWVkIGFib3V0IHRoZSBvY2Nh
c2lvbmFsIGNhdmFsaWVyIGF0dGl0dWRlIHRvIGNvc3RzLiAgSXQgbWF5IGJlIGRpZmZpY3VsdCBm
b3IgdXMgZXN0aW1hdGUgdGhlIGNvc3Qgb2YgYSBwcm90b2NvbCBmZWF0dXJlLCBqdXN0IGxpa2Ug
aXQgaXMgZGlmZmljdWx0IHRvIGVzdGltYXRlIHRoZSBwcml2YWN5IG9yIG9zc2lmaWNhdGlvbiBy
aXNrcy4NCg0KQ29zdHMgaGF2ZSBhIHJlYWwgZWZmZWN0IG9uIHRoZSBwZXJmb3JtYW5jZSwgYWZm
b3JkYWJpbGl0eSwgYW5kIGF2YWlsYWJpbGl0eSBvZiBzZXJ2aWNlIGZvciB0aGUgZW5kIHVzZXJz
LiAgSWYgd2UgYXJlIHdpbGxpbmcgdG8gcmlzayBpbXBvc2luZyBhIHRheCBvbiB1c2VycyB0byBh
dm9pZCBhIHJpc2sgb2Ygc29tZXRoaW5nLCB3ZSBzaG91bGQgYW5hbHl6ZSB0aGlzIHRyYWRlLW9m
ZiBjYXJlZnVsbHkuDQoNCiogQXJlIHdlIGFza2luZyBhbGwgSW50ZXJuZXQgdXNlcnMgdG8gcGF5
IGEgdGF4IHRvIGltcHJvdmUgcHJpdmFjeT8gIERvZXMgdGhlIGFtb3VudCBvZiB0aGUgdGF4IGp1
c3RpZnkgdGhlIGFtb3VudCBvZiBwcml2YWN5IGJlbmVmaXRzIGl0IGJ1eXM/DQoNCiogQXJlIHdl
IGFza2luZyBhbGwgSW50ZXJuZXQgdXNlcnMgdG8gcGF5IGEgdGF4IHRvIHJlZHVjZSBQTiBvc3Np
ZmljYXRpb24/ICBEb2VzIHRoZSBhbW91bnQgb2YgdGhlIHRheCBqdXN0aWZ5IHRoZSBhZGRlZCBm
bGV4aWJpbGl0eSBwcm90b2NvbCBkZXNpZ25lcnMgbWlnaHQgbmVlZCBpbiB0aGUgZnV0dXJlPw0K
DQpJIGRvIG5vdCBrbm93IHRoZSBhbnN3ZXJzIHRvIHRoZXNlIHF1ZXN0aW9ucywgYnV0IHRoZXNl
IHF1ZXN0aW9ucyBtdXN0IGJlIGNvbnNpZGVyZWQgY2FyZWZ1bGx5Lg0KDQotIElnb3INCg0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUm9iZXJ0byBQZW9uIFttYWlsdG86ZmVu
aXhAZmIuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTEsIDIwMTggNDo0MiBBTQ0KVG86
IEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UpIDx0aG9tYXMuZm9zc2F0aUBu
b2tpYS5jb20+OyBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPjsgUHJhdmVlbiBCYWxh
c3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+DQpDYzogVmljdG9yIFZhc2lsaWV2IDx2
YXNpbHZ2QGdvb2dsZS5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBSeWFuIEhh
bWlsdG9uIDxyY2hAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IFJlOiBTaW1wbGUgdHJhbnNmb3JtIGZv
ciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24NCg0KIm9idmlvdXMiIGF2ZW51
ZXMgb2YgKG1pcyl1c2U6IHJlb3JkZXIsIGJsb2NrLCBkZWxheSwgaW5mb3JtIE5BVCBtYXBwaW5n
cywgZXRjLiANCg0KV2hpbGUgSSdkIGhvcGUgdGhhdCBtYW55IG9mIG5vdCBhbGwgb2YgdGhlc2Ug
d291bGQgbm90IGJlIGRvbmUsIEkgaGF2ZSBsaXR0bGUgY29uZmlkZW5jZSB0aGF0IHRoZXkgd2ls
bCBub3QgYmUgc2hvd24gdG8gaGF2ZSBzb21lIGltcHJvdmVtZW50IGZvciBzb21lIHNjZW5hcmlv
cy4gTkFUIG1hcHBpbmcgaW4gcGFydGljdWxhciBzZWVtcyBhIHBvaW50IG9mIHBvdGVudGlhbCAi
b3B0aW1pemF0aW9uIiB0aGF0IGxlYXZlcyBtZSBmZWVsaW5nIHdvcnJpZWQuDQoNCldoYXQgYWJv
dXQgcm91dGVycyB3aGljaCBtYXkgYmUgYXR0ZW1wdGluZyB0byBwcm92aWRlICJzZWN1cml0eSIg
YnkgZXhhbWluaW5nIHRoZSBQTnMgKHN1Y2gsIGlmIHRoZXkgZG9uJ3QgdHJ1c3QgdGhlIGltcGxl
bWVudGF0aW9uIHNob3VsZCByZXNvcnQgdG8gb3RoZXIgb3B0aW9ucyBpbnN0ZWFkKSB0byBmaW5n
ZXJwcmludCB0aGluZ3MgKGhvdyByYW5kb20gYXJlIHlvdXIgc2h1ZmZsZXM/IFdoZXJlIGRvIHlv
dSBzdGFydCBmcm9tPyBIb3cgbWFueSBiaXQpLCBldGMuDQoNClRCSCwgSSdtIG1vcmUgd29ycmll
ZCBhYm91dCB0aGUgdGhpbmdzIHdlIGNhbid0IHRoaW5rIG9mLiBDUklNRSB3YXMgYSBnb29kIGV4
YW1wbGUgb2YgYSBmYWlsdXJlIG9mIGltYWdpbmF0aW9uIG9uIG91ciBwYXJ0LCBhbmQgSSB0aGlu
ayB3ZSBzaG91bGQgaGVlZCBpdHMgbGVzc29uOiBUaGUgc2lkZSBjaGFubmVscyBtYXR0ZXIgdG9v
LCBhbmQgUE4gaXMgYXJndWFibGUgYSBzaWRlIGNoYW5uZWwuDQotPVINCiAgICAgICAgDQogICAg
DQogICAgDQogICAgDQoNCg==


From nobody Wed Apr 11 08:37:21 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E300D1200FC for ; Wed, 11 Apr 2018 08:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV2vwupwNpew for ; Wed, 11 Apr 2018 08:37:07 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0975912702E for ; Wed, 11 Apr 2018 08:37:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C6C8DBE55; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSae1iIuw8_q; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 87CCDBE50; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1523461024; bh=gJf9Kx9aZ+yyY/Wok6jO4cNIEi0vwZ8ddZEEZs5ardE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=xVgK3cxJTAi6TpGlTM+dmwMFYhJhFxIMACy7UaEoFZkosGDwTCO0hNdFiMbkNOFfK 9BudYNAzogEpmg19RxLgG3azsWIXFTVeegi/BGvS0F5Hszd5o4UH/9PihgoCmTXR4f J/UPp5rFofYCyqXk89gAh9oqYtOfhu+6xCUrlgZ8=
Subject: Re: Simple transform for improving PN ossification prevention
To: "Lubashev, Igor" , Roberto Peon , "Fossati, Thomas (Nokia - GB/Cambridge)" , Kazuho Oku , Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG , Ryan Hamilton 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
Date: Wed, 11 Apr 2018 16:37:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SMrnRyY4SgsbwRQwW8CYptci8VI2TVzbi"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 15:37:10 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--SMrnRyY4SgsbwRQwW8CYptci8VI2TVzbi
Content-Type: multipart/mixed; boundary="lw9jK7n5miq0Qg79xB9Ntz7P0UC7kIsjb";
 protected-headers="v1"
From: Stephen Farrell 
To: "Lubashev, Igor" ,
 Roberto Peon ,
 "Fossati, Thomas (Nokia - GB/Cambridge)" ,
 Kazuho Oku ,
 Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG ,
 Ryan Hamilton 
Message-ID: <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
Subject: Re: Simple transform for improving PN ossification prevention
References: 
 
 
 
 
 
 <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
 
 <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
 <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>

--lw9jK7n5miq0Qg79xB9Ntz7P0UC7kIsjb
Content-Type: multipart/mixed;
 boundary="------------D162289FFDBFEEBA4F78AE9D"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------D162289FFDBFEEBA4F78AE9D
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 11/04/18 16:21, Lubashev, Igor wrote:
> * Are we asking all Internet users to pay a tax to improve privacy?
> Does the amount of the tax justify the amount of privacy benefits it
> buys?
I think that (and your other questions) are good things to
ponder, but I don't believe the questions above are really
answerable, at least not unless we can also answer the
opposite question ("Are we asking all Internet users to pay
a tax by not improving privacy?"), and I'm pretty sure I
at least don't know how to evaluate that question. Maybe
that's part of why this discussion is so tricky.

Personally, as a future user of QUIC (but not an implementer),
I'd really prefer that the WG prioritise privacy-friendly
mechanisms if at all possible, even if the direct benefits
aren't completely clear.

Cheers,
S.

--------------D162289FFDBFEEBA4F78AE9D
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------D162289FFDBFEEBA4F78AE9D--

--lw9jK7n5miq0Qg79xB9Ntz7P0UC7kIsjb--

--SMrnRyY4SgsbwRQwW8CYptci8VI2TVzbi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJaziufAAoJEFqy+vF7FyvqXFoP/RYyRHRi1PozHRQvfQ6X3/TT
R8+0b7cWarK7CwtwmyQowFpX9Re7OT33Lof1aI3NDV4738jEjezrXIPbmiaZlI+u
EKTzFB6z8b+cPsFETGDjN3NJdSxyu7V+tDkaiyugI2WjMRcIWh6KcZEAsr4CHoWf
+RYrrBAADZqH3sddTXyittnTSJKFKXi3YWGeWnKBAUoqopM4aw7h+gBF/CDfM58m
ZSbLuk1c2wif1hm1M+VblXhrWMYp8HpPP89TMpv2mw7if95tOA6l4OkFcq5Ocu+B
3/MOFG6sPOyHsEx6EomOhQPr2MrKreROaKRhX01ERMyRQy8ZIpyLDCBeDEY7w/pN
kMu4x5Y+QV6g9rEVU4NIpHDiZR1cEkiVDBqWZMCUDTvt+q74OxHHS9+sv3z2Y1u2
M96yks3wr2P2bTn5f38GPul5q9TgP92k0vYgjtT7R/z15/HH51h/hMEv0K9gcTfZ
UeaZrWHa3eUMAuHBaoc55tWdj6XXeLqb14MECdIayrwpDrpdk7bf5oBntw5WFY3d
kroEX/o8tJqvW+1ToXrQbzYTJwMW28+ud26sl/JliN/ob1YWHetbdEgX/m1neIkq
WUanjzQldhr13vI89rqEkPzSV1qnsnJUQHCNK3vLr8+ccoj8yKS59UngbGsG62jl
EZTHKRC+v+ZLH2+GA62M
=BeD3
-----END PGP SIGNATURE-----

--SMrnRyY4SgsbwRQwW8CYptci8VI2TVzbi--


From nobody Wed Apr 11 08:37:26 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 439511200FC for ; Wed, 11 Apr 2018 08:37:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523461040; bh=gJf9Kx9aZ+yyY/Wok6jO4cNIEi0vwZ8ddZEEZs5ardE=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To:To:To:To; b=yH88bn7MN2pfwFkZ7ja81pc6DLqBpf3EoMXnUhBM968Drnj/bD7dBA2dBbkRbFUCS RzFg9Ld0wxxaMkq9c7h+1fpof7cvf0KRSg8Q1adHS2YjUnGtQpX6Ah4lMIj2OEXtMX 2bQ91uyTQvPJRRi9LzGWHeAdN1Uuzdxe9TnFcbEM=
X-Mailbox-Line: From stephen.farrell@cs.tcd.ie  Wed Apr 11 08:37:20 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06342124BFA; Wed, 11 Apr 2018 08:37:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523461040; bh=gJf9Kx9aZ+yyY/Wok6jO4cNIEi0vwZ8ddZEEZs5ardE=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To:To:To:To; b=yH88bn7MN2pfwFkZ7ja81pc6DLqBpf3EoMXnUhBM968Drnj/bD7dBA2dBbkRbFUCS RzFg9Ld0wxxaMkq9c7h+1fpof7cvf0KRSg8Q1adHS2YjUnGtQpX6Ah4lMIj2OEXtMX 2bQ91uyTQvPJRRi9LzGWHeAdN1Uuzdxe9TnFcbEM=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73C0127419 for ; Wed, 11 Apr 2018 08:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tE14-UcSHgL for ; Wed, 11 Apr 2018 08:37:07 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09694124BFA for ; Wed, 11 Apr 2018 08:37:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C6C8DBE55; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSae1iIuw8_q; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 87CCDBE50; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1523461024; bh=gJf9Kx9aZ+yyY/Wok6jO4cNIEi0vwZ8ddZEEZs5ardE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=xVgK3cxJTAi6TpGlTM+dmwMFYhJhFxIMACy7UaEoFZkosGDwTCO0hNdFiMbkNOFfK 9BudYNAzogEpmg19RxLgG3azsWIXFTVeegi/BGvS0F5Hszd5o4UH/9PihgoCmTXR4f J/UPp5rFofYCyqXk89gAh9oqYtOfhu+6xCUrlgZ8=
Subject: Re: Simple transform for improving PN ossification prevention
Cc: Victor Vasiliev , IETF QUIC WG , Ryan Hamilton 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
Date: Wed, 11 Apr 2018 16:37:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SMrnRyY4SgsbwRQwW8CYptci8VI2TVzbi"
To: "Lubashev, Igor" 
To: Roberto Peon 
To: "Fossati, Thomas \(Nokia - GB/Cambridge\)" 
To: Kazuho Oku 
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 15:37:20 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--SMrnRyY4SgsbwRQwW8CYptci8VI2TVzbi
Content-Type: multipart/mixed; boundary="lw9jK7n5miq0Qg79xB9Ntz7P0UC7kIsjb";
 protected-headers="v1"
From: Stephen Farrell 
To: "Lubashev, Igor" ,
 Roberto Peon ,
 "Fossati, Thomas (Nokia - GB/Cambridge)" ,
 Kazuho Oku ,
 Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG ,
 Ryan Hamilton 
Message-ID: <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
Subject: Re: Simple transform for improving PN ossification prevention
References: 
 
 
 
 
 
 <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
 
 <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
 <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>

--lw9jK7n5miq0Qg79xB9Ntz7P0UC7kIsjb
Content-Type: multipart/mixed;
 boundary="------------D162289FFDBFEEBA4F78AE9D"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------D162289FFDBFEEBA4F78AE9D
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 11/04/18 16:21, Lubashev, Igor wrote:
> * Are we asking all Internet users to pay a tax to improve privacy?
> Does the amount of the tax justify the amount of privacy benefits it
> buys?
I think that (and your other questions) are good things to
ponder, but I don't believe the questions above are really
answerable, at least not unless we can also answer the
opposite question ("Are we asking all Internet users to pay
a tax by not improving privacy?"), and I'm pretty sure I
at least don't know how to evaluate that question. Maybe
that's part of why this discussion is so tricky.

Personally, as a future user of QUIC (but not an implementer),
I'd really prefer that the WG prioritise privacy-friendly
mechanisms if at all possible, even if the direct benefits
aren't completely clear.

Cheers,
S.

--------------D162289FFDBFEEBA4F78AE9D
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------D162289FFDBFEEBA4F78AE9D--

--lw9jK7n5miq0Qg79xB9Ntz7P0UC7kIsjb--

--SMrnRyY4SgsbwRQwW8CYptci8VI2TVzbi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJaziufAAoJEFqy+vF7FyvqXFoP/RYyRHRi1PozHRQvfQ6X3/TT
R8+0b7cWarK7CwtwmyQowFpX9Re7OT33Lof1aI3NDV4738jEjezrXIPbmiaZlI+u
EKTzFB6z8b+cPsFETGDjN3NJdSxyu7V+tDkaiyugI2WjMRcIWh6KcZEAsr4CHoWf
+RYrrBAADZqH3sddTXyittnTSJKFKXi3YWGeWnKBAUoqopM4aw7h+gBF/CDfM58m
ZSbLuk1c2wif1hm1M+VblXhrWMYp8HpPP89TMpv2mw7if95tOA6l4OkFcq5Ocu+B
3/MOFG6sPOyHsEx6EomOhQPr2MrKreROaKRhX01ERMyRQy8ZIpyLDCBeDEY7w/pN
kMu4x5Y+QV6g9rEVU4NIpHDiZR1cEkiVDBqWZMCUDTvt+q74OxHHS9+sv3z2Y1u2
M96yks3wr2P2bTn5f38GPul5q9TgP92k0vYgjtT7R/z15/HH51h/hMEv0K9gcTfZ
UeaZrWHa3eUMAuHBaoc55tWdj6XXeLqb14MECdIayrwpDrpdk7bf5oBntw5WFY3d
kroEX/o8tJqvW+1ToXrQbzYTJwMW28+ud26sl/JliN/ob1YWHetbdEgX/m1neIkq
WUanjzQldhr13vI89rqEkPzSV1qnsnJUQHCNK3vLr8+ccoj8yKS59UngbGsG62jl
EZTHKRC+v+ZLH2+GA62M
=BeD3
-----END PGP SIGNATURE-----

--SMrnRyY4SgsbwRQwW8CYptci8VI2TVzbi--


From nobody Wed Apr 11 08:46:49 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FE012702E for ; Wed, 11 Apr 2018 08:46:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523461607; bh=ZJQbFBSfTaWdLX3wn/Sd5XibQ7FYTnl6qAZDcAZxReg=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To:To:To:To; b=AdKTh+3nTx2E3Vnl2hrpFTY17AmvVbWQo1uK0uQ4sYla6pFn7ExjiIzLHiX//CHCI i9Io1PHU0zduu0i0UemyZcKvxiyzGS8zrM2L0WwtGJLNxyFCRXEEJmXvAypRuadUGi HRrVBnDPzP1iqxoohrjVr98WvtpmDCcoiBGTxTIg=
X-Mailbox-Line: From stephen.farrell@cs.tcd.ie  Wed Apr 11 08:46:47 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDF51200FC; Wed, 11 Apr 2018 08:46:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523461607; bh=ZJQbFBSfTaWdLX3wn/Sd5XibQ7FYTnl6qAZDcAZxReg=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To:To:To:To; b=AdKTh+3nTx2E3Vnl2hrpFTY17AmvVbWQo1uK0uQ4sYla6pFn7ExjiIzLHiX//CHCI i9Io1PHU0zduu0i0UemyZcKvxiyzGS8zrM2L0WwtGJLNxyFCRXEEJmXvAypRuadUGi HRrVBnDPzP1iqxoohrjVr98WvtpmDCcoiBGTxTIg=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878F712702E for ; Wed, 11 Apr 2018 08:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiKHYTd1XjOa for ; Wed, 11 Apr 2018 08:46:45 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508131200FC for ; Wed, 11 Apr 2018 08:46:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 47AA4BE4D; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNg1aqafWFqU; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F0B33BDD8; Wed, 11 Apr 2018 16:37:03 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1523461024; bh=ZJQbFBSfTaWdLX3wn/Sd5XibQ7FYTnl6qAZDcAZxReg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Z0O9iYdoJdVJMKHGGxmIQueaCoepnIf9SZpIv/yWL/wplS1xqJq+Oqb6BkF7q4VN5 135W5HgDEzpsLtx+Y1xZC5BaSDyA9608sYj5nrW/o0pde98DQ2DkvlYsheTldmKOHS pEzkI0W71G2p+XoF4WdLB6G7QREZWELH4cLO0mhc=
Subject: Re: Simple transform for improving PN ossification prevention
Cc: Victor Vasiliev , IETF QUIC WG , Ryan Hamilton 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>
Date: Wed, 11 Apr 2018 16:37:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JBGCoMsypKPYYdhZo4BNO6MuyFVbHv8rK"
To: "Lubashev, Igor" 
To: Roberto Peon 
To: "Fossati, Thomas \(Nokia - GB/Cambridge\)" 
To: Kazuho Oku 
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 15:46:48 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--JBGCoMsypKPYYdhZo4BNO6MuyFVbHv8rK
Content-Type: multipart/mixed; boundary="Qm3sZGDHWzALzvlJHV5HB8AXmUUUlbwSG";
 protected-headers="v1"
From: Stephen Farrell 
To: "Lubashev, Igor" ,
 Roberto Peon ,
 "Fossati, Thomas (Nokia - GB/Cambridge)" ,
 Kazuho Oku ,
 Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG ,
 Ryan Hamilton 
Message-ID: <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>
Subject: Re: Simple transform for improving PN ossification prevention
References: 
 
 
 
 
 
 <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
 
 <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
 <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>

--Qm3sZGDHWzALzvlJHV5HB8AXmUUUlbwSG
Content-Type: multipart/mixed;
 boundary="------------D0BC1A1D96B0729779AB6BD0"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------D0BC1A1D96B0729779AB6BD0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 11/04/18 16:21, Lubashev, Igor wrote:
> * Are we asking all Internet users to pay a tax to improve privacy?
> Does the amount of the tax justify the amount of privacy benefits it
> buys?
I think that (and your other questions) are good things to
ponder, but I don't believe the questions above are really
answerable, at least not unless we can also answer the
opposite question ("Are we asking all Internet users to pay
a tax by not improving privacy?"), and I'm pretty sure I
at least don't know how to evaluate that question. Maybe
that's part of why this discussion is so tricky.

Personally, as a future user of QUIC (but not an implementer),
I'd really prefer that the WG prioritise privacy-friendly
mechanisms if at all possible, even if the direct benefits
aren't completely clear.

Cheers,
S.

--------------D0BC1A1D96B0729779AB6BD0
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------D0BC1A1D96B0729779AB6BD0--

--Qm3sZGDHWzALzvlJHV5HB8AXmUUUlbwSG--

--JBGCoMsypKPYYdhZo4BNO6MuyFVbHv8rK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJaziueAAoJEFqy+vF7Fyvqt6wP/1v/3FOkcbmrmG0BaCx913qE
CLNWIpCXzKdeW12B5er255dUUxBc8jDERCbCq5bAjduqDJoXWdnlFmfeh4v68pFA
eLzcyqukcejBinaLRQvbowEtjUbZpNPxB+OCFMY8C0ASQ9fZYYIPCH/UWomiuwtC
X419PhILX4Neps/+ntoqQWBZ9PrmZlciVawad06bfO9YkHa7OYT8kfTtgjZAkowU
oJVaRZDVSdggQt2eOCgc/HcowLUjjWZX9ddV98zUmUyrf17nmiT0sE1WrBblKB0H
opoIMhQx+GFazMbRIDTYjDRoMR2H54wK6cB7shrNpoHM6/9/ku+b7I0R7dhOgfvi
xeRoJWl5ozQoT5Isf20WMuVGd93tL67mBN8FwTtDlfn8jgwvt/jlUDf2PWpWuGxD
x6Cu2y9R3ef6/Ao/MMauvbVwaAC2NsLawbej3bExkXPY9NrrO9q4q/ONOG+psTYp
Acd78EvwNxuNUcjp4cWhP10YSOQvMZjRMhG9L6+to5Ln7hJWnN3SXK3AFFpy8zHm
Ok/mDyIcGm7wIvyrFd0l7HqasoZcljh4/vOUbH+mRhEpfeoTWwUxQW1cMtvYrir3
wUGKt4DNinDx4oov2gqyDIflmTSc2mD0tWqj8xXM3AkBUTdkdGEYkZD49ivPxI0X
sx4Mi/mxLhtWB4m8ZqgU
=Mvfn
-----END PGP SIGNATURE-----

--JBGCoMsypKPYYdhZo4BNO6MuyFVbHv8rK--


From nobody Wed Apr 11 08:47:00 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E8812702E for ; Wed, 11 Apr 2018 08:46:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523461609; bh=0KTEKJYb7wQqeFldEY/16ealomN82D39Y43WGPPm+18=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To:To:To:To; b=jxN5D4qSgYewtrqEnwrlDoQyuftcfJ4b3njkmOvw/nZrGwud4rPUGXa+Dz+SWwAaw xu6kTYpLCmuNZAkpbzxT+bkumUmiWu/fU3siogRc3JlN7lt7VE6TrfIcH0yKiomK0E 8arWwvhWDvJVxrXFC4orgJXhJ87uffs1NfJuMLvQ=
X-Mailbox-Line: From stephen.farrell@cs.tcd.ie  Wed Apr 11 08:46:49 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E8A127010; Wed, 11 Apr 2018 08:46:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523461609; bh=0KTEKJYb7wQqeFldEY/16ealomN82D39Y43WGPPm+18=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To:To:To:To; b=jxN5D4qSgYewtrqEnwrlDoQyuftcfJ4b3njkmOvw/nZrGwud4rPUGXa+Dz+SWwAaw xu6kTYpLCmuNZAkpbzxT+bkumUmiWu/fU3siogRc3JlN7lt7VE6TrfIcH0yKiomK0E 8arWwvhWDvJVxrXFC4orgJXhJ87uffs1NfJuMLvQ=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBB51200FC for ; Wed, 11 Apr 2018 08:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU8D6Itj8Six for ; Wed, 11 Apr 2018 08:46:45 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509CC127010 for ; Wed, 11 Apr 2018 08:46:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 135AFBE50; Wed, 11 Apr 2018 16:37:05 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmTLIKZjZXYH; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B6603BDD8; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1523461024; bh=0KTEKJYb7wQqeFldEY/16ealomN82D39Y43WGPPm+18=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ScWupvvOXmqUGwQEmWRJszrpSmoUDgULo9BFPuNILsrdLw2uFWsI7euRNkDkZlocs ufnZT9IzocHH7pr5+y3ZKUDkoXSHheCTGnLvTh/EjXBEC0ndrRJ5pFmqDCe6POZAfm qRVzF/CA45tBjbQX+n2R4H6kv/r4q6RUROdv0zes=
Subject: Re: Simple transform for improving PN ossification prevention
Cc: Victor Vasiliev , IETF QUIC WG , Ryan Hamilton 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <9198a18a-266b-d6ee-2545-e75182382b0a@cs.tcd.ie>
Date: Wed, 11 Apr 2018 16:37:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vNQBL9kTULatfeVuthP8b52Jh1CRK3qeN"
To: "Lubashev, Igor" 
To: Roberto Peon 
To: "Fossati, Thomas \(Nokia - GB/Cambridge\)" 
To: Kazuho Oku 
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 15:46:49 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vNQBL9kTULatfeVuthP8b52Jh1CRK3qeN
Content-Type: multipart/mixed; boundary="WxbZ1mng8VazSxsiepsOsxUqZWpU6FB4c";
 protected-headers="v1"
From: Stephen Farrell 
To: "Lubashev, Igor" ,
 Roberto Peon ,
 "Fossati, Thomas (Nokia - GB/Cambridge)" ,
 Kazuho Oku ,
 Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG ,
 Ryan Hamilton 
Message-ID: <9198a18a-266b-d6ee-2545-e75182382b0a@cs.tcd.ie>
Subject: Re: Simple transform for improving PN ossification prevention
References: 
 
 
 
 
 
 <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
 
 <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
 <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>

--WxbZ1mng8VazSxsiepsOsxUqZWpU6FB4c
Content-Type: multipart/mixed;
 boundary="------------133928B5D1C9344B88FCF1F7"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------133928B5D1C9344B88FCF1F7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 11/04/18 16:21, Lubashev, Igor wrote:
> * Are we asking all Internet users to pay a tax to improve privacy?
> Does the amount of the tax justify the amount of privacy benefits it
> buys?
I think that (and your other questions) are good things to
ponder, but I don't believe the questions above are really
answerable, at least not unless we can also answer the
opposite question ("Are we asking all Internet users to pay
a tax by not improving privacy?"), and I'm pretty sure I
at least don't know how to evaluate that question. Maybe
that's part of why this discussion is so tricky.

Personally, as a future user of QUIC (but not an implementer),
I'd really prefer that the WG prioritise privacy-friendly
mechanisms if at all possible, even if the direct benefits
aren't completely clear.

Cheers,
S.

--------------133928B5D1C9344B88FCF1F7
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------133928B5D1C9344B88FCF1F7
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------133928B5D1C9344B88FCF1F7--

--WxbZ1mng8VazSxsiepsOsxUqZWpU6FB4c--

--vNQBL9kTULatfeVuthP8b52Jh1CRK3qeN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJaziugAAoJEFqy+vF7Fyvq5c8QAMz3hum6EtdrLUedGbgStrdR
I4a2L/BZeQ7uNBLXBfJxwepCl6PpwtcrXafMSzDjv6Vv611zDdlP2d8gem4Wdex3
H/fQwRBu3nI9DLUe2pt6FsBg4Tg365mPFQGc+6PlX7USw1ieZBzA/5gJUymX67NM
YkyWdJ1L1+bPNXVhOCkvZqUdGriF6fRUkbSJgs6MHZz2fbMIvzrTeiM9nByvRbxs
ocYGWcOGsR7hMGxiCC0Kh81EGqA1eYXE8pOCkIcFs42YW8UHiB2Yov2ctOYI9Xvo
drU/lR0bUW/Ob4KHbjunFvi6WDuDSo6wKAKH50DiKYTLRSEEMNeYgpNeWxvUHDTV
PbQwyZJhwf6dH9JW7aAIo8jNJcccRVy6NYk6sGL66sLms4/Q9MzJz/DUCjQmKnF2
DZ+9VOS0hYIN2Q62h0u07oa6ZwVHxnE8m3ZFfgUPQjwEfdvtZU+t01DQZJfllOLy
YM579MfKK6zk2/8a+KsCg1jjxB9SgOIOEbf7E26flB9qV2iavbA/4wggpwJ9Cgoh
oOMo+9XUb3KFHVUYvLTdHT60mwjFEG7VCp6yO+aW05mgCTozgZM8vH2DEzF9lVW3
xtSV0nJaVfAiqhVSYeaVg8Q3OFhFbCBJLPqGF4ejdthPMVcPfNc1arc/JKvFfDPX
Zwup3HfTetXjmjTkef8V
=Hs8r
-----END PGP SIGNATURE-----

--vNQBL9kTULatfeVuthP8b52Jh1CRK3qeN--


From nobody Wed Apr 11 08:56:50 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0155512711E for ; Wed, 11 Apr 2018 08:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL0p-cOSaXfX for ; Wed, 11 Apr 2018 08:56:46 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B566A1200FC for ; Wed, 11 Apr 2018 08:56:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 47AA4BE4D; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNg1aqafWFqU; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F0B33BDD8; Wed, 11 Apr 2018 16:37:03 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1523461024; bh=ZJQbFBSfTaWdLX3wn/Sd5XibQ7FYTnl6qAZDcAZxReg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Z0O9iYdoJdVJMKHGGxmIQueaCoepnIf9SZpIv/yWL/wplS1xqJq+Oqb6BkF7q4VN5 135W5HgDEzpsLtx+Y1xZC5BaSDyA9608sYj5nrW/o0pde98DQ2DkvlYsheTldmKOHS pEzkI0W71G2p+XoF4WdLB6G7QREZWELH4cLO0mhc=
Subject: Re: Simple transform for improving PN ossification prevention
To: "Lubashev, Igor" , Roberto Peon , "Fossati, Thomas (Nokia - GB/Cambridge)" , Kazuho Oku , Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG , Ryan Hamilton 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>
Date: Wed, 11 Apr 2018 16:37:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JBGCoMsypKPYYdhZo4BNO6MuyFVbHv8rK"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 15:56:48 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--JBGCoMsypKPYYdhZo4BNO6MuyFVbHv8rK
Content-Type: multipart/mixed; boundary="Qm3sZGDHWzALzvlJHV5HB8AXmUUUlbwSG";
 protected-headers="v1"
From: Stephen Farrell 
To: "Lubashev, Igor" ,
 Roberto Peon ,
 "Fossati, Thomas (Nokia - GB/Cambridge)" ,
 Kazuho Oku ,
 Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG ,
 Ryan Hamilton 
Message-ID: <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>
Subject: Re: Simple transform for improving PN ossification prevention
References: 
 
 
 
 
 
 <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
 
 <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
 <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>

--Qm3sZGDHWzALzvlJHV5HB8AXmUUUlbwSG
Content-Type: multipart/mixed;
 boundary="------------D0BC1A1D96B0729779AB6BD0"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------D0BC1A1D96B0729779AB6BD0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 11/04/18 16:21, Lubashev, Igor wrote:
> * Are we asking all Internet users to pay a tax to improve privacy?
> Does the amount of the tax justify the amount of privacy benefits it
> buys?
I think that (and your other questions) are good things to
ponder, but I don't believe the questions above are really
answerable, at least not unless we can also answer the
opposite question ("Are we asking all Internet users to pay
a tax by not improving privacy?"), and I'm pretty sure I
at least don't know how to evaluate that question. Maybe
that's part of why this discussion is so tricky.

Personally, as a future user of QUIC (but not an implementer),
I'd really prefer that the WG prioritise privacy-friendly
mechanisms if at all possible, even if the direct benefits
aren't completely clear.

Cheers,
S.

--------------D0BC1A1D96B0729779AB6BD0
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------D0BC1A1D96B0729779AB6BD0--

--Qm3sZGDHWzALzvlJHV5HB8AXmUUUlbwSG--

--JBGCoMsypKPYYdhZo4BNO6MuyFVbHv8rK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJaziueAAoJEFqy+vF7Fyvqt6wP/1v/3FOkcbmrmG0BaCx913qE
CLNWIpCXzKdeW12B5er255dUUxBc8jDERCbCq5bAjduqDJoXWdnlFmfeh4v68pFA
eLzcyqukcejBinaLRQvbowEtjUbZpNPxB+OCFMY8C0ASQ9fZYYIPCH/UWomiuwtC
X419PhILX4Neps/+ntoqQWBZ9PrmZlciVawad06bfO9YkHa7OYT8kfTtgjZAkowU
oJVaRZDVSdggQt2eOCgc/HcowLUjjWZX9ddV98zUmUyrf17nmiT0sE1WrBblKB0H
opoIMhQx+GFazMbRIDTYjDRoMR2H54wK6cB7shrNpoHM6/9/ku+b7I0R7dhOgfvi
xeRoJWl5ozQoT5Isf20WMuVGd93tL67mBN8FwTtDlfn8jgwvt/jlUDf2PWpWuGxD
x6Cu2y9R3ef6/Ao/MMauvbVwaAC2NsLawbej3bExkXPY9NrrO9q4q/ONOG+psTYp
Acd78EvwNxuNUcjp4cWhP10YSOQvMZjRMhG9L6+to5Ln7hJWnN3SXK3AFFpy8zHm
Ok/mDyIcGm7wIvyrFd0l7HqasoZcljh4/vOUbH+mRhEpfeoTWwUxQW1cMtvYrir3
wUGKt4DNinDx4oov2gqyDIflmTSc2mD0tWqj8xXM3AkBUTdkdGEYkZD49ivPxI0X
sx4Mi/mxLhtWB4m8ZqgU
=Mvfn
-----END PGP SIGNATURE-----

--JBGCoMsypKPYYdhZo4BNO6MuyFVbHv8rK--


From nobody Wed Apr 11 08:56:55 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136B01200FC for ; Wed, 11 Apr 2018 08:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MntQlyB9zyn for ; Wed, 11 Apr 2018 08:56:46 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B577D1270A7 for ; Wed, 11 Apr 2018 08:56:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 135AFBE50; Wed, 11 Apr 2018 16:37:05 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmTLIKZjZXYH; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B6603BDD8; Wed, 11 Apr 2018 16:37:04 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1523461024; bh=0KTEKJYb7wQqeFldEY/16ealomN82D39Y43WGPPm+18=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ScWupvvOXmqUGwQEmWRJszrpSmoUDgULo9BFPuNILsrdLw2uFWsI7euRNkDkZlocs ufnZT9IzocHH7pr5+y3ZKUDkoXSHheCTGnLvTh/EjXBEC0ndrRJ5pFmqDCe6POZAfm qRVzF/CA45tBjbQX+n2R4H6kv/r4q6RUROdv0zes=
Subject: Re: Simple transform for improving PN ossification prevention
To: "Lubashev, Igor" , Roberto Peon , "Fossati, Thomas (Nokia - GB/Cambridge)" , Kazuho Oku , Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG , Ryan Hamilton 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <9198a18a-266b-d6ee-2545-e75182382b0a@cs.tcd.ie>
Date: Wed, 11 Apr 2018 16:37:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vNQBL9kTULatfeVuthP8b52Jh1CRK3qeN"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 15:56:48 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vNQBL9kTULatfeVuthP8b52Jh1CRK3qeN
Content-Type: multipart/mixed; boundary="WxbZ1mng8VazSxsiepsOsxUqZWpU6FB4c";
 protected-headers="v1"
From: Stephen Farrell 
To: "Lubashev, Igor" ,
 Roberto Peon ,
 "Fossati, Thomas (Nokia - GB/Cambridge)" ,
 Kazuho Oku ,
 Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG ,
 Ryan Hamilton 
Message-ID: <9198a18a-266b-d6ee-2545-e75182382b0a@cs.tcd.ie>
Subject: Re: Simple transform for improving PN ossification prevention
References: 
 
 
 
 
 
 <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
 
 <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
 <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>

--WxbZ1mng8VazSxsiepsOsxUqZWpU6FB4c
Content-Type: multipart/mixed;
 boundary="------------133928B5D1C9344B88FCF1F7"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------133928B5D1C9344B88FCF1F7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 11/04/18 16:21, Lubashev, Igor wrote:
> * Are we asking all Internet users to pay a tax to improve privacy?
> Does the amount of the tax justify the amount of privacy benefits it
> buys?
I think that (and your other questions) are good things to
ponder, but I don't believe the questions above are really
answerable, at least not unless we can also answer the
opposite question ("Are we asking all Internet users to pay
a tax by not improving privacy?"), and I'm pretty sure I
at least don't know how to evaluate that question. Maybe
that's part of why this discussion is so tricky.

Personally, as a future user of QUIC (but not an implementer),
I'd really prefer that the WG prioritise privacy-friendly
mechanisms if at all possible, even if the direct benefits
aren't completely clear.

Cheers,
S.

--------------133928B5D1C9344B88FCF1F7
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------133928B5D1C9344B88FCF1F7
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------133928B5D1C9344B88FCF1F7--

--WxbZ1mng8VazSxsiepsOsxUqZWpU6FB4c--

--vNQBL9kTULatfeVuthP8b52Jh1CRK3qeN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJaziugAAoJEFqy+vF7Fyvq5c8QAMz3hum6EtdrLUedGbgStrdR
I4a2L/BZeQ7uNBLXBfJxwepCl6PpwtcrXafMSzDjv6Vv611zDdlP2d8gem4Wdex3
H/fQwRBu3nI9DLUe2pt6FsBg4Tg365mPFQGc+6PlX7USw1ieZBzA/5gJUymX67NM
YkyWdJ1L1+bPNXVhOCkvZqUdGriF6fRUkbSJgs6MHZz2fbMIvzrTeiM9nByvRbxs
ocYGWcOGsR7hMGxiCC0Kh81EGqA1eYXE8pOCkIcFs42YW8UHiB2Yov2ctOYI9Xvo
drU/lR0bUW/Ob4KHbjunFvi6WDuDSo6wKAKH50DiKYTLRSEEMNeYgpNeWxvUHDTV
PbQwyZJhwf6dH9JW7aAIo8jNJcccRVy6NYk6sGL66sLms4/Q9MzJz/DUCjQmKnF2
DZ+9VOS0hYIN2Q62h0u07oa6ZwVHxnE8m3ZFfgUPQjwEfdvtZU+t01DQZJfllOLy
YM579MfKK6zk2/8a+KsCg1jjxB9SgOIOEbf7E26flB9qV2iavbA/4wggpwJ9Cgoh
oOMo+9XUb3KFHVUYvLTdHT60mwjFEG7VCp6yO+aW05mgCTozgZM8vH2DEzF9lVW3
xtSV0nJaVfAiqhVSYeaVg8Q3OFhFbCBJLPqGF4ejdthPMVcPfNc1arc/JKvFfDPX
Zwup3HfTetXjmjTkef8V
=Hs8r
-----END PGP SIGNATURE-----

--vNQBL9kTULatfeVuthP8b52Jh1CRK3qeN--


From nobody Wed Apr 11 09:37:18 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7691276AF for ; Wed, 11 Apr 2018 09:37:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523464636; bh=e58/OIvhsJtLL2L5o2fVspF14JEtNenAvKcJtzHE9Nc=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To:To:To:To; b=Z/J4rs+4vC1EO9vfb93w2ovQa7VYBNZfl/0e1BzkqIb8UjZ4+ExHqnegq+Jz8Wjum OMRoyuC+Se5ulYxu4SKLYF8dggkVYHgv6Lbg3Q0S16dFAs+rbcsTijfMlxE8IPKNwG yTN+3tPFZKkSy+V++gBoKEanwaQORMebg1kc3h0o=
X-Mailbox-Line: From ilubashe@akamai.com  Wed Apr 11 09:37:15 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B551126C25; Wed, 11 Apr 2018 09:37:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523464635; bh=e58/OIvhsJtLL2L5o2fVspF14JEtNenAvKcJtzHE9Nc=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To:To:To:To; b=IVhHg8Sm+LLhaO1h3FQsB8SrTIL0duPPFAseLE1Rmqrz5Jhn5rFkjB1Dp1PK715sp Km31b8YDIPg7jLIvx8kMkwMZc25dFvw2p+uOK7EHpw8KJep5LL82pi+k0SHLiHo4z8 sQGUt9yXnUaEmV49fdWx+RFEzvTXAdDDl06sRv+E=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6914E12762F for ; Wed, 11 Apr 2018 09:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zudGAXNDlD6Z for ; Wed, 11 Apr 2018 09:37:13 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A542A126C25 for ; Wed, 11 Apr 2018 09:37:13 -0700 (PDT)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3BGURVW020742; Wed, 11 Apr 2018 17:37:10 +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=e58/OIvhsJtLL2L5o2fVspF14JEtNenAvKcJtzHE9Nc=; b=VQMgdI4DM0koL/c//cvMCQ5l/Osl8YTewsFdTyJOrqBgwQ7PBQ90Q680EhkHo3qN8jLs 5I8pjr6sM1vHXCYvJM5Hg8cey9qBdE1b20C2qzbMQpPmM6v3bok9CugWMxpSVJXgoy8n nQJPO4NrgU2O8ivF8kvxcCMDZ6/yNoP9CLWYkph9HMs+NKruty+I1x7D9lI0vZ2GSad6 TbbKq2dmoNeauWnro1u22rhCm1tCrd6z7l+ySvfAyzfAShtEsPSm02KXbrhKczWadLgN V9DFHdidE0Wep6tcwCv3n/ZmH7XCM8BFVdje0bThNMFQQL0LtO626iDNzaQgxjFzsZh0 DA== 
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2h6uttkgmg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 17:37:10 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3BGaZlO030597; Wed, 11 Apr 2018 12:37:09 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2h6saur3nf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 12:37:09 -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.1365.1; Wed, 11 Apr 2018 12:37:08 -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.1365.000; Wed, 11 Apr 2018 12:37:08 -0400
From: "Lubashev, Igor" 
CC: Victor Vasiliev , IETF QUIC WG , "Ryan Hamilton" 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAgCbeAABH1ToAAB78MgAAEx/uAAAb1bwAADHjfgAAAkzqAAAEjd4AABEmfIAAKNo+AAAcX+OA=
Date: Wed, 11 Apr 2018 16:37:07 +0000
Message-ID: <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
In-Reply-To: <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.33.243]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110154
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110153
To: Stephen Farrell 
To: "Lubashev, Igor" 
To: Roberto Peon 
To: "Fossati, Thomas \(Nokia - GB/Cambridge\)" 
To: Kazuho Oku 
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 16:37:16 -0000

WWVzLCB0aGVzZSBhcmUgZGlmZmljdWx0IHF1ZXN0aW9ucywgZXNwZWNpYWxseSBzaW5jZSBtb3N0
IG9mIHRoZSBpbmZvcm1hdGlvbiBpcyB1bmtub3duLCBhbmQgd2UgYXJlIHRvIHdlaWdoIGVzdGlt
YXRlcyBhbmQgcmlza3MgYWdhaW5zdCBlYWNoIG90aGVyLiAgQnV0IHRoaXMgaXMgZXNwZWNpYWxs
eSBpbXBvcnRhbnQgd2hlbiBzbyBtYW55IHRoaW5ncyBhcmUgdW5jZXJ0YWluIHRvIGtlZXAgYXQg
bGVhc3QgdGhlIHF1ZXN0aW9ucyB3ZSBhcmUgYW5zd2VyaW5nIGNsZWFyLiAgSGVuY2UsIEkgd291
bGQgY29uc2lkZXIgIkFyZSB3ZSBhc2tpbmcgYWxsIEludGVybmV0IHVzZXJzIHRvIHBheSBhIHRh
eCBieSBub3QgaW1wcm92aW5nIHByaXZhY3k/IiB0byBiZSBub3QgYSBjbGVhciBxdWVzdGlvbiBi
dXQgYSByaGV0b3JpY2FsIG9uZS4gIEkgbWVhbnQgInRheCIgaW4gYSB2ZXJ5IHNwZWNpZmljIHdh
eSAtLSB0aGUgcmVhbC13b3JsZCBfZmluYW5jaWFsXyBjb3N0LiAgSSBzcGVjaWZpY2FsbHkgd2Fu
dCB0byBwb3NlIHF1ZXN0aW9ucyBvZiB0cmFkZS1vZmZzIG9mIGZpbmFuY2lhbCBjb3N0cyB2cy4g
YmVuZWZpdHMgKHZlcnkgdmFsdWFibGUgYmVuZWZpdHMgdG8gYmUgc3VyZSkuDQoNCiogQXJlIHdl
IGFza2luZyBhbGwgSW50ZXJuZXQgdXNlcnMgdG8gcGF5IGEgdGF4IHRvIGltcHJvdmUgcHJpdmFj
eT8gIERvZXMgdGhlIGFtb3VudCBvZiB0aGUgdGF4IGp1c3RpZnkgdGhlIGFtb3VudCBvZiBwcml2
YWN5IGJlbmVmaXRzIGl0IGJ1eXM/DQoNCiogQXJlIHdlIGFza2luZyBhbGwgSW50ZXJuZXQgdXNl
cnMgdG8gcGF5IGEgdGF4IHRvIHJlZHVjZSBQTiBvc3NpZmljYXRpb24/ICBEb2VzIHRoZSBhbW91
bnQgb2YgdGhlIHRheCBqdXN0aWZ5IHRoZSBhZGRlZCBmbGV4aWJpbGl0eSBwcm90b2NvbCBkZXNp
Z25lcnMgbWlnaHQgbmVlZCBpbiB0aGUgZnV0dXJlPw0KDQoNCi0gSWdvcg0KDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVu
LmZhcnJlbGxAY3MudGNkLmllXSANClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTEsIDIwMTggMTE6
MzcgQU0NClRvOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGU9NDBha2FtYWkuY29tQGRtYXJjLmll
dGYub3JnPjsgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+OyBGb3NzYXRpLCBUaG9tYXMgKE5v
a2lhIC0gR0IvQ2FtYnJpZGdlKSA8dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tPjsgS2F6dWhvIE9r
dSA8a2F6dWhvb2t1QGdtYWlsLmNvbT47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBt
aWNyb3NvZnQuY29tPg0KQ2M6IFZpY3RvciBWYXNpbGlldiA8dmFzaWx2dkBnb29nbGUuY29tPjsg
SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2dsZS5j
b20+DQpTdWJqZWN0OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lm
aWNhdGlvbiBwcmV2ZW50aW9uDQoNCg0KSGl5YSwNCg0KT24gMTEvMDQvMTggMTY6MjEsIEx1YmFz
aGV2LCBJZ29yIHdyb3RlOg0KPiAqIEFyZSB3ZSBhc2tpbmcgYWxsIEludGVybmV0IHVzZXJzIHRv
IHBheSBhIHRheCB0byBpbXByb3ZlIHByaXZhY3k/DQo+IERvZXMgdGhlIGFtb3VudCBvZiB0aGUg
dGF4IGp1c3RpZnkgdGhlIGFtb3VudCBvZiBwcml2YWN5IGJlbmVmaXRzIGl0IA0KPiBidXlzPw0K
SSB0aGluayB0aGF0IChhbmQgeW91ciBvdGhlciBxdWVzdGlvbnMpIGFyZSBnb29kIHRoaW5ncyB0
byBwb25kZXIsIGJ1dCBJIGRvbid0IGJlbGlldmUgdGhlIHF1ZXN0aW9ucyBhYm92ZSBhcmUgcmVh
bGx5IGFuc3dlcmFibGUsIGF0IGxlYXN0IG5vdCB1bmxlc3Mgd2UgY2FuIGFsc28gYW5zd2VyIHRo
ZSBvcHBvc2l0ZSBxdWVzdGlvbiAoIkFyZSB3ZSBhc2tpbmcgYWxsIEludGVybmV0IHVzZXJzIHRv
IHBheSBhIHRheCBieSBub3QgaW1wcm92aW5nIHByaXZhY3k/IiksIGFuZCBJJ20gcHJldHR5IHN1
cmUgSSBhdCBsZWFzdCBkb24ndCBrbm93IGhvdyB0byBldmFsdWF0ZSB0aGF0IHF1ZXN0aW9uLiBN
YXliZSB0aGF0J3MgcGFydCBvZiB3aHkgdGhpcyBkaXNjdXNzaW9uIGlzIHNvIHRyaWNreS4NCg0K
UGVyc29uYWxseSwgYXMgYSBmdXR1cmUgdXNlciBvZiBRVUlDIChidXQgbm90IGFuIGltcGxlbWVu
dGVyKSwgSSdkIHJlYWxseSBwcmVmZXIgdGhhdCB0aGUgV0cgcHJpb3JpdGlzZSBwcml2YWN5LWZy
aWVuZGx5IG1lY2hhbmlzbXMgaWYgYXQgYWxsIHBvc3NpYmxlLCBldmVuIGlmIHRoZSBkaXJlY3Qg
YmVuZWZpdHMgYXJlbid0IGNvbXBsZXRlbHkgY2xlYXIuDQoNCkNoZWVycywNClMuDQo=


From nobody Wed Apr 11 09:37:33 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE71C12D869 for ; Wed, 11 Apr 2018 09:37:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable 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 x4yTZEut5Cqx for ; Wed, 11 Apr 2018 09:37:19 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB68128961 for ; Wed, 11 Apr 2018 09:37:18 -0700 (PDT)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3BGURVW020742; Wed, 11 Apr 2018 17:37:10 +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=e58/OIvhsJtLL2L5o2fVspF14JEtNenAvKcJtzHE9Nc=; b=VQMgdI4DM0koL/c//cvMCQ5l/Osl8YTewsFdTyJOrqBgwQ7PBQ90Q680EhkHo3qN8jLs 5I8pjr6sM1vHXCYvJM5Hg8cey9qBdE1b20C2qzbMQpPmM6v3bok9CugWMxpSVJXgoy8n nQJPO4NrgU2O8ivF8kvxcCMDZ6/yNoP9CLWYkph9HMs+NKruty+I1x7D9lI0vZ2GSad6 TbbKq2dmoNeauWnro1u22rhCm1tCrd6z7l+ySvfAyzfAShtEsPSm02KXbrhKczWadLgN V9DFHdidE0Wep6tcwCv3n/ZmH7XCM8BFVdje0bThNMFQQL0LtO626iDNzaQgxjFzsZh0 DA== 
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2h6uttkgmg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 17:37:10 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3BGaZlO030597; Wed, 11 Apr 2018 12:37:09 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2h6saur3nf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 12:37:09 -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.1365.1; Wed, 11 Apr 2018 12:37:08 -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.1365.000; Wed, 11 Apr 2018 12:37:08 -0400
From: "Lubashev, Igor" 
To: Stephen Farrell , "Lubashev, Igor" , Roberto Peon , "Fossati, Thomas (Nokia - GB/Cambridge)" , "Kazuho Oku" , Praveen Balasubramanian 
CC: Victor Vasiliev , IETF QUIC WG , "Ryan Hamilton" 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAgCbeAABH1ToAAB78MgAAEx/uAAAb1bwAADHjfgAAAkzqAAAEjd4AABEmfIAAKNo+AAAcX+OA=
Date: Wed, 11 Apr 2018 16:37:07 +0000
Message-ID: <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
In-Reply-To: <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.33.243]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110154
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110153
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 16:37:24 -0000

WWVzLCB0aGVzZSBhcmUgZGlmZmljdWx0IHF1ZXN0aW9ucywgZXNwZWNpYWxseSBzaW5jZSBtb3N0
IG9mIHRoZSBpbmZvcm1hdGlvbiBpcyB1bmtub3duLCBhbmQgd2UgYXJlIHRvIHdlaWdoIGVzdGlt
YXRlcyBhbmQgcmlza3MgYWdhaW5zdCBlYWNoIG90aGVyLiAgQnV0IHRoaXMgaXMgZXNwZWNpYWxs
eSBpbXBvcnRhbnQgd2hlbiBzbyBtYW55IHRoaW5ncyBhcmUgdW5jZXJ0YWluIHRvIGtlZXAgYXQg
bGVhc3QgdGhlIHF1ZXN0aW9ucyB3ZSBhcmUgYW5zd2VyaW5nIGNsZWFyLiAgSGVuY2UsIEkgd291
bGQgY29uc2lkZXIgIkFyZSB3ZSBhc2tpbmcgYWxsIEludGVybmV0IHVzZXJzIHRvIHBheSBhIHRh
eCBieSBub3QgaW1wcm92aW5nIHByaXZhY3k/IiB0byBiZSBub3QgYSBjbGVhciBxdWVzdGlvbiBi
dXQgYSByaGV0b3JpY2FsIG9uZS4gIEkgbWVhbnQgInRheCIgaW4gYSB2ZXJ5IHNwZWNpZmljIHdh
eSAtLSB0aGUgcmVhbC13b3JsZCBfZmluYW5jaWFsXyBjb3N0LiAgSSBzcGVjaWZpY2FsbHkgd2Fu
dCB0byBwb3NlIHF1ZXN0aW9ucyBvZiB0cmFkZS1vZmZzIG9mIGZpbmFuY2lhbCBjb3N0cyB2cy4g
YmVuZWZpdHMgKHZlcnkgdmFsdWFibGUgYmVuZWZpdHMgdG8gYmUgc3VyZSkuDQoNCiogQXJlIHdl
IGFza2luZyBhbGwgSW50ZXJuZXQgdXNlcnMgdG8gcGF5IGEgdGF4IHRvIGltcHJvdmUgcHJpdmFj
eT8gIERvZXMgdGhlIGFtb3VudCBvZiB0aGUgdGF4IGp1c3RpZnkgdGhlIGFtb3VudCBvZiBwcml2
YWN5IGJlbmVmaXRzIGl0IGJ1eXM/DQoNCiogQXJlIHdlIGFza2luZyBhbGwgSW50ZXJuZXQgdXNl
cnMgdG8gcGF5IGEgdGF4IHRvIHJlZHVjZSBQTiBvc3NpZmljYXRpb24/ICBEb2VzIHRoZSBhbW91
bnQgb2YgdGhlIHRheCBqdXN0aWZ5IHRoZSBhZGRlZCBmbGV4aWJpbGl0eSBwcm90b2NvbCBkZXNp
Z25lcnMgbWlnaHQgbmVlZCBpbiB0aGUgZnV0dXJlPw0KDQoNCi0gSWdvcg0KDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVu
LmZhcnJlbGxAY3MudGNkLmllXSANClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTEsIDIwMTggMTE6
MzcgQU0NClRvOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGU9NDBha2FtYWkuY29tQGRtYXJjLmll
dGYub3JnPjsgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+OyBGb3NzYXRpLCBUaG9tYXMgKE5v
a2lhIC0gR0IvQ2FtYnJpZGdlKSA8dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tPjsgS2F6dWhvIE9r
dSA8a2F6dWhvb2t1QGdtYWlsLmNvbT47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBt
aWNyb3NvZnQuY29tPg0KQ2M6IFZpY3RvciBWYXNpbGlldiA8dmFzaWx2dkBnb29nbGUuY29tPjsg
SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2dsZS5j
b20+DQpTdWJqZWN0OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lm
aWNhdGlvbiBwcmV2ZW50aW9uDQoNCg0KSGl5YSwNCg0KT24gMTEvMDQvMTggMTY6MjEsIEx1YmFz
aGV2LCBJZ29yIHdyb3RlOg0KPiAqIEFyZSB3ZSBhc2tpbmcgYWxsIEludGVybmV0IHVzZXJzIHRv
IHBheSBhIHRheCB0byBpbXByb3ZlIHByaXZhY3k/DQo+IERvZXMgdGhlIGFtb3VudCBvZiB0aGUg
dGF4IGp1c3RpZnkgdGhlIGFtb3VudCBvZiBwcml2YWN5IGJlbmVmaXRzIGl0IA0KPiBidXlzPw0K
SSB0aGluayB0aGF0IChhbmQgeW91ciBvdGhlciBxdWVzdGlvbnMpIGFyZSBnb29kIHRoaW5ncyB0
byBwb25kZXIsIGJ1dCBJIGRvbid0IGJlbGlldmUgdGhlIHF1ZXN0aW9ucyBhYm92ZSBhcmUgcmVh
bGx5IGFuc3dlcmFibGUsIGF0IGxlYXN0IG5vdCB1bmxlc3Mgd2UgY2FuIGFsc28gYW5zd2VyIHRo
ZSBvcHBvc2l0ZSBxdWVzdGlvbiAoIkFyZSB3ZSBhc2tpbmcgYWxsIEludGVybmV0IHVzZXJzIHRv
IHBheSBhIHRheCBieSBub3QgaW1wcm92aW5nIHByaXZhY3k/IiksIGFuZCBJJ20gcHJldHR5IHN1
cmUgSSBhdCBsZWFzdCBkb24ndCBrbm93IGhvdyB0byBldmFsdWF0ZSB0aGF0IHF1ZXN0aW9uLiBN
YXliZSB0aGF0J3MgcGFydCBvZiB3aHkgdGhpcyBkaXNjdXNzaW9uIGlzIHNvIHRyaWNreS4NCg0K
UGVyc29uYWxseSwgYXMgYSBmdXR1cmUgdXNlciBvZiBRVUlDIChidXQgbm90IGFuIGltcGxlbWVu
dGVyKSwgSSdkIHJlYWxseSBwcmVmZXIgdGhhdCB0aGUgV0cgcHJpb3JpdGlzZSBwcml2YWN5LWZy
aWVuZGx5IG1lY2hhbmlzbXMgaWYgYXQgYWxsIHBvc3NpYmxlLCBldmVuIGlmIHRoZSBkaXJlY3Qg
YmVuZWZpdHMgYXJlbid0IGNvbXBsZXRlbHkgY2xlYXIuDQoNCkNoZWVycywNClMuDQo=


From nobody Wed Apr 11 10:04:00 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA54212762F for ; Wed, 11 Apr 2018 10:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO0vhP12Hm9r for ; Wed, 11 Apr 2018 10:03:58 -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 E9D1B127241 for ; Wed, 11 Apr 2018 10:03:57 -0700 (PDT)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx67.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1f6J8Q-0005Gy-E5 for quic@ietf.org; Wed, 11 Apr 2018 19:02:25 +0200
Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1f6J7K-0001Mg-GI for quic@ietf.org; Wed, 11 Apr 2018 13:01:06 -0400
Received: (qmail 8135 invoked from network); 11 Apr 2018 16:32:48 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.61]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Apr 2018 16:32:48 -0000
To: quic@ietf.org
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>
From: Christian Huitema 
Openpgp: preference=signencrypt
Message-ID: 
Date: Wed, 11 Apr 2018 09:32:39 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hTY5LVmFQRD7YZLLiY6O7598zh75ysTAZ"
Subject: Re: Simple transform for improving PN ossification prevention
X-Originating-IP: 168.144.250.245
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.38)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5tC3ZJTp3F0aPwktEhySHDN602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViVxNstYnPgeg2zicuayFZSM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBuUr1xlTzNqsfVzHDPFP8hh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpXCfkTKtiYrN2n3IcaXAOcqnnXm95a0vRtjH3/UwFOlrejKdZRIe6rc V+bXlCqleKm3B+q+bUHXAsYFgsNREGhlzTFYPIyr5voE3ggyv83xvYRfyCMB4QZToA5YKb0SaS5E llm5CBzrwBATJ22MAarYDrnzsG5f+caI1dL5Ye/k8E7k+vjbEFIODONvVl7uk82hwkUrqlWfY+jJ Wqs8TJ58vwL8dBaG4DsB0pkkciat3dfH1yALUGC6BHMPRvkcc+0OvUbAhuBcxhaqUsiJeMQS9R/2 gMGq0KWAzmMf+ibVDq6cyN5oTOsLjetNPyF2Ho+qWKEc9MBxZCWS72/wjopIVAY+3RHRetx4B6Z4 Ei5woFss+n2ffnQxt6aJ7klZab+5U3mWTJPTqb+xVIKqgeO7n3iwosDmKSszPVW9RecIRsxn9uie 2n4+ooHGqAOWILQxL7hrJSk60SF3F6RYOYr2
X-Report-Abuse-To: spam@quarantine6.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, 11 Apr 2018 17:04:00 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--hTY5LVmFQRD7YZLLiY6O7598zh75ysTAZ
Content-Type: multipart/mixed; boundary="ynmmWvKomCFPmKUu1WuQAL1IDvpyJnH5o";
 protected-headers="v1"
From: Christian Huitema 
To: quic@ietf.org
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
References: 
 
 
 
 
 
 <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
 
 <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
 <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
 <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>
In-Reply-To: <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>

--ynmmWvKomCFPmKUu1WuQAL1IDvpyJnH5o
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

On 4/11/2018 8:37 AM, Stephen Farrell wrote:

> Personally, as a future user of QUIC (but not an implementer),
> I'd really prefer that the WG prioritise privacy-friendly
> mechanisms if at all possible, even if the direct benefits
> aren't completely clear.

Second that. Praveen and Igor are making a fine point about performance,
but in my book performance optimization should be done after we have the
agreed functionality going. So, I would see the following sequence:

1) Agree that we want to prevent PN tracking, middlebox shenanigans, and
ossification. I think we do have rough consensus on that.

2) Check in PR #1079 as a basic way to accomplish this now.

3) Study higher performance alternative and a negotiation mechanism later=
=2E

-- Christian Huitema





--ynmmWvKomCFPmKUu1WuQAL1IDvpyJnH5o--

--hTY5LVmFQRD7YZLLiY6O7598zh75ysTAZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJazjiuAAoJELba05IUOHVQdzMH/jEbWY6bC4vCBV/8AnOV6z2T
9R0OF6fOjddtJgMJmvFdpn7y7LxokCwW6Qww59+7NZpfnfDXL+fNB/1aPvccnxwp
gBdhQxs12w5gygjv1ACUmjQsSuwiJVphBimqt9mx8YS0qe7H0bgGl+qZnyAhud6z
aQdJsFftUlUUz9dudlaT86Egdf0VdzfHZRg4I9mJ1G6RGAA2J/rgX8Ws59T9BZ6B
MpoZH8ji9Mj0Mu89EmmXm3rBVq5LHfpe+213f1tnyhL5L3bQX66CKeB1hNRu5SFC
ffqmfXnC4Areb1r9XRpHTw4kz98LXGpWrikkfWfQ1EjyYROe8EE1E+lOH/o4gpM=
=UHrY
-----END PGP SIGNATURE-----

--hTY5LVmFQRD7YZLLiY6O7598zh75ysTAZ--


From nobody Wed Apr 11 10:06:29 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95F7127735 for ; Wed, 11 Apr 2018 10:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsexjqDrvZ-5 for ; Wed, 11 Apr 2018 10:06:25 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0134.outbound.protection.outlook.com [104.47.34.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F48F1276AF for ; Wed, 11 Apr 2018 10:06:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RGJMtpkUxbDg3oCrBi5pgTu7e3dKFttsHd/TtL0q2x0=; b=m61I80IDQIkUDGT+2MV490OWxyR6Q/yA3FlF3tjCiGu4QATMJFmLjrbz4veOLPpCQzswNsGyNlz+GH+GsI3jZZy/TxGAYrK2Eow3+K+kQ+qWC51XYmKDxl/kfyHneM50m4iDuagA9rAvJyaCVA8BHM0LUAMj5F179MkcG/jXh9U=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0182.namprd21.prod.outlook.com (10.173.193.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.3; Wed, 11 Apr 2018 17:06:24 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.006; Wed, 11 Apr 2018 17:06:24 +0000
From: Praveen Balasubramanian 
To: huitema , "quic@ietf.org" 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAuyyQD//+5tAIAAipkA//+DHACAAOT9gIAABF0AgAAPioD///bsEA==
Date: Wed, 11 Apr 2018 17:06:23 +0000
Message-ID: 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:a::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0182; 7:jDFvT0rkgcbt1LxrtAw9Wa5XLDOBtDF8vsvSTZ+R1ElpUKos0hGsMfpniAosvIKdLJjLPLJauMypPBO20599ElMJL9kwpnBhBqh0fsstlAVWpUCJGn16hYTMMlxTFG+kewBrMhQrbPzIDcAH1ur+FGn+catZ+YdcjMlC9C6q44K5HagljDkuKc4fY9bkyyytHhhIHdvZaIFdgiqzX9F8d22JUnz07PBMnRvawCiOE5mzHW3qv8TLlV2Oj3hCpJrP; 20:Sw43XCEKWE94lDNSt9jF9NQ3Xj5JMBIrsGdu2Bn9oHoSDh9zEf2gyobdb2MGWpxSKuwKI1Md8DfPOfE7I0prRBB0LT72IdIsjI6yVJVp8xXzs+2cHm11sGknsIxdtm43VyNZYyEVrZ5Lo/AInH4WKn0GBi+7VKaxYfPtaqgf7/k=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0182; 
x-ms-traffictypediagnostic: CY4PR21MB0182:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR21MB0182; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0182; 
x-forefront-prvs: 0639027A9E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(396003)(376002)(39380400002)(13464003)(189003)(199004)(53936002)(102836004)(76176011)(9686003)(53546011)(7696005)(46003)(6506007)(99286004)(110136005)(25786009)(316002)(33656002)(86612001)(3280700002)(478600001)(3660700001)(22452003)(93886005)(105586002)(10290500003)(186003)(6246003)(2906002)(14454004)(5250100002)(2501003)(81166006)(8676002)(81156014)(229853002)(10090500001)(7736002)(74316002)(305945005)(106356001)(8990500004)(5660300001)(6116002)(2900100001)(446003)(6436002)(86362001)(68736007)(476003)(11346002)(55016002)(97736004)(8936002)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0182; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: RkOC7toSW6yODFihqIO+07+3Xt91qonwRuykNyPvooeH3UsK3ZmqwQBfW6OMTA4d/6WH6d7GUjc1ccF1wvXpsk0kUz2UNjONBMY8xmiTe2lwrdLnk4e8E6VZyHJuhmDRetkuGs9mLbuh2wExHLy+v+hZP4J17yZgqsQtIL1Gg9D1/+9PjMZV+FNZ1CX4ttVSG4lyc5RqPATWm9mCG4g+SYfBnWgGe7IwY47BH74IKPhWrRsiw4kGTFeORRU7Dnt3qM/9mTyCJEN9q+x59hFxHITRov2f4RjtiogKmAyv8o/6AZoaka+K708Zc3GZgj4F2QGkmMRAOtqKGVqcAM3xQdppWq+Ip67Bm8rDpRx10Qqrq4AyJkLZ/lprDHqTOtlzU9G/cxZXlDU7nGoTNSrzrkOyYlSS2RQNisNnkC1IBAM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: b664b084-196f-42e8-2e09-08d59fce8e34
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b664b084-196f-42e8-2e09-08d59fce8e34
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 17:06:23.9250 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0182
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 17:06:28 -0000

Tm90IGp1c3QgdXNlcnMsIGJ1dCB3ZWIgc2VydmljZSBwcm92aWRlcnMgYXJlIGFmZmVjdGVkLiBB
cyBhbiBpbXBsZW1lbnRlciBhbmQgc29tZW9uZSB3aG8gd2lsbCBuZWVkIHRvIGNvbnZpbmNlIHdv
cmtsb2FkcyB0byBhZG9wdCBRVUlDIGF0IHNjYWxlLCBJIGhhdmUgdGhlIHZpZXcgdGhhdCB3ZSBz
aG91bGQgbWluaW1pemUgY29tcGxleGl0eSBhbmQgY29zdCB1bmxlc3MgcHJvcGVybHkganVzdGlm
aWVkLiBQZXJmb3JtYW5jZSBpcyBnb2luZyB0byBiZSBhIGtleSBmYWN0b3IgaW4gZ2V0dGluZyBh
ZG9wdGlvbiBmb3IgdGhpcyBwcm90b2NvbC4gV2hldGhlciB3ZSBsaWtlIEl0IG9yIG5vdCwgSFRU
UFMvUVVJQyB3aWxsIGJlIGp1ZGdlZCBhZ2FpbnN0IHRoZSBzdGFjayBIVFRQUy9UQ1Agd2UgaGF2
ZSB0b2RheS4gSWYgOTArIHBlcmNlbnRpbGUgbGF0ZW5jeSBpbXByb3ZlbWVudHMgY29tZSBhdCBh
IGxhcmdlIENQVSBjb3N0LCB0aGUgaW5jZW50aXZlIHRvIG1vdmUgYXdheSBmcm9tIFRDUCB3aWxs
IGJlIGxlc3MuIFNhbWUgaG9sZHMgaWYgbW9yZSBiYXR0ZXJ5IGlzIHNwZW50IGxvYWRpbmcgd2Vi
IHBhZ2VzIG9uIGxvdyBwb3dlciBkZXZpY2VzLiANCg0KSSB0aG91Z2h0IHRoaXMgZGlzY3Vzc2lv
biB3YXMgZm9jdXNlZCBvbiBvc3NpZmljYXRpb24gYnV0IGlmIHdlIGFyZSB0YWxraW5nIGFib3V0
IHByaXZhY3ksIGl0IGlzIGEgY29tcGxleCB0b3BpYyBhbmQgdGhlbiB3ZSBuZWVkIGFuIGFkdmVy
c2FyaWFsIG1vZGVsLCBwb3NzaWJsZSBhdHRhY2tzLCBhbmQgY2xlYXJseSBsaXN0IHRoZSB0cmFk
ZS1vZmZzIGZvciBnZXR0aW5nIG1hcmdpbmFsIGltcHJvdmVtZW50cyBpbiBwcml2YWN5LiBUaGUg
bW9yZSBtZWNoYW5pc21zIHdlIGFkZCBmb3IgcHJldmVudGluZyBsZWFrYWdlIG9mIHNpZGUgY2hh
bm5lbCBpbmZvcm1hdGlvbiwgdGhlIG1vcmUgY29tcGxleCB0aGUgaW1wbGVtZW50YXRpb25zIGFu
ZCB0aGUgY29zdC4gDQoNCkJlZm9yZSB3ZSBtYWtlIGVuZHBvaW50cyBhZGQgcGVyZiBvdmVyaGVh
ZCwgY3JlYXRlIHByb2JsZW1zIGZvciBoYXJkd2FyZSBpbXBsZW1lbnRhdGlvbnMsIGp1c3QgcGxh
aW4gYnJlYWsgbmV0d29yayBzaWduYWxpbmcgYW5kIGhlYWx0aCBzY2VuYXJpb3MgdGhhdCB3b3Jr
IHdpdGggVENQIHRvZGF5LCBhbmQgbWFrZSBubyBhdHRlbXB0cyB0byBtaXRpZ2F0ZSBhZ2dyZXNz
aXZlIFVEUCBOQVQgdGltZW91dHMsIGxldCdzIGp1c3RpZnkgd2h5LiBBbHNvIHNvbHV0aW9ucyBt
YXkgbm90IGJlIHVuaXZlcnNhbGx5IGFwcGxpY2FibGUgLSB3aGF0IGlzIG5lZWRlZCBvbiB0aGUg
SW50ZXJuZXQgKGFuZCBhY3Jvc3MgbXVsdGlwbGUgcGF0aHMpIGlzIHZlcnkgZGlmZmVyZW50IGZy
b20gd2hhdCBpcyBuZWVkZWQgaW4gY29uc3RyYWluZWQgbmV0d29ya3MgbGlrZSBkYXRhY2VudGVy
cyBvciBwcml2YXRlIHNpbmdsZSBhZG1pbiBkb21haW4gbmV0d29ya3MuIFRoaXMgaXMgYSBnZW5l
cmFsIHB1cnBvc2UgdHJhbnNwb3J0IC0gc28gSU1PIHdlIG5lZWQgdG8gZGVmaW5lIG1lY2hhbmlz
bXMgdGhhdCBzdXBwb3J0IGEgcmFuZ2Ugb2YgdHJhZGUtb2ZmcyBhbmQgbWFrZSBwb2xpY3kgcmVj
b21tZW5kYXRpb25zLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBb
bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGlhbiBIdWl0
ZW1hDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDExLCAyMDE4IDk6MzMgQU0NClRvOiBxdWljQGll
dGYub3JnDQpTdWJqZWN0OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9z
c2lmaWNhdGlvbiBwcmV2ZW50aW9uDQoNCk9uIDQvMTEvMjAxOCA4OjM3IEFNLCBTdGVwaGVuIEZh
cnJlbGwgd3JvdGU6DQoNCj4gUGVyc29uYWxseSwgYXMgYSBmdXR1cmUgdXNlciBvZiBRVUlDIChi
dXQgbm90IGFuIGltcGxlbWVudGVyKSwgSSdkIA0KPiByZWFsbHkgcHJlZmVyIHRoYXQgdGhlIFdH
IHByaW9yaXRpc2UgcHJpdmFjeS1mcmllbmRseSBtZWNoYW5pc21zIGlmIGF0IA0KPiBhbGwgcG9z
c2libGUsIGV2ZW4gaWYgdGhlIGRpcmVjdCBiZW5lZml0cyBhcmVuJ3QgY29tcGxldGVseSBjbGVh
ci4NCg0KU2Vjb25kIHRoYXQuIFByYXZlZW4gYW5kIElnb3IgYXJlIG1ha2luZyBhIGZpbmUgcG9p
bnQgYWJvdXQgcGVyZm9ybWFuY2UsIGJ1dCBpbiBteSBib29rIHBlcmZvcm1hbmNlIG9wdGltaXph
dGlvbiBzaG91bGQgYmUgZG9uZSBhZnRlciB3ZSBoYXZlIHRoZSBhZ3JlZWQgZnVuY3Rpb25hbGl0
eSBnb2luZy4gU28sIEkgd291bGQgc2VlIHRoZSBmb2xsb3dpbmcgc2VxdWVuY2U6DQoNCjEpIEFn
cmVlIHRoYXQgd2Ugd2FudCB0byBwcmV2ZW50IFBOIHRyYWNraW5nLCBtaWRkbGVib3ggc2hlbmFu
aWdhbnMsIGFuZCBvc3NpZmljYXRpb24uIEkgdGhpbmsgd2UgZG8gaGF2ZSByb3VnaCBjb25zZW5z
dXMgb24gdGhhdC4NCg0KMikgQ2hlY2sgaW4gUFIgIzEwNzkgYXMgYSBiYXNpYyB3YXkgdG8gYWNj
b21wbGlzaCB0aGlzIG5vdy4NCg0KMykgU3R1ZHkgaGlnaGVyIHBlcmZvcm1hbmNlIGFsdGVybmF0
aXZlIGFuZCBhIG5lZ290aWF0aW9uIG1lY2hhbmlzbSBsYXRlci4NCg0KLS0gQ2hyaXN0aWFuIEh1
aXRlbWENCg0KDQoNCg0K


From nobody Wed Apr 11 10:31:55 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BE4127873 for ; Wed, 11 Apr 2018 10:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ZpSQy5xlvpNi for ; Wed, 11 Apr 2018 10:31:51 -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 33AF212025C for ; Wed, 11 Apr 2018 10:31:51 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id i187so816897ywd.10 for ; Wed, 11 Apr 2018 10:31:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0lqzR1CG4p4nXTXF/Al9rH9aJ5fGBoxNCYDuVbTL/60=; b=MWPoMXKDqfmkvAzajNf/6Gw1YYPeVKbEO7/7xnOhGCwfNz32jxLrDAxcQpL1BATglc jSNEkDHN1nc/0ugGrYId0Bxn9Y7Nqhw3/k1g0GBttPHdY4Yw6+8OzugrZi+v40Vvr2II kfWDh9bx0xCvy30sMS0JecDQRQhQhVE8i59NFKQZQTcvFOcc/v3TcKUXoi6uVIh8mFOo 2kNM8xL9gKLojDAJ1qipApybKNedkmbJ9COiTAmeSu5GzFGpHK2fF4WjdGtMsspFJu4p L+HNcCFPkCjzPeYMUFaSzyepbXvBMSofm5BoSBGH0vYu2MJhDV5W4/m11qCiTDFWmo0j CL1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=0lqzR1CG4p4nXTXF/Al9rH9aJ5fGBoxNCYDuVbTL/60=; b=mi8ci4qMXklU15ywxh+hUY0gbrF/4aWemDzSP1JfYoZo2kRg8iKOrP9eu9f6hdKrg2 HrboE0JMm98DAORt2KxD/vTksfarBMM8xEvG1EUVYJx+uaMDHpRa7dFlhSRi3iP0SnCW 1XbujNrch2XKSvLrH+kycmn1+A1gVE9olLj0ni+0OsQOrW9mPryOkmjl5mYn0HHdC73n PqLlBsa/bu/y0GPX/Fc7T6nBIhZYeP2JYS4Zwt9g1R1TMxiKqCU7omshBKzuufG3eiFG 4IQgc+HOtf6zAuxxhIUvkAV/szxHtXe9rw6x7R4oHC0LVNVQVdZNTU2ZMVq5eKtoagKY fYdA==
X-Gm-Message-State: ALQs6tAlIekbWup/3is0Gg3kanFqcZH57S11CmMgLYTmV3LP8vP8s+gk CmbXJYhcVNgEahy2cQTUzAnnLZtIu5xTwec6qLE=
X-Google-Smtp-Source: AIpwx49d5qYBXo/GLkj8G59PUpQTPUvCF6utrKfRGjSrZ6fyLGtMuCsfvERxUyCaquAW4QViLTtTtkhXkXZwdFZmqpc=
X-Received: by 10.13.192.198 with SMTP id b189mr2575459ywd.52.1523467910130; Wed, 11 Apr 2018 10:31:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:7cc1:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 10:31:49 -0700 (PDT)
In-Reply-To: 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>  
From: Spencer Dawkins at IETF 
Date: Wed, 11 Apr 2018 12:31:49 -0500
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Praveen Balasubramanian 
Cc: huitema , "quic@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114e6f629c2f540569960335"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 17:31:54 -0000

--001a114e6f629c2f540569960335
Content-Type: text/plain; charset="UTF-8"

No hats, but ...

On Wed, Apr 11, 2018 at 12:06 PM, Praveen Balasubramanian <
pravb=40microsoft.com@dmarc.ietf.org> wrote:

> Not just users, but web service providers are affected. As an implementer
> and someone who will need to convince workloads to adopt QUIC at scale, I
> have the view that we should minimize complexity and cost unless properly
> justified. Performance is going to be a key factor in getting adoption for
> this protocol. Whether we like It or not, HTTPS/QUIC will be judged against
> the stack HTTPS/TCP we have today. If 90+ percentile latency improvements
> come at a large CPU cost, the incentive to move away from TCP will be less.
> Same holds if more battery is spent loading web pages on low power devices.
>
> I thought this discussion was focused on ossification but if we are
> talking about privacy, it is a complex topic and then we need an
> adversarial model, possible attacks, and clearly list the trade-offs for
> getting marginal improvements in privacy.


The thing I've wondered most about from threads in this space, is the
discussion about preventing linkages due to address changes as a result of
NAT rebinding, and what the concerns are, and how bad linking after NAT
rebinding would be, or would not be.

It's OK for me to have questions about discussions that QUIC WG has, and
I'm not asking for people to explain things to me - please, continue to do
the work you're doing - but I suspect that the clearer the points Praveen
listed (adversarial model, possible attacks, tradeoffs) are in documents
that QUIC puts forward for publication, the fewer questions will come up
during AD Evaluation, Last Call and review team reviews, and IESG
Evaluation.

FWIW, of course. Do the right thing.

Spencer


> The more mechanisms we add for preventing leakage of side channel
> information, the more complex the implementations and the cost.
>
> Before we make endpoints add perf overhead, create problems for hardware
> implementations, just plain break network signaling and health scenarios
> that work with TCP today, and make no attempts to mitigate aggressive UDP
> NAT timeouts, let's justify why. Also solutions may not be universally
> applicable - what is needed on the Internet (and across multiple paths) is
> very different from what is needed in constrained networks like datacenters
> or private single admin domain networks. This is a general purpose
> transport - so IMO we need to define mechanisms that support a range of
> trade-offs and make policy recommendations.
>
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
> Sent: Wednesday, April 11, 2018 9:33 AM
> To: quic@ietf.org
> Subject: Re: Simple transform for improving PN ossification prevention
>
> On 4/11/2018 8:37 AM, Stephen Farrell wrote:
>
> > Personally, as a future user of QUIC (but not an implementer), I'd
> > really prefer that the WG prioritise privacy-friendly mechanisms if at
> > all possible, even if the direct benefits aren't completely clear.
>
> Second that. Praveen and Igor are making a fine point about performance,
> but in my book performance optimization should be done after we have the
> agreed functionality going. So, I would see the following sequence:
>
> 1) Agree that we want to prevent PN tracking, middlebox shenanigans, and
> ossification. I think we do have rough consensus on that.
>
> 2) Check in PR #1079 as a basic way to accomplish this now.
>
> 3) Study higher performance alternative and a negotiation mechanism later.
>
> -- Christian Huitema
>
>
>
>
>

--001a114e6f629c2f540569960335
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


No hats, but ...

On Wed, Apr 11, 2018 at 12:06 PM, Praveen Balasubramanian =
<pravb=3D40microsoft.com@dmarc.ietf.org> wrote:
Not just users, but web service =
providers are affected. As an implementer and someone who will need to conv=
ince workloads to adopt QUIC at scale, I have the view that we should minim=
ize complexity and cost unless properly justified. Performance is going to =
be a key factor in getting adoption for this protocol. Whether we like It o=
r not, HTTPS/QUIC will be judged against the stack HTTPS/TCP we have today.=
 If 90+ percentile latency improvements come at a large CPU cost, the incen=
tive to move away from TCP will be less. Same holds if more battery is spen=
t loading web pages on low power devices.



I thought this discussion was focused on ossification but if we are talking=
 about privacy, it is a complex topic and then we need an adversarial model=
, possible attacks, and clearly list the trade-offs for getting marginal im=
provements in privacy. 

The thing I've =
wondered most about from threads in this space, is the discussion about pre=
venting linkages due to address changes as a result of NAT rebinding, and w=
hat the concerns are, and how bad linking after NAT rebinding would be, or =
would not be.=C2=A0

It's OK for me to have que=
stions about discussions that QUIC WG has, and I'm not asking for peopl=
e to explain things to me - please, continue to do the work you're doin=
g - but I suspect that the clearer the points Praveen listed (adversarial m=
odel, possible attacks, tradeoffs) are in documents that QUIC puts forward =
for publication, the fewer questions will come up during AD Evaluation, Las=
t Call and review team reviews, and IESG Evaluation.=C2=A0

FWIW, of course. Do the right thing.

Spen=
cer
=C2=A0
The more mechanism=
s we add for preventing leakage of side channel information, the more compl=
ex the implementations and the cost.



Before we make endpoints add perf overhead, create problems for hardware im=
plementations, just plain break network signaling and health scenarios that=
 work with TCP today, and make no attempts to mitigate aggressive UDP NAT t=
imeouts, let's justify why. Also solutions may not be universally appli=
cable - what is needed on the Internet (and across multiple paths) is very =
different from what is needed in constrained networks like datacenters or p=
rivate single admin domain networks. This is a general purpose transport - =
so IMO we need to define mechanisms that support a range of trade-offs and =
make policy recommendations.



-----Original Message-----

From: QUIC [mailto:quic-bounces@ie=
tf.org] On Behalf Of Christian Huitema

Sent: Wednesday, April 11, 2018 9:33 AM

To: quic@ietf.org

Subject: Re: Simple transform for improving PN ossification prevention




On 4/11/2018 8:37 AM, Stephe=
n Farrell wrote:



> Personally, as a future user of QUIC (but not an implementer), I'd=


> really prefer that the WG prioritise privacy-friendly mechanisms if at=


> all possible, even if the direct benefits aren't completely clear.=




Second that. Praveen and Igor are making a fine point about performance, bu=
t in my book performance optimization should be done after we have the agre=
ed functionality going. So, I would see the following sequence:



1) Agree that we want to prevent PN tracking, middlebox shenanigans, and os=
sification. I think we do have rough consensus on that.



2) Check in PR #1079 as a basic way to accomplish this now.



3) Study higher performance alternative and a negotiation mechanism later.<=
br>


-- Christian Huitema













--001a114e6f629c2f540569960335--


From nobody Wed Apr 11 10:32:11 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69719127873 for ; Wed, 11 Apr 2018 10:31:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523467915; bh=0lqzR1CG4p4nXTXF/Al9rH9aJ5fGBoxNCYDuVbTL/60=; h=In-Reply-To:References:From:Date:Subject:Cc:To; b=uVyl1znhJrUfF6nrmHxrS5HFbMalwE4/hr9guotlafteLEuCBsizI+8jLBwMnO/uI JQvRogJgn8tV6LUmXHUnXU5tAGTtaYzEZK3JQaIbJHhOp5XGf3uzhzJZtrPldbnD9m tb2FUX0+SlLtfCQieyG/GfeS1IB4Zrof0aDlRWec=
X-Mailbox-Line: From spencerdawkins.ietf@gmail.com  Wed Apr 11 10:31:55 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F9312785F; Wed, 11 Apr 2018 10:31:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523467915; bh=0lqzR1CG4p4nXTXF/Al9rH9aJ5fGBoxNCYDuVbTL/60=; h=In-Reply-To:References:From:Date:Subject:Cc:To; b=uVyl1znhJrUfF6nrmHxrS5HFbMalwE4/hr9guotlafteLEuCBsizI+8jLBwMnO/uI JQvRogJgn8tV6LUmXHUnXU5tAGTtaYzEZK3JQaIbJHhOp5XGf3uzhzJZtrPldbnD9m tb2FUX0+SlLtfCQieyG/GfeS1IB4Zrof0aDlRWec=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0448712025C for ; Wed, 11 Apr 2018 10:31:55 -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=unavailable 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 Bj8pZFZBZkEp for ; Wed, 11 Apr 2018 10:31:51 -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 671EC12785F for ; Wed, 11 Apr 2018 10:31:51 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id v68so814677ywg.13 for ; Wed, 11 Apr 2018 10:31:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0lqzR1CG4p4nXTXF/Al9rH9aJ5fGBoxNCYDuVbTL/60=; b=MWPoMXKDqfmkvAzajNf/6Gw1YYPeVKbEO7/7xnOhGCwfNz32jxLrDAxcQpL1BATglc jSNEkDHN1nc/0ugGrYId0Bxn9Y7Nqhw3/k1g0GBttPHdY4Yw6+8OzugrZi+v40Vvr2II kfWDh9bx0xCvy30sMS0JecDQRQhQhVE8i59NFKQZQTcvFOcc/v3TcKUXoi6uVIh8mFOo 2kNM8xL9gKLojDAJ1qipApybKNedkmbJ9COiTAmeSu5GzFGpHK2fF4WjdGtMsspFJu4p L+HNcCFPkCjzPeYMUFaSzyepbXvBMSofm5BoSBGH0vYu2MJhDV5W4/m11qCiTDFWmo0j CL1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=0lqzR1CG4p4nXTXF/Al9rH9aJ5fGBoxNCYDuVbTL/60=; b=HxZEiaZmqpXT34hozNShCGiDxXSz7R2IL0DZY7G1VfhRPMigT47vNYMaSCNg6IZPWI on9myLLnYXa+2CIzRMzMWHO6LEH5k8mOeCbYYCkbX3HhztRPnb6js6xreT/T0qavaAjo JoRn2LgNVFBrHAYWzvaTLXvW3fkmr3qtXXLsluB3d79n/nirys4qQAM4G9LcwjQ0gnrp FCxnTcBfOuQj3qoWfcfZiXpXjy/jpDqTzTq9y0NCz5K4mmbctTfiDzB3Fo6sPKCRey3R NLCsiB9QysDAM+UnCATNcVHl6bR4jo4kx3cQYmQcuzIQFDnME2yEhKLPZuTuFrKeYf8I f3jg==
X-Gm-Message-State: ALQs6tAttzu0TGVvDHDpxoBSaKYN3tEoBKy3fed45zmhjNDHf3TIlYfp TdE05OpVOxrAi93ayhlg9fse4O1TlWRV6lJUeag=
X-Google-Smtp-Source: AIpwx49d5qYBXo/GLkj8G59PUpQTPUvCF6utrKfRGjSrZ6fyLGtMuCsfvERxUyCaquAW4QViLTtTtkhXkXZwdFZmqpc=
X-Received: by 10.13.192.198 with SMTP id b189mr2575459ywd.52.1523467910130; Wed, 11 Apr 2018 10:31:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:7cc1:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 10:31:49 -0700 (PDT)
In-Reply-To: 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>  
From: Spencer Dawkins at IETF 
Date: Wed, 11 Apr 2018 12:31:49 -0500
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
Cc: huitema , "quic@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114e6f629c2f540569960335"
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 17:31:55 -0000

--001a114e6f629c2f540569960335
Content-Type: text/plain; charset="UTF-8"

No hats, but ...

On Wed, Apr 11, 2018 at 12:06 PM, Praveen Balasubramanian <
pravb=40microsoft.com@dmarc.ietf.org> wrote:

> Not just users, but web service providers are affected. As an implementer
> and someone who will need to convince workloads to adopt QUIC at scale, I
> have the view that we should minimize complexity and cost unless properly
> justified. Performance is going to be a key factor in getting adoption for
> this protocol. Whether we like It or not, HTTPS/QUIC will be judged against
> the stack HTTPS/TCP we have today. If 90+ percentile latency improvements
> come at a large CPU cost, the incentive to move away from TCP will be less.
> Same holds if more battery is spent loading web pages on low power devices.
>
> I thought this discussion was focused on ossification but if we are
> talking about privacy, it is a complex topic and then we need an
> adversarial model, possible attacks, and clearly list the trade-offs for
> getting marginal improvements in privacy.


The thing I've wondered most about from threads in this space, is the
discussion about preventing linkages due to address changes as a result of
NAT rebinding, and what the concerns are, and how bad linking after NAT
rebinding would be, or would not be.

It's OK for me to have questions about discussions that QUIC WG has, and
I'm not asking for people to explain things to me - please, continue to do
the work you're doing - but I suspect that the clearer the points Praveen
listed (adversarial model, possible attacks, tradeoffs) are in documents
that QUIC puts forward for publication, the fewer questions will come up
during AD Evaluation, Last Call and review team reviews, and IESG
Evaluation.

FWIW, of course. Do the right thing.

Spencer


> The more mechanisms we add for preventing leakage of side channel
> information, the more complex the implementations and the cost.
>
> Before we make endpoints add perf overhead, create problems for hardware
> implementations, just plain break network signaling and health scenarios
> that work with TCP today, and make no attempts to mitigate aggressive UDP
> NAT timeouts, let's justify why. Also solutions may not be universally
> applicable - what is needed on the Internet (and across multiple paths) is
> very different from what is needed in constrained networks like datacenters
> or private single admin domain networks. This is a general purpose
> transport - so IMO we need to define mechanisms that support a range of
> trade-offs and make policy recommendations.
>
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
> Sent: Wednesday, April 11, 2018 9:33 AM
> To: quic@ietf.org
> Subject: Re: Simple transform for improving PN ossification prevention
>
> On 4/11/2018 8:37 AM, Stephen Farrell wrote:
>
> > Personally, as a future user of QUIC (but not an implementer), I'd
> > really prefer that the WG prioritise privacy-friendly mechanisms if at
> > all possible, even if the direct benefits aren't completely clear.
>
> Second that. Praveen and Igor are making a fine point about performance,
> but in my book performance optimization should be done after we have the
> agreed functionality going. So, I would see the following sequence:
>
> 1) Agree that we want to prevent PN tracking, middlebox shenanigans, and
> ossification. I think we do have rough consensus on that.
>
> 2) Check in PR #1079 as a basic way to accomplish this now.
>
> 3) Study higher performance alternative and a negotiation mechanism later.
>
> -- Christian Huitema
>
>
>
>
>

--001a114e6f629c2f540569960335
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


No hats, but ...

On Wed, Apr 11, 2018 at 12:06 PM, Praveen Balasubramanian =
<pravb=3D40microsoft.com@dmarc.ietf.org> wrote:
Not just users, but web service =
providers are affected. As an implementer and someone who will need to conv=
ince workloads to adopt QUIC at scale, I have the view that we should minim=
ize complexity and cost unless properly justified. Performance is going to =
be a key factor in getting adoption for this protocol. Whether we like It o=
r not, HTTPS/QUIC will be judged against the stack HTTPS/TCP we have today.=
 If 90+ percentile latency improvements come at a large CPU cost, the incen=
tive to move away from TCP will be less. Same holds if more battery is spen=
t loading web pages on low power devices.



I thought this discussion was focused on ossification but if we are talking=
 about privacy, it is a complex topic and then we need an adversarial model=
, possible attacks, and clearly list the trade-offs for getting marginal im=
provements in privacy. 

The thing I've =
wondered most about from threads in this space, is the discussion about pre=
venting linkages due to address changes as a result of NAT rebinding, and w=
hat the concerns are, and how bad linking after NAT rebinding would be, or =
would not be.=C2=A0

It's OK for me to have que=
stions about discussions that QUIC WG has, and I'm not asking for peopl=
e to explain things to me - please, continue to do the work you're doin=
g - but I suspect that the clearer the points Praveen listed (adversarial m=
odel, possible attacks, tradeoffs) are in documents that QUIC puts forward =
for publication, the fewer questions will come up during AD Evaluation, Las=
t Call and review team reviews, and IESG Evaluation.=C2=A0

FWIW, of course. Do the right thing.

Spen=
cer
=C2=A0
The more mechanism=
s we add for preventing leakage of side channel information, the more compl=
ex the implementations and the cost.



Before we make endpoints add perf overhead, create problems for hardware im=
plementations, just plain break network signaling and health scenarios that=
 work with TCP today, and make no attempts to mitigate aggressive UDP NAT t=
imeouts, let's justify why. Also solutions may not be universally appli=
cable - what is needed on the Internet (and across multiple paths) is very =
different from what is needed in constrained networks like datacenters or p=
rivate single admin domain networks. This is a general purpose transport - =
so IMO we need to define mechanisms that support a range of trade-offs and =
make policy recommendations.



-----Original Message-----

From: QUIC [mailto:quic-bounces@ie=
tf.org] On Behalf Of Christian Huitema

Sent: Wednesday, April 11, 2018 9:33 AM

To: quic@ietf.org

Subject: Re: Simple transform for improving PN ossification prevention




On 4/11/2018 8:37 AM, Stephe=
n Farrell wrote:



> Personally, as a future user of QUIC (but not an implementer), I'd=


> really prefer that the WG prioritise privacy-friendly mechanisms if at=


> all possible, even if the direct benefits aren't completely clear.=




Second that. Praveen and Igor are making a fine point about performance, bu=
t in my book performance optimization should be done after we have the agre=
ed functionality going. So, I would see the following sequence:



1) Agree that we want to prevent PN tracking, middlebox shenanigans, and os=
sification. I think we do have rough consensus on that.



2) Check in PR #1079 as a basic way to accomplish this now.



3) Study higher performance alternative and a negotiation mechanism later.<=
br>


-- Christian Huitema













--001a114e6f629c2f540569960335--


From nobody Wed Apr 11 10:45:24 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29568128954 for ; Wed, 11 Apr 2018 10:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9jKv48K8EBX for ; Wed, 11 Apr 2018 10:45:20 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0096.outbound.protection.outlook.com [104.47.36.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AACA127873 for ; Wed, 11 Apr 2018 10:45:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iRDJIKNQWdeRG3MiYBUprOaDQcT7v7HrkweFxzFpShM=; b=jXaHcbci0Wc10xeoWvhsP3IjeozQFCv2flUKPGSegK3Hz+wZtvFTRDxyWBBhAlXuFSognNec7AUOaXBgebnKcCwtyCyANmKOrqWezysBpWHUHnvy3v0ZbVw55sFqOjZ1nXEdW+lXONAkd0GXUagIccMoG6PdRAd0qq7yZ5Iuhu8=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1341.namprd08.prod.outlook.com (10.162.1.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.10; Wed, 11 Apr 2018 17:45:16 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0653.015; Wed, 11 Apr 2018 17:45:15 +0000
From: Mike Bishop 
To: IETF QUIC WG 
CC: "Brian Trammell (IETF)" 
Subject: RE: [quicwg/base-drafts] add draft-ietf-quic-spin-exp (#1286)
Thread-Topic: [quicwg/base-drafts] add draft-ietf-quic-spin-exp (#1286)
Thread-Index: AQHT0Wa+Mv7Xfjj010mo5ObJoHSyt6P71paQ
Date: Wed, 11 Apr 2018 17:45:15 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; 
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1341; 7:2jcrT/CQHFIa0eAdA1RAc94NyANOO/NBnYIsgQYNGRxhrjzdIYXpD9r0m6+Mm+yHd49LM0NMQ1jsCq4rpXa/UaLjmyDPYFhGqFsAD0D7v63vj9l318vJ4/SUES7oCCIiU85ot9f3DiMMPJsRI4wdozisaKMGGocvX/EvViNWI7t9T9xhPRvX2tG38TnqMV5nyw02ZmHwFPcpCLn4pIO/BB1OWrjxIooGUQcQIynDa0X4ue5UWH+ML5pcHgHu/s+I
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(3008032)(2017052603328)(7153060)(49563074)(7193020); SRVR:SN1PR08MB1341; 
x-ms-traffictypediagnostic: SN1PR08MB1341:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(209352067349851)(15185016700835)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(3002001)(10201501046)(6041310)(2016111802025)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6043046)(6072148)(201708071742011); SRVR:SN1PR08MB1341; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1341; 
x-forefront-prvs: 0639027A9E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(396003)(39830400003)(39380400002)(376002)(199004)(189003)(102836004)(186003)(68736007)(26005)(8676002)(81166006)(8936002)(6506007)(81156014)(86362001)(486006)(476003)(316002)(3280700002)(11346002)(2906002)(5250100002)(76176011)(7736002)(74316002)(7696005)(53546011)(3660700001)(5660300001)(2900100001)(19609705001)(99286004)(478600001)(6306002)(606006)(99936001)(229853002)(55016002)(6116002)(66066001)(97736004)(33656002)(3846002)(790700001)(74482002)(53936002)(733005)(54896002)(236005)(446003)(105586002)(54556002)(966005)(6436002)(6246003)(14454004)(59450400001)(106356001)(25786009)(4326008)(6916009)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1341; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: sa+vR13FA1ij9yOxPywMPMHz5Vhfohrvmu4ONlC7ACztRAS5bCIjIFQrkWE93UXrwQ2vH0rUhgRE8E17NFAfQ5yCnXg3Mzm6BkpfMunh0UEEwuolDtU/mM8mc8dM30iytEORshaH3s20jr8jIIxJF9BN/PNiY8UChaah2MXfe6NzwrpDLRLeQXtUQBrEPm1pxTsw/CFTmFFjwPIY2m7KqQ0bkDPe+GKyQpfp4z53GJV0DZFDrM4OtQh0RQLYjp2blDCnJIy2/18BH5kvrn7ZASoGHXVBM5myo9vSDBaciLzcFfgrUCvg+I2IETr5Iw+M6nIm7bb/6y2RYJWPthfOmJWtCVw3R1R4PTb2WS0wVlGoAXo+sgvmoM9yYAEcy9WhiHAFTenhF46165TR1/qUk/LkGt6o+F8P3hPIF5auYiM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/related; boundary="_004_SN1PR08MB185420462CA62A71F6420C23DABD0SN1PR08MB1854namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 0728d49e-cf12-47b0-df25-08d59fd3fc23
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 0728d49e-cf12-47b0-df25-08d59fd3fc23
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 17:45:15.8512 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1341
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 17:45:23 -0000

--_004_SN1PR08MB185420462CA62A71F6420C23DABD0SN1PR08MB1854namp_
Content-Type: multipart/alternative;
 boundary="_000_SN1PR08MB185420462CA62A71F6420C23DABD0SN1PR08MB1854namp_"

--_000_SN1PR08MB185420462CA62A71F6420C23DABD0SN1PR08MB1854namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGF2ZSB3ZSBhY3R1YWxseSBhZG9wdGVkIHRoYXQgZG9jdW1lbnQ/DQoNCkZyb206IEJyaWFuIFRy
YW1tZWxsIFttYWlsdG86bm90aWZpY2F0aW9uc0BnaXRodWIuY29tXQ0KU2VudDogV2VkbmVzZGF5
LCBBcHJpbCAxMSwgMjAxOCAxMjoyOCBBTQ0KVG86IHF1aWN3Zy9iYXNlLWRyYWZ0cyA8YmFzZS1k
cmFmdHNAbm9yZXBseS5naXRodWIuY29tPg0KQ2M6IFN1YnNjcmliZWQgPHN1YnNjcmliZWRAbm9y
ZXBseS5naXRodWIuY29tPg0KU3ViamVjdDogW3F1aWN3Zy9iYXNlLWRyYWZ0c10gYWRkIGRyYWZ0
LWlldGYtcXVpYy1zcGluLWV4cCAoIzEyODYpDQoNCg0KVGhpcyBhZGRzIGRyYWZ0LWlldGYtcXVp
Yy1zcGluLWV4cC0wMCwgZGVzY3JpYmluZyB0aGUgc3BpbiBiaXQsIHRvIHRoZSBiYXNlLWRyYWZ0
cyByZXBvc2l0b3J5Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KWW91IGNh
biB2aWV3LCBjb21tZW50IG9uLCBvciBtZXJnZSB0aGlzIHB1bGwgcmVxdWVzdCBvbmxpbmUgYXQ6
DQoNCiAgaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzEyODYNCg0K
Q29tbWl0IFN1bW1hcnkNCg0KICAqICAgYWRkIGRyYWZ0LWlldGYtcXVpYy1zcGluLWV4cA0KDQpG
aWxlIENoYW5nZXMNCg0KICAqICAgQSBkcmFmdC1pZXRmLXF1aWMtc3Bpbi1leHAubWQ8aHR0cHM6
Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzEyODYvZmlsZXMjZGlmZi0wPiAo
MjQ3KQ0KDQpQYXRjaCBMaW5rczoNCg0KICAqICAgaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9i
YXNlLWRyYWZ0cy9wdWxsLzEyODYucGF0Y2gNCiAgKiAgIGh0dHBzOi8vZ2l0aHViLmNvbS9xdWlj
d2cvYmFzZS1kcmFmdHMvcHVsbC8xMjg2LmRpZmYNCg0K4oCUDQpZb3UgYXJlIHJlY2VpdmluZyB0
aGlzIGJlY2F1c2UgeW91IGFyZSBzdWJzY3JpYmVkIHRvIHRoaXMgdGhyZWFkLg0KUmVwbHkgdG8g
dGhpcyBlbWFpbCBkaXJlY3RseSwgdmlldyBpdCBvbiBHaXRIdWI8aHR0cHM6Ly9naXRodWIuY29t
L3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzEyODY+LCBvciBtdXRlIHRoZSB0aHJlYWQ8aHR0cHM6
Ly9naXRodWIuY29tL25vdGlmaWNhdGlvbnMvdW5zdWJzY3JpYmUtYXV0aC9BRUUyaFFuRWFCZzNv
R2k0WU42eGMzcGswUmNFalowNmtzNXRuYkNZZ2FKcFpNNFRQZ1hJPi4NCg==

--_000_SN1PR08MB185420462CA62A71F6420C23DABD0SN1PR08MB1854namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6
MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7
DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg
Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpoNA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsN
Cgltc28tc3R5bGUtbGluazoiSGVhZGluZyA0IENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph
dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ
bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLHNhbnMtc2VyaWY7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQphOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQpzcGFuLkhlYWRpbmc0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVh
ZGluZyA0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJI
ZWFkaW5nIDQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0IixzYW5zLXNlcmlmOw0KCWNv
bG9yOiMyRjU0OTY7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u
b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu
MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x
DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww
DQoJe21zby1saXN0LWlkOjUwMzc4ODYxMDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTg0OTY0
OTg2O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu
c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2
ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT
eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6
bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg
bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTAwNDYyMzA4NTsNCgltc28t
bGlzdC10ZW1wbGF0ZS1pZHM6LTEyODM3MDM3OTQ7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K
CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVs
Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn
Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10
YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6
V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs
aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K
CW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt
c3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu
Z2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0
IGwyDQoJe21zby1saXN0LWlkOjE1NjU2ODM3MTY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjUz
MzYyNTQzNDt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy
OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl
bC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0
IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVp
bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs
aXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOQ0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z
by1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u
dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE3ODk5MzIzNTU7DQoJ
bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMjQ1OTQ1ODAwO30NCkBsaXN0IGwzOmxldmVsMQ0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z
by1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBp
bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3
IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMzps
ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu
MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41
aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp
bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9
DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m
b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZl
bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C
pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0
Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA
bGlzdCBsNA0KCXttc28tbGlzdC1pZDoxODE2OTUxMDAxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk
czotNTI3NDAzNjIwO30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp
c3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZh
bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp
bmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt
c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz
dCBsNDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl
bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp
emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDYNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv
bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk
aW5nczt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t
YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs
NDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNQ0KCXttc28tbGlzdC1p
ZDoxODMxMjA4ODY1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTE1ODc2MTAxODt9DQpAbGlz
dCBsNTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl
bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVp
bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs
aXN0IGw1OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNQ0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z
by1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u
dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz
LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N
CkBsaXN0IGw1OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsOA0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K
CW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv
cDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s
O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N
Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6
ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2
OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t
LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYXZl
IHdlIGFjdHVhbGx5IGFkb3B0ZWQgdGhhdCBkb2N1bWVudD88bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGI+RnJvbTo8L2I+IEJyaWFuIFRyYW1tZWxsIFttYWlsdG86bm90aWZpY2F0aW9uc0BnaXRo
dWIuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMTEsIDIwMTggMTI6
MjggQU08YnI+DQo8Yj5Ubzo8L2I+IHF1aWN3Zy9iYXNlLWRyYWZ0cyAmbHQ7YmFzZS1kcmFmdHNA
bm9yZXBseS5naXRodWIuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gU3Vic2NyaWJlZCAmbHQ7c3Vi
c2NyaWJlZEBub3JlcGx5LmdpdGh1Yi5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtxdWlj
d2cvYmFzZS1kcmFmdHNdIGFkZCBkcmFmdC1pZXRmLXF1aWMtc3Bpbi1leHAgKCMxMjg2KTxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cD5UaGlzIGFkZHMgZHJhZnQtaWV0Zi1xdWljLXNwaW4tZXhwLTAwLCBkZXNjcmliaW5nIHRoZSBz
cGluIGJpdCwgdG8gdGhlIGJhc2UtZHJhZnRzIHJlcG9zaXRvcnkuPG86cD48L286cD48L3A+DQo8
ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl
bnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+
DQo8aDQ+WW91IGNhbiB2aWV3LCBjb21tZW50IG9uLCBvciBtZXJnZSB0aGlzIHB1bGwgcmVxdWVz
dCBvbmxpbmUgYXQ6PG86cD48L286cD48L2g0Pg0KPHA+Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0
cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzEyODYiPmh0dHBzOi8vZ2l0
aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8xMjg2PC9hPjxvOnA+PC9vOnA+PC9wPg0K
PGg0PkNvbW1pdCBTdW1tYXJ5PG86cD48L286cD48L2g0Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxp
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+DQphZGQgZHJhZnQt
aWV0Zi1xdWljLXNwaW4tZXhwPG86cD48L286cD48L2xpPjwvdWw+DQo8aDQ+RmlsZSBDaGFuZ2Vz
PG86cD48L286cD48L2g0Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzttc28tbGlzdDpsNCBsZXZlbDEgbGZvNiI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkE8L3NwYW4+PC9zdHJvbmc+IDxh
IGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8xMjg2L2Zp
bGVzI2RpZmYtMCI+DQpkcmFmdC1pZXRmLXF1aWMtc3Bpbi1leHAubWQ8L2E+ICgyNDcpIDxvOnA+
PC9vOnA+PC9saT48L3VsPg0KPGg0PlBhdGNoIExpbmtzOjxvOnA+PC9vOnA+PC9oND4NCjx1bCB0
eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm
bzkiPg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxs
LzEyODYucGF0Y2giPmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8x
Mjg2LnBhdGNoPC9hPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s
aXN0OmwxIGxldmVsMSBsZm85Ij4NCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cv
YmFzZS1kcmFmdHMvcHVsbC8xMjg2LmRpZmYiPmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFz
ZS1kcmFmdHMvcHVsbC8xMjg2LmRpZmY8L2E+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBzdHls
ZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0Om5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0O2NvbG9yOiM2NjY2NjYiPuKAlDxicj4NCllvdSBhcmUgcmVjZWl2aW5nIHRoaXMgYmVj
YXVzZSB5b3UgYXJlIHN1YnNjcmliZWQgdG8gdGhpcyB0aHJlYWQuPGJyPg0KUmVwbHkgdG8gdGhp
cyBlbWFpbCBkaXJlY3RseSwgPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWlj
d2cvYmFzZS1kcmFmdHMvcHVsbC8xMjg2Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+
dmlldyBpdCBvbiBHaXRIdWI8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2NvbG9yOiM2NjY2NjYiPiwgb3INCjwvc3Bhbj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v
bm90aWZpY2F0aW9ucy91bnN1YnNjcmliZS1hdXRoL0FFRTJoUW5FYUJnM29HaTRZTjZ4YzNwazBS
Y0VqWjA2a3M1dG5iQ1lnYUpwWk00VFBnWEkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
Ij5tdXRlIHRoZSB0aHJlYWQ8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2NvbG9yOiM2NjY2NjYiPi48c3BhbiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4w
cHQ7cGFkZGluZzowaW4iPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBzdHls
ZT0id2lkdGg6LjAxMDRpbjtoZWlnaHQ6LjAxMDRpbiIgaWQ9IlBpY3R1cmVfeDAwMjBfMiIgc3Jj
PSJjaWQ6aW1hZ2UwMDIuanBnQDAxRDNEMTgyLjJDM0QxMkIwIiBhbHQ9IkltYWdlIHJlbW92ZWQg
Ynkgc2VuZGVyLiI+PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_SN1PR08MB185420462CA62A71F6420C23DABD0SN1PR08MB1854namp_--

--_004_SN1PR08MB185420462CA62A71F6420C23DABD0SN1PR08MB1854namp_
Content-Type: image/jpeg; name="image002.jpg"
Content-Description: image002.jpg
Content-Disposition: inline; filename="image002.jpg"; size=332;
 creation-date="Wed, 11 Apr 2018 17:45:15 GMT";
 modification-date="Wed, 11 Apr 2018 17:45:15 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/wAALCAABAAEBAREA/8QAHwAAAQUBAQEB
AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh
ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ
WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG
x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZK/9k=

--_004_SN1PR08MB185420462CA62A71F6420C23DABD0SN1PR08MB1854namp_--


From nobody Wed Apr 11 11:34:42 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D636112946D for ; Wed, 11 Apr 2018 11:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAV_3j1z3BFV for ; Wed, 11 Apr 2018 11:34:38 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9C6128959 for ; Wed, 11 Apr 2018 11:34:38 -0700 (PDT)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1f6KZm-0000Hc-J4 for quic@ietf.org; Wed, 11 Apr 2018 20:34:35 +0200
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1f6KZk-0001Ay-Mv for quic@ietf.org; Wed, 11 Apr 2018 14:34:33 -0400
Received: (qmail 1154 invoked from network); 11 Apr 2018 18:34:27 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.61]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Apr 2018 18:34:27 -0000
To: Spencer Dawkins at IETF 
Cc: "quic@ietf.org" 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>   
From: Christian Huitema 
Openpgp: preference=signencrypt
Message-ID: <46f22a3d-b2ad-8c1a-9149-7d69dcde003c@huitema.net>
Date: Wed, 11 Apr 2018 11:34:24 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.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: Migration privacy and NAT rebinding
X-Originating-IP: 168.144.250.232
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.35)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5t4L16irBpUfytiTssLp6tp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViBc9ZaiVrnNLhSs87+PVAR87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1c1FPznmLv13i1NL5aXaHx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpU1moK5+umQAfdUHagyvOVYIM9y1H2cTGqHMD4iYMvwe3/vhQDG5cUE qlkXHHLFoudz1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAVi5bZXEudL3ieMOBM2bJNcVYE7tCqypI5WX0qWh4YQLBGLgR6WKyKEJvE xhRwxbMxbr8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLXYENHEHdfH4WKtOnkQjvURQKHY 6H+wSCoVvwvquzDDiAFgqbLsMBS3CSu0TYW/KPOYdub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0=
X-Report-Abuse-To: spam@quarantine6.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, 11 Apr 2018 18:34:41 -0000

On 4/11/2018 10:31 AM, Spencer Dawkins at IETF wrote:

> The thing I've wondered most about from threads in this space, is the
> discussion about preventing linkages due to address changes as a
> result of NAT rebinding, and what the concerns are, and how bad
> linking after NAT rebinding would be, or would not be.

That's a good question, and it probably deserves its own thread.

I think we need to consider two kinds of migration: voluntary migration,
and NAT rebinding. I really want to support privacy for voluntary
migration. I doubt than we can do better than a best effort for NAT
rebinding.

An example of voluntary migration is the parking lot scenario, in which
the client will voluntarily migrate the connection from WiFi to cellular
as the WiFi signal fades away. The migration is voluntary, as the client
will actively decide to send packets from a different source address,
and possibly from a different source port. Involuntary migration happens
when something change in the network without the client's knowledge, and
packet start arriving to the server from a different IP and port. The
canonical example of that is NAT rebinding.

There is no question in my mind that we want to prevent linkability when
doing voluntary migration, and that means rotating the connection ID and
breaking PN linkability. But NAT rebinding is another matter. There are
many big arguments against expanding too much resource to specifically
increase NAT rebinding privacy:

* Most NAT rebinding happens without the client's knowledge, which
seriously limit mitigation capability.

* If the connection was using IPv6 instead of IPv4, in theory there
would be no NAT.

* In the case of residential NAT, only the port changes upon rebinding,
so linkability is obvious.

* If there is just a short interval between the old and new NAT
bindings, adversaries can use time based solutions to link the two
connection.

The proposal in the document is that clients may simulate a voluntary
migration when going out of quiescence. This seems like a reasonable
best effort approach. Most NAT rebinding occurs after connections have
been idle for some time. Since there is a long interval, adversaries
have a harder time using time stamps for linkability. In case of long
intervals, carrier grade NAT may have recycled both the address and the
port. And we need to grease the migration code path in servers and
clients, so we can just as well do that.

DKG pointed out that NAT rebinding also happens in mobile platforms,
such as a car roaming between various cells. The car network offers a
router + NAT service to devices inside the car. The router would be
getting a new IPv4 address at each new cell, and there would be
rebinding of any connection between internal devices and outside
servers. If the QUIC connection survived, the adversaries will be able
to deduce from traffic observation the successive locations of the
device. This seems bad. If internal devices new about the connection
changes, they could use the voluntary mechanisms. DKG argued that we
should have protection even if the devices don't know about the
migration, but the only practical solution is to rotate the connection
ID for every packet -- effectively, encrypt the connection ID. This is
not what we are debating now. I personally think that the mobile
platform issue should be solved with some cooperation of the mobile
router, so the devices can engage in voluntary migration.

-- Christian Huitema



From nobody Wed Apr 11 12:18:26 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3DE129C56 for ; Wed, 11 Apr 2018 12:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbQnsVzan_ug for ; Wed, 11 Apr 2018 12:18:22 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on070c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::70c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0DC1271FD for ; Wed, 11 Apr 2018 12:18: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=lIB4Cecbm6+Mm4BSpnEfou33Kf+QNXmtsgHNCByHx4E=; b=XET+I08ri8ZCQmvvZMjoTxkpzOwQqVw0iRZoLiAAtNs/tvEi8a6xvAGmFuHW/i0Z2FN9X2/Ju1eI+Vlu6XWYv3AB2PS6cNpzJgP7IapWCD2LiZn4db6qXElZc+PezWoUkaey7hG6mehdBdcSzVZmnFZ8tLb8Fmyj/iq1CiuDrVc=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0631.namprd21.prod.outlook.com (10.175.115.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Wed, 11 Apr 2018 19:18:21 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.006; Wed, 11 Apr 2018 19:18:21 +0000
From: Praveen Balasubramanian 
To: IETF QUIC WG 
Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Thread-Index: AQHTzPOfhJMCgvyw60+hsX7hCsq0T6P6QG/QgAAFTQCAACClkA==
Date: Wed, 11 Apr 2018 19:18:21 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-898 3-0ecabeb9fea5@huitema.net>  <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:a::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0631; 7:SOr8ABrEr4l/+C54CNXhpi7NHbTZ2WqmP6eqi+NVy7D8OegpA+QEmcLFg8Im1N8VNdNrTKBx7hiYkidd3+f5ELUDMmq7r1JTfKxZnGhO2p8T1OlBTYxCejeN1LO458hLYBiPHDlQGn6mjPZ0v+TJggDIE5sCU3icqwPwWcI/HF/ttL1+xXk5eW39jNRZec3/9E8YzMebzqLHmRRsDEU/Qg2kLtNLNDkkErDcrui4yWw7+8p+HDBbFYg2wiN5b/fW; 20:mXC/SYwSOeVN74nSKWrZcNhpI5ZmwXsV+oA4wmMuGRwQGE+eqd9Y+gdpZFQff6HMxIoKhrDbpVffDW/2n4dUzj9sYg93NlOZi7m856tLm44dwLI2ufykEqwUGhpPZbZdge6veOKZejOQKNjVjcSagtn+G9d+xfj34pIfIKFi38c=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0631; 
x-ms-traffictypediagnostic: CY4PR21MB0631:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(131327999870524)(100405760836317); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231221)(944501337)(52105095)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0631; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0631; 
x-forefront-prvs: 0639027A9E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(376002)(396003)(346002)(366004)(189003)(199004)(13464003)(105586002)(8936002)(53936002)(11346002)(446003)(8990500004)(10090500001)(81156014)(81166006)(86612001)(8676002)(93886005)(46003)(9686003)(86362001)(68736007)(6246003)(5250100002)(2906002)(97736004)(6916009)(14454004)(74316002)(186003)(305945005)(106356001)(25786009)(2900100001)(229853002)(3660700001)(3280700002)(7736002)(6436002)(7696005)(102836004)(22452003)(33656002)(316002)(59450400001)(5660300001)(53546011)(478600001)(6506007)(76176011)(6116002)(476003)(99286004)(55016002)(10290500003)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0631; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: V4JF3mPPHKUCxhDAVmZ5t5e4c9dGmIjXR9K3SfAbjFQpVh2vRIgZGAZUuVug/oglGwyixBnNbOw/x8U7q5ewRkxN5zJw4ZEEryLJBVXgZS9Z5l02ataqViKq+ZV2HQcY6B8uSgxk5RnfqVfOfRE1kugnsGQcBKKTxdl5917wgTrXRL68U5zgJ0qjolIGMS952ueGOAEjkqd/QPCOGa/XdIVtjnP6d1fic/RVuuuoQVpGYXSGTo5TAHT/p+TYaQ0HpRLPvun24oIKwo8sG5dnIGRna0ivqxpyAGLTzwNTHIzuki26A9/lEXWtlcZV6PurOA8nWjY1g/sp/bfwPncz7T2dOEQxHYDQ8RUIYUVABoY5Rq3G7/+fV3bJdrlj+u8jYovYh/+c6XMb3eLQIwmqrU7rx+hw/qCeJxgWF5LFZmw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 4fa54e02-b1f4-4aac-5d7b-08d59fe0fd36
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4fa54e02-b1f4-4aac-5d7b-08d59fe0fd36
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 19:18:21.1544 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0631
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 19:18:25 -0000

R29pbmcgYmFjayB0byBDaHJpc3RpYW4ncyBvcmlnaW5hbCBxdWVzdGlvbiBvbiBwcml2YWN5IGhv
bGVzLCB0aGVyZSBpcyBhbiBhdHRhY2sgZm9yIGxpbmtpbmcgSVAgYWRkcmVzc2VzIGluIHRoZSB2
b2x1bnRhcnkgbWlncmF0aW9uIGNhc2UuDQoNCkxldCdzIGNvbnNpZGVyIHRoZSBwYXJraW5nIGxv
dCBwcm9ibGVtIG9yIGluIGdlbmVyYWwgY2FzZSBsb3Npbmcgb25lIG5ldHdvcmsgYW5kIHJvYW1p
bmcgdG8gYW5vdGhlciBuZXR3b3JrLiBUaGlzIGlzIHRoZSBwcmltYXJ5IHVzZSBjYXNlIGZvciBj
b25uZWN0aW9uIG1pZ3JhdGlvbi4gSW4gdGhpcyBjYXNlIGFsbCBhY3RpdmUgUVVJQyBjb25uZWN0
aW9ucyB0aGF0IGNhbiBtaWdyYXRlLCB3aWxsIGRvIHNvLiBXaGVuIHRoZXNlIGNvbm5lY3Rpb25z
IG1pZ3JhdGUgdGhleSBjYW4gY2hhbmdlIHRoZSBDSUQsIHRoZSBsb2NhbCBwb3J0IG51bWJlciBh
bmQgcGFja2V0IG51bWJlcnMuIEhvd2V2ZXIgZG8gbm90aWNlIHRoYXQgb25seSB0aGUgbG9jYWwg
Mi10dXBsZSBjaGFuZ2VzIGZvciBlYWNoIGNvbm5lY3Rpb24sIHRoZSBzZXJ2ZXIncyAyLXR1cGxl
IHJlbWFpbnMgdGhlIHNhbWUuIA0KDQpMZXQncyBhc3N1bWUgYSBwb3dlcmZ1bCBhZHZlcnNhcnkg
Y2FuIGNvbGxlY3QgYSBuZXR3b3JrIHNuaWZmIG9mIGFsbCB0aGlzIHRyYWZmaWMgYW5kIGJ1aWxk
cyBhIG1hc3NpdmUgZGF0YXNldC4gVGhlIGFkdmVyc2FyeSBjYW4gdGhlbiBydW4gYSBtYWNoaW5l
IGxlYXJuaW5nIGFsZ29yaXRobSB0byBpZGVudGlmeSB0aW1lIGluc3RhbnRzIHdoZXJlIGEgYnVu
Y2ggb2YgY29ubmVjdGlvbnMgY2hhbmdlIHRoZWlyIGxvY2FsIDItdHVwbGUgYXQgbmVhciB0aGUg
c2FtZSB0aW1lIGluc3RhbnQgYnV0IGNvbnRpbnVlIGdvaW5nIHRvIHRoZSBzYW1lIHNlcnZlciBz
aWRlIDItdHVwbGVzLiBUaGlzIHdpbGwgYWxsb3cgdGhlIGFkdmVyc2FyeSB0byBsaW5rIHR3byBJ
UCBhZGRyZXNzZXMuIFRoZSBtb3JlIHRpbWVzIHRoZSB1c2VyIHJvYW1zIGJldHdlZW4gbmV0d29y
a3MgYmFjayBhbmQgZm9ydGggdGhlIHJpY2hlciB0aGUgY29ycmVsYXRpb24uIFRoZSBtb3JlIG9w
ZW4gY29ubmVjdGlvbnMgdG8gZGlmZmVyZW50IHNlcnZlcnMsIHRoZSByaWNoZXIgdGhlIGNvcnJl
bGF0aW9uLiBHZW9sb2NhdGlvbiBpbmZvcm1hdGlvbiBjYW4gbWluaW1pemUgdGhlIG51bWJlciBv
ZiBhZGRyZXNzZXMgdGhlIGFkdmVyc2FyeSBuZWVkcyB0byBjb3JyZWxhdGUuIA0KDQpUaGUgZnVu
ZGFtZW50YWwgcHJvYmxlbSBzZWVtcyB0byBiZSB0aGF0IHRoZSBzdWJzdHJhdGUgaXMgVURQL0lQ
IGFuZCBpdCBpcyBpbiB0aGUgY2xlYXIgYW5kIGFsbG93cyBsaW5rYWJpbGl0eS4gDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGll
dGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuIEh1aXRlbWENClNlbnQ6IFRodXJzZGF5LCBB
cHJpbCA1LCAyMDE4IDg6MzQgQU0NClRvOiBNaXJqYSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3
aW5kQHRpay5lZS5ldGh6LmNoPg0KQ2M6IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFByaXZhY3kg
aG9sZXMgKHdhczogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5j
cnlwdGlvbikNCg0KIA0KDQo+IE9uIEFwciA1LCAyMDE4LCBhdCAyOjI2IEFNLCBNaXJqYSBLw7xo
bGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPiB3cm90ZToNCj4gLi4uDQo+
IFRpbWluZyBkb2VzbuKAmXQgaGVscCBoZXJlIGVpdGhlciBiZWNhdXNlIHlvdSBzdGlsbCBoYXZl
IHRoZSBzYW1lIGRlc3RpbmF0aW9uIElQLCBib3RoIHBvcnQgbnVtYmVycyBhbmQgdGhlIGZhY3Qg
dGhhdCBhIG1pZ3JhdGVkIGNvbm5lY3Rpb24gZG9lcyBub3QgaGF2ZSBhIGhhbmRzaGFrZS4gSWYg
d2Ugd2FudCB0byBhZGRyZXNzIHRoZSBsaW5rYWJpbGl0eSBwcm9ibGVtLCB3ZSB3b3VsZCBuZWVk
IHRvIGRvIG11Y2ggbW9yZSwgcHJvYmFibHkgYmFyaW5nIG1vcmUgaGl0cyBvbiBwZXJmb3JtYW5j
ZS4gDQoNCk1pcmphLA0KDQpZb3UgcmlnaHRseSBwb2ludCBvdXQgdGhhdCB0aGUgY29ubmVjdGlv
biBJRCBhbmQgdGhlIFBhY2tldCBOdW1iZXIgYXJlIG5vdCB0aGUgb25seSBlbGVtZW50cyB0aGF0
IHByb3ZpZGUgbGlua2FiaWxpdHkuIFRoZXJlIGlzIGFsc28gb2YgY291cnNlIHRoZSBVRFAgc291
cmNlIHBvcnQuIFRoYXQgb25lIGlzIG5vdCBtdWNoIG9mIGFuIGlzc3VlIGZvciBzZXJ2ZXJzLCBi
dXQgaXQgaXMgYW4gaXNzdWUgZm9yIGNsaWVudHMuIFdlIGFyZSBub3Qgc3BlbGxpbmcgdGhhdCBv
dXQgaW4gdGhlIGRyYWZ0LiBXZSBzaG91bGQsIGJlY2F1c2UgY2xpZW50cyBjYW4gdHJpdmlhbGx5
IGNsb3NlIHRoYXQgaG9sZSB3aGVuIGRvaW5nIG1pZ3JhdGlvbi4NCg0KSSBhbSBub3Qgc3VyZSB0
aGF0IHRoZSBhYnNlbmNlIG9mIG5lZ290aWF0aW9uIGRpdnVsZ2VzIG11Y2ggZGF0YS4gSXQgbWFy
a3MgdGhlIHBhdGggYXMgb3JpZ2luYXRpbmcgZnJvbSBhIG1pZ3JhdGlvbiwgYnV0IGl0IGRvZXMg
bm90IHRlbGwgZnJvbSB3aGVyZS4gQnV0IHRoZXJlIG1pZ2h0IGJlIGFuIG9zc2lmaWNhdGlvbiBp
c3N1ZS4gV2Ugd2lsbCBnZXQgdGhhdCBvc3NpZmljYXRpb24gaWYgd2UgdHJhaW4gbWlkZGxlYm94
ZXMgdG8gYmVsaWV2ZSB0aGF0IGNvbm5lY3Rpb24gYWx3YXlzIHN0YXJ0IHdpdGggYW4gb2JzZXJ2
YWJsZSBuZWdvdGlhdGlvbi4gU28gbWF5YmUgd2Ugc2hvdWxkIGV4cGxvcmUgd2F5cyB0byBncmVh
c2UgdGhhdC4NCg0KQW55IG90aGVyIHByaXZhY3kgaG9sZSB0aGF0IHdlIHNob3VsZCBmaXg/DQoN
Ci0tIENocmlzdGlhbiBIdWl0ZW1hIA0K


From nobody Wed Apr 11 13:12:34 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B541E12D777 for ; Wed, 11 Apr 2018 13:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77qerf7b8J2U for ; Wed, 11 Apr 2018 13:12:29 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976B012D72F for ; Wed, 11 Apr 2018 13:12:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B46BEBE4D; Wed, 11 Apr 2018 21:12:27 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZlHV_QdvRGv; Wed, 11 Apr 2018 21:12:26 +0100 (IST)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AB3A3BE38; Wed, 11 Apr 2018 21:12:25 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1523477546; bh=d6X4e9hLNBjKHXPneT2M8qCt1qUYIJdBN0Fmesb532s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VyKK21J12Fg/wwgciYSVATVBlU1rdwoREGHtHV9POA1F3YsVHvKhFlBVZiyLqoPKA rc9QxXejlAXBAeM3CKALT845l8V/Xv9QIHndEm9EO3kW3fS8HWAeaDzkcaabo4iKeT b2AHbRmlZxTtnfL3AblexEthRxTyPwDs1cMeiga4=
Subject: Re: Simple transform for improving PN ossification prevention
To: "Lubashev, Igor" , "Lubashev, Igor" , Roberto Peon , "Fossati, Thomas (Nokia - GB/Cambridge)" , Kazuho Oku , Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG , Ryan Hamilton 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie> <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie>
Date: Wed, 11 Apr 2018 21:12:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HYhe0G09Oqk4gqfyksOOM80GRLvB36j9M"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 20:12:32 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HYhe0G09Oqk4gqfyksOOM80GRLvB36j9M
Content-Type: multipart/mixed; boundary="oGy0YEakfmwoCdWnotn3VNgtxuCvm7I7R";
 protected-headers="v1"
From: Stephen Farrell 
To: "Lubashev, Igor" ,
 "Lubashev, Igor" , Roberto Peon ,
 "Fossati, Thomas (Nokia - GB/Cambridge)" ,
 Kazuho Oku ,
 Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG ,
 Ryan Hamilton 
Message-ID: <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie>
Subject: Re: Simple transform for improving PN ossification prevention
References: 
 
 
 
 
 
 <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
 
 <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
 <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
 <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
 <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>

--oGy0YEakfmwoCdWnotn3VNgtxuCvm7I7R
Content-Type: multipart/mixed;
 boundary="------------1592AEDF8CC6515139DDE8D0"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------1592AEDF8CC6515139DDE8D0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 11/04/18 17:37, Lubashev, Igor wrote:
> Yes, these are difficult questions, especially since most of the=20
> information is unknown, and we are to weigh estimates and risks=20
> against each other.  But this is especially important when so many=20
> things are uncertain to keep at least the questions we are answering=20
> clear.  Hence, I would consider "Are we asking all Internet users to=20
> pay a tax by not improving privacy?" to be not a clear question but
> a rhetorical one. =20

I took 'em as questions and not as rhetorical questions:-)

> I meant "tax" in a very specific way -- the=20
> real-world _financial_ cost.  I specifically want to pose questions=20
> of trade-offs of financial costs vs. benefits (very valuable
> benefits to be sure).

Again, there's the same problem - are you trying to measure the
financial benefits of privacy? Or are you trying to compare the
financial costs of (e.g. PNE) against some other measure of the
benefits of privacy? I'm still in a position where I don't know
how to make those comparisons.

So maybe yeah, you're right that we're better considering your
specific questions purely as rhetorical and try find other
questions that could be answered.

Cheers,
S.

>=20
> * Are we asking all Internet users to pay a tax to improve privacy?=20
> Does the amount of the tax justify the amount of privacy benefits it=20
> buys?
>=20
> * Are we asking all Internet users to pay a tax to reduce PN=20
> ossification?  Does the amount of the tax justify the added=20
> flexibility protocol designers might need in the future?
>=20
>=20
> - Igor
>=20
>=20
> -----Original Message----- From: Stephen Farrell=20
> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, April 11, 2018=20
> 11:37 AM To: Lubashev, Igor ;=20
> Roberto Peon ; Fossati, Thomas (Nokia - GB/Cambridge)=20
> ; Kazuho Oku ;
> Praveen Balasubramanian  Cc: Victor Vasiliev=20
> ; IETF QUIC WG ; Ryan Hamilton=20
>  Subject: Re: Simple transform for improving PN=20
> ossification prevention
>=20
>=20
> Hiya,
>=20
> On 11/04/18 16:21, Lubashev, Igor wrote:
>> * Are we asking all Internet users to pay a tax to improve privacy?
>> Does the amount of the tax justify the amount of privacy benefits
>> it buys?
> I think that (and your other questions) are good things to ponder,=20
> but I don't believe the questions above are really answerable, at=20
> least not unless we can also answer the opposite question ("Are we=20
> asking all Internet users to pay a tax by not improving privacy?"),=20
> and I'm pretty sure I at least don't know how to evaluate that=20
> question. Maybe that's part of why this discussion is so tricky.
>=20
> Personally, as a future user of QUIC (but not an implementer), I'd=20
> really prefer that the WG prioritise privacy-friendly mechanisms if=20
> at all possible, even if the direct benefits aren't completely=20
> clear.
>=20
> Cheers, S.
>=20

--------------1592AEDF8CC6515139DDE8D0
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------1592AEDF8CC6515139DDE8D0--

--oGy0YEakfmwoCdWnotn3VNgtxuCvm7I7R--

--HYhe0G09Oqk4gqfyksOOM80GRLvB36j9M
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJazmwoAAoJEFqy+vF7FyvqiwwQAM8VYhOAk8pFtvCJpPwuZg6L
ou6Sp0W/caffNmnjeRsdscofup89TR3HJDMfs7ebQMEJqujMPmVEHJcs1OLaa6HL
v1YgJ4QFZriU2kyq8iYro5O0lUwB//AWR8DrbD1SDw/4T75TadjG99qDmRTH9V2m
h4Cx0Ul7BOqLH84VL59kl0Z0ECaF90zGyLDrTpDz+7jZsWFevByxN1Szj/Q2Z/CC
DJCpOh/FJaHQ7Q3Vp9BGrheajCzClnsnjhgjX2d8mMoWYCp1hZ+HjrB/jBGGUKzh
XcW+99ON/uZXXZgjC6yXUgG6KNWXHC8/QU/1eU0xQRDZgv6JyEhwXSOSq9KISzGJ
vVt6QjoK0uXgQwjHNzFAF38X27xVp7YZjRBg10SorqPAr8DdO/YernlYmjo0CQOR
5Tady26TrzIi90yi8AVZgvtRJ+prXTBf/QyV+aLOsOnOsYNYpp8h56rU/8XnsB1M
OaBysJakDN2FGZLxv2M5qlr27HAbKYs/Bi9aRDpGFFFUsLxoqMmZBMJyS4KGkR4L
Kk0rdIDBpZuOf9WKTav0gCQINkZiHa0lRatXp0cL2FJl7w9fSCkg7/+xx4ue1+z/
8rD8BqYGMBMi/gh2cT0umCq8aBPqiNzMRkzzMgLDG3U7ecSj6zSuCdyy3ztZE9tb
+X58eNQHkQll3W1ySn8w
=xw/E
-----END PGP SIGNATURE-----

--HYhe0G09Oqk4gqfyksOOM80GRLvB36j9M--


From nobody Wed Apr 11 13:12:38 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4470C12D777 for ; Wed, 11 Apr 2018 13:12:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523477553; bh=d6X4e9hLNBjKHXPneT2M8qCt1qUYIJdBN0Fmesb532s=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To:To:To:To:To; b=oiBEfSpd63Babr7jmeW2Pt/OqEevDB8wmuMTW7OgRZRba/u3+F6pxyp2wPgzgXQXe orckZAUjUHOWlIDBjl6SkIKZMmEeDSYRPo7cmgRaxycLiFK1IV/84RKxssxqHRTays ugjm6ZEwYM0bccAro/iUnHtePwDRj+nD+N4SJ2mM=
X-Mailbox-Line: From stephen.farrell@cs.tcd.ie  Wed Apr 11 13:12:33 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BBB1271FD; Wed, 11 Apr 2018 13:12:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523477553; bh=d6X4e9hLNBjKHXPneT2M8qCt1qUYIJdBN0Fmesb532s=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To:To:To:To:To; b=oiBEfSpd63Babr7jmeW2Pt/OqEevDB8wmuMTW7OgRZRba/u3+F6pxyp2wPgzgXQXe orckZAUjUHOWlIDBjl6SkIKZMmEeDSYRPo7cmgRaxycLiFK1IV/84RKxssxqHRTays ugjm6ZEwYM0bccAro/iUnHtePwDRj+nD+N4SJ2mM=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49CB12D72F for ; Wed, 11 Apr 2018 13:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXa3cAxdEXah for ; Wed, 11 Apr 2018 13:12:29 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976831271FD for ; Wed, 11 Apr 2018 13:12:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B46BEBE4D; Wed, 11 Apr 2018 21:12:27 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZlHV_QdvRGv; Wed, 11 Apr 2018 21:12:26 +0100 (IST)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AB3A3BE38; Wed, 11 Apr 2018 21:12:25 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1523477546; bh=d6X4e9hLNBjKHXPneT2M8qCt1qUYIJdBN0Fmesb532s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VyKK21J12Fg/wwgciYSVATVBlU1rdwoREGHtHV9POA1F3YsVHvKhFlBVZiyLqoPKA rc9QxXejlAXBAeM3CKALT845l8V/Xv9QIHndEm9EO3kW3fS8HWAeaDzkcaabo4iKeT b2AHbRmlZxTtnfL3AblexEthRxTyPwDs1cMeiga4=
Subject: Re: Simple transform for improving PN ossification prevention
Cc: Victor Vasiliev , IETF QUIC WG , Ryan Hamilton 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie> <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie>
Date: Wed, 11 Apr 2018 21:12:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HYhe0G09Oqk4gqfyksOOM80GRLvB36j9M"
To: "Lubashev, Igor" 
To: "Lubashev, Igor" 
To: Roberto Peon 
To: "Fossati, Thomas \(Nokia - GB/Cambridge\)" 
To: Kazuho Oku 
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 20:12:33 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HYhe0G09Oqk4gqfyksOOM80GRLvB36j9M
Content-Type: multipart/mixed; boundary="oGy0YEakfmwoCdWnotn3VNgtxuCvm7I7R";
 protected-headers="v1"
From: Stephen Farrell 
To: "Lubashev, Igor" ,
 "Lubashev, Igor" , Roberto Peon ,
 "Fossati, Thomas (Nokia - GB/Cambridge)" ,
 Kazuho Oku ,
 Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG ,
 Ryan Hamilton 
Message-ID: <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie>
Subject: Re: Simple transform for improving PN ossification prevention
References: 
 
 
 
 
 
 <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
 
 <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
 <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
 <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
 <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>

--oGy0YEakfmwoCdWnotn3VNgtxuCvm7I7R
Content-Type: multipart/mixed;
 boundary="------------1592AEDF8CC6515139DDE8D0"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------1592AEDF8CC6515139DDE8D0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 11/04/18 17:37, Lubashev, Igor wrote:
> Yes, these are difficult questions, especially since most of the=20
> information is unknown, and we are to weigh estimates and risks=20
> against each other.  But this is especially important when so many=20
> things are uncertain to keep at least the questions we are answering=20
> clear.  Hence, I would consider "Are we asking all Internet users to=20
> pay a tax by not improving privacy?" to be not a clear question but
> a rhetorical one. =20

I took 'em as questions and not as rhetorical questions:-)

> I meant "tax" in a very specific way -- the=20
> real-world _financial_ cost.  I specifically want to pose questions=20
> of trade-offs of financial costs vs. benefits (very valuable
> benefits to be sure).

Again, there's the same problem - are you trying to measure the
financial benefits of privacy? Or are you trying to compare the
financial costs of (e.g. PNE) against some other measure of the
benefits of privacy? I'm still in a position where I don't know
how to make those comparisons.

So maybe yeah, you're right that we're better considering your
specific questions purely as rhetorical and try find other
questions that could be answered.

Cheers,
S.

>=20
> * Are we asking all Internet users to pay a tax to improve privacy?=20
> Does the amount of the tax justify the amount of privacy benefits it=20
> buys?
>=20
> * Are we asking all Internet users to pay a tax to reduce PN=20
> ossification?  Does the amount of the tax justify the added=20
> flexibility protocol designers might need in the future?
>=20
>=20
> - Igor
>=20
>=20
> -----Original Message----- From: Stephen Farrell=20
> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, April 11, 2018=20
> 11:37 AM To: Lubashev, Igor ;=20
> Roberto Peon ; Fossati, Thomas (Nokia - GB/Cambridge)=20
> ; Kazuho Oku ;
> Praveen Balasubramanian  Cc: Victor Vasiliev=20
> ; IETF QUIC WG ; Ryan Hamilton=20
>  Subject: Re: Simple transform for improving PN=20
> ossification prevention
>=20
>=20
> Hiya,
>=20
> On 11/04/18 16:21, Lubashev, Igor wrote:
>> * Are we asking all Internet users to pay a tax to improve privacy?
>> Does the amount of the tax justify the amount of privacy benefits
>> it buys?
> I think that (and your other questions) are good things to ponder,=20
> but I don't believe the questions above are really answerable, at=20
> least not unless we can also answer the opposite question ("Are we=20
> asking all Internet users to pay a tax by not improving privacy?"),=20
> and I'm pretty sure I at least don't know how to evaluate that=20
> question. Maybe that's part of why this discussion is so tricky.
>=20
> Personally, as a future user of QUIC (but not an implementer), I'd=20
> really prefer that the WG prioritise privacy-friendly mechanisms if=20
> at all possible, even if the direct benefits aren't completely=20
> clear.
>=20
> Cheers, S.
>=20

--------------1592AEDF8CC6515139DDE8D0
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------1592AEDF8CC6515139DDE8D0--

--oGy0YEakfmwoCdWnotn3VNgtxuCvm7I7R--

--HYhe0G09Oqk4gqfyksOOM80GRLvB36j9M
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJazmwoAAoJEFqy+vF7FyvqiwwQAM8VYhOAk8pFtvCJpPwuZg6L
ou6Sp0W/caffNmnjeRsdscofup89TR3HJDMfs7ebQMEJqujMPmVEHJcs1OLaa6HL
v1YgJ4QFZriU2kyq8iYro5O0lUwB//AWR8DrbD1SDw/4T75TadjG99qDmRTH9V2m
h4Cx0Ul7BOqLH84VL59kl0Z0ECaF90zGyLDrTpDz+7jZsWFevByxN1Szj/Q2Z/CC
DJCpOh/FJaHQ7Q3Vp9BGrheajCzClnsnjhgjX2d8mMoWYCp1hZ+HjrB/jBGGUKzh
XcW+99ON/uZXXZgjC6yXUgG6KNWXHC8/QU/1eU0xQRDZgv6JyEhwXSOSq9KISzGJ
vVt6QjoK0uXgQwjHNzFAF38X27xVp7YZjRBg10SorqPAr8DdO/YernlYmjo0CQOR
5Tady26TrzIi90yi8AVZgvtRJ+prXTBf/QyV+aLOsOnOsYNYpp8h56rU/8XnsB1M
OaBysJakDN2FGZLxv2M5qlr27HAbKYs/Bi9aRDpGFFFUsLxoqMmZBMJyS4KGkR4L
Kk0rdIDBpZuOf9WKTav0gCQINkZiHa0lRatXp0cL2FJl7w9fSCkg7/+xx4ue1+z/
8rD8BqYGMBMi/gh2cT0umCq8aBPqiNzMRkzzMgLDG3U7ecSj6zSuCdyy3ztZE9tb
+X58eNQHkQll3W1ySn8w
=xw/E
-----END PGP SIGNATURE-----

--HYhe0G09Oqk4gqfyksOOM80GRLvB36j9M--


From nobody Wed Apr 11 14:55:16 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6D912D7E4 for ; Wed, 11 Apr 2018 14:55:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523483715; bh=xV9AUaYFmucyi/X+SyFUvR+Dcj9xH3n4u+bguTesnXY=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To:To:To:To; b=cvMwiRpYQkv/OtwP+qZZwdrrR7Ptu+atk8k5I0cTIkH85yBW7ph0XSUQjJPu0HJSA DzL2Cn+EJ5IzXrkXNA0cP1ZSZMwBTiWAspqu5FXJwC7aybZswtPvxCqwA+h9wrWF2m 2c39k9nIXxfzYymsFeSvKAj6T/t2wG2lXLBxmirI=
X-Mailbox-Line: From ilubashe@akamai.com  Wed Apr 11 14:55:15 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C21012D77D; Wed, 11 Apr 2018 14:55:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523483715; bh=xV9AUaYFmucyi/X+SyFUvR+Dcj9xH3n4u+bguTesnXY=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To:To:To:To; b=cvMwiRpYQkv/OtwP+qZZwdrrR7Ptu+atk8k5I0cTIkH85yBW7ph0XSUQjJPu0HJSA DzL2Cn+EJ5IzXrkXNA0cP1ZSZMwBTiWAspqu5FXJwC7aybZswtPvxCqwA+h9wrWF2m 2c39k9nIXxfzYymsFeSvKAj6T/t2wG2lXLBxmirI=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1894A124D37 for ; Wed, 11 Apr 2018 14:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSF_hnwCh3Yi for ; Wed, 11 Apr 2018 14:55:12 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8CB12D77D for ; Wed, 11 Apr 2018 14:55:12 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w3BLrGLO017206; Wed, 11 Apr 2018 22:55:08 +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=xV9AUaYFmucyi/X+SyFUvR+Dcj9xH3n4u+bguTesnXY=; b=IQqxyXKBGUZce4nI5xFRRo2XPBZ9JTqYyPqtP7sZ1WMjKufwCTtDNjiFS7X2bWFi8Wsu rZMjgMS999BcM78Nwq7Uc6h/WDeYk8TBWVSWMlZ5lpkAzFv9n9ki2FfPajeVzgBR5pOF mwbBnKvh8GlEZ6uQdI2D74kKwSYhCRDffurORuwA2umGt1wDoLD5YLWANkRSku2IjiRc rcimYvX48wyMfoBDx9joBoU37nBG2FakuYz9wYr4X2/h5boO15By3n37eTMVAuLzm0yL iB1hB+M839u5Li3vkYBVEmK6D1uu4tQ/f+QsknZniTXo3P27JIExmUjJzUeRywBwpZRy ZQ== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2h9edua3j9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 22:55:08 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3BLjq3A005698; Wed, 11 Apr 2018 17:55:07 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint3.akamai.com with ESMTP id 2h78phyexq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 17:55:07 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 11 Apr 2018 17:55:05 -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.1365.000; Wed, 11 Apr 2018 17:55:05 -0400
From: "Lubashev, Igor" 
CC: Victor Vasiliev , IETF QUIC WG , "Ryan Hamilton" 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAgCbeAABH1ToAAB78MgAAEx/uAAAb1bwAADHjfgAAAkzqAAAEjd4AABEmfIAAKNo+AAAcX+OAAAoXaAAAG/xqA
Date: Wed, 11 Apr 2018 21:55:04 +0000
Message-ID: <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie> <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com> <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie>
In-Reply-To: <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.33.243]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110203
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=935 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110204
To: Stephen Farrell 
To: "Lubashev, Igor" 
To: Roberto Peon 
To: "Fossati, Thomas \(Nokia - GB/Cambridge\)" 
To: Kazuho Oku 
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 21:55:15 -0000

U3RlcGhlbiwgSSB0aGluayBJIHdhcyBub3QgY2xlYXIuICBNeSBhcG9sb2dpZXMuDQoNClRvIGNv
bXBhcmUgdGhlIHZhbHVlIG9mIHRoaW5ncywgeW91IGNlcnRhaW5seSBuZWVkIHRvIGZpcnN0IGNv
bnZlcnQgdGhlIHZhbHVlcyB0byB0aGUgc2FtZSB1bml0cy4gIFNpbmNlIG9uIG9uZSBoYW5kIHdl
IGhhdmUgYSAkIHZhbHVlIChtb3JlIENQVXMsIGxhcmdlciBiYXR0ZXJpZXMsIG1vcmUgYmFzZSBz
dGF0aW9ucywgY29zdGxpZXIgbmV0d29yayB0cm91Ymxlc2hvb3RpbmcsIC4uLiksIGl0IHNlZW1z
IG5hdHVyYWwgdG8gY29udmVydCBldmVyeXRoaW5nIHRvICQuICAoT2YgY291cnNlLCB3ZSBjYW4g
b25seSBob3BlIGZvciB2ZXJ5IHJvdWdoIFQtc2hpcnQgc2l6ZSBhcHByb3hpbWF0aW9ucyBoZXJl
LikNCg0KDQo+IGZpbmFuY2lhbCBiZW5lZml0cyBvZiBwcml2YWN5DQoNClllcy4gIE9yLCBiZXR0
ZXIsICJmaW5hbmNpYWwgYmVuZWZpdHMgb2YgdGhlIGluY3JlbWVudGFsIGNoYW5nZSBpbiBwcml2
YWN5IGR1cmluZyBkZWxpYmVyYXRlIGNvbm5lY3Rpb24gbWlncmF0aW9uIi4gIChBbnl0aGluZyB0
aGF0IGlzIG5vdCB3b3JzZSB0aGFuIFRMUzEuMytUQ1AgZml0cyB0aGUgQ2hhcnRlci4pICBXZSBt
YXkgYXMgd2VsbCBkZWNpZGUgdGhhdCBtb3N0IHBlb3BsZSBvbiB0aGUgSW50ZXJuZXQgYXJlIHdp
bGxpbmcgdG8gcGF5IChvciB3b3VsZCBiZSB3aWxsaW5nIHRvIHBheSwgaWYgdGhleSBrbmV3IGJl
dHRlcikgYSBsb3QgZm9yIGV2ZXJ5IHNpbmdsZSBiaXQgb2YgZXh0cmEgcHJpdmFjeSBmcm9tIHBl
cnZhc2l2ZSBzdXJ2ZWlsbGFuY2UsIHNvIHRoZSBjb3N0cyBhcmUganVzdGlmaWVkLiAgKEp1ZGdp
bmcgZnJvbSBwZW9wbGUncyBjdXJyZW50IGJlaGF2aW9yIHBhdHRlcm5zIHRoaXMgZG9lcyBub3Qg
c2VlbSB0byBiZSB0cnVlLikNCg0KRGl0dG8gZm9yIHRoZSBmaW5hbmNpYWwgYmVuZWZpdHMgb2Yg
cHJldmVudGluZyBvc3NpZmljYXRpb24gb2YgUE5zLg0KDQotIElnb3INCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFy
cmVsbEBjcy50Y2QuaWVdIA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMSwgMjAxOCA0OjEyIFBN
DQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlPTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9y
Zz47IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsgUm9iZXJ0byBQZW9uIDxm
ZW5peEBmYi5jb20+OyBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlKSA8dGhv
bWFzLmZvc3NhdGlAbm9raWEuY29tPjsgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbT47
IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPg0KQ2M6IFZpY3Rv
ciBWYXNpbGlldiA8dmFzaWx2dkBnb29nbGUuY29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYu
b3JnPjsgUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTogU2ltcGxl
IHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uDQoNCg0K
SGl5YSwNCg0KT24gMTEvMDQvMTggMTc6MzcsIEx1YmFzaGV2LCBJZ29yIHdyb3RlOg0KPiBZZXMs
IHRoZXNlIGFyZSBkaWZmaWN1bHQgcXVlc3Rpb25zLCBlc3BlY2lhbGx5IHNpbmNlIG1vc3Qgb2Yg
dGhlIA0KPiBpbmZvcm1hdGlvbiBpcyB1bmtub3duLCBhbmQgd2UgYXJlIHRvIHdlaWdoIGVzdGlt
YXRlcyBhbmQgcmlza3MgDQo+IGFnYWluc3QgZWFjaCBvdGhlci4gIEJ1dCB0aGlzIGlzIGVzcGVj
aWFsbHkgaW1wb3J0YW50IHdoZW4gc28gbWFueSANCj4gdGhpbmdzIGFyZSB1bmNlcnRhaW4gdG8g
a2VlcCBhdCBsZWFzdCB0aGUgcXVlc3Rpb25zIHdlIGFyZSBhbnN3ZXJpbmcgDQo+IGNsZWFyLiAg
SGVuY2UsIEkgd291bGQgY29uc2lkZXIgIkFyZSB3ZSBhc2tpbmcgYWxsIEludGVybmV0IHVzZXJz
IHRvIA0KPiBwYXkgYSB0YXggYnkgbm90IGltcHJvdmluZyBwcml2YWN5PyIgdG8gYmUgbm90IGEg
Y2xlYXIgcXVlc3Rpb24gYnV0IGEgDQo+IHJoZXRvcmljYWwgb25lLg0KDQpJIHRvb2sgJ2VtIGFz
IHF1ZXN0aW9ucyBhbmQgbm90IGFzIHJoZXRvcmljYWwgcXVlc3Rpb25zOi0pDQoNCj4gSSBtZWFu
dCAidGF4IiBpbiBhIHZlcnkgc3BlY2lmaWMgd2F5IC0tIHRoZSByZWFsLXdvcmxkIF9maW5hbmNp
YWxfIA0KPiBjb3N0LiAgSSBzcGVjaWZpY2FsbHkgd2FudCB0byBwb3NlIHF1ZXN0aW9ucyBvZiB0
cmFkZS1vZmZzIG9mIA0KPiBmaW5hbmNpYWwgY29zdHMgdnMuIGJlbmVmaXRzICh2ZXJ5IHZhbHVh
YmxlIGJlbmVmaXRzIHRvIGJlIHN1cmUpLg0KDQpBZ2FpbiwgdGhlcmUncyB0aGUgc2FtZSBwcm9i
bGVtIC0gYXJlIHlvdSB0cnlpbmcgdG8gbWVhc3VyZSB0aGUgZmluYW5jaWFsIGJlbmVmaXRzIG9m
IHByaXZhY3k/IE9yIGFyZSB5b3UgdHJ5aW5nIHRvIGNvbXBhcmUgdGhlIGZpbmFuY2lhbCBjb3N0
cyBvZiAoZS5nLiBQTkUpIGFnYWluc3Qgc29tZSBvdGhlciBtZWFzdXJlIG9mIHRoZSBiZW5lZml0
cyBvZiBwcml2YWN5PyBJJ20gc3RpbGwgaW4gYSBwb3NpdGlvbiB3aGVyZSBJIGRvbid0IGtub3cg
aG93IHRvIG1ha2UgdGhvc2UgY29tcGFyaXNvbnMuDQoNClNvIG1heWJlIHllYWgsIHlvdSdyZSBy
aWdodCB0aGF0IHdlJ3JlIGJldHRlciBjb25zaWRlcmluZyB5b3VyIHNwZWNpZmljIHF1ZXN0aW9u
cyBwdXJlbHkgYXMgcmhldG9yaWNhbCBhbmQgdHJ5IGZpbmQgb3RoZXIgcXVlc3Rpb25zIHRoYXQg
Y291bGQgYmUgYW5zd2VyZWQuDQoNCkNoZWVycywNClMuDQoNCj4gDQo+ICogQXJlIHdlIGFza2lu
ZyBhbGwgSW50ZXJuZXQgdXNlcnMgdG8gcGF5IGEgdGF4IHRvIGltcHJvdmUgcHJpdmFjeT8gDQo+
IERvZXMgdGhlIGFtb3VudCBvZiB0aGUgdGF4IGp1c3RpZnkgdGhlIGFtb3VudCBvZiBwcml2YWN5
IGJlbmVmaXRzIGl0IA0KPiBidXlzPw0KPiANCj4gKiBBcmUgd2UgYXNraW5nIGFsbCBJbnRlcm5l
dCB1c2VycyB0byBwYXkgYSB0YXggdG8gcmVkdWNlIFBOIA0KPiBvc3NpZmljYXRpb24/ICBEb2Vz
IHRoZSBhbW91bnQgb2YgdGhlIHRheCBqdXN0aWZ5IHRoZSBhZGRlZCANCj4gZmxleGliaWxpdHkg
cHJvdG9jb2wgZGVzaWduZXJzIG1pZ2h0IG5lZWQgaW4gdGhlIGZ1dHVyZT8NCj4gDQo+IA0KPiAt
IElnb3INCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBTdGVwaGVu
IEZhcnJlbGwgDQo+IFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0gU2VudDogV2Vk
bmVzZGF5LCBBcHJpbCAxMSwgMjAxOA0KPiAxMTozNyBBTSBUbzogTHViYXNoZXYsIElnb3IgPGls
dWJhc2hlPTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZz47DQo+IFJvYmVydG8gUGVvbiA8ZmVu
aXhAZmIuY29tPjsgRm9zc2F0aSwgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSkgDQo+IDx0
aG9tYXMuZm9zc2F0aUBub2tpYS5jb20+OyBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29t
PjsgUHJhdmVlbiANCj4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPiBDYzog
VmljdG9yIFZhc2lsaWV2IA0KPiA8dmFzaWx2dkBnb29nbGUuY29tPjsgSUVURiBRVUlDIFdHIDxx
dWljQGlldGYub3JnPjsgUnlhbiBIYW1pbHRvbiANCj4gPHJjaEBnb29nbGUuY29tPiBTdWJqZWN0
OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIA0KPiBvc3NpZmljYXRpb24g
cHJldmVudGlvbg0KPiANCj4gDQo+IEhpeWEsDQo+IA0KPiBPbiAxMS8wNC8xOCAxNjoyMSwgTHVi
YXNoZXYsIElnb3Igd3JvdGU6DQo+PiAqIEFyZSB3ZSBhc2tpbmcgYWxsIEludGVybmV0IHVzZXJz
IHRvIHBheSBhIHRheCB0byBpbXByb3ZlIHByaXZhY3k/DQo+PiBEb2VzIHRoZSBhbW91bnQgb2Yg
dGhlIHRheCBqdXN0aWZ5IHRoZSBhbW91bnQgb2YgcHJpdmFjeSBiZW5lZml0cyBpdCANCj4+IGJ1
eXM/DQo+IEkgdGhpbmsgdGhhdCAoYW5kIHlvdXIgb3RoZXIgcXVlc3Rpb25zKSBhcmUgZ29vZCB0
aGluZ3MgdG8gcG9uZGVyLCBidXQgDQo+IEkgZG9uJ3QgYmVsaWV2ZSB0aGUgcXVlc3Rpb25zIGFi
b3ZlIGFyZSByZWFsbHkgYW5zd2VyYWJsZSwgYXQgbGVhc3QgDQo+IG5vdCB1bmxlc3Mgd2UgY2Fu
IGFsc28gYW5zd2VyIHRoZSBvcHBvc2l0ZSBxdWVzdGlvbiAoIkFyZSB3ZSBhc2tpbmcgDQo+IGFs
bCBJbnRlcm5ldCB1c2VycyB0byBwYXkgYSB0YXggYnkgbm90IGltcHJvdmluZyBwcml2YWN5PyIp
LCBhbmQgSSdtIA0KPiBwcmV0dHkgc3VyZSBJIGF0IGxlYXN0IGRvbid0IGtub3cgaG93IHRvIGV2
YWx1YXRlIHRoYXQgcXVlc3Rpb24uIE1heWJlIA0KPiB0aGF0J3MgcGFydCBvZiB3aHkgdGhpcyBk
aXNjdXNzaW9uIGlzIHNvIHRyaWNreS4NCj4gDQo+IFBlcnNvbmFsbHksIGFzIGEgZnV0dXJlIHVz
ZXIgb2YgUVVJQyAoYnV0IG5vdCBhbiBpbXBsZW1lbnRlciksIEknZCANCj4gcmVhbGx5IHByZWZl
ciB0aGF0IHRoZSBXRyBwcmlvcml0aXNlIHByaXZhY3ktZnJpZW5kbHkgbWVjaGFuaXNtcyBpZiBh
dCANCj4gYWxsIHBvc3NpYmxlLCBldmVuIGlmIHRoZSBkaXJlY3QgYmVuZWZpdHMgYXJlbid0IGNv
bXBsZXRlbHkgY2xlYXIuDQo+IA0KPiBDaGVlcnMsIFMuDQo+IA0K


From nobody Wed Apr 11 14:55:23 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB6712D948 for ; Wed, 11 Apr 2018 14:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable 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 CYQDsXyGEoJC for ; Wed, 11 Apr 2018 14:55:16 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8397712D7E4 for ; Wed, 11 Apr 2018 14:55:16 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w3BLrGLO017206; Wed, 11 Apr 2018 22:55:08 +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=xV9AUaYFmucyi/X+SyFUvR+Dcj9xH3n4u+bguTesnXY=; b=IQqxyXKBGUZce4nI5xFRRo2XPBZ9JTqYyPqtP7sZ1WMjKufwCTtDNjiFS7X2bWFi8Wsu rZMjgMS999BcM78Nwq7Uc6h/WDeYk8TBWVSWMlZ5lpkAzFv9n9ki2FfPajeVzgBR5pOF mwbBnKvh8GlEZ6uQdI2D74kKwSYhCRDffurORuwA2umGt1wDoLD5YLWANkRSku2IjiRc rcimYvX48wyMfoBDx9joBoU37nBG2FakuYz9wYr4X2/h5boO15By3n37eTMVAuLzm0yL iB1hB+M839u5Li3vkYBVEmK6D1uu4tQ/f+QsknZniTXo3P27JIExmUjJzUeRywBwpZRy ZQ== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2h9edua3j9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 22:55:08 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3BLjq3A005698; Wed, 11 Apr 2018 17:55:07 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint3.akamai.com with ESMTP id 2h78phyexq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 17:55:07 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 11 Apr 2018 17:55:05 -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.1365.000; Wed, 11 Apr 2018 17:55:05 -0400
From: "Lubashev, Igor" 
To: Stephen Farrell , "Lubashev, Igor" , Roberto Peon , "Fossati, Thomas (Nokia - GB/Cambridge)" , "Kazuho Oku" , Praveen Balasubramanian 
CC: Victor Vasiliev , IETF QUIC WG , "Ryan Hamilton" 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAgCbeAABH1ToAAB78MgAAEx/uAAAb1bwAADHjfgAAAkzqAAAEjd4AABEmfIAAKNo+AAAcX+OAAAoXaAAAG/xqA
Date: Wed, 11 Apr 2018 21:55:04 +0000
Message-ID: <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie> <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com> <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie>
In-Reply-To: <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.33.243]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110203
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=935 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110204
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 21:55:21 -0000

U3RlcGhlbiwgSSB0aGluayBJIHdhcyBub3QgY2xlYXIuICBNeSBhcG9sb2dpZXMuDQoNClRvIGNv
bXBhcmUgdGhlIHZhbHVlIG9mIHRoaW5ncywgeW91IGNlcnRhaW5seSBuZWVkIHRvIGZpcnN0IGNv
bnZlcnQgdGhlIHZhbHVlcyB0byB0aGUgc2FtZSB1bml0cy4gIFNpbmNlIG9uIG9uZSBoYW5kIHdl
IGhhdmUgYSAkIHZhbHVlIChtb3JlIENQVXMsIGxhcmdlciBiYXR0ZXJpZXMsIG1vcmUgYmFzZSBz
dGF0aW9ucywgY29zdGxpZXIgbmV0d29yayB0cm91Ymxlc2hvb3RpbmcsIC4uLiksIGl0IHNlZW1z
IG5hdHVyYWwgdG8gY29udmVydCBldmVyeXRoaW5nIHRvICQuICAoT2YgY291cnNlLCB3ZSBjYW4g
b25seSBob3BlIGZvciB2ZXJ5IHJvdWdoIFQtc2hpcnQgc2l6ZSBhcHByb3hpbWF0aW9ucyBoZXJl
LikNCg0KDQo+IGZpbmFuY2lhbCBiZW5lZml0cyBvZiBwcml2YWN5DQoNClllcy4gIE9yLCBiZXR0
ZXIsICJmaW5hbmNpYWwgYmVuZWZpdHMgb2YgdGhlIGluY3JlbWVudGFsIGNoYW5nZSBpbiBwcml2
YWN5IGR1cmluZyBkZWxpYmVyYXRlIGNvbm5lY3Rpb24gbWlncmF0aW9uIi4gIChBbnl0aGluZyB0
aGF0IGlzIG5vdCB3b3JzZSB0aGFuIFRMUzEuMytUQ1AgZml0cyB0aGUgQ2hhcnRlci4pICBXZSBt
YXkgYXMgd2VsbCBkZWNpZGUgdGhhdCBtb3N0IHBlb3BsZSBvbiB0aGUgSW50ZXJuZXQgYXJlIHdp
bGxpbmcgdG8gcGF5IChvciB3b3VsZCBiZSB3aWxsaW5nIHRvIHBheSwgaWYgdGhleSBrbmV3IGJl
dHRlcikgYSBsb3QgZm9yIGV2ZXJ5IHNpbmdsZSBiaXQgb2YgZXh0cmEgcHJpdmFjeSBmcm9tIHBl
cnZhc2l2ZSBzdXJ2ZWlsbGFuY2UsIHNvIHRoZSBjb3N0cyBhcmUganVzdGlmaWVkLiAgKEp1ZGdp
bmcgZnJvbSBwZW9wbGUncyBjdXJyZW50IGJlaGF2aW9yIHBhdHRlcm5zIHRoaXMgZG9lcyBub3Qg
c2VlbSB0byBiZSB0cnVlLikNCg0KRGl0dG8gZm9yIHRoZSBmaW5hbmNpYWwgYmVuZWZpdHMgb2Yg
cHJldmVudGluZyBvc3NpZmljYXRpb24gb2YgUE5zLg0KDQotIElnb3INCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFy
cmVsbEBjcy50Y2QuaWVdIA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMSwgMjAxOCA0OjEyIFBN
DQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlPTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9y
Zz47IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsgUm9iZXJ0byBQZW9uIDxm
ZW5peEBmYi5jb20+OyBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlKSA8dGhv
bWFzLmZvc3NhdGlAbm9raWEuY29tPjsgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbT47
IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPg0KQ2M6IFZpY3Rv
ciBWYXNpbGlldiA8dmFzaWx2dkBnb29nbGUuY29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYu
b3JnPjsgUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTogU2ltcGxl
IHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uDQoNCg0K
SGl5YSwNCg0KT24gMTEvMDQvMTggMTc6MzcsIEx1YmFzaGV2LCBJZ29yIHdyb3RlOg0KPiBZZXMs
IHRoZXNlIGFyZSBkaWZmaWN1bHQgcXVlc3Rpb25zLCBlc3BlY2lhbGx5IHNpbmNlIG1vc3Qgb2Yg
dGhlIA0KPiBpbmZvcm1hdGlvbiBpcyB1bmtub3duLCBhbmQgd2UgYXJlIHRvIHdlaWdoIGVzdGlt
YXRlcyBhbmQgcmlza3MgDQo+IGFnYWluc3QgZWFjaCBvdGhlci4gIEJ1dCB0aGlzIGlzIGVzcGVj
aWFsbHkgaW1wb3J0YW50IHdoZW4gc28gbWFueSANCj4gdGhpbmdzIGFyZSB1bmNlcnRhaW4gdG8g
a2VlcCBhdCBsZWFzdCB0aGUgcXVlc3Rpb25zIHdlIGFyZSBhbnN3ZXJpbmcgDQo+IGNsZWFyLiAg
SGVuY2UsIEkgd291bGQgY29uc2lkZXIgIkFyZSB3ZSBhc2tpbmcgYWxsIEludGVybmV0IHVzZXJz
IHRvIA0KPiBwYXkgYSB0YXggYnkgbm90IGltcHJvdmluZyBwcml2YWN5PyIgdG8gYmUgbm90IGEg
Y2xlYXIgcXVlc3Rpb24gYnV0IGEgDQo+IHJoZXRvcmljYWwgb25lLg0KDQpJIHRvb2sgJ2VtIGFz
IHF1ZXN0aW9ucyBhbmQgbm90IGFzIHJoZXRvcmljYWwgcXVlc3Rpb25zOi0pDQoNCj4gSSBtZWFu
dCAidGF4IiBpbiBhIHZlcnkgc3BlY2lmaWMgd2F5IC0tIHRoZSByZWFsLXdvcmxkIF9maW5hbmNp
YWxfIA0KPiBjb3N0LiAgSSBzcGVjaWZpY2FsbHkgd2FudCB0byBwb3NlIHF1ZXN0aW9ucyBvZiB0
cmFkZS1vZmZzIG9mIA0KPiBmaW5hbmNpYWwgY29zdHMgdnMuIGJlbmVmaXRzICh2ZXJ5IHZhbHVh
YmxlIGJlbmVmaXRzIHRvIGJlIHN1cmUpLg0KDQpBZ2FpbiwgdGhlcmUncyB0aGUgc2FtZSBwcm9i
bGVtIC0gYXJlIHlvdSB0cnlpbmcgdG8gbWVhc3VyZSB0aGUgZmluYW5jaWFsIGJlbmVmaXRzIG9m
IHByaXZhY3k/IE9yIGFyZSB5b3UgdHJ5aW5nIHRvIGNvbXBhcmUgdGhlIGZpbmFuY2lhbCBjb3N0
cyBvZiAoZS5nLiBQTkUpIGFnYWluc3Qgc29tZSBvdGhlciBtZWFzdXJlIG9mIHRoZSBiZW5lZml0
cyBvZiBwcml2YWN5PyBJJ20gc3RpbGwgaW4gYSBwb3NpdGlvbiB3aGVyZSBJIGRvbid0IGtub3cg
aG93IHRvIG1ha2UgdGhvc2UgY29tcGFyaXNvbnMuDQoNClNvIG1heWJlIHllYWgsIHlvdSdyZSBy
aWdodCB0aGF0IHdlJ3JlIGJldHRlciBjb25zaWRlcmluZyB5b3VyIHNwZWNpZmljIHF1ZXN0aW9u
cyBwdXJlbHkgYXMgcmhldG9yaWNhbCBhbmQgdHJ5IGZpbmQgb3RoZXIgcXVlc3Rpb25zIHRoYXQg
Y291bGQgYmUgYW5zd2VyZWQuDQoNCkNoZWVycywNClMuDQoNCj4gDQo+ICogQXJlIHdlIGFza2lu
ZyBhbGwgSW50ZXJuZXQgdXNlcnMgdG8gcGF5IGEgdGF4IHRvIGltcHJvdmUgcHJpdmFjeT8gDQo+
IERvZXMgdGhlIGFtb3VudCBvZiB0aGUgdGF4IGp1c3RpZnkgdGhlIGFtb3VudCBvZiBwcml2YWN5
IGJlbmVmaXRzIGl0IA0KPiBidXlzPw0KPiANCj4gKiBBcmUgd2UgYXNraW5nIGFsbCBJbnRlcm5l
dCB1c2VycyB0byBwYXkgYSB0YXggdG8gcmVkdWNlIFBOIA0KPiBvc3NpZmljYXRpb24/ICBEb2Vz
IHRoZSBhbW91bnQgb2YgdGhlIHRheCBqdXN0aWZ5IHRoZSBhZGRlZCANCj4gZmxleGliaWxpdHkg
cHJvdG9jb2wgZGVzaWduZXJzIG1pZ2h0IG5lZWQgaW4gdGhlIGZ1dHVyZT8NCj4gDQo+IA0KPiAt
IElnb3INCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBTdGVwaGVu
IEZhcnJlbGwgDQo+IFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0gU2VudDogV2Vk
bmVzZGF5LCBBcHJpbCAxMSwgMjAxOA0KPiAxMTozNyBBTSBUbzogTHViYXNoZXYsIElnb3IgPGls
dWJhc2hlPTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZz47DQo+IFJvYmVydG8gUGVvbiA8ZmVu
aXhAZmIuY29tPjsgRm9zc2F0aSwgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSkgDQo+IDx0
aG9tYXMuZm9zc2F0aUBub2tpYS5jb20+OyBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29t
PjsgUHJhdmVlbiANCj4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPiBDYzog
VmljdG9yIFZhc2lsaWV2IA0KPiA8dmFzaWx2dkBnb29nbGUuY29tPjsgSUVURiBRVUlDIFdHIDxx
dWljQGlldGYub3JnPjsgUnlhbiBIYW1pbHRvbiANCj4gPHJjaEBnb29nbGUuY29tPiBTdWJqZWN0
OiBSZTogU2ltcGxlIHRyYW5zZm9ybSBmb3IgaW1wcm92aW5nIFBOIA0KPiBvc3NpZmljYXRpb24g
cHJldmVudGlvbg0KPiANCj4gDQo+IEhpeWEsDQo+IA0KPiBPbiAxMS8wNC8xOCAxNjoyMSwgTHVi
YXNoZXYsIElnb3Igd3JvdGU6DQo+PiAqIEFyZSB3ZSBhc2tpbmcgYWxsIEludGVybmV0IHVzZXJz
IHRvIHBheSBhIHRheCB0byBpbXByb3ZlIHByaXZhY3k/DQo+PiBEb2VzIHRoZSBhbW91bnQgb2Yg
dGhlIHRheCBqdXN0aWZ5IHRoZSBhbW91bnQgb2YgcHJpdmFjeSBiZW5lZml0cyBpdCANCj4+IGJ1
eXM/DQo+IEkgdGhpbmsgdGhhdCAoYW5kIHlvdXIgb3RoZXIgcXVlc3Rpb25zKSBhcmUgZ29vZCB0
aGluZ3MgdG8gcG9uZGVyLCBidXQgDQo+IEkgZG9uJ3QgYmVsaWV2ZSB0aGUgcXVlc3Rpb25zIGFi
b3ZlIGFyZSByZWFsbHkgYW5zd2VyYWJsZSwgYXQgbGVhc3QgDQo+IG5vdCB1bmxlc3Mgd2UgY2Fu
IGFsc28gYW5zd2VyIHRoZSBvcHBvc2l0ZSBxdWVzdGlvbiAoIkFyZSB3ZSBhc2tpbmcgDQo+IGFs
bCBJbnRlcm5ldCB1c2VycyB0byBwYXkgYSB0YXggYnkgbm90IGltcHJvdmluZyBwcml2YWN5PyIp
LCBhbmQgSSdtIA0KPiBwcmV0dHkgc3VyZSBJIGF0IGxlYXN0IGRvbid0IGtub3cgaG93IHRvIGV2
YWx1YXRlIHRoYXQgcXVlc3Rpb24uIE1heWJlIA0KPiB0aGF0J3MgcGFydCBvZiB3aHkgdGhpcyBk
aXNjdXNzaW9uIGlzIHNvIHRyaWNreS4NCj4gDQo+IFBlcnNvbmFsbHksIGFzIGEgZnV0dXJlIHVz
ZXIgb2YgUVVJQyAoYnV0IG5vdCBhbiBpbXBsZW1lbnRlciksIEknZCANCj4gcmVhbGx5IHByZWZl
ciB0aGF0IHRoZSBXRyBwcmlvcml0aXNlIHByaXZhY3ktZnJpZW5kbHkgbWVjaGFuaXNtcyBpZiBh
dCANCj4gYWxsIHBvc3NpYmxlLCBldmVuIGlmIHRoZSBkaXJlY3QgYmVuZWZpdHMgYXJlbid0IGNv
bXBsZXRlbHkgY2xlYXIuDQo+IA0KPiBDaGVlcnMsIFMuDQo+IA0K


From nobody Wed Apr 11 15:14:36 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC356129C70 for ; Wed, 11 Apr 2018 15:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75mjIOMbInAx for ; Wed, 11 Apr 2018 15:14:31 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0400124D6C for ; Wed, 11 Apr 2018 15:14:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19426BE50; Wed, 11 Apr 2018 23:14:29 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TNLoMVngc47; Wed, 11 Apr 2018 23:14:27 +0100 (IST)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0C301BE38; Wed, 11 Apr 2018 23:14:27 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1523484867; bh=MNDnbs6ulaQ3oX9RV20Blz/k7nTXsnabMoCEOb4r9SQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZL4Jwo4cPxvGi8p6AvGlkVwd3EEB2Y4nhsq0pCz6FoYbYG3v7KRrkmPsTsYAKW9Vb zpdZNjCj5RYC4zrpmcF1zBu3nUcFPwGjURkqIQ1RPdwY2+f2Z+hd2QG49YsjD9TcFD 2lGmLsnHWJ3aT35B8f36uFB8rqti5dmypQmj8ntc=
Subject: Re: Simple transform for improving PN ossification prevention
To: "Lubashev, Igor" , Roberto Peon , "Fossati, Thomas (Nokia - GB/Cambridge)" , Kazuho Oku , Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG , Ryan Hamilton 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie> <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com> <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie> <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: 
Date: Wed, 11 Apr 2018 23:14:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UeWFCWNvsVDQaAc1aiSheYXycqi8EHsIX"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 22:14:34 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--UeWFCWNvsVDQaAc1aiSheYXycqi8EHsIX
Content-Type: multipart/mixed; boundary="8zBHNsH5Z6DxoNdlFcBwVJoQfXj92X37a";
 protected-headers="v1"
From: Stephen Farrell 
To: "Lubashev, Igor" ,
 Roberto Peon ,
 "Fossati, Thomas (Nokia - GB/Cambridge)" ,
 Kazuho Oku ,
 Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG ,
 Ryan Hamilton 
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
References: 
 
 
 
 
 
 <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
 
 <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
 <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
 <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
 <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>
 <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie>
 <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>

--8zBHNsH5Z6DxoNdlFcBwVJoQfXj92X37a
Content-Type: multipart/mixed;
 boundary="------------366525139E08410BB5A8FA00"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------366525139E08410BB5A8FA00
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 11/04/18 22:55, Lubashev, Igor wrote:
> Stephen, I think I was not clear.  My apologies.
>=20
> To compare the value of things, you certainly need to first convert
> the values to the same units.  Since on one hand we have a $ value
> (more CPUs, larger batteries, more base stations, costlier network
> troubleshooting, ...), it seems natural to convert everything to $.
> (Of course, we can only hope for very rough T-shirt size
> approximations here.)
>=20
>=20
>> financial benefits of privacy
>=20
> Yes.  Or, better, "financial benefits of the incremental change in
> privacy during deliberate connection migration". =20

So I've no idea how one might go about doing that without
stripping the term privacy of most of it's meaning. Nor do
I think it'd be particularly worthwhile trying tbh. OTOH,
you do give me the always-worthwhile opportunity to quote
Oscar Wilde: "Nowadays people know the price of everything
and the value of nothing." :-)

But if you do attempt to work that out, I'd be interested
in seeing what you come up with. Mind you that'd likely be
better off-list as I think we'd be wandering pretty far from
the WG's remit when we end up inevitably debating whether
Oscar was right or not.

S.

PS: Don't take this as me arguing for inefficiency wrt PNE,
I'm only arguing here about your suggested approach for
trying to analyse the trade-offs related to PNE.

> (Anything that is
> not worse than TLS1.3+TCP fits the Charter.)  We may as well decide
> that most people on the Internet are willing to pay (or would be
> willing to pay, if they knew better) a lot for every single bit of
> extra privacy from pervasive surveillance, so the costs are
> justified.  (Judging from people's current behavior patterns this
> does not seem to be true.)
>=20
> Ditto for the financial benefits of preventing ossification of PNs.
>=20
> - Igor
>=20
> -----Original Message----- From: Stephen Farrell
> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, April 11, 2018
> 4:12 PM To: Lubashev, Igor ;
> Lubashev, Igor ; Roberto Peon ;
> Fossati, Thomas (Nokia - GB/Cambridge) ;
> Kazuho Oku ; Praveen Balasubramanian
>  Cc: Victor Vasiliev ; IETF
> QUIC WG ; Ryan Hamilton  Subject: Re:
> Simple transform for improving PN ossification prevention
>=20
>=20
> Hiya,
>=20
> On 11/04/18 17:37, Lubashev, Igor wrote:
>> Yes, these are difficult questions, especially since most of the=20
>> information is unknown, and we are to weigh estimates and risks=20
>> against each other.  But this is especially important when so many
>>  things are uncertain to keep at least the questions we are
>> answering clear.  Hence, I would consider "Are we asking all
>> Internet users to pay a tax by not improving privacy?" to be not a
>> clear question but a rhetorical one.
>=20
> I took 'em as questions and not as rhetorical questions:-)
>=20
>> I meant "tax" in a very specific way -- the real-world _financial_
>>  cost.  I specifically want to pose questions of trade-offs of=20
>> financial costs vs. benefits (very valuable benefits to be sure).
>=20
> Again, there's the same problem - are you trying to measure the
> financial benefits of privacy? Or are you trying to compare the
> financial costs of (e.g. PNE) against some other measure of the
> benefits of privacy? I'm still in a position where I don't know how
> to make those comparisons.
>=20
> So maybe yeah, you're right that we're better considering your
> specific questions purely as rhetorical and try find other questions
> that could be answered.
>=20
> Cheers, S.
>=20
>>=20
>> * Are we asking all Internet users to pay a tax to improve privacy?
>>  Does the amount of the tax justify the amount of privacy benefits
>> it buys?
>>=20
>> * Are we asking all Internet users to pay a tax to reduce PN=20
>> ossification?  Does the amount of the tax justify the added=20
>> flexibility protocol designers might need in the future?
>>=20
>>=20
>> - Igor
>>=20
>>=20
>> -----Original Message----- From: Stephen Farrell=20
>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, April 11, 2018=20
>> 11:37 AM To: Lubashev, Igor
>> ; Roberto Peon
>> ; Fossati, Thomas (Nokia - GB/Cambridge)=20
>> ; Kazuho Oku ;
>> Praveen Balasubramanian  Cc: Victor Vasiliev=20
>> ; IETF QUIC WG ; Ryan Hamilton=20
>>  Subject: Re: Simple transform for improving PN=20
>> ossification prevention
>>=20
>>=20
>> Hiya,
>>=20
>> On 11/04/18 16:21, Lubashev, Igor wrote:
>>> * Are we asking all Internet users to pay a tax to improve
>>> privacy? Does the amount of the tax justify the amount of privacy
>>> benefits it buys?
>> I think that (and your other questions) are good things to ponder,
>> but I don't believe the questions above are really answerable, at
>> least not unless we can also answer the opposite question ("Are we
>> asking all Internet users to pay a tax by not improving privacy?"),
>> and I'm pretty sure I at least don't know how to evaluate that
>> question. Maybe that's part of why this discussion is so tricky.
>>=20
>> Personally, as a future user of QUIC (but not an implementer), I'd
>>  really prefer that the WG prioritise privacy-friendly mechanisms
>> if at all possible, even if the direct benefits aren't completely
>> clear.
>>=20
>> Cheers, S.
>>=20

--------------366525139E08410BB5A8FA00
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------366525139E08410BB5A8FA00--

--8zBHNsH5Z6DxoNdlFcBwVJoQfXj92X37a--

--UeWFCWNvsVDQaAc1aiSheYXycqi8EHsIX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJazojCAAoJEFqy+vF7FyvqFbcQAIEz4gk0L1tKG5Q5zeAREPoj
AFOZnrwku/xoaZpsC/mL77pi8XCCV0wT1/+duDX8rbj1qLCvAgVz9Hei1/MxPzf1
uQWFEhSlZFwsa8FvotuJPC+N6ancbK53yEBSJm3fc0SEq//GsRqhxUyUyBmiNyOR
svWjBHGrJKBOsDyrfx77iDj21n0UMfFOQuD4hN8hsBszgj4rHwdXMCRQ6xJFMOp2
KeDEqsB3h3r1oL2dbhKBlWkhqPFMyD4Wnprr8Dgq4tKD8Za4gJr+QcYRceToqzYU
XVb8IolGofwD5BnU29Lmw2TBIZSV/w+eKcGx/Uq0zft6LPTAZyyXvohDfU0dJgzB
wJDt7NxkxoxYWqPqP8mjqrMQCv+c6MBScP9amtxnnjdZnZ364Z39i6UE7v+AucFh
zXQw0N2SIBiwpDlRrgAY2hsPLy02F26f8e0s7Ej8kIhR6kNgs/YGGsuWMDpLQJCJ
KCmcU6XP/OSfTMuzvTujsBkcWLsmnkWhn4bSL3fvXneRVh5Lwq0gpPGS11ldIUpk
kG36OF6FaFC78yaZSbIpscsSrTl8QOKnuHgI8pO5vTeS/sNzd8mtaBWmRgKjzPzY
uvG9BvJBuLDgrlZ+JSRPCLMIq+NuZbbbSuke5Tdd3v027oyOMdG4Fpvt0vhPzqw8
5zUYVdtBOW4fsya+0NHq
=Nhkn
-----END PGP SIGNATURE-----

--UeWFCWNvsVDQaAc1aiSheYXycqi8EHsIX--


From nobody Wed Apr 11 15:14:54 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1215F129C70 for ; Wed, 11 Apr 2018 15:14:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523484875; bh=MNDnbs6ulaQ3oX9RV20Blz/k7nTXsnabMoCEOb4r9SQ=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To:To:To:To; b=U18WXAd0Olmh5rvLtVIJKgfLq/C6jyfX65F3cwi9cmjqarAsVXn8WZAVLcs4dFcv0 j5Ofx7y6JrZK8H8L171dzVeoqnDUfubzky3zGYXJVw4l6QlOSEgVzd2vNG0aD9+Dx4 qnGuNI+dmiVmeSe2/SzZQjirI3Jxhk14aqmSbXug=
X-Mailbox-Line: From stephen.farrell@cs.tcd.ie  Wed Apr 11 15:14:34 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A6C12422F; Wed, 11 Apr 2018 15:14:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523484874; bh=MNDnbs6ulaQ3oX9RV20Blz/k7nTXsnabMoCEOb4r9SQ=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To:To:To:To; b=wD/qtK0mY8wBr4Z+1u8gnlKOq4wxA7BT9mDb1urX2tp3CCD+5rhgpCaK7fpyqt1dr XbvBMcfA/o2+HKjJsoiide+ryNCWvrab15iVwgrJ9XEREZQXO9xcyryFK1VUkOIPoN j+/BTAj04Xmm2E9xbOXEwp7dtXLV0WSy4mBHfSaw=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2410124D6C for ; Wed, 11 Apr 2018 15:14:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYFHemvxOKAj for ; Wed, 11 Apr 2018 15:14:31 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00D312422F for ; Wed, 11 Apr 2018 15:14:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19426BE50; Wed, 11 Apr 2018 23:14:29 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TNLoMVngc47; Wed, 11 Apr 2018 23:14:27 +0100 (IST)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0C301BE38; Wed, 11 Apr 2018 23:14:27 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1523484867; bh=MNDnbs6ulaQ3oX9RV20Blz/k7nTXsnabMoCEOb4r9SQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZL4Jwo4cPxvGi8p6AvGlkVwd3EEB2Y4nhsq0pCz6FoYbYG3v7KRrkmPsTsYAKW9Vb zpdZNjCj5RYC4zrpmcF1zBu3nUcFPwGjURkqIQ1RPdwY2+f2Z+hd2QG49YsjD9TcFD 2lGmLsnHWJ3aT35B8f36uFB8rqti5dmypQmj8ntc=
Subject: Re: Simple transform for improving PN ossification prevention
Cc: Victor Vasiliev , IETF QUIC WG , Ryan Hamilton 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie> <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com> <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie> <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: 
Date: Wed, 11 Apr 2018 23:14:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UeWFCWNvsVDQaAc1aiSheYXycqi8EHsIX"
To: "Lubashev, Igor" 
To: Roberto Peon 
To: "Fossati, Thomas \(Nokia - GB/Cambridge\)" 
To: Kazuho Oku 
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 22:14:35 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--UeWFCWNvsVDQaAc1aiSheYXycqi8EHsIX
Content-Type: multipart/mixed; boundary="8zBHNsH5Z6DxoNdlFcBwVJoQfXj92X37a";
 protected-headers="v1"
From: Stephen Farrell 
To: "Lubashev, Igor" ,
 Roberto Peon ,
 "Fossati, Thomas (Nokia - GB/Cambridge)" ,
 Kazuho Oku ,
 Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG ,
 Ryan Hamilton 
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
References: 
 
 
 
 
 
 <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
 
 <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
 <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
 <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
 <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>
 <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie>
 <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>

--8zBHNsH5Z6DxoNdlFcBwVJoQfXj92X37a
Content-Type: multipart/mixed;
 boundary="------------366525139E08410BB5A8FA00"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------366525139E08410BB5A8FA00
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 11/04/18 22:55, Lubashev, Igor wrote:
> Stephen, I think I was not clear.  My apologies.
>=20
> To compare the value of things, you certainly need to first convert
> the values to the same units.  Since on one hand we have a $ value
> (more CPUs, larger batteries, more base stations, costlier network
> troubleshooting, ...), it seems natural to convert everything to $.
> (Of course, we can only hope for very rough T-shirt size
> approximations here.)
>=20
>=20
>> financial benefits of privacy
>=20
> Yes.  Or, better, "financial benefits of the incremental change in
> privacy during deliberate connection migration". =20

So I've no idea how one might go about doing that without
stripping the term privacy of most of it's meaning. Nor do
I think it'd be particularly worthwhile trying tbh. OTOH,
you do give me the always-worthwhile opportunity to quote
Oscar Wilde: "Nowadays people know the price of everything
and the value of nothing." :-)

But if you do attempt to work that out, I'd be interested
in seeing what you come up with. Mind you that'd likely be
better off-list as I think we'd be wandering pretty far from
the WG's remit when we end up inevitably debating whether
Oscar was right or not.

S.

PS: Don't take this as me arguing for inefficiency wrt PNE,
I'm only arguing here about your suggested approach for
trying to analyse the trade-offs related to PNE.

> (Anything that is
> not worse than TLS1.3+TCP fits the Charter.)  We may as well decide
> that most people on the Internet are willing to pay (or would be
> willing to pay, if they knew better) a lot for every single bit of
> extra privacy from pervasive surveillance, so the costs are
> justified.  (Judging from people's current behavior patterns this
> does not seem to be true.)
>=20
> Ditto for the financial benefits of preventing ossification of PNs.
>=20
> - Igor
>=20
> -----Original Message----- From: Stephen Farrell
> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, April 11, 2018
> 4:12 PM To: Lubashev, Igor ;
> Lubashev, Igor ; Roberto Peon ;
> Fossati, Thomas (Nokia - GB/Cambridge) ;
> Kazuho Oku ; Praveen Balasubramanian
>  Cc: Victor Vasiliev ; IETF
> QUIC WG ; Ryan Hamilton  Subject: Re:
> Simple transform for improving PN ossification prevention
>=20
>=20
> Hiya,
>=20
> On 11/04/18 17:37, Lubashev, Igor wrote:
>> Yes, these are difficult questions, especially since most of the=20
>> information is unknown, and we are to weigh estimates and risks=20
>> against each other.  But this is especially important when so many
>>  things are uncertain to keep at least the questions we are
>> answering clear.  Hence, I would consider "Are we asking all
>> Internet users to pay a tax by not improving privacy?" to be not a
>> clear question but a rhetorical one.
>=20
> I took 'em as questions and not as rhetorical questions:-)
>=20
>> I meant "tax" in a very specific way -- the real-world _financial_
>>  cost.  I specifically want to pose questions of trade-offs of=20
>> financial costs vs. benefits (very valuable benefits to be sure).
>=20
> Again, there's the same problem - are you trying to measure the
> financial benefits of privacy? Or are you trying to compare the
> financial costs of (e.g. PNE) against some other measure of the
> benefits of privacy? I'm still in a position where I don't know how
> to make those comparisons.
>=20
> So maybe yeah, you're right that we're better considering your
> specific questions purely as rhetorical and try find other questions
> that could be answered.
>=20
> Cheers, S.
>=20
>>=20
>> * Are we asking all Internet users to pay a tax to improve privacy?
>>  Does the amount of the tax justify the amount of privacy benefits
>> it buys?
>>=20
>> * Are we asking all Internet users to pay a tax to reduce PN=20
>> ossification?  Does the amount of the tax justify the added=20
>> flexibility protocol designers might need in the future?
>>=20
>>=20
>> - Igor
>>=20
>>=20
>> -----Original Message----- From: Stephen Farrell=20
>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, April 11, 2018=20
>> 11:37 AM To: Lubashev, Igor
>> ; Roberto Peon
>> ; Fossati, Thomas (Nokia - GB/Cambridge)=20
>> ; Kazuho Oku ;
>> Praveen Balasubramanian  Cc: Victor Vasiliev=20
>> ; IETF QUIC WG ; Ryan Hamilton=20
>>  Subject: Re: Simple transform for improving PN=20
>> ossification prevention
>>=20
>>=20
>> Hiya,
>>=20
>> On 11/04/18 16:21, Lubashev, Igor wrote:
>>> * Are we asking all Internet users to pay a tax to improve
>>> privacy? Does the amount of the tax justify the amount of privacy
>>> benefits it buys?
>> I think that (and your other questions) are good things to ponder,
>> but I don't believe the questions above are really answerable, at
>> least not unless we can also answer the opposite question ("Are we
>> asking all Internet users to pay a tax by not improving privacy?"),
>> and I'm pretty sure I at least don't know how to evaluate that
>> question. Maybe that's part of why this discussion is so tricky.
>>=20
>> Personally, as a future user of QUIC (but not an implementer), I'd
>>  really prefer that the WG prioritise privacy-friendly mechanisms
>> if at all possible, even if the direct benefits aren't completely
>> clear.
>>=20
>> Cheers, S.
>>=20

--------------366525139E08410BB5A8FA00
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------366525139E08410BB5A8FA00--

--8zBHNsH5Z6DxoNdlFcBwVJoQfXj92X37a--

--UeWFCWNvsVDQaAc1aiSheYXycqi8EHsIX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJazojCAAoJEFqy+vF7FyvqFbcQAIEz4gk0L1tKG5Q5zeAREPoj
AFOZnrwku/xoaZpsC/mL77pi8XCCV0wT1/+duDX8rbj1qLCvAgVz9Hei1/MxPzf1
uQWFEhSlZFwsa8FvotuJPC+N6ancbK53yEBSJm3fc0SEq//GsRqhxUyUyBmiNyOR
svWjBHGrJKBOsDyrfx77iDj21n0UMfFOQuD4hN8hsBszgj4rHwdXMCRQ6xJFMOp2
KeDEqsB3h3r1oL2dbhKBlWkhqPFMyD4Wnprr8Dgq4tKD8Za4gJr+QcYRceToqzYU
XVb8IolGofwD5BnU29Lmw2TBIZSV/w+eKcGx/Uq0zft6LPTAZyyXvohDfU0dJgzB
wJDt7NxkxoxYWqPqP8mjqrMQCv+c6MBScP9amtxnnjdZnZ364Z39i6UE7v+AucFh
zXQw0N2SIBiwpDlRrgAY2hsPLy02F26f8e0s7Ej8kIhR6kNgs/YGGsuWMDpLQJCJ
KCmcU6XP/OSfTMuzvTujsBkcWLsmnkWhn4bSL3fvXneRVh5Lwq0gpPGS11ldIUpk
kG36OF6FaFC78yaZSbIpscsSrTl8QOKnuHgI8pO5vTeS/sNzd8mtaBWmRgKjzPzY
uvG9BvJBuLDgrlZ+JSRPCLMIq+NuZbbbSuke5Tdd3v027oyOMdG4Fpvt0vhPzqw8
5zUYVdtBOW4fsya+0NHq
=Nhkn
-----END PGP SIGNATURE-----

--UeWFCWNvsVDQaAc1aiSheYXycqi8EHsIX--


From nobody Wed Apr 11 15:21:50 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157D9126CBF for ; Wed, 11 Apr 2018 15:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYLPLV38zE1I for ; Wed, 11 Apr 2018 15:21:45 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F851200A0 for ; Wed, 11 Apr 2018 15:21:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E302FBE38; Wed, 11 Apr 2018 23:14:33 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W40Me0InhNbx; Wed, 11 Apr 2018 23:14:28 +0100 (IST)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 49F0DBE4D; Wed, 11 Apr 2018 23:14:27 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1523484868; bh=83kckRVj8mUy54qIVvhRUG6KMED+V4oszwlZBCzSay8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pRKj7ibJeKhi+MrgHQiqNWY1O+CvV+E1iXo6XXUqwLZM39VFxnPDY9mPXFhgIMeja i6C3ceGKVmuQcB3WDsnyUWwb9bk8xu6UIc00pRoMY0t9IRX2cBS2qkr1WER3DHRrj5 b0SR7bNCOmFFbLrFJFahlpccCCYV5KanG6J5yfzo=
Subject: Re: Simple transform for improving PN ossification prevention
To: "Lubashev, Igor" , Roberto Peon , "Fossati, Thomas (Nokia - GB/Cambridge)" , Kazuho Oku , Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG , Ryan Hamilton 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie> <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com> <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie> <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <2a8f3016-1906-fd75-df16-d48314c6fb6e@cs.tcd.ie>
Date: Wed, 11 Apr 2018 23:14:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2CkQCIOwjZKn4hI8p4AZqnpXLLnpp2Yyu"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 22:21:49 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2CkQCIOwjZKn4hI8p4AZqnpXLLnpp2Yyu
Content-Type: multipart/mixed; boundary="jSAFGhtmhOss4S7bXwoc0m99L8kzWYX53";
 protected-headers="v1"
From: Stephen Farrell 
To: "Lubashev, Igor" ,
 Roberto Peon ,
 "Fossati, Thomas (Nokia - GB/Cambridge)" ,
 Kazuho Oku ,
 Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG ,
 Ryan Hamilton 
Message-ID: <2a8f3016-1906-fd75-df16-d48314c6fb6e@cs.tcd.ie>
Subject: Re: Simple transform for improving PN ossification prevention
References: 
 
 
 
 
 
 <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
 
 <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
 <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
 <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
 <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>
 <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie>
 <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>

--jSAFGhtmhOss4S7bXwoc0m99L8kzWYX53
Content-Type: multipart/mixed;
 boundary="------------BE554EDF80D43377D0D8C28F"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------BE554EDF80D43377D0D8C28F
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 11/04/18 22:55, Lubashev, Igor wrote:
> Stephen, I think I was not clear.  My apologies.
>=20
> To compare the value of things, you certainly need to first convert
> the values to the same units.  Since on one hand we have a $ value
> (more CPUs, larger batteries, more base stations, costlier network
> troubleshooting, ...), it seems natural to convert everything to $.
> (Of course, we can only hope for very rough T-shirt size
> approximations here.)
>=20
>=20
>> financial benefits of privacy
>=20
> Yes.  Or, better, "financial benefits of the incremental change in
> privacy during deliberate connection migration". =20

So I've no idea how one might go about doing that without
stripping the term privacy of most of it's meaning. Nor do
I think it'd be particularly worthwhile trying tbh. OTOH,
you do give me the always-worthwhile opportunity to quote
Oscar Wilde: "Nowadays people know the price of everything
and the value of nothing." :-)

But if you do attempt to work that out, I'd be interested
in seeing what you come up with. Mind you that'd likely be
better off-list as I think we'd be wandering pretty far from
the WG's remit when we end up inevitably debating whether
Oscar was right or not.

S.

PS: Don't take this as me arguing for inefficiency wrt PNE,
I'm only arguing here about your suggested approach for
trying to analyse the trade-offs related to PNE.

> (Anything that is
> not worse than TLS1.3+TCP fits the Charter.)  We may as well decide
> that most people on the Internet are willing to pay (or would be
> willing to pay, if they knew better) a lot for every single bit of
> extra privacy from pervasive surveillance, so the costs are
> justified.  (Judging from people's current behavior patterns this
> does not seem to be true.)
>=20
> Ditto for the financial benefits of preventing ossification of PNs.
>=20
> - Igor
>=20
> -----Original Message----- From: Stephen Farrell
> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, April 11, 2018
> 4:12 PM To: Lubashev, Igor ;
> Lubashev, Igor ; Roberto Peon ;
> Fossati, Thomas (Nokia - GB/Cambridge) ;
> Kazuho Oku ; Praveen Balasubramanian
>  Cc: Victor Vasiliev ; IETF
> QUIC WG ; Ryan Hamilton  Subject: Re:
> Simple transform for improving PN ossification prevention
>=20
>=20
> Hiya,
>=20
> On 11/04/18 17:37, Lubashev, Igor wrote:
>> Yes, these are difficult questions, especially since most of the=20
>> information is unknown, and we are to weigh estimates and risks=20
>> against each other.  But this is especially important when so many
>>  things are uncertain to keep at least the questions we are
>> answering clear.  Hence, I would consider "Are we asking all
>> Internet users to pay a tax by not improving privacy?" to be not a
>> clear question but a rhetorical one.
>=20
> I took 'em as questions and not as rhetorical questions:-)
>=20
>> I meant "tax" in a very specific way -- the real-world _financial_
>>  cost.  I specifically want to pose questions of trade-offs of=20
>> financial costs vs. benefits (very valuable benefits to be sure).
>=20
> Again, there's the same problem - are you trying to measure the
> financial benefits of privacy? Or are you trying to compare the
> financial costs of (e.g. PNE) against some other measure of the
> benefits of privacy? I'm still in a position where I don't know how
> to make those comparisons.
>=20
> So maybe yeah, you're right that we're better considering your
> specific questions purely as rhetorical and try find other questions
> that could be answered.
>=20
> Cheers, S.
>=20
>>=20
>> * Are we asking all Internet users to pay a tax to improve privacy?
>>  Does the amount of the tax justify the amount of privacy benefits
>> it buys?
>>=20
>> * Are we asking all Internet users to pay a tax to reduce PN=20
>> ossification?  Does the amount of the tax justify the added=20
>> flexibility protocol designers might need in the future?
>>=20
>>=20
>> - Igor
>>=20
>>=20
>> -----Original Message----- From: Stephen Farrell=20
>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, April 11, 2018=20
>> 11:37 AM To: Lubashev, Igor
>> ; Roberto Peon
>> ; Fossati, Thomas (Nokia - GB/Cambridge)=20
>> ; Kazuho Oku ;
>> Praveen Balasubramanian  Cc: Victor Vasiliev=20
>> ; IETF QUIC WG ; Ryan Hamilton=20
>>  Subject: Re: Simple transform for improving PN=20
>> ossification prevention
>>=20
>>=20
>> Hiya,
>>=20
>> On 11/04/18 16:21, Lubashev, Igor wrote:
>>> * Are we asking all Internet users to pay a tax to improve
>>> privacy? Does the amount of the tax justify the amount of privacy
>>> benefits it buys?
>> I think that (and your other questions) are good things to ponder,
>> but I don't believe the questions above are really answerable, at
>> least not unless we can also answer the opposite question ("Are we
>> asking all Internet users to pay a tax by not improving privacy?"),
>> and I'm pretty sure I at least don't know how to evaluate that
>> question. Maybe that's part of why this discussion is so tricky.
>>=20
>> Personally, as a future user of QUIC (but not an implementer), I'd
>>  really prefer that the WG prioritise privacy-friendly mechanisms
>> if at all possible, even if the direct benefits aren't completely
>> clear.
>>=20
>> Cheers, S.
>>=20

--------------BE554EDF80D43377D0D8C28F
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------BE554EDF80D43377D0D8C28F
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------BE554EDF80D43377D0D8C28F--

--jSAFGhtmhOss4S7bXwoc0m99L8kzWYX53--

--2CkQCIOwjZKn4hI8p4AZqnpXLLnpp2Yyu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJazojCAAoJEFqy+vF7Fyvq8L8P/i7gnOXLPQJ+1luKG0M26wUc
LEyQ5yQhdK8WTBfNBYuoh0PoftJA15nkoRbvWhCkAs0QeHrcAxKJyNW9FwabWxvJ
xw3BhL6JHZ8zZ9nA+rKW/driaIv8okV0Jg6GSPjonE3sq+mUWEipuyEsezQutSLX
qROqdv8kcWPIsC2YrglsqM+IXWdI2goa5jSPC35jWazpSGo6oGx+Vth9f5fQkAy+
XPlZ6svJdmc6aWQg8yTbqf/5pMeRADa2yMcU2rb4LO2VyZzfbuGTX2ZIPqG9ZP0z
h83LPbZ/WwVeX6DQDZ5x+ERAoIruu+kTuOHWyv8nyYIRSKVWwmfLzSDrHl//TSHZ
EhsqQx7eTmrSLX/nBSAk0P1Woa6bLS9lLmUx2Zaml6Gxw+lUS+gXZ3TOtraAqm7W
s+i4dpHLpNB9bx2FlVR3/5to7qu41Ho8sp7fV3ZH7ml2U3NCE17SmbBeka2tBmin
26JUUjkgQK4yazb5qxl3DZclPidl4pYgLYlFM7Rz6oHxYcc/Rw/YCRwrpFg4Ww6L
6gEBI27xb1k2tlVhbbjmlXWt6CA6JVyQCNqcDk1OjCdFTJu6rsNBzgzMlQEpgAY/
TdEthVjqSThpKzdTDWuHhEMadYjCSvEYySzeZizboWqjhrPRkj2iwurQXk7LxLPz
xpXO6dUUY05+h2MhPFG/
=H9+2
-----END PGP SIGNATURE-----

--2CkQCIOwjZKn4hI8p4AZqnpXLLnpp2Yyu--


From nobody Wed Apr 11 15:21:55 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40291129C70 for ; Wed, 11 Apr 2018 15:21:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523485309; bh=83kckRVj8mUy54qIVvhRUG6KMED+V4oszwlZBCzSay8=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To:To:To:To; b=wqJlTAdMfDDX5d8tfoYhMc3AJvuj3uGj3C4+ieB0zkoxc2OfJLOsmFWc+t9AywvD/ ESLmiiB4+RMjW/skX4428zR9WDaQF1oUPWdPL3vPIwXKxJq6qYd6AKdzWEze/MChEt IK2KZKDWPVxRuaM/b2lOO9FxV8l4wor8lqNjNDJ8=
X-Mailbox-Line: From stephen.farrell@cs.tcd.ie  Wed Apr 11 15:21:49 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFCC124D6C; Wed, 11 Apr 2018 15:21:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523485308; bh=83kckRVj8mUy54qIVvhRUG6KMED+V4oszwlZBCzSay8=; h=Subject:Cc:References:From:Date:In-Reply-To:To:To:To:To:To; b=Gv8eVEyGCqKz3mTpi+zEVO3kCcJAycH+eakP8PDw1ZEt4GaPwooYzVLc59c1EbiB3 7loX3pVj2Zf3GSLhD73jER6zqQnJUiedU+LC6lYmCio0XwzLinXlzI5qWDIOX7n5mn 2dQLGEyS2VhB9LU0VYSIofY8gKG8gAKrLHra4P4E=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE8B126CBF for ; Wed, 11 Apr 2018 15:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haeYhZRADAgO for ; Wed, 11 Apr 2018 15:21:45 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A001124D6C for ; Wed, 11 Apr 2018 15:21:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E302FBE38; Wed, 11 Apr 2018 23:14:33 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W40Me0InhNbx; Wed, 11 Apr 2018 23:14:28 +0100 (IST)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 49F0DBE4D; Wed, 11 Apr 2018 23:14:27 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1523484868; bh=83kckRVj8mUy54qIVvhRUG6KMED+V4oszwlZBCzSay8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pRKj7ibJeKhi+MrgHQiqNWY1O+CvV+E1iXo6XXUqwLZM39VFxnPDY9mPXFhgIMeja i6C3ceGKVmuQcB3WDsnyUWwb9bk8xu6UIc00pRoMY0t9IRX2cBS2qkr1WER3DHRrj5 b0SR7bNCOmFFbLrFJFahlpccCCYV5KanG6J5yfzo=
Subject: Re: Simple transform for improving PN ossification prevention
Cc: Victor Vasiliev , IETF QUIC WG , Ryan Hamilton 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie> <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com> <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie> <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <2a8f3016-1906-fd75-df16-d48314c6fb6e@cs.tcd.ie>
Date: Wed, 11 Apr 2018 23:14:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2CkQCIOwjZKn4hI8p4AZqnpXLLnpp2Yyu"
To: "Lubashev, Igor" 
To: Roberto Peon 
To: "Fossati, Thomas \(Nokia - GB/Cambridge\)" 
To: Kazuho Oku 
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 22:21:49 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2CkQCIOwjZKn4hI8p4AZqnpXLLnpp2Yyu
Content-Type: multipart/mixed; boundary="jSAFGhtmhOss4S7bXwoc0m99L8kzWYX53";
 protected-headers="v1"
From: Stephen Farrell 
To: "Lubashev, Igor" ,
 Roberto Peon ,
 "Fossati, Thomas (Nokia - GB/Cambridge)" ,
 Kazuho Oku ,
 Praveen Balasubramanian 
Cc: Victor Vasiliev , IETF QUIC WG ,
 Ryan Hamilton 
Message-ID: <2a8f3016-1906-fd75-df16-d48314c6fb6e@cs.tcd.ie>
Subject: Re: Simple transform for improving PN ossification prevention
References: 
 
 
 
 
 
 <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>
 
 <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com>
 <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com>
 <840dda9d-4c77-02a3-6d96-9cebbbc13ac6@cs.tcd.ie>
 <265c13cfcd044871b3ada99f6fbb4416@usma1ex-dag1mb5.msg.corp.akamai.com>
 <3e93497e-dfb8-90cc-23e9-a2986e970edf@cs.tcd.ie>
 <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <60d723bac2004888bbdbf78acf000e0c@usma1ex-dag1mb5.msg.corp.akamai.com>

--jSAFGhtmhOss4S7bXwoc0m99L8kzWYX53
Content-Type: multipart/mixed;
 boundary="------------BE554EDF80D43377D0D8C28F"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------BE554EDF80D43377D0D8C28F
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 11/04/18 22:55, Lubashev, Igor wrote:
> Stephen, I think I was not clear.  My apologies.
>=20
> To compare the value of things, you certainly need to first convert
> the values to the same units.  Since on one hand we have a $ value
> (more CPUs, larger batteries, more base stations, costlier network
> troubleshooting, ...), it seems natural to convert everything to $.
> (Of course, we can only hope for very rough T-shirt size
> approximations here.)
>=20
>=20
>> financial benefits of privacy
>=20
> Yes.  Or, better, "financial benefits of the incremental change in
> privacy during deliberate connection migration". =20

So I've no idea how one might go about doing that without
stripping the term privacy of most of it's meaning. Nor do
I think it'd be particularly worthwhile trying tbh. OTOH,
you do give me the always-worthwhile opportunity to quote
Oscar Wilde: "Nowadays people know the price of everything
and the value of nothing." :-)

But if you do attempt to work that out, I'd be interested
in seeing what you come up with. Mind you that'd likely be
better off-list as I think we'd be wandering pretty far from
the WG's remit when we end up inevitably debating whether
Oscar was right or not.

S.

PS: Don't take this as me arguing for inefficiency wrt PNE,
I'm only arguing here about your suggested approach for
trying to analyse the trade-offs related to PNE.

> (Anything that is
> not worse than TLS1.3+TCP fits the Charter.)  We may as well decide
> that most people on the Internet are willing to pay (or would be
> willing to pay, if they knew better) a lot for every single bit of
> extra privacy from pervasive surveillance, so the costs are
> justified.  (Judging from people's current behavior patterns this
> does not seem to be true.)
>=20
> Ditto for the financial benefits of preventing ossification of PNs.
>=20
> - Igor
>=20
> -----Original Message----- From: Stephen Farrell
> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, April 11, 2018
> 4:12 PM To: Lubashev, Igor ;
> Lubashev, Igor ; Roberto Peon ;
> Fossati, Thomas (Nokia - GB/Cambridge) ;
> Kazuho Oku ; Praveen Balasubramanian
>  Cc: Victor Vasiliev ; IETF
> QUIC WG ; Ryan Hamilton  Subject: Re:
> Simple transform for improving PN ossification prevention
>=20
>=20
> Hiya,
>=20
> On 11/04/18 17:37, Lubashev, Igor wrote:
>> Yes, these are difficult questions, especially since most of the=20
>> information is unknown, and we are to weigh estimates and risks=20
>> against each other.  But this is especially important when so many
>>  things are uncertain to keep at least the questions we are
>> answering clear.  Hence, I would consider "Are we asking all
>> Internet users to pay a tax by not improving privacy?" to be not a
>> clear question but a rhetorical one.
>=20
> I took 'em as questions and not as rhetorical questions:-)
>=20
>> I meant "tax" in a very specific way -- the real-world _financial_
>>  cost.  I specifically want to pose questions of trade-offs of=20
>> financial costs vs. benefits (very valuable benefits to be sure).
>=20
> Again, there's the same problem - are you trying to measure the
> financial benefits of privacy? Or are you trying to compare the
> financial costs of (e.g. PNE) against some other measure of the
> benefits of privacy? I'm still in a position where I don't know how
> to make those comparisons.
>=20
> So maybe yeah, you're right that we're better considering your
> specific questions purely as rhetorical and try find other questions
> that could be answered.
>=20
> Cheers, S.
>=20
>>=20
>> * Are we asking all Internet users to pay a tax to improve privacy?
>>  Does the amount of the tax justify the amount of privacy benefits
>> it buys?
>>=20
>> * Are we asking all Internet users to pay a tax to reduce PN=20
>> ossification?  Does the amount of the tax justify the added=20
>> flexibility protocol designers might need in the future?
>>=20
>>=20
>> - Igor
>>=20
>>=20
>> -----Original Message----- From: Stephen Farrell=20
>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, April 11, 2018=20
>> 11:37 AM To: Lubashev, Igor
>> ; Roberto Peon
>> ; Fossati, Thomas (Nokia - GB/Cambridge)=20
>> ; Kazuho Oku ;
>> Praveen Balasubramanian  Cc: Victor Vasiliev=20
>> ; IETF QUIC WG ; Ryan Hamilton=20
>>  Subject: Re: Simple transform for improving PN=20
>> ossification prevention
>>=20
>>=20
>> Hiya,
>>=20
>> On 11/04/18 16:21, Lubashev, Igor wrote:
>>> * Are we asking all Internet users to pay a tax to improve
>>> privacy? Does the amount of the tax justify the amount of privacy
>>> benefits it buys?
>> I think that (and your other questions) are good things to ponder,
>> but I don't believe the questions above are really answerable, at
>> least not unless we can also answer the opposite question ("Are we
>> asking all Internet users to pay a tax by not improving privacy?"),
>> and I'm pretty sure I at least don't know how to evaluate that
>> question. Maybe that's part of why this discussion is so tricky.
>>=20
>> Personally, as a future user of QUIC (but not an implementer), I'd
>>  really prefer that the WG prioritise privacy-friendly mechanisms
>> if at all possible, even if the direct benefits aren't completely
>> clear.
>>=20
>> Cheers, S.
>>=20

--------------BE554EDF80D43377D0D8C28F
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------BE554EDF80D43377D0D8C28F
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy
ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC
GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6
8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp
0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr
uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t
AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS
COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF
/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh
LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce
ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM
XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X
QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI
AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r
KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ
5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u
14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC
XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB
5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA
JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6
UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM
1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/
lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO
Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9
lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/
VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu
Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk
hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb
KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl
biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA
JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx
excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn
crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg
rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c
F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP
y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5
b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7
b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo
rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR
dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl
Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA
BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq
Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO
dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD
4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz
nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I
WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H
Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU
NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8
tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d
G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym
9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp
vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP
ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny
qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX
XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv
T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP
BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc
LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx
iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm
h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz
mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo
p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6
6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk
r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n
/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj
mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi
nUk+H3pkqOKoHAy/8fST
=3DTOQn
-----END PGP PUBLIC KEY BLOCK-----

--------------BE554EDF80D43377D0D8C28F--

--jSAFGhtmhOss4S7bXwoc0m99L8kzWYX53--

--2CkQCIOwjZKn4hI8p4AZqnpXLLnpp2Yyu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJazojCAAoJEFqy+vF7Fyvq8L8P/i7gnOXLPQJ+1luKG0M26wUc
LEyQ5yQhdK8WTBfNBYuoh0PoftJA15nkoRbvWhCkAs0QeHrcAxKJyNW9FwabWxvJ
xw3BhL6JHZ8zZ9nA+rKW/driaIv8okV0Jg6GSPjonE3sq+mUWEipuyEsezQutSLX
qROqdv8kcWPIsC2YrglsqM+IXWdI2goa5jSPC35jWazpSGo6oGx+Vth9f5fQkAy+
XPlZ6svJdmc6aWQg8yTbqf/5pMeRADa2yMcU2rb4LO2VyZzfbuGTX2ZIPqG9ZP0z
h83LPbZ/WwVeX6DQDZ5x+ERAoIruu+kTuOHWyv8nyYIRSKVWwmfLzSDrHl//TSHZ
EhsqQx7eTmrSLX/nBSAk0P1Woa6bLS9lLmUx2Zaml6Gxw+lUS+gXZ3TOtraAqm7W
s+i4dpHLpNB9bx2FlVR3/5to7qu41Ho8sp7fV3ZH7ml2U3NCE17SmbBeka2tBmin
26JUUjkgQK4yazb5qxl3DZclPidl4pYgLYlFM7Rz6oHxYcc/Rw/YCRwrpFg4Ww6L
6gEBI27xb1k2tlVhbbjmlXWt6CA6JVyQCNqcDk1OjCdFTJu6rsNBzgzMlQEpgAY/
TdEthVjqSThpKzdTDWuHhEMadYjCSvEYySzeZizboWqjhrPRkj2iwurQXk7LxLPz
xpXO6dUUY05+h2MhPFG/
=H9+2
-----END PGP SIGNATURE-----

--2CkQCIOwjZKn4hI8p4AZqnpXLLnpp2Yyu--


From nobody Wed Apr 11 16:03:43 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC5B1277BB for ; Wed, 11 Apr 2018 16:03:42 -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=DxnDH5YX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HQrw4EAb
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsO6GMt3C5JE for ; Wed, 11 Apr 2018 16:03:36 -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 0012312D7ED for ; Wed, 11 Apr 2018 16:03:35 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 0DD3E207F3; Wed, 11 Apr 2018 19:03:32 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 11 Apr 2018 19:03: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; s=fm2; bh=68vqb2690rWRbTHGcMj8F7Zh3WdtT GlSLJajP08HFyA=; b=DxnDH5YXTqwbtsVT+eFjhykBVJdlKHQy1yWqTrcIuxXOq rbrk+rg2IiAdvi0hGNki7CJUqvNpPqEbXv6iLxJ3mJqTR68JnuXU9gAN4K8VhFBU F0jWwSSB2VLC2kh6mjpw4ZyB5j4ClFblfHZMy9anS6jNDNJCZY2bnMmldezzIjqD z1pyAfkPXyovjtgLwZ/KnaEavMe2SSpBrhaQ9b3V7FTlGJYb8qB4zSPyzZ/t4Bw5 Cqj+oRRfo+OWb64DLtXFbL7Et4UFKyjaYR+glFqNmW0Cgz08bNIcqrO3zlbzx7oU E0U6/87YWZc+QNx2hV5RJTCDXlJWpQIKkAmk0/NfQ==
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; s=fm2; bh=68vqb2 690rWRbTHGcMj8F7Zh3WdtTGlSLJajP08HFyA=; b=HQrw4EAbtXhxTBxasXHMZd zNmQWOuZLzs2QffUNuv39FRbqgQwZ6T1SAObf9YMrtMuogRTrxE2vX2Rl4zyLFkM V1Sr10k7Qqt6B7qTjfpiak5jrQB53j4Slm2qe/25QvIe9PkKLQbFowQOtuoufW+6 tj9G3qlhlJ3S7OT8JDS92k5YwRE+KczHmpRKpjFznlq8QXAhCNPkhqe+8RdwiKaT vtAhRD3wyDluRbucRIuHzrtSyW18ycHC7fD2B2JI12dofTmx47k7NkXu3YZRIAQt f3K04TJPpmXCUUoezy+2cTVFqpSEGKORXQqB/XW4Bm3JZMklJ4bpLSxJ2XxoKLeQ ==
X-ME-Sender: 
Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 6D4FF1025C; Wed, 11 Apr 2018 19:03:30 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: [quicwg/base-drafts] add draft-ietf-quic-spin-exp (#1286)
From: Mark Nottingham 
In-Reply-To: 
Date: Thu, 12 Apr 2018 09:03:27 +1000
Cc: IETF QUIC WG , "Brian Trammell (IETF)" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <29D7740D-61A7-444E-B027-5E5781DC376A@mnot.net>
References:  
To: Mike Bishop 
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 23:03:42 -0000

Yes - see thread "Spin Bit -- A Path Forward".

Cheers,


> On 12 Apr 2018, at 3:45 am, Mike Bishop  wrote:
>=20
> Have we actually adopted that document?
> =20
> From: Brian Trammell [mailto:notifications@github.com]=20
> Sent: Wednesday, April 11, 2018 12:28 AM
> To: quicwg/base-drafts 
> Cc: Subscribed 
> Subject: [quicwg/base-drafts] add draft-ietf-quic-spin-exp (#1286)
> =20
> This adds draft-ietf-quic-spin-exp-00, describing the spin bit, to the =
base-drafts repository.
>=20
> You can view, comment on, or merge this pull request online at:
>=20
>   https://github.com/quicwg/base-drafts/pull/1286
>=20
> Commit Summary
>=20
> 	=E2=80=A2 add draft-ietf-quic-spin-exp
> File Changes
>=20
> 	=E2=80=A2 A draft-ietf-quic-spin-exp.md (247)=20
> Patch Links:
>=20
> 	=E2=80=A2 https://github.com/quicwg/base-drafts/pull/1286.patch
> 	=E2=80=A2 https://github.com/quicwg/base-drafts/pull/1286.diff
> =E2=80=94
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the =
thread.
>=20

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


From nobody Wed Apr 11 16:07:13 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACFD12D7ED for ; Wed, 11 Apr 2018 16:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lViVqx246R1k for ; Wed, 11 Apr 2018 16:07:09 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0133.outbound.protection.outlook.com [104.47.40.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6951277BB for ; Wed, 11 Apr 2018 16:07:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZgcBSDZUthjDvUsB1CVcDEfeqoOsHnWrmCmcd+cWRPA=; b=h7mDd7MQAGq9nm/3BudLLQmessTt1y8/RbXcdYZAwk6jf6xfo03Oaqt8tAcuOBgpFOklHFQo4EWSsIKtAW0gpkXI35lyxudOrlk5bEk4dcPMxnjfGwJX9I9G/eHW7WPGi5GYrXHKCqpI6pVa2zL5zXR52JbJDBXqyItPG0LNStE=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1391.namprd08.prod.outlook.com (10.162.1.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Wed, 11 Apr 2018 23:07:05 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0653.015; Wed, 11 Apr 2018 23:07:05 +0000
From: Mike Bishop 
To: Mark Nottingham 
CC: IETF QUIC WG , "Brian Trammell (IETF)" 
Subject: RE: [quicwg/base-drafts] add draft-ietf-quic-spin-exp (#1286)
Thread-Topic: [quicwg/base-drafts] add draft-ietf-quic-spin-exp (#1286)
Thread-Index: AQHT0Wa+Mv7Xfjj010mo5ObJoHSyt6P71paQgABZNoCAAACEIA==
Date: Wed, 11 Apr 2018 23:07:05 +0000
Message-ID: 
References:   <29D7740D-61A7-444E-B027-5E5781DC376A@mnot.net>
In-Reply-To: <29D7740D-61A7-444E-B027-5E5781DC376A@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; 
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1391; 7:SOJm6A/LI6NJrDYBVWQTSadwXmdouoovvd85JTTjtHW7s3kvhBru48G4ewz7KeX/QuJsBdXcenNfO08p106+jduguyZK4UcdvU275u6TTSd34OHR9afgV5VT7QyExCtZkSipMGUub30WW/45UOTpkKUwxR4yc9M7lspdiEKLrnIScFgZmxamUBNoUMv/r3bVybsdhoSdqbAxcVKrIB6bij5FVmyr3rN0KegK6phVJ22W/Woi5MBoDqgOj3PIH1VW
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(3008032)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1391; 
x-ms-traffictypediagnostic: SN1PR08MB1391:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820)(209352067349851)(15185016700835); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(3002001)(10201501046)(6041310)(20161123558120)(2016111802025)(20161123564045)(20161123562045)(20161123560045)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1391; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1391; 
x-forefront-prvs: 0639027A9E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(376002)(39830400003)(366004)(396003)(189003)(199004)(13464003)(53546011)(6116002)(6436002)(7736002)(8936002)(305945005)(74316002)(66066001)(33656002)(54906003)(316002)(8676002)(81156014)(68736007)(81166006)(3846002)(55016002)(229853002)(966005)(6916009)(9686003)(5250100002)(53936002)(2906002)(105586002)(6246003)(14454004)(6306002)(11346002)(2900100001)(3660700001)(26005)(59450400001)(3280700002)(25786009)(74482002)(186003)(476003)(86362001)(478600001)(7696005)(4326008)(106356001)(446003)(486006)(99286004)(6506007)(76176011)(5660300001)(97736004)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1391; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Oz8xbKCKtpbrN79Xrxqy30f5sFK3K86voIJZFHnxfVJv0VP/ZiVu81bp2Ia18045EHW/aLXtaTfjjUk1Vz5Wp8Wi7cWo2hwteqI/OgBpB/dP8Q8XETHPYeGkuyOQcxMUCPueXiX+8H0c0lcCdFvQS+3w+zI/WR4tkxx7DmwIAfJR80DJ3/+b715Coz6LLD79OawsjX9MhACWRFZsXq+wxiC6mMLwrUhyvzTgiSfAVnOiVfd/mMl6CPb2QOioBzS5nXJn835czQ1xcx3fAxhWA5CB7/ealWHQJTVa8xyAd7sMwG17qSVPkmY2k8XsT5RjAy51NxEALSgmeIbTCPTv/27jntNfhWWDoDhxyLAwQwLxehzP3CdlmtrP6TsAd3jFaf3/j2FYxcmnpBvKBB437YHkSXcuaCu+prvjeWpxz+E=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 3d0761f3-faa7-499f-f9c0-08d5a000f161
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 3d0761f3-faa7-499f-f9c0-08d5a000f161
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 23:07:05.1561 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1391
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 23:07:11 -0000

Tm8gZGlzYWdyZWVtZW50IHRoYXQgd2UgYWdyZWVkIHRoZXJlIHdvdWxkIGJlIGEgZG9jdW1lbnQg
aW4gdGhhdCB0aHJlYWQ7IEkganVzdCB3YXNuJ3QgYXdhcmUgdGhhdCB0aGVyZSB3YXMgYSBjYWxs
IGZvciBhZG9wdGlvbiBvZiBhIHBhcnRpY3VsYXIgZG9jdW1lbnQgZW1iZWRkZWQgaW4gdGhhdCBk
aXNjdXNzaW9uLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFyayBOb3R0
aW5naGFtIFttYWlsdG86bW5vdEBtbm90Lm5ldF0gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDEx
LCAyMDE4IDQ6MDMgUE0NClRvOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU+DQpD
YzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxp
ZXRmQHRyYW1tZWxsLmNoPg0KU3ViamVjdDogUmU6IFtxdWljd2cvYmFzZS1kcmFmdHNdIGFkZCBk
cmFmdC1pZXRmLXF1aWMtc3Bpbi1leHAgKCMxMjg2KQ0KDQpZZXMgLSBzZWUgdGhyZWFkICJTcGlu
IEJpdCAtLSBBIFBhdGggRm9yd2FyZCIuDQoNCkNoZWVycywNCg0KDQo+IE9uIDEyIEFwciAyMDE4
LCBhdCAzOjQ1IGFtLCBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU+IHdyb3RlOg0K
PiANCj4gSGF2ZSB3ZSBhY3R1YWxseSBhZG9wdGVkIHRoYXQgZG9jdW1lbnQ/DQo+ICANCj4gRnJv
bTogQnJpYW4gVHJhbW1lbGwgW21haWx0bzpub3RpZmljYXRpb25zQGdpdGh1Yi5jb21dDQo+IFNl
bnQ6IFdlZG5lc2RheSwgQXByaWwgMTEsIDIwMTggMTI6MjggQU0NCj4gVG86IHF1aWN3Zy9iYXNl
LWRyYWZ0cyA8YmFzZS1kcmFmdHNAbm9yZXBseS5naXRodWIuY29tPg0KPiBDYzogU3Vic2NyaWJl
ZCA8c3Vic2NyaWJlZEBub3JlcGx5LmdpdGh1Yi5jb20+DQo+IFN1YmplY3Q6IFtxdWljd2cvYmFz
ZS1kcmFmdHNdIGFkZCBkcmFmdC1pZXRmLXF1aWMtc3Bpbi1leHAgKCMxMjg2KQ0KPiAgDQo+IFRo
aXMgYWRkcyBkcmFmdC1pZXRmLXF1aWMtc3Bpbi1leHAtMDAsIGRlc2NyaWJpbmcgdGhlIHNwaW4g
Yml0LCB0byB0aGUgYmFzZS1kcmFmdHMgcmVwb3NpdG9yeS4NCj4gDQo+IFlvdSBjYW4gdmlldywg
Y29tbWVudCBvbiwgb3IgbWVyZ2UgdGhpcyBwdWxsIHJlcXVlc3Qgb25saW5lIGF0Og0KPiANCj4g
ICBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMTI4Ng0KPiANCj4g
Q29tbWl0IFN1bW1hcnkNCj4gDQo+IAnigKIgYWRkIGRyYWZ0LWlldGYtcXVpYy1zcGluLWV4cA0K
PiBGaWxlIENoYW5nZXMNCj4gDQo+IAnigKIgQSBkcmFmdC1pZXRmLXF1aWMtc3Bpbi1leHAubWQg
KDI0NykgUGF0Y2ggTGlua3M6DQo+IA0KPiAJ4oCiIGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cv
YmFzZS1kcmFmdHMvcHVsbC8xMjg2LnBhdGNoDQo+IAnigKIgaHR0cHM6Ly9naXRodWIuY29tL3F1
aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzEyODYuZGlmZg0KPiDigJQNCj4gWW91IGFyZSByZWNlaXZp
bmcgdGhpcyBiZWNhdXNlIHlvdSBhcmUgc3Vic2NyaWJlZCB0byB0aGlzIHRocmVhZC4NCj4gUmVw
bHkgdG8gdGhpcyBlbWFpbCBkaXJlY3RseSwgdmlldyBpdCBvbiBHaXRIdWIsIG9yIG11dGUgdGhl
IA0KPiB0aHJlYWQuPGltYWdlMDAyLmpwZz4NCj4gDQoNCi0tDQpNYXJrIE5vdHRpbmdoYW0gICBo
dHRwczovL3d3dy5tbm90Lm5ldC8NCg0K


From nobody Wed Apr 11 16:10:55 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C141277BB for ; Wed, 11 Apr 2018 16:10:53 -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=CKME+ryR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jzhlgjky
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOsBh8mjF8mw for ; Wed, 11 Apr 2018 16:10:51 -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 6043D126D3F for ; Wed, 11 Apr 2018 16:10:51 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C751920EC5; Wed, 11 Apr 2018 19:10:50 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 11 Apr 2018 19:10:50 -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; s=fm2; bh=kPtYN4HIHKsl2uht0g6k6stITmD7+ sAP9zhvIgjQWpA=; b=CKME+ryRtoA847FcuY9FSV3rXaHoi/69AMyaxwSfkBE6r n1zn3vDOf6posOhkp1pAwCwzTBi+UYl9WBwE9f9MS0VK1hlFmIlh6GLWMgk9k16H AR3ZvT2RDrU6xKbGXyg73Gg5ExxurPyUcXIyfBfkjRoucF2OGP+ohmb6YspgDP9+ SzpQHcteTQNEjVqcl5aJzzEnnZtQZpSrHap8UyyVzaDx0dIFGnhuIjB1WI1NrlCq EOyp/iY2VH1VLoAJWwteM/qagE6ofEZKD3HpKIhZmuMBB4hQE7qyiishqWbIzFOS o/8x03Cpn79OzC/p70zYq7mE2gL6ZSavn0Pu9TNww==
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; s=fm2; bh=kPtYN4 HIHKsl2uht0g6k6stITmD7+sAP9zhvIgjQWpA=; b=jzhlgjkyteAv2CNUQRcTr7 gRjYlfJBxyNTfY3hqxpQXNZuCV9GYg5jLQ3+T2MDH72f0ho5tpq6CpSnDSvewB9T 2ceGdSFI77H2m8el9IHLShd07ouA1CxlOQczcFVe2mmCXpry1k49qvioZo6yai2N shXsNkrLXrg6KvB9ofyO+ySqlirN+t1mfVTdXO0K937UBPg2D0sedFTu9e+OvnSO feXt4EnWPdzYqDY25WDOAytTEg8o9hewcMKXgXmEIWbR2O0RwomZ0ZJH2U0lrs2Z GBum3zykDDx8MnZBTKNI2H8Snf9vXSvLbGvJ5NNODp75eiWvOqg6VXaSHDZ3dVrw ==
X-ME-Sender: 
Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A3BEE446D; Wed, 11 Apr 2018 19:10:48 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: [quicwg/base-drafts] add draft-ietf-quic-spin-exp (#1286)
From: Mark Nottingham 
In-Reply-To: 
Date: Thu, 12 Apr 2018 09:10:45 +1000
Cc: IETF QUIC WG , "Brian Trammell (IETF)" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <28989044-83EB-44D4-B56B-691E169C4A3B@mnot.net>
References:   <29D7740D-61A7-444E-B027-5E5781DC376A@mnot.net> 
To: Mike Bishop 
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Apr 2018 23:10:53 -0000

Apologies if that surprised you, Mike.

This one is a bit "special" -- we've agreed to start a WG document, but =
have NOT agreed to a milestone for it yet; i.e., the document isn't =
*currently* planned to be sent to the IESG. As such it's not a formal =
deliverable.

If that causes heartburn, we can do a formal CfA before approving the =
-00, but I didn't think that was necessary in this case. Please speak up =
ASAP if you think otherwise.

Cheers,


> On 12 Apr 2018, at 9:07 am, Mike Bishop  wrote:
>=20
> No disagreement that we agreed there would be a document in that =
thread; I just wasn't aware that there was a call for adoption of a =
particular document embedded in that discussion.
>=20
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]=20
> Sent: Wednesday, April 11, 2018 4:03 PM
> To: Mike Bishop 
> Cc: IETF QUIC WG ; Brian Trammell (IETF) =

> Subject: Re: [quicwg/base-drafts] add draft-ietf-quic-spin-exp (#1286)
>=20
> Yes - see thread "Spin Bit -- A Path Forward".
>=20
> Cheers,
>=20
>=20
>> On 12 Apr 2018, at 3:45 am, Mike Bishop  wrote:
>>=20
>> Have we actually adopted that document?
>>=20
>> From: Brian Trammell [mailto:notifications@github.com]
>> Sent: Wednesday, April 11, 2018 12:28 AM
>> To: quicwg/base-drafts 
>> Cc: Subscribed 
>> Subject: [quicwg/base-drafts] add draft-ietf-quic-spin-exp (#1286)
>>=20
>> This adds draft-ietf-quic-spin-exp-00, describing the spin bit, to =
the base-drafts repository.
>>=20
>> You can view, comment on, or merge this pull request online at:
>>=20
>>  https://github.com/quicwg/base-drafts/pull/1286
>>=20
>> Commit Summary
>>=20
>> 	=E2=80=A2 add draft-ietf-quic-spin-exp
>> File Changes
>>=20
>> 	=E2=80=A2 A draft-ietf-quic-spin-exp.md (247) Patch Links:
>>=20
>> 	=E2=80=A2 https://github.com/quicwg/base-drafts/pull/1286.patch
>> 	=E2=80=A2 https://github.com/quicwg/base-drafts/pull/1286.diff
>> =E2=80=94
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub, or mute the=20
>> thread.
>>=20
>=20
> --
> Mark Nottingham   https://www.mnot.net/
>=20

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


From nobody Wed Apr 11 17:18:11 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1328212D872 for ; Wed, 11 Apr 2018 17:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6R7KbRCNuPA for ; Wed, 11 Apr 2018 17:17:45 -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 36ECA126D3F for ; Wed, 11 Apr 2018 17:17:45 -0700 (PDT)
Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx12.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1f6Pvq-0006h1-A9 for quic@ietf.org; Thu, 12 Apr 2018 02:17:43 +0200
Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1f6PvJ-0005TE-3I for quic@ietf.org; Wed, 11 Apr 2018 20:17:39 -0400
Received: (qmail 4919 invoked from network); 12 Apr 2018 00:17:07 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.61]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Apr 2018 00:17:07 -0000
To: quic@ietf.org
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-898 3-0ecabeb9fea5@huitema.net>  <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>   
From: Christian Huitema 
Openpgp: preference=signencrypt
Message-ID: <4eb09bd5-0a5c-6cc5-6b15-ad05b162ff93@huitema.net>
Date: Wed, 11 Apr 2018 17:17:04 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.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: Privacy holes
X-Originating-IP: 168.144.250.234
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.37)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5jEWOuEGYXc1I+pOl+y22NF602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViLx7BC/khgNw62WWO0UXczs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBfeuTov1vPAP3qEy01CsKmx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpWVqbBQU21a1smzLjhCpKfKnzeemZtkSi5l5TGiuBrSc1G9b/YbCyZL lbTGxQiVuzSU2yw6z85L3UyCdO+oQ3S7VPd90DA1c/ZLOZZo7XGPVfWv8HL1YL3Zn8TE/e4IMjT6 4dZYZAAUgQSn0n4YsmwRySDwo7H6ZklSehsmICPoX+ggKW28pboyZCmKkHUYXakF3IPspD5p+6iq bUajRNiqSmvK4wZlsUi4sVLQxJPkpntB4/4Pbrz2QtFuyl+Sh6dB9TpvkuZeq0ZkrlXHlSrCfqb5 R4VemuUI6bcEARsm0AJkTmCkdIST5sK0IWStzAqNZy58uobCIkCdwVDO83SGTnM2K/9iKCD9v589 nVS3hWSdEOMftBjsWb6BDQzjSsHUIomTnJwT4ky6b7E7Hukt2Ge4B8NG0VKlrY+34Zmj+F/tjlrZ UvGhhjiSam0tWhQxL7hrJSk60SF3F6RYOYr2
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Apr 2018 00:18:09 -0000

On 4/11/2018 12:18 PM, Praveen Balasubramanian wrote:
> Going back to Christian's original question on privacy holes, there is =
an attack for linking IP addresses in the voluntary migration case.
>
> Let's consider the parking lot problem or in general case losing one ne=
twork and roaming to another network. This is the primary use case for co=
nnection migration. In this case all active QUIC connections that can mig=
rate, will do so. When these connections migrate they can change the CID,=
 the local port number and packet numbers. However do notice that only th=
e local 2-tuple changes for each connection, the server's 2-tuple remains=
 the same.=20
>
> Let's assume a powerful adversary can collect a network sniff of all th=
is traffic and builds a massive dataset. The adversary can then run a mac=
hine learning algorithm to identify time instants where a bunch of connec=
tions change their local 2-tuple at near the same time instant but contin=
ue going to the same server side 2-tuples. This will allow the adversary =
to link two IP addresses. The more times the user roams between networks =
back and forth the richer the correlation. The more open connections to d=
ifferent servers, the richer the correlation. Geolocation information can=
 minimize the number of addresses the adversary needs to correlate.=20
>
> The fundamental problem seems to be that the substrate is UDP/IP and it=
 is in the clear and allows linkability.=20

The server 2-tuple does provide some information, but we should not
overstate it. One element of the 2-tuple, the port number, is likely to
be set to 443 for pretty much all servers, so I don't think it is
terribly useful. The IP address is useful, but in many cases these
address will be shared by a large number of connections, either because
it is a big service like Microsoft.com, or because it ends in some kind
of CDN.

I don't like the general line of reasoning that "because there is
another hole here, we should not fix this hole there." If you accept
that, you end up with so many unpatched holes that the situation is
indeed hopeless. But if we fix now the holes that we can fix, and if
other holes prove important, we can fix them later. For example, if
tracking by IP is an important problem, we can start using multiple
addresses per server, or maybe some form of onion routing, or some CDN
trick. But if we stick a clear text ID in the headers, we lose.

-- Christian Huitema


From nobody Wed Apr 11 18:44:14 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE871243F6 for ; Wed, 11 Apr 2018 18:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 rlr6ugzpU6S2 for ; Wed, 11 Apr 2018 18:44:11 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E3B12D876 for ; Wed, 11 Apr 2018 18:44:11 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id p6so2237556pfn.4 for ; Wed, 11 Apr 2018 18:44:11 -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=5qIzPwlSnAr/waZsDG7vXlQk7NzwH4gx/NfubObs82s=; b=NboNRw6iqZ9mTlTpXd+q85mnkMRg8lfVDuCwg5tMwJ0Rbe+kG2DJp0AnrPxtp3HkWV YUJNVR+xQM06Qf5O8uC/srWw6bHFrjd3p3jT+54mgc83iCfkOXuryX58sdESTXwbP4q5 E0hvpbB4W5n2MbfW0QwosWfrgTIf3pos6WOcOalWumE9Fv46daxKHoSSLfqUEcGs+h4V Q9ItLsOtgb6Oqat7UwM/do8MKgWBzRhM7DkJc634+ncbQ5zRJ9kyXgdB6OIchyBo4lQz XzvtwUq6mjp3yN0g5f92Itk42yVkoHoOZSP6ahhAkGUjnJPv6FdnPDNRwld5Gif7TB5c iIcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=5qIzPwlSnAr/waZsDG7vXlQk7NzwH4gx/NfubObs82s=; b=AatXVn1OPS8fX0tzobXXf7NPhuZdDE7mTeVsgsPt1kk2agw0Nr1DkLfw83Dvfb4THO sH2Db7H9jaJ4ZGnL9UnbTONY0vpV4aDOpbwUNhCJMXRZGcNeiNnHqDlrsN7O+0BGTSQD v96mq9VP2WtvCLpM1wjub3xsYaz+PMsag++Y5jNpwF6txLK9opiTLT+++ioV5YTrm+3O cuAaL+FlvJFq9CgoC8m0+pbs5etZUVpv4ZrKX2eX0SfwHpT8tvl8kSxhbJejiu5E1DLs vLztGABOjgEilKDdvO5XJUSDRa57M1gaCqlPtvz7G56gCzw1VN5GBy1uH9GB54nA6+QA b/DA==
X-Gm-Message-State: ALQs6tCLb0JS/h7ouqt5XAOqCl8Y2MGW0CH0DcQbKwVcjGbdvqcG1+MR 7GK3wYvbROB7XH6jcPrH1+hrMks/Lqj9b6Or+N/dXQ==
X-Google-Smtp-Source: AIpwx49qErSpmBiyLNMlsQ6W5+lnmYwfyd1vIY9jUbPP0NeqgTnIK8BPestt50LvQZw0rpj52XXcbjQ+fhirWBskHtY=
X-Received: by 10.99.44.141 with SMTP id s135mr5056669pgs.67.1523497450643; Wed, 11 Apr 2018 18:44:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Wed, 11 Apr 2018 18:44:09 -0700 (PDT)
In-Reply-To: <60955AE8-7637-4CC4-9FD8-56201685EE03@nokia.com>
References:         <60955AE8-7637-4CC4-9FD8-56201685EE03@nokia.com>
From: Kazuho Oku 
Date: Thu, 12 Apr 2018 10:44:09 +0900
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: "Fossati, Thomas (Nokia - GB/Cambridge)" 
Cc: "Brian Trammell (IETF)" , Praveen Balasubramanian , IETF QUIC WG ,  Ryan Hamilton , Victor Vasiliev 
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, 12 Apr 2018 01:44:13 -0000

2018-04-11 17:56 GMT+09:00 Fossati, Thomas (Nokia - GB/Cambridge)
:
> Hi Kazuho
>
> =EF=BB=BFOn 11/04/2018, 09:41, "QUIC on behalf of Kazuho Oku"  wrote:
>> What I am arguing is that the KPI of the middleboxes that optimize TCP
>> are not only the end-user-percieved performance, but also how
>> efficient the bandwidth is used.
>>
>> It's true that with QUIC there will be much less "optimizations" that
>> middleboxes can make. But the bandwidth efficiency could still be
>> improvable, and mobile network operators will have the incentive to do
>> so since, as I stated, it helps them cram more users into each base
>> station.
>>
>> And PN will likely be the vector being used for such optimizations
>> unless we encrypt it.
>
> I'm not aware of any technique that uses an untamperable PN to achieve
> bandwidth optimisation.

Well, assuming that the majority of the senders will use PN in a
monotonously increasing manner and that skips will be inserted
infrequently, and assuming that such senders will implement ACK-based
loss detection, I would anticipate that it would make sense for a
middlebox to reorder the packet by the PN (by buffering out-of-order
packets for up to some short amount of time (e.g., 1/16 RTT)), since
it would reduce the probability of fast retransmits that could be
spurious.

I am not sure how effective doing so would be, or what the side
effects of doing that would be (or if such side effects can be
fixed)...

Am I missing something?

And anyways, let me assert what Roberto said. There will be many ways
of misusing a signal in the ways that we cannot expect of.

Let's start from the safe side (by having PNE) instead of exposing us
to the risk of ossification that will become unfixable once we start
seeing them.

> The middlebox needs to be able to actively
> manipulate the SEQ/ACK space - and maybe other things - to do that.
> And this is already not possible in QUIC, which is why network equipment
> vendors are mainly looking at AQM-based solutions.
>



--=20
Kazuho Oku


From nobody Wed Apr 11 18:46:47 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8163612D876 for ; Wed, 11 Apr 2018 18:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 xXXdFSO_RAbK for ; Wed, 11 Apr 2018 18:46:43 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0093.outbound.protection.outlook.com [104.47.42.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1CD1243F6 for ; Wed, 11 Apr 2018 18:46:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uG1pkIegN2yvYxPOoUqKRK3/+oiWlsVZ62GAOlZujio=; b=FyB88Wac0bQsrcFMbXhhs/9O1yYxSkt72Ls/YGR9nHbAyz1Cz0af89AG679Hca2uoz76OGPeVzUZwuVjyw7bynoC50KtGeW3IoUg0w91j5kJzOJqYM48BCRIsJqjSZYsGxezakgcCzEkAKiS8/q06cOKvEAPfZy7xTSehmcwtQY=
Received: from MWHPR21MB0638.namprd21.prod.outlook.com (10.175.141.139) by MWHPR21MB0125.namprd21.prod.outlook.com (10.173.52.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.3; Thu, 12 Apr 2018 01:46:41 +0000
Received: from MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::6d48:f7af:d267:2021]) by MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::6d48:f7af:d267:2021%6]) with mapi id 15.20.0696.006; Thu, 12 Apr 2018 01:46:41 +0000
From: Praveen Balasubramanian 
To: huitema , "quic@ietf.org" 
Subject: RE: Privacy holes
Thread-Topic: Privacy holes
Thread-Index: AQHT0fPCjE+2yJJX1kG/ZO2j/ihAdaP8RCzQ
Date: Thu, 12 Apr 2018 01:46:41 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-898 3-0ecabeb9fea5@huitema.net>  <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>    <4eb09bd5-0a5c-6cc5-6b15-ad05b162ff93@huitema.net>
In-Reply-To: <4eb09bd5-0a5c-6cc5-6b15-ad05b162ff93@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:3::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0125; 7:1qmLduykqA4qeH96HSrOQMmXWzxwzQr/4W4T8slaJgx650hjs/iENf8vudp9C98lWra3vd3CSl/X+cNfZbw5qtKQmu6gy6ZfN23dVaavMpMWVz2kxuHJq1jJekBXOtMosISXFfbs+K5bQrASff9bZv/kcjC7r048SKuzrzwVIiAp5dCRG9YGWqVgJmB6zD41GC7UxVKoSKs8cfcwUHMOfBmasrZyvkjKtMZNttY1wl8U2Oou+F6hhSU3sdU2xxvW; 20:U/d5fmaptOdFDCv/0KTKdB5s9Yu8Yh8hChbN4EsMWpR6jjlOtjvjOsEqLo22yXfrHOIG1oBLtf+K4CGBkbQ/CdS0M3lM9OehaRe1jC54oitpTQlR7jG2/OG6fBgQt8ukZ8E5UIRXt2ycRycjY3fsiB9ghdqBg5EJv9OJB1thjPQ=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(3008032)(2017052603328)(7193020); SRVR:MWHPR21MB0125; 
x-ms-traffictypediagnostic: MWHPR21MB0125:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231221)(944501343)(52105095)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR21MB0125; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0125; 
x-forefront-prvs: 06400060E1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(39380400002)(346002)(396003)(13464003)(189003)(199004)(9686003)(3480700004)(8936002)(8676002)(25786009)(81156014)(81166006)(97736004)(53936002)(478600001)(105586002)(446003)(2906002)(55016002)(3660700001)(3280700002)(68736007)(7116003)(6116002)(106356001)(6436002)(5250100002)(2501003)(6246003)(10290500003)(5660300001)(74316002)(33656002)(86362001)(110136005)(221733001)(305945005)(22452003)(186003)(7736002)(316002)(86612001)(229853002)(93886005)(14454004)(11346002)(476003)(486006)(2900100001)(102836004)(76176011)(10090500001)(99286004)(46003)(8990500004)(7696005)(6506007)(59450400001)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0125; H:MWHPR21MB0638.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 3af3ad2a-9725-40cb-927e-08d5a0173d54
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3af3ad2a-9725-40cb-927e-08d5a0173d54
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2018 01:46:41.2687 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0125
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Apr 2018 01:46:45 -0000

SXQncyBub3QganVzdCB0aGUgc2VydmVyIGluZm9ybWF0aW9uLiBJdHMgdGltaW5nIGluZm9ybWF0
aW9uIHRoYXQgaXMgZmFyIG1vcmUgdmFsdWFibGUgZm9yIHRoZSBhZHZlcnNhcnkuIE5vdCBhbGwg
Y2xpZW50cyB3aWxsIGZhaWxvdmVyIGZyb20gd2lmaSB0byBjZWxsdWxhciBhdCB0aGUgc2FtZSB0
aW1lIGFuZCBoZW5jZSB0aGUgY29ycmVsYXRpb24gd2lsbCBiZSB2ZXJ5IHN0cm9uZy4gWW91IGp1
c3QgbmVlZCBhIGZldyBmYWlsb3ZlciBldmVudHMgaW4gYSBkYXkgZm9yIGEgdmVyeSBzdHJvbmcg
Y29ycmVsYXRpb24uIFdoYXQgYWxzbyBtYWtlcyB0aGlzIGVhc3kgaXMgdGhhdCBJbiBhIGNhcHR1
cmUsIGEgbWlncmF0aW9uIGxvb2tzIHZlcnkgZGlmZmVyZW50IHRoYW4gYSBuZXcgY29ubmVjdGlv
bi4gVGhlIGF0dGFjayBzZWVtcyB2ZXJ5IHByYWN0aWNhbCBmb3IgYSBwb3dlcmZ1bCBhZHZlcnNh
cnkuDQoNCj4+IEkgZG9uJ3QgbGlrZSB0aGUgZ2VuZXJhbCBsaW5lIG9mIHJlYXNvbmluZyB0aGF0
ICJiZWNhdXNlIHRoZXJlIGlzIGFub3RoZXIgaG9sZSBoZXJlLCB3ZSBzaG91bGQgbm90IGZpeCB0
aGlzIGhvbGUgdGhlcmUuIg0KSSBkaWRuJ3Qgc3RhdGUgdGhpcyBhbmQgaW5jcmVtZW50YWwgcHJv
Z3Jlc3MgaXMgdXNlZnVsLiBJIHdhcyBzaW1wbHkgdHJ5aW5nIHRvIGxpc3QgcG9zc2libGUgcHJp
dmFjeSBob2xlcyBzaW5jZSB0aGF0IHdhcyB0aGUgcXVlc3Rpb24gb24gdGhpcyB0aHJlYWQuDQoN
Cj4+IHdlIGNhbiBzdGFydCB1c2luZyBtdWx0aXBsZSBhZGRyZXNzZXMgcGVyIHNlcnZlciwgb3Ig
bWF5YmUgc29tZSBmb3JtIG9mIG9uaW9uIHJvdXRpbmcsIG9yIHNvbWUgQ0ROIHRyaWNrDQpJbiBh
biBpZGVhbCB3b3JsZCB5ZXMuIEJ1dCBtb3N0IGRlcGxveW1lbnRzIHdpbGwgYmUgaW5jcmVtZW50
YWwgb24gY3VycmVudCBpbmZyYS4NCg0KPj4gQnV0IGlmIHdlIHN0aWNrIGEgY2xlYXIgdGV4dCBJ
RCBpbiB0aGUgaGVhZGVycywgd2UgbG9zZQ0KVGhpcyBpcyB0b28gYnJvYWQgLSBzdGlja2luZyB0
aGUgKnNhbWUqIGNsZWFydGV4dCBJRCBpcyBhIHByb2JsZW0uIERpZmZlcmVudCBjbGVhcnRleHQg
SURzIGlzIG5vIGRpZmZlcmVudCB0aGFuIHVzaW5nIGVuY3J5cHRpb24gaS5lLiBtYWtlIGNsZWFy
IHRleHQgZmllbGRzIGxvb2sgbGlrZSBhIG5ldyBjb25uZWN0aW9uIG9uIHRoZSB3aXJlLiANCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RpYW4gSHVpdGVtYQ0KU2VudDogV2VkbmVz
ZGF5LCBBcHJpbCAxMSwgMjAxOCA1OjE3IFBNDQpUbzogcXVpY0BpZXRmLm9yZw0KU3ViamVjdDog
UmU6IFByaXZhY3kgaG9sZXMNCg0KDQoNCk9uIDQvMTEvMjAxOCAxMjoxOCBQTSwgUHJhdmVlbiBC
YWxhc3VicmFtYW5pYW4gd3JvdGU6DQo+IEdvaW5nIGJhY2sgdG8gQ2hyaXN0aWFuJ3Mgb3JpZ2lu
YWwgcXVlc3Rpb24gb24gcHJpdmFjeSBob2xlcywgdGhlcmUgaXMgYW4gYXR0YWNrIGZvciBsaW5r
aW5nIElQIGFkZHJlc3NlcyBpbiB0aGUgdm9sdW50YXJ5IG1pZ3JhdGlvbiBjYXNlLg0KPg0KPiBM
ZXQncyBjb25zaWRlciB0aGUgcGFya2luZyBsb3QgcHJvYmxlbSBvciBpbiBnZW5lcmFsIGNhc2Ug
bG9zaW5nIG9uZSBuZXR3b3JrIGFuZCByb2FtaW5nIHRvIGFub3RoZXIgbmV0d29yay4gVGhpcyBp
cyB0aGUgcHJpbWFyeSB1c2UgY2FzZSBmb3IgY29ubmVjdGlvbiBtaWdyYXRpb24uIEluIHRoaXMg
Y2FzZSBhbGwgYWN0aXZlIFFVSUMgY29ubmVjdGlvbnMgdGhhdCBjYW4gbWlncmF0ZSwgd2lsbCBk
byBzby4gV2hlbiB0aGVzZSBjb25uZWN0aW9ucyBtaWdyYXRlIHRoZXkgY2FuIGNoYW5nZSB0aGUg
Q0lELCB0aGUgbG9jYWwgcG9ydCBudW1iZXIgYW5kIHBhY2tldCBudW1iZXJzLiBIb3dldmVyIGRv
IG5vdGljZSB0aGF0IG9ubHkgdGhlIGxvY2FsIDItdHVwbGUgY2hhbmdlcyBmb3IgZWFjaCBjb25u
ZWN0aW9uLCB0aGUgc2VydmVyJ3MgMi10dXBsZSByZW1haW5zIHRoZSBzYW1lLiANCj4NCj4gTGV0
J3MgYXNzdW1lIGEgcG93ZXJmdWwgYWR2ZXJzYXJ5IGNhbiBjb2xsZWN0IGEgbmV0d29yayBzbmlm
ZiBvZiBhbGwgdGhpcyB0cmFmZmljIGFuZCBidWlsZHMgYSBtYXNzaXZlIGRhdGFzZXQuIFRoZSBh
ZHZlcnNhcnkgY2FuIHRoZW4gcnVuIGEgbWFjaGluZSBsZWFybmluZyBhbGdvcml0aG0gdG8gaWRl
bnRpZnkgdGltZSBpbnN0YW50cyB3aGVyZSBhIGJ1bmNoIG9mIGNvbm5lY3Rpb25zIGNoYW5nZSB0
aGVpciBsb2NhbCAyLXR1cGxlIGF0IG5lYXIgdGhlIHNhbWUgdGltZSBpbnN0YW50IGJ1dCBjb250
aW51ZSBnb2luZyB0byB0aGUgc2FtZSBzZXJ2ZXIgc2lkZSAyLXR1cGxlcy4gVGhpcyB3aWxsIGFs
bG93IHRoZSBhZHZlcnNhcnkgdG8gbGluayB0d28gSVAgYWRkcmVzc2VzLiBUaGUgbW9yZSB0aW1l
cyB0aGUgdXNlciByb2FtcyBiZXR3ZWVuIG5ldHdvcmtzIGJhY2sgYW5kIGZvcnRoIHRoZSByaWNo
ZXIgdGhlIGNvcnJlbGF0aW9uLiBUaGUgbW9yZSBvcGVuIGNvbm5lY3Rpb25zIHRvIGRpZmZlcmVu
dCBzZXJ2ZXJzLCB0aGUgcmljaGVyIHRoZSBjb3JyZWxhdGlvbi4gR2VvbG9jYXRpb24gaW5mb3Jt
YXRpb24gY2FuIG1pbmltaXplIHRoZSBudW1iZXIgb2YgYWRkcmVzc2VzIHRoZSBhZHZlcnNhcnkg
bmVlZHMgdG8gY29ycmVsYXRlLiANCj4NCj4gVGhlIGZ1bmRhbWVudGFsIHByb2JsZW0gc2VlbXMg
dG8gYmUgdGhhdCB0aGUgc3Vic3RyYXRlIGlzIFVEUC9JUCBhbmQgaXQgaXMgaW4gdGhlIGNsZWFy
IGFuZCBhbGxvd3MgbGlua2FiaWxpdHkuIA0KDQpUaGUgc2VydmVyIDItdHVwbGUgZG9lcyBwcm92
aWRlIHNvbWUgaW5mb3JtYXRpb24sIGJ1dCB3ZSBzaG91bGQgbm90IG92ZXJzdGF0ZSBpdC4gT25l
IGVsZW1lbnQgb2YgdGhlIDItdHVwbGUsIHRoZSBwb3J0IG51bWJlciwgaXMgbGlrZWx5IHRvIGJl
IHNldCB0byA0NDMgZm9yIHByZXR0eSBtdWNoIGFsbCBzZXJ2ZXJzLCBzbyBJIGRvbid0IHRoaW5r
IGl0IGlzIHRlcnJpYmx5IHVzZWZ1bC4gVGhlIElQIGFkZHJlc3MgaXMgdXNlZnVsLCBidXQgaW4g
bWFueSBjYXNlcyB0aGVzZSBhZGRyZXNzIHdpbGwgYmUgc2hhcmVkIGJ5IGEgbGFyZ2UgbnVtYmVy
IG9mIGNvbm5lY3Rpb25zLCBlaXRoZXIgYmVjYXVzZSBpdCBpcyBhIGJpZyBzZXJ2aWNlIGxpa2Ug
TWljcm9zb2Z0LmNvbSwgb3IgYmVjYXVzZSBpdCBlbmRzIGluIHNvbWUga2luZCBvZiBDRE4uDQoN
CkkgZG9uJ3QgbGlrZSB0aGUgZ2VuZXJhbCBsaW5lIG9mIHJlYXNvbmluZyB0aGF0ICJiZWNhdXNl
IHRoZXJlIGlzIGFub3RoZXIgaG9sZSBoZXJlLCB3ZSBzaG91bGQgbm90IGZpeCB0aGlzIGhvbGUg
dGhlcmUuIiBJZiB5b3UgYWNjZXB0IHRoYXQsIHlvdSBlbmQgdXAgd2l0aCBzbyBtYW55IHVucGF0
Y2hlZCBob2xlcyB0aGF0IHRoZSBzaXR1YXRpb24gaXMgaW5kZWVkIGhvcGVsZXNzLiBCdXQgaWYg
d2UgZml4IG5vdyB0aGUgaG9sZXMgdGhhdCB3ZSBjYW4gZml4LCBhbmQgaWYgb3RoZXIgaG9sZXMg
cHJvdmUgaW1wb3J0YW50LCB3ZSBjYW4gZml4IHRoZW0gbGF0ZXIuIEZvciBleGFtcGxlLCBpZiB0
cmFja2luZyBieSBJUCBpcyBhbiBpbXBvcnRhbnQgcHJvYmxlbSwgd2UgY2FuIHN0YXJ0IHVzaW5n
IG11bHRpcGxlIGFkZHJlc3NlcyBwZXIgc2VydmVyLCBvciBtYXliZSBzb21lIGZvcm0gb2Ygb25p
b24gcm91dGluZywgb3Igc29tZSBDRE4gdHJpY2suIEJ1dCBpZiB3ZSBzdGljayBhIGNsZWFyIHRl
eHQgSUQgaW4gdGhlIGhlYWRlcnMsIHdlIGxvc2UuDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoN
Cg==


From nobody Wed Apr 11 19:01:30 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273D912D875 for ; Wed, 11 Apr 2018 19:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVpuoxQHP-hj for ; Wed, 11 Apr 2018 19:01:26 -0700 (PDT)
Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116861241F8 for ; Wed, 11 Apr 2018 19:01:26 -0700 (PDT)
Received: by mail-ot0-x231.google.com with SMTP id j8-v6so4264708ota.7 for ; Wed, 11 Apr 2018 19:01:26 -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=pfVPYD0tdc01oW8NhwLbukjNkfzkE2KIHiIQi+FHQ9A=; b=J+Vqux+nRF+EtuSsxSMXqiJRvl3Vxc9BXTx1NwjWEacy2iQdYLsrt9jTOc152fhj24 vUhALJEqiTkXRt8em74yD6hZZSF+9Mjuzb9GT2Mn1VujrZxu6XrgcDnFYHc71OjOWEEa MucPVI1MyzpE3t/mC/rs9Jc9Q6AsAUJJTrZtm5e8WfTe3MhlIXAwGq1rLZcraILfyDCF av7c6FhZMzhQo+Ivt6N5LeF+n7ZynIivFTSv2eeNhSKK7qGynRan8iNIdWGYbdDYNxab gxzQVUVXy1x3Wby8dFadTVMbtjqixyqPWGViliJ6CGmbIT2kQ4IJfDqv7RMIudRSnq8b XTuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=pfVPYD0tdc01oW8NhwLbukjNkfzkE2KIHiIQi+FHQ9A=; b=UQhGhnwAGnev6h7sye64RRlZh4Y5OLEm9HsEQJ24p2JF/5rTEeqPE5ETKrC4jJj66x UICIV8LvWfKnILTmfXNuJMO/TtVKAOhxy2CT6yGw95gSvvMP9ylEbjAz4RJouNi/dVR2 UveGdEJaHMSicFVABbo6tXXPSXayXFXpF+5opKBcOBtBGjop87LycT1rHuif67JI8Nc4 /gzaPK0On8f9xlttRoDWRARQ0/6Z3Y+uDa0wWgc2xZM4y9dGn/uato6lK2bjpymuALId f7YhK+73QeOGAEwxhYMTkMT0kDN+85S9f5kWnPHP7//nToTtauRyJJshPttR1oRwXEh0 JBSA==
X-Gm-Message-State: ALQs6tA10/lH9jlad65zS/a8XR41QVdc9rGo7zXzkirDwrEAe5YwCbIb bR8fVzbfgLb11IfSnhfHHJrd7GpEFmFfHnI7aTc=
X-Google-Smtp-Source: AIpwx4+AEBlBSGDtPNiCZCk8hvSiPEvr4QTnNGS1UsQf5SN31yN2mIqCXXuWC/0vx86FvZsRjW2OjvAAyyhbZjxkFBk=
X-Received: by 2002:a9d:2a09:: with SMTP id t9-v6mr4514199ota.392.1523498485142;  Wed, 11 Apr 2018 19:01:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 19:01:24 -0700 (PDT)
In-Reply-To: <46f22a3d-b2ad-8c1a-9149-7d69dcde003c@huitema.net>
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>    <46f22a3d-b2ad-8c1a-9149-7d69dcde003c@huitema.net>
From: Martin Thomson 
Date: Thu, 12 Apr 2018 12:01:24 +1000
Message-ID: 
Subject: Re: Migration privacy and NAT rebinding
To: Christian Huitema 
Cc: Spencer Dawkins at IETF , "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: Thu, 12 Apr 2018 02:01:28 -0000

I don't know how realistic DKG's scenario is.  Most of these systems
aim to provide continuity of addressing because to do otherwise makes
the most common applications break all the time.  That means hiding
the consequences of handovers in the network, likely at great expense.

On Thu, Apr 12, 2018 at 4:34 AM, Christian Huitema  wrote:
> On 4/11/2018 10:31 AM, Spencer Dawkins at IETF wrote:
>
>> The thing I've wondered most about from threads in this space, is the
>> discussion about preventing linkages due to address changes as a
>> result of NAT rebinding, and what the concerns are, and how bad
>> linking after NAT rebinding would be, or would not be.
>
> That's a good question, and it probably deserves its own thread.
>
> I think we need to consider two kinds of migration: voluntary migration,
> and NAT rebinding. I really want to support privacy for voluntary
> migration. I doubt than we can do better than a best effort for NAT
> rebinding.
>
> An example of voluntary migration is the parking lot scenario, in which
> the client will voluntarily migrate the connection from WiFi to cellular
> as the WiFi signal fades away. The migration is voluntary, as the client
> will actively decide to send packets from a different source address,
> and possibly from a different source port. Involuntary migration happens
> when something change in the network without the client's knowledge, and
> packet start arriving to the server from a different IP and port. The
> canonical example of that is NAT rebinding.
>
> There is no question in my mind that we want to prevent linkability when
> doing voluntary migration, and that means rotating the connection ID and
> breaking PN linkability. But NAT rebinding is another matter. There are
> many big arguments against expanding too much resource to specifically
> increase NAT rebinding privacy:
>
> * Most NAT rebinding happens without the client's knowledge, which
> seriously limit mitigation capability.
>
> * If the connection was using IPv6 instead of IPv4, in theory there
> would be no NAT.
>
> * In the case of residential NAT, only the port changes upon rebinding,
> so linkability is obvious.
>
> * If there is just a short interval between the old and new NAT
> bindings, adversaries can use time based solutions to link the two
> connection.
>
> The proposal in the document is that clients may simulate a voluntary
> migration when going out of quiescence. This seems like a reasonable
> best effort approach. Most NAT rebinding occurs after connections have
> been idle for some time. Since there is a long interval, adversaries
> have a harder time using time stamps for linkability. In case of long
> intervals, carrier grade NAT may have recycled both the address and the
> port. And we need to grease the migration code path in servers and
> clients, so we can just as well do that.
>
> DKG pointed out that NAT rebinding also happens in mobile platforms,
> such as a car roaming between various cells. The car network offers a
> router + NAT service to devices inside the car. The router would be
> getting a new IPv4 address at each new cell, and there would be
> rebinding of any connection between internal devices and outside
> servers. If the QUIC connection survived, the adversaries will be able
> to deduce from traffic observation the successive locations of the
> device. This seems bad. If internal devices new about the connection
> changes, they could use the voluntary mechanisms. DKG argued that we
> should have protection even if the devices don't know about the
> migration, but the only practical solution is to rotate the connection
> ID for every packet -- effectively, encrypt the connection ID. This is
> not what we are debating now. I personally think that the mobile
> platform issue should be solved with some cooperation of the mobile
> router, so the devices can engage in voluntary migration.
>
> -- Christian Huitema
>
>


From nobody Wed Apr 11 19:17:50 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFD712D88C for ; Wed, 11 Apr 2018 19:17: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, 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 GHJO70XrxUoQ for ; Wed, 11 Apr 2018 19:17:46 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E99F1241F8 for ; Wed, 11 Apr 2018 19:17:46 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id x9-v6so3709682oig.7 for ; Wed, 11 Apr 2018 19:17:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1dag2IiIHELMjx796/dsgGaDNy+TWKjTprnBMIAJQFM=; b=pi/t3rym6F27kX/on+v5Y9EGnMbj7GXHe8y3mSsBU3Kx/sjeDrb5xtKKioSXDcGwQf BGMjLzXpcC8L5g+d3BZU/gg7oQ4PV4mdYuUkmk2Di4q9sVpfKtqy9+suzamgu505np1S SHZs/8aDu2JD8NMG68ZRN5qHP9VdregCMDZ4OGcjgFpkA/dPLH6vqTtP8pCiFvBq3Bqn 7jeRBKIREhLDa2+rHhOONEUFFprcPZVEpDPl5qXZf8eru/9JUiGHU9TeOCatrKEaPDZ4 MCsNk3+7OcbZvdqVDdXJEvKeLKzd/0tJY1Oc36Lo0QJm/qhOJOp7F24cqot1bmVvdfLu H3RA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=1dag2IiIHELMjx796/dsgGaDNy+TWKjTprnBMIAJQFM=; b=Q88E8QY4TFIyi+Lo+nzCIBGhSuaEwJM0zYgBcJByYGJIA/LmLwyMcpxPV/q4b280Mo DnxoTIBZNtON7wUpzKDB4WlfLY+Zf++l7pSfGOmU19HLBYzvUEeWb2ynjs/1sm+BQfSE 2lZwJFoo2l9LanNX4wHIc+JC5VsdDI4+BZpBJOlkVx3qbldUdD5Zqb3LrttnTn8O5PQP OFRG6x3TAGcClgCObTJ1cqNZO8I5GjPT+4789Nhr4m+qYY2Q3dUmf7B1V+Zce2uOmWfh II1W4/ZW+YtnFr+bSEWEsGVaYmlMwO3kbwOwE40nAjn82ZMZQ1kIV2LNpUcE5ysRUn15 fmbQ==
X-Gm-Message-State: ALQs6tDO/iRkSuKbxJfsbtvoUG6g6HLUiXGbpjTm0AniXy16AJctu7zv cw6u1kC9VVwtSDfYLdhzPKTOMU2J/codkCTreqo=
X-Google-Smtp-Source: AIpwx49Bbo1OlAbGBXZgUEMFVdEnNUAaYjHfdMOnGYyGeiZ19roHBE4pViffh9o3zr6Hm6PSiPNX8CH6QjCk9umB6+c=
X-Received: by 2002:aca:c68d:: with SMTP id w135-v6mr4683634oif.215.1523499465591;  Wed, 11 Apr 2018 19:17:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 19:17:44 -0700 (PDT)
In-Reply-To: 
References:         <60955AE8-7637-4CC4-9FD8-56201685EE03@nokia.com> 
From: Martin Thomson 
Date: Thu, 12 Apr 2018 12:17:44 +1000
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Kazuho Oku 
Cc: "Fossati, Thomas (Nokia - GB/Cambridge)" , Victor Vasiliev ,  "Brian Trammell (IETF)" , IETF QUIC WG , Ryan Hamilton ,  Praveen Balasubramanian 
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, 12 Apr 2018 02:17:48 -0000

On Thu, Apr 12, 2018 at 11:44 AM, Kazuho Oku  wrote:
>> I'm not aware of any technique that uses an untamperable PN to achieve
>> bandwidth optimisation.
>
> Well, assuming that the majority of the senders will use PN in a
> monotonously increasing manner and that skips will be inserted
> infrequently, and assuming that such senders will implement ACK-based
> loss detection, I would anticipate that it would make sense for a
> middlebox to reorder the packet by the PN (by buffering out-of-order
> packets for up to some short amount of time (e.g., 1/16 RTT)), since
> it would reduce the probability of fast retransmits that could be
> spurious.

While it might seem like the latency hit here would be noticeable and
thus this optimization would be obviously undesirable, consider a
network operator that has to trade off between peak hour utilization
and latency.  If this little bit of HoLB gets their efficiency numbers
up by reducing retransmissions, maybe they will consider that a good
trade.

The other point is that in TLS, we have direct experience with
middleboxes "policing" the protocol.  That is, if it doesn't look like
TLS, the flow is stopped.  We know for sure that this includes
checking the record header, which means that TLS 1.3 uses 3 more
octets per record than it needs to.  It also includes a whole bunch of
handshake fields as well, which we have less information on as a
whole.  Even if we discount the QUIC==7 fiasco as aberrant, this is a
cost I'd rather not have to worry about paying some time in the
future.

So, from my perspective, in addition to the privacy "intangibles" that
Christian and Stephen have talked about, there is a real defensive
value in this.  That's without considering that we've already decided
that voluntary migration is a feature we need to have.


From nobody Wed Apr 11 23:16:52 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9141512D95A for ; Wed, 11 Apr 2018 23:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjEarNQtRa3A for ; Wed, 11 Apr 2018 23:16:49 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1482212D955 for ; Wed, 11 Apr 2018 23:16:49 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 68A05630425D6 for ; Thu, 12 Apr 2018 07:16:44 +0100 (IST)
Received: from DGGEMM424-HUB.china.huawei.com (10.1.198.41) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 12 Apr 2018 07:16:45 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm424-hub.china.huawei.com ([10.1.198.41]) with mapi id 14.03.0361.001; Thu, 12 Apr 2018 14:16:39 +0800
From: "Roni Even (A)" 
To: Christian Huitema , Spencer Dawkins at IETF 
CC: "quic@ietf.org" 
Subject: RE: Migration privacy and NAT rebinding
Thread-Topic: Migration privacy and NAT rebinding
Thread-Index: AQHT0cPL0YGMzPrjCkGJJYYXj2qnMqP8psEQ
Date: Thu, 12 Apr 2018 06:16:39 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8728E1@DGGEMM506-MBX.china.huawei.com>
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>    <46f22a3d-b2ad-8c1a-9149-7d69dcde003c@huitema.net>
In-Reply-To: <46f22a3d-b2ad-8c1a-9149-7d69dcde003c@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.69]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Apr 2018 06:16:51 -0000

SGkgQ2hyaXN0aWFuLA0KT24gdGhlIHZvbHVudGFyeSBtaWdyYXRpb24sIHdoYXQgYWJvdXQgd2hl
biB3YWxraW5nIGZyb20gdGhlIHBhcmtpbmcgbG90IHRvd2FyZHMgdGhlIGhvdXNlLCB3aWxsIGNv
bm5lY3QgdG8gV2lmaSBhbmQgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIGhvbWUgcm91dGVyIHdpbGwg
cHJvYmFibHkgYmUgdGhlIHNhbWUgYXMgd2hlbiBnb2luZyBvdXQuICBUaGVyZSB3aWxsIHN1ZGRl
bmx5IGJlIGEgbG90IG9mIHRyYWZmaWMgZnJvbSB0aGUgaG9tZSByb3V0ZXIgKG5vdCBvbmx5IFFV
SUMpLCBmb3IgZXhhbXBsZSBzeW5jaHJvbml6aW5nIGFsbCBhcHBsaWNhdGlvbnMgdGhhdCB3ZXJl
IGRlZmluZWQgdG8gZG93bmxvYWQgb25seSBvbiB3aWZpLiBUaGUgbWlncmF0aW9uIHdpbGwgYmUg
ZWFzeSB0byBzcG90IGluIHRoaXMgY2FzZS4NClJvbmkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBDaHJpc3RpYW4gSHVpdGVtYQ0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMSwgMjAxOCA5
OjM0IFBNDQpUbzogU3BlbmNlciBEYXdraW5zIGF0IElFVEYNCkNjOiBxdWljQGlldGYub3JnDQpT
dWJqZWN0OiBNaWdyYXRpb24gcHJpdmFjeSBhbmQgTkFUIHJlYmluZGluZw0KDQpPbiA0LzExLzIw
MTggMTA6MzEgQU0sIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIHdyb3RlOg0KDQo+IFRoZSB0aGlu
ZyBJJ3ZlIHdvbmRlcmVkIG1vc3QgYWJvdXQgZnJvbSB0aHJlYWRzIGluIHRoaXMgc3BhY2UsIGlz
IHRoZSANCj4gZGlzY3Vzc2lvbiBhYm91dCBwcmV2ZW50aW5nIGxpbmthZ2VzIGR1ZSB0byBhZGRy
ZXNzIGNoYW5nZXMgYXMgYSANCj4gcmVzdWx0IG9mIE5BVCByZWJpbmRpbmcsIGFuZCB3aGF0IHRo
ZSBjb25jZXJucyBhcmUsIGFuZCBob3cgYmFkIA0KPiBsaW5raW5nIGFmdGVyIE5BVCByZWJpbmRp
bmcgd291bGQgYmUsIG9yIHdvdWxkIG5vdCBiZS4NCg0KVGhhdCdzIGEgZ29vZCBxdWVzdGlvbiwg
YW5kIGl0IHByb2JhYmx5IGRlc2VydmVzIGl0cyBvd24gdGhyZWFkLg0KDQpJIHRoaW5rIHdlIG5l
ZWQgdG8gY29uc2lkZXIgdHdvIGtpbmRzIG9mIG1pZ3JhdGlvbjogdm9sdW50YXJ5IG1pZ3JhdGlv
biwgYW5kIE5BVCByZWJpbmRpbmcuIEkgcmVhbGx5IHdhbnQgdG8gc3VwcG9ydCBwcml2YWN5IGZv
ciB2b2x1bnRhcnkgbWlncmF0aW9uLiBJIGRvdWJ0IHRoYW4gd2UgY2FuIGRvIGJldHRlciB0aGFu
IGEgYmVzdCBlZmZvcnQgZm9yIE5BVCByZWJpbmRpbmcuDQoNCkFuIGV4YW1wbGUgb2Ygdm9sdW50
YXJ5IG1pZ3JhdGlvbiBpcyB0aGUgcGFya2luZyBsb3Qgc2NlbmFyaW8sIGluIHdoaWNoIHRoZSBj
bGllbnQgd2lsbCB2b2x1bnRhcmlseSBtaWdyYXRlIHRoZSBjb25uZWN0aW9uIGZyb20gV2lGaSB0
byBjZWxsdWxhciBhcyB0aGUgV2lGaSBzaWduYWwgZmFkZXMgYXdheS4gVGhlIG1pZ3JhdGlvbiBp
cyB2b2x1bnRhcnksIGFzIHRoZSBjbGllbnQgd2lsbCBhY3RpdmVseSBkZWNpZGUgdG8gc2VuZCBw
YWNrZXRzIGZyb20gYSBkaWZmZXJlbnQgc291cmNlIGFkZHJlc3MsIGFuZCBwb3NzaWJseSBmcm9t
IGEgZGlmZmVyZW50IHNvdXJjZSBwb3J0LiBJbnZvbHVudGFyeSBtaWdyYXRpb24gaGFwcGVucyB3
aGVuIHNvbWV0aGluZyBjaGFuZ2UgaW4gdGhlIG5ldHdvcmsgd2l0aG91dCB0aGUgY2xpZW50J3Mg
a25vd2xlZGdlLCBhbmQgcGFja2V0IHN0YXJ0IGFycml2aW5nIHRvIHRoZSBzZXJ2ZXIgZnJvbSBh
IGRpZmZlcmVudCBJUCBhbmQgcG9ydC4gVGhlIGNhbm9uaWNhbCBleGFtcGxlIG9mIHRoYXQgaXMg
TkFUIHJlYmluZGluZy4NCg0KVGhlcmUgaXMgbm8gcXVlc3Rpb24gaW4gbXkgbWluZCB0aGF0IHdl
IHdhbnQgdG8gcHJldmVudCBsaW5rYWJpbGl0eSB3aGVuIGRvaW5nIHZvbHVudGFyeSBtaWdyYXRp
b24sIGFuZCB0aGF0IG1lYW5zIHJvdGF0aW5nIHRoZSBjb25uZWN0aW9uIElEIGFuZCBicmVha2lu
ZyBQTiBsaW5rYWJpbGl0eS4gQnV0IE5BVCByZWJpbmRpbmcgaXMgYW5vdGhlciBtYXR0ZXIuIFRo
ZXJlIGFyZSBtYW55IGJpZyBhcmd1bWVudHMgYWdhaW5zdCBleHBhbmRpbmcgdG9vIG11Y2ggcmVz
b3VyY2UgdG8gc3BlY2lmaWNhbGx5IGluY3JlYXNlIE5BVCByZWJpbmRpbmcgcHJpdmFjeToNCg0K
KiBNb3N0IE5BVCByZWJpbmRpbmcgaGFwcGVucyB3aXRob3V0IHRoZSBjbGllbnQncyBrbm93bGVk
Z2UsIHdoaWNoIHNlcmlvdXNseSBsaW1pdCBtaXRpZ2F0aW9uIGNhcGFiaWxpdHkuDQoNCiogSWYg
dGhlIGNvbm5lY3Rpb24gd2FzIHVzaW5nIElQdjYgaW5zdGVhZCBvZiBJUHY0LCBpbiB0aGVvcnkg
dGhlcmUgd291bGQgYmUgbm8gTkFULg0KDQoqIEluIHRoZSBjYXNlIG9mIHJlc2lkZW50aWFsIE5B
VCwgb25seSB0aGUgcG9ydCBjaGFuZ2VzIHVwb24gcmViaW5kaW5nLCBzbyBsaW5rYWJpbGl0eSBp
cyBvYnZpb3VzLg0KDQoqIElmIHRoZXJlIGlzIGp1c3QgYSBzaG9ydCBpbnRlcnZhbCBiZXR3ZWVu
IHRoZSBvbGQgYW5kIG5ldyBOQVQgYmluZGluZ3MsIGFkdmVyc2FyaWVzIGNhbiB1c2UgdGltZSBi
YXNlZCBzb2x1dGlvbnMgdG8gbGluayB0aGUgdHdvIGNvbm5lY3Rpb24uDQoNClRoZSBwcm9wb3Nh
bCBpbiB0aGUgZG9jdW1lbnQgaXMgdGhhdCBjbGllbnRzIG1heSBzaW11bGF0ZSBhIHZvbHVudGFy
eSBtaWdyYXRpb24gd2hlbiBnb2luZyBvdXQgb2YgcXVpZXNjZW5jZS4gVGhpcyBzZWVtcyBsaWtl
IGEgcmVhc29uYWJsZSBiZXN0IGVmZm9ydCBhcHByb2FjaC4gTW9zdCBOQVQgcmViaW5kaW5nIG9j
Y3VycyBhZnRlciBjb25uZWN0aW9ucyBoYXZlIGJlZW4gaWRsZSBmb3Igc29tZSB0aW1lLiBTaW5j
ZSB0aGVyZSBpcyBhIGxvbmcgaW50ZXJ2YWwsIGFkdmVyc2FyaWVzIGhhdmUgYSBoYXJkZXIgdGlt
ZSB1c2luZyB0aW1lIHN0YW1wcyBmb3IgbGlua2FiaWxpdHkuIEluIGNhc2Ugb2YgbG9uZyBpbnRl
cnZhbHMsIGNhcnJpZXIgZ3JhZGUgTkFUIG1heSBoYXZlIHJlY3ljbGVkIGJvdGggdGhlIGFkZHJl
c3MgYW5kIHRoZSBwb3J0LiBBbmQgd2UgbmVlZCB0byBncmVhc2UgdGhlIG1pZ3JhdGlvbiBjb2Rl
IHBhdGggaW4gc2VydmVycyBhbmQgY2xpZW50cywgc28gd2UgY2FuIGp1c3QgYXMgd2VsbCBkbyB0
aGF0Lg0KDQpES0cgcG9pbnRlZCBvdXQgdGhhdCBOQVQgcmViaW5kaW5nIGFsc28gaGFwcGVucyBp
biBtb2JpbGUgcGxhdGZvcm1zLCBzdWNoIGFzIGEgY2FyIHJvYW1pbmcgYmV0d2VlbiB2YXJpb3Vz
IGNlbGxzLiBUaGUgY2FyIG5ldHdvcmsgb2ZmZXJzIGEgcm91dGVyICsgTkFUIHNlcnZpY2UgdG8g
ZGV2aWNlcyBpbnNpZGUgdGhlIGNhci4gVGhlIHJvdXRlciB3b3VsZCBiZSBnZXR0aW5nIGEgbmV3
IElQdjQgYWRkcmVzcyBhdCBlYWNoIG5ldyBjZWxsLCBhbmQgdGhlcmUgd291bGQgYmUgcmViaW5k
aW5nIG9mIGFueSBjb25uZWN0aW9uIGJldHdlZW4gaW50ZXJuYWwgZGV2aWNlcyBhbmQgb3V0c2lk
ZSBzZXJ2ZXJzLiBJZiB0aGUgUVVJQyBjb25uZWN0aW9uIHN1cnZpdmVkLCB0aGUgYWR2ZXJzYXJp
ZXMgd2lsbCBiZSBhYmxlIHRvIGRlZHVjZSBmcm9tIHRyYWZmaWMgb2JzZXJ2YXRpb24gdGhlIHN1
Y2Nlc3NpdmUgbG9jYXRpb25zIG9mIHRoZSBkZXZpY2UuIFRoaXMgc2VlbXMgYmFkLiBJZiBpbnRl
cm5hbCBkZXZpY2VzIG5ldyBhYm91dCB0aGUgY29ubmVjdGlvbiBjaGFuZ2VzLCB0aGV5IGNvdWxk
IHVzZSB0aGUgdm9sdW50YXJ5IG1lY2hhbmlzbXMuIERLRyBhcmd1ZWQgdGhhdCB3ZSBzaG91bGQg
aGF2ZSBwcm90ZWN0aW9uIGV2ZW4gaWYgdGhlIGRldmljZXMgZG9uJ3Qga25vdyBhYm91dCB0aGUg
bWlncmF0aW9uLCBidXQgdGhlIG9ubHkgcHJhY3RpY2FsIHNvbHV0aW9uIGlzIHRvIHJvdGF0ZSB0
aGUgY29ubmVjdGlvbiBJRCBmb3IgZXZlcnkgcGFja2V0IC0tIGVmZmVjdGl2ZWx5LCBlbmNyeXB0
IHRoZSBjb25uZWN0aW9uIElELiBUaGlzIGlzIG5vdCB3aGF0IHdlIGFyZSBkZWJhdGluZyBub3cu
IEkgcGVyc29uYWxseSB0aGluayB0aGF0IHRoZSBtb2JpbGUgcGxhdGZvcm0gaXNzdWUgc2hvdWxk
IGJlIHNvbHZlZCB3aXRoIHNvbWUgY29vcGVyYXRpb24gb2YgdGhlIG1vYmlsZSByb3V0ZXIsIHNv
IHRoZSBkZXZpY2VzIGNhbiBlbmdhZ2UgaW4gdm9sdW50YXJ5IG1pZ3JhdGlvbi4NCg0KLS0gQ2hy
aXN0aWFuIEh1aXRlbWENCg0KDQo=


From nobody Wed Apr 11 23:23:22 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5057812D953 for ; Wed, 11 Apr 2018 23:23:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udCJ9u9me0lX for ; Wed, 11 Apr 2018 23:23:19 -0700 (PDT)
Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 137DE1267BB for ; Wed, 11 Apr 2018 23:23:18 -0700 (PDT)
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w3C6NBYT022056; Thu, 12 Apr 2018 08:23:11 +0200
Date: Thu, 12 Apr 2018 08:23:11 +0200
From: Willy Tarreau 
To: Christian Huitema 
Cc: Spencer Dawkins at IETF , "quic@ietf.org" 
Subject: Re: Migration privacy and NAT rebinding
Message-ID: <20180412062311.GB21908@1wt.eu>
References:  <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>    <46f22a3d-b2ad-8c1a-9149-7d69dcde003c@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <46f22a3d-b2ad-8c1a-9149-7d69dcde003c@huitema.net>
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Apr 2018 06:23:21 -0000

Hi Christian,

On Wed, Apr 11, 2018 at 11:34:24AM -0700, Christian Huitema wrote:
(...)
> DKG pointed out that NAT rebinding also happens in mobile platforms,
> such as a car roaming between various cells. The car network offers a
> router + NAT service to devices inside the car. The router would be
> getting a new IPv4 address at each new cell, and there would be
> rebinding of any connection between internal devices and outside
> servers. If the QUIC connection survived, the adversaries will be able
> to deduce from traffic observation the successive locations of the
> device. This seems bad. If internal devices new about the connection
> changes, they could use the voluntary mechanisms. DKG argued that we
> should have protection even if the devices don't know about the
> migration, but the only practical solution is to rotate the connection
> ID for every packet -- effectively, encrypt the connection ID. This is
> not what we are debating now. I personally think that the mobile
> platform issue should be solved with some cooperation of the mobile
> router, so the devices can engage in voluntary migration.

First, thanks for the long detailed explanation. To be honest, I'm not
much convinced that this rebinding will really happen often in the case
of the car network described above, as it would provide a terrible
experience to users inside the car and it's in the carrier's interest
not to break the end-to-end connectivity. At 130 km/h on a highway
you'd switch to a new tower roughly every ~2 minutes (4km).

Now regarding what you mention about the cooperation of the mobile router,
that makes me think about TCP ECN where intermediary routers may mark the
packets to signal certain conditions. That's a perfect example of why we
need to ensure that it *is* possible within certain limits to let the
network understand a stream and mark it. If we make sure the router cannot
recognize connections or needs to do very complex stuff to be able to just
decrypt a connection ID, we'll hardly get a good cooperation from such
equipments. And in my opinion in 2018 it wouldn't seem stupid to have a
"handover" bit in a transport protocol to signal that something changed
in the path and that both ends might have something to do (change an ID,
resend a packet to be sure to reopen a NAT flow, etc).

Willy


From nobody Thu Apr 12 00:03:01 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D5D126FDC for ; Thu, 12 Apr 2018 00:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5EqpCgRcruk for ; Thu, 12 Apr 2018 00:02:58 -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 04D221241FC for ; Thu, 12 Apr 2018 00:02:58 -0700 (PDT)
Received: by mail-it0-x231.google.com with SMTP id b5-v6so6044313itj.1 for ; Thu, 12 Apr 2018 00:02:57 -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=8DRSn4Hi8pBC3nCgv1IIzI1bT0hn0WfFzyYlaI1bSB0=; b=DT0LhAexlddlfieSEF7u1yMrrO0g4291LGeQZsv3oIDuI/B9mjX91ZqC275oyZOqXq 50vzNm2dBulRClqG9rR7ac6OtpwouUNcewimFl0SNC+B+bEwDTq6NWXrGNswL7lTEirg pX/17XE+T1jdEqjJ7O7E05xSM2AXtkDKug1/9t1TzJwQBlvRGTqbzkI5nLHoQxJqDbPv uudtX54KeQb5dnQEpBYIxX/ZHuSMOeJdX02VyV8tFBIocUytEru9DoMEZCfor5ib6pxG M83SPko3dbDLuWnVxTVKYig2xp7w1XzflumbUkAYFthV2BHZ1GeMzRkVPvjJm9MQ90CX yzOg==
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=8DRSn4Hi8pBC3nCgv1IIzI1bT0hn0WfFzyYlaI1bSB0=; b=FhefZCr84tT/C7j3+T224kwgArCB7TY+9vSWpd6i112xRfxbfZy2YX7VUfZ/oxWU3w jshB+bZKWMSpcGunFpPAbCckjD/W5hisv9j/kvDKZKoRdgyya7IUyUHidSvmMAhp1QYo DljrYraWoTxi36ZhOnOTYQ+Cssz7aEeFSvOwROOld0jFFQmC/D/sRuI0WU23VqpLpeA0 rpw96AW7f8ICL9n8N4D3T1pDFJi8xQQhdwCrS1TouuLoiBD5tBv8IjPSaKHZl3TA8pLW eYsLot2ARHUmMt8sq65u75uPwZhjt53vc79U4R/jl2UckaxAVWlItlXv06CFpoTjLVN1 ApCw==
X-Gm-Message-State: ALQs6tCcQ+dbDT9LJqOPKXnWf6yo1EvrRrvAogwk67eSkvfmYvhj2tf3 a50t78DA0IT7wsfMs05fyvOLlbOo6yw3N3ZJep8=
X-Google-Smtp-Source: AIpwx48YBo9qwHc+nyLN5DJQEUvX5VxHvt/xtYKwi+cgkFsnLaY4GLg1RcqzlWakT8vQNhlrgeOj/vIZ49hrfdeXNMs=
X-Received: by 2002:a24:5085:: with SMTP id m127-v6mr7652839itb.118.1523516577350;  Thu, 12 Apr 2018 00:02:57 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 12 Apr 2018 00:02:56 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:         <60955AE8-7637-4CC4-9FD8-56201685EE03@nokia.com>  
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 12 Apr 2018 00:02:56 -0700
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Martin Thomson , Kazuho Oku 
Cc: Praveen Balasubramanian , Ryan Hamilton , IETF QUIC WG ,  "Brian Trammell (IETF)" , Victor Vasiliev ,  "Fossati, Thomas (Nokia - GB/Cambridge)" 
Content-Type: multipart/alternative; boundary="00000000000067289d0569a15855"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 12 Apr 2018 07:03:00 -0000

--00000000000067289d0569a15855
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

So if a certain PN permutation scheme were deployed, even light middle
boxes could use this to classify the stream as QUIC connection and
immediately ossify away any future QUIC versions. It just need to do some
simple standard deviance on the for a given tuple.

I=E2=80=99d say we either need a clean incremental PN stream per path, or a=
n
encrypted PN that is not breakable.

Mikkel


On 12 April 2018 at 04.17.56, Martin Thomson (martin.thomson@gmail.com)
wrote:

On Thu, Apr 12, 2018 at 11:44 AM, Kazuho Oku  wrote:
>> I'm not aware of any technique that uses an untamperable PN to achieve
>> bandwidth optimisation.
>
> Well, assuming that the majority of the senders will use PN in a
> monotonously increasing manner and that skips will be inserted
> infrequently, and assuming that such senders will implement ACK-based
> loss detection, I would anticipate that it would make sense for a
> middlebox to reorder the packet by the PN (by buffering out-of-order
> packets for up to some short amount of time (e.g., 1/16 RTT)), since
> it would reduce the probability of fast retransmits that could be
> spurious.

While it might seem like the latency hit here would be noticeable and
thus this optimization would be obviously undesirable, consider a
network operator that has to trade off between peak hour utilization
and latency. If this little bit of HoLB gets their efficiency numbers
up by reducing retransmissions, maybe they will consider that a good
trade.

The other point is that in TLS, we have direct experience with
middleboxes "policing" the protocol. That is, if it doesn't look like
TLS, the flow is stopped. We know for sure that this includes
checking the record header, which means that TLS 1.3 uses 3 more
octets per record than it needs to. It also includes a whole bunch of
handshake fields as well, which we have less information on as a
whole. Even if we discount the QUIC=3D=3D7 fiasco as aberrant, this is a
cost I'd rather not have to worry about paying some time in the
future.

So, from my perspective, in addition to the privacy "intangibles" that
Christian and Stephen have talked about, there is a real defensive
value in this. That's without considering that we've already decided
that voluntary migration is a feature we need to have.

--00000000000067289d0569a15855
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
So if a certain PN p=
ermutation scheme were deployed, even light middle boxes could use this to =
classify the stream as QUIC connection and immediately ossify away any futu=
re QUIC versions. It just need to do some simple standard deviance on the f=
or a given tuple.

I=
=E2=80=99d say we either need a clean incremental PN stream per path, or an=
 encrypted PN that is not breakable.
 

Mikkel

=

 
On 12 April 2018 at 04.17.56, Martin Tho=
mson (martin.thomson@gmail.com<=
/a>) wrote:
 
On Thu, Apr 12, 2018 at 11:44 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:

>> I'm not aware of any technique that uses an untamperable P=
N to achieve

>> bandwidth optimisation.

>

> Well, assuming that the majority of the senders will use PN in a

> monotonously increasing manner and that skips will be inserted

> infrequently, and assuming that such senders will implement ACK-ba=
sed

> loss detection, I would anticipate that it would make sense for a

> middlebox to reorder the packet by the PN (by buffering out-of-ord=
er

> packets for up to some short amount of time (e.g., 1/16 RTT)), sin=
ce

> it would reduce the probability of fast retransmits that could be

> spurious.



While it might seem like the latency hit here would be noticeable and

thus this optimization would be obviously undesirable, consider a

network operator that has to trade off between peak hour utilization

and latency.  If this little bit of HoLB gets their efficiency numbers

up by reducing retransmissions, maybe they will consider that a good

trade.



The other point is that in TLS, we have direct experience with

middleboxes "policing" the protocol.  That is, if it doesn=
9;t look like

TLS, the flow is stopped.  We know for sure that this includes

checking the record header, which means that TLS 1.3 uses 3 more

octets per record than it needs to.  It also includes a whole bunch of

handshake fields as well, which we have less information on as a

whole.  Even if we discount the QUIC=3D=3D7 fiasco as aberrant, this is=
 a

cost I'd rather not have to worry about paying some time in the

future.



So, from my perspective, in addition to the privacy "intangibles&q=
uot; that

Christian and Stephen have talked about, there is a real defensive

value in this.  That's without considering that we've already d=
ecided

that voluntary migration is a feature we need to have.





--00000000000067289d0569a15855--


From nobody Thu Apr 12 02:01:51 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD2D124F57 for ; Thu, 12 Apr 2018 02:01: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 iq9vo8pYoS2K for ; Thu, 12 Apr 2018 02:01:48 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (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 ECB84120454 for ; Thu, 12 Apr 2018 02:01:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1523523705; s=strato-dkim-0002; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Date:Message-ID: From:References:To:Subject:X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject: Sender; bh=x537eLZXG3WURzAWyegoXWXXR3k+mTsurfKZVGR4O5E=; b=t1oc5IwC1be5Xqx72VVH3j4slJPi6vTj3686Cdwj63iqSSnvV25LEt/DjhX/8OZ6Gr vH3SipQV6bZw6xgV1y5o4PLcpuRdZ6ednwjbdQGB+GK7972QEyIFFh8six9cJet8IWpF eVsKjZJG9UE0tB8/rhYC6OP20aqYE+F+6AoyaYIHuDpuY8FwWNUBiyFTFhsaesvK7BHI HvkGZeyJtzYgO9cyePpMexPhiw78pAnmHISmurDkgnNqIWEPjnwLD2pH4K7vWCXossXt L3mAHH1vf8jduThOKnUSeljgvcPkYKPg23z8JtbjBOdqafo8JHLjxD/FL9w89ubSTpZg pvSA==
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1YaZ2OgvlDQIHaS9kr0=
X-RZG-CLASS-ID: mo00
Received: from [10.33.22.7] by smtp.strato.de (RZmta 43.2 DYNA|AUTH) with ESMTPSA id 302523u3C91j4cO (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, 12 Apr 2018 11:01:45 +0200 (CEST)
Subject: Re: Migration privacy and NAT rebinding
To: quic@ietf.org
References:  <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>    <46f22a3d-b2ad-8c1a-9149-7d69dcde003c@huitema.net> <20180412062311.GB21908@1wt.eu>
From: Roland Zink 
Message-ID: <137bd394-06ff-5730-a41e-03b97287dac9@zinks.de>
Date: Thu, 12 Apr 2018 11:01:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180412062311.GB21908@1wt.eu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Apr 2018 09:01:51 -0000

In GPRS, UMTS or LTE networks wireless devices do not get new IP 
addresses when there is a handover between cells.  The packets are 
tunneled via GTP-U to the cells. However the path is changed (between 
SGW and eNB in LTE) and this may cause for example reordering of packets 
or no transmission of packets during the handover. Note that the 
throughput also changes between near and far cell conditions. The QUIC 
developers will need to handle this in their congestion avoidance 
algortihms.

Regards,

Roland



Am 12.04.2018 um 08:23 schrieb Willy Tarreau:
> Hi Christian,
>
> On Wed, Apr 11, 2018 at 11:34:24AM -0700, Christian Huitema wrote:
> (...)
>> DKG pointed out that NAT rebinding also happens in mobile platforms,
>> such as a car roaming between various cells. The car network offers a
>> router + NAT service to devices inside the car. The router would be
>> getting a new IPv4 address at each new cell, and there would be
>> rebinding of any connection between internal devices and outside
>> servers. If the QUIC connection survived, the adversaries will be able
>> to deduce from traffic observation the successive locations of the
>> device. This seems bad. If internal devices new about the connection
>> changes, they could use the voluntary mechanisms. DKG argued that we
>> should have protection even if the devices don't know about the
>> migration, but the only practical solution is to rotate the connection
>> ID for every packet -- effectively, encrypt the connection ID. This is
>> not what we are debating now. I personally think that the mobile
>> platform issue should be solved with some cooperation of the mobile
>> router, so the devices can engage in voluntary migration.
> First, thanks for the long detailed explanation. To be honest, I'm not
> much convinced that this rebinding will really happen often in the case
> of the car network described above, as it would provide a terrible
> experience to users inside the car and it's in the carrier's interest
> not to break the end-to-end connectivity. At 130 km/h on a highway
> you'd switch to a new tower roughly every ~2 minutes (4km).
>
> Now regarding what you mention about the cooperation of the mobile router,
> that makes me think about TCP ECN where intermediary routers may mark the
> packets to signal certain conditions. That's a perfect example of why we
> need to ensure that it *is* possible within certain limits to let the
> network understand a stream and mark it. If we make sure the router cannot
> recognize connections or needs to do very complex stuff to be able to just
> decrypt a connection ID, we'll hardly get a good cooperation from such
> equipments. And in my opinion in 2018 it wouldn't seem stupid to have a
> "handover" bit in a transport protocol to signal that something changed
> in the path and that both ends might have something to do (change an ID,
> resend a packet to be sure to reopen a NAT flow, etc).
>
> Willy
>


From nobody Thu Apr 12 02:05:20 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80AA1252BA for ; Thu, 12 Apr 2018 02:05:19 -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 eHlDy2wul8As for ; Thu, 12 Apr 2018 02:05:18 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11451124F57 for ; Thu, 12 Apr 2018 02:05:18 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id l190-v6so4450041oig.9 for ; Thu, 12 Apr 2018 02:05:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bs9/1ejwylJHkX9lLyztDS6AGVtQQSqeMRcZmUtkK0o=; b=ueg2q+skjh/cDpMxGq09zsjDbq9NcZnhBvtJPKemlPD7x1VuSyEvsCxtRG5stVPUO5 Hn4gv/A+saB+5SJYBMKGbkflyoLzAb0VSH5TBrd+VOukkjmWy1wd7Xzw65NQU8uQJALl XRMr+EZ/ScY4JM2C0TzhVbnuFgIPW8nhMuUZqgK7zpXI86CEUgjOOBpiCdny9lmsLudM +4yyOO0SxfGvP++50HSKA9NGyGFuB9NxBveO6oKZO+c2ImNCZ1/68SJbz6LCiuUUQibr NJIdIbXbUuBav0xwI2dpdvycomMX8qnnMbhsAPk24liOZ2UcguM04D/WE7lf0iMN9dLa H+7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=bs9/1ejwylJHkX9lLyztDS6AGVtQQSqeMRcZmUtkK0o=; b=QfSUDk3DtaewuSt56CaTLZAyJxEipyBFh8mAsRBO45TAeRvAcLuvjlamkrfPjAUJme Ygu+cy8Z0WqOpFFwTKVC1dKjFeRf6nGorGWJlrzHTV7MwnprwmQxYko4E+2PaBylvSAq 7YJHd3sfBa0VZHITJx1OllVJc2Up5s/9u91+Z2qZwZEyP85In88qOcTRmhizi1h/RoKt Q+kXl2bzR1qSbzxMisdMCMO9mwDx05sO06j+DMiCxPqwqBBY89ME11K+T9G7bXQY3wbk 9CvlxL57DFSaTkC78+dA4TIpu5+4l32+pnTnJjEZpAg8Z86fR9Y4pN+ks+wuJ0Fml0O8 wzSg==
X-Gm-Message-State: ALQs6tD0dxktu2BISr0nODBmqGYysa/G0SuoSbaCnlN6Lsu9tRRhnRYQ dETgbhYnXtpoZIbWR8hE3UEt4y+4jz7tO/c3aaM=
X-Google-Smtp-Source: AIpwx4/PjLAfMErgApRYEbKxyXacBf7xrdI3838P8IOR4FUzA9GpKz87hxbnBdQq51ij5nM41z2VpkrNv7OJbomUNzE=
X-Received: by 2002:aca:ebd1:: with SMTP id j200-v6mr5403087oih.110.1523523917416;  Thu, 12 Apr 2018 02:05:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 12 Apr 2018 02:05:16 -0700 (PDT)
In-Reply-To: 
References:         <60955AE8-7637-4CC4-9FD8-56201685EE03@nokia.com>   
From: Martin Thomson 
Date: Thu, 12 Apr 2018 19:05:16 +1000
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Cc: Kazuho Oku , Praveen Balasubramanian ,  Ryan Hamilton , IETF QUIC WG ,  "Brian Trammell (IETF)" , Victor Vasiliev ,  "Fossati, Thomas (Nokia - GB/Cambridge)" 
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, 12 Apr 2018 09:05:20 -0000

On Thu, Apr 12, 2018 at 5:02 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen
 wrote:
> I=E2=80=99d say we either need a clean incremental PN stream per path, or=
 an
> encrypted PN that is not breakable.

The clean per-path packet number doesn't defend against "helpfulness"
of the nature I described.  Those problems exist if the signal exists
at all.


From nobody Thu Apr 12 03:52:22 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EC5126E01 for ; Thu, 12 Apr 2018 03:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tJgcPmYClLF for ; Thu, 12 Apr 2018 03:52:19 -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 CB3ED126D85 for ; Thu, 12 Apr 2018 03:52:18 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id b5-v6so6736412itj.1 for ; Thu, 12 Apr 2018 03:52:18 -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=hCx1mjE28Z7mQSst/ZitJr2tnXv0QkJVJ15rG8O/w/8=; b=upTjZJwmOtkkZHvFqlgJYIOIgH6MLXEplqo2PUQucpc6zrYf2oA13gvNdc2+qYw/+h GgInE93/c+Ok96zzoq7u1otvubT17HlpyOEJ7DBltsxNbUWPS9fSOyRcZCP7BQ1UQTnx 0BJod2PgpXF8OOtUdsrXBA371063Nxkloxt/8riFX7bfdhoC5rZx1MWI9DVEEsVgt5sh S9lOPh/9bqYeue0NANe0yau9qKZ7g9lBb+3N25oeBwMSn+70bRJApehYVg/XpbGVRo0A 22jwfmatF9vvrtFJfavYmUn5NSUuOeAzJSLzzof+CtzFzmzUIBqL14B6Ptfx3t0HnSim kBsw==
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=hCx1mjE28Z7mQSst/ZitJr2tnXv0QkJVJ15rG8O/w/8=; b=K9jXbGvXCgqtiLyP42nkNtYJmR6uMTBNrMuG0E6TfpKR5zC5nm+/QqzLfKiVpIRCBl PtY4a8ew1HEFY4fS9C/AUuxUt+bJEzciVuWVdxC6hO9SEdvxXt3iGn6YV5crRcYsEgC7 4PlXAefSxor+w20CJoNBvUYzYg08RePAjPQ7Sm1QwUW9wZKBWVvbejP47GmRe5ZMBUDu ffIifzSRwJGyx7qzrO5Fl8AzKPrCcoitt3F+OwOanYrjAMcC2eKCm8g/aArlggQA9X7i j1cwUr3phcckZIDifmWUY76xyxdjshy3pQCZbLUvIhV8TheNa2a5i1t2/kJzrdw7lpou H7Cg==
X-Gm-Message-State: ALQs6tCX5s8Qj0xaojBmYWtHr54ybYtH6LusT0PMPqQkvz02Jo6wFjCl WTX1NHeMqxFDTlKaRsSa8SG+gMaAWHxuOk40O5Y=
X-Google-Smtp-Source: AIpwx48/zWB2Nf1okTij4t+nkVVy6yCFyDUP5ejmydd7KghGGdttsLLOgJoAumNsAWrB+xfOo0YrVVdLmobCAlFKpuY=
X-Received: by 2002:a24:e085:: with SMTP id c127-v6mr371295ith.25.1523530338208;  Thu, 12 Apr 2018 03:52:18 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 12 Apr 2018 03:52:17 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:         <60955AE8-7637-4CC4-9FD8-56201685EE03@nokia.com>    
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 12 Apr 2018 03:52:17 -0700
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Martin Thomson 
Cc: IETF QUIC WG , "Brian Trammell (IETF)" ,  Ryan Hamilton , Victor Vasiliev ,  "Fossati, Thomas (Nokia - GB/Cambridge)" , Kazuho Oku ,  Praveen Balasubramanian 
Content-Type: multipart/alternative; boundary="0000000000009d10b60569a48c0e"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 12 Apr 2018 10:52:20 -0000

--0000000000009d10b60569a48c0e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On 12 April 2018 at 11.05.17, Martin Thomson (martin.thomson@gmail.com)
wrote:

The clean per-path packet number doesn't defend against "helpfulness"
of the nature I described. Those problems exist if the signal exists
at all.


True. But these are still the options as I see it. Half-baked obfuscation
will only make it worse.

There is the holy grail of fast 32-bit permutations that can be used
directly as IV, which are sufficiently safe wrt. privacy, and where the
permutation does not depend on the packet content.

The following function is useful to disperse a low-quality hash - it is a
perfect permutation. Unfortunately, or fortunately, it can be trivially
reversed - see stack overflow article. There are also 64-bit variants, and
it could also be just a single multiplication. Martin T. already hinted at
something similar in an earlier mail.

The benefit of this over lower octet permutation is that stupid
middle-boxes don=E2=80=99t have a chance, while slightly intelligent middle=
-boxes
can use it is loss / reordering signal, and QUIC hardware offload
decryptors can use the value unmodified as IV rather than computing the
inverse first. From a privacy perspective this is no better than plain
sequential numbers.

But it still serves as fingerprinting a given QUIC version. I=E2=80=99d say=
 full
encryption or clear text sequential are the only viable choices.



    /* http://stackoverflow.com/a/12996028 */

    uint32_t x =3D type_hash;


    x =3D ((x >> 16) ^ x) * 0x45d9f3bUL;

    x =3D ((x >> 16) ^ x) * 0x45d9f3bUL;

    x =3D ((x >> 16) ^ x);

    return x;

--0000000000009d10b60569a48c0e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

On 12 April 2018 at 11.05.17, Martin Thomson (martin.thomson@gmail.com) wrote:
 
The clean per-path packet number doesn't defend=
 against "helpfulness"=C2=
=A0
of the nature I described. Those problems exist if=
 the signal exists=C2=A0
at all.

True. =
But these are still the options as I see it. Half-baked obfuscation will on=
ly make it worse.
There is the holy grail of fast 32-bit permutations=
 that can be used directly as IV, which are sufficiently safe wrt. privacy,=
 and where the permutation does not depend on the packet content.
The=
 following function is useful to disperse a low-quality hash - it is a perf=
ect permutation. Unfortunately, or fortunately, it can be trivially reverse=
d - see stack overflow article. There are also 64-bit variants, and it coul=
d also be just a single multiplication. Martin T. already hinted at somethi=
ng similar in an earlier mail.
The benefit of this over lower octet p=
ermutation is that stupid middle-boxes don=E2=80=99t have a chance, while s=
lightly intelligent middle-boxes can use it is loss / reordering signal, an=
d QUIC hardware offload decryptors can use the value unmodified as IV rathe=
r than computing the inverse first. From a privacy perspective this is no b=
etter than plain sequential numbers.
But it still serves as fingerpri=
nting a given QUIC version. I=E2=80=99d say full encryption or clear text s=
equential are the only viable choices.


=C2=A0 =C2=A0 /* http://stackoverflow.com/a/12996028 */
=C2=A0 =C2=A0 uint32_t x =3D t=
ype_hash;

=

=C2=A0 =C2=A0 x =3D ((x >=
;> 16) ^ x) * 0x45d9f3bUL;
=C2=A0 =C2=A0 x =3D ((x >> 16) ^ x) * 0x45d9f3bUL;
=C2=A0 =C2=A0 x =3D ((x >&g=
t; 16) ^ x);
=C2=A0 =
=C2=A0 return x;


--0000000000009d10b60569a48c0e--


From nobody Thu Apr 12 06:39:40 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4C712741D for ; Thu, 12 Apr 2018 06:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cp9S5YYQvY6e for ; Thu, 12 Apr 2018 06:39:37 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB0A127136 for ; Thu, 12 Apr 2018 06:39:36 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3CDYosQ030135; Thu, 12 Apr 2018 14:39:25 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=pDJpqZT+kDFpJMXj0olrfv+x4+nK1Snp82PJqVvRV5Y=; b=pHdXhDXCTk11NIL6zFYAS4epgDLvQS/KKmIMe/00u+kKP6Kll6yX0Ierhlm6e56uLSeT f372SokgUrkjJc2Z/aNnGZPDnfo8k8acEra+5daMsn4+kp2Owr7doSdU+aUbZp6E8dOM zojf0dSqab/08dT9320THNLk5WsV6xSCa5WNZ1S2wrOxp8Vxzoxcfush9xy4Gyvq3W9q uIDIIm1U2UiWCffAFNHZQpBbF0xsBNwvqJWmfhKJKMGyB3Jwip2bhbFMFzY+cwJoPfoq 14Si175L2qB4lgqc2srtUcMo7ntP6fmoLJudage9NKeb0fC0SoQi0HUY5dh5xW+rV1b4 gQ== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2h9stc1vk2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Apr 2018 14:39:25 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3CDZvtc029942; Thu, 12 Apr 2018 09:39:24 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2h78pj20up-1; Thu, 12 Apr 2018 09:39:24 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id C4B4C82CA1; Thu, 12 Apr 2018 13:39:24 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1f6cRf-0007iA-QE; Thu, 12 Apr 2018 08:39:23 -0500
Date: Thu, 12 Apr 2018 08:39:23 -0500
From: Benjamin Kaduk 
To: "Roni Even (A)" 
Cc: Christian Huitema , Spencer Dawkins at IETF , "quic@ietf.org" 
Subject: Re: Migration privacy and NAT rebinding
Message-ID: <20180412133923.GC20782@akamai.com>
References: <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>    <46f22a3d-b2ad-8c1a-9149-7d69dcde003c@huitema.net> <6E58094ECC8D8344914996DAD28F1CCD8728E1@DGGEMM506-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8728E1@DGGEMM506-MBX.china.huawei.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-12_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=773 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804120136
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-12_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=737 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804120135
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 12 Apr 2018 13:39:38 -0000

On Thu, Apr 12, 2018 at 06:16:39AM +0000, Roni Even (A) wrote:
> Hi Christian,
> On the voluntary migration, what about when walking from the parking lot towards the house, will connect to Wifi and the IP address of the home router will probably be the same as when going out.  There will suddenly be a lot of traffic from the home router (not only QUIC), for example synchronizing all applications that were defined to download only on wifi. The migration will be easy to spot in this case.

I'm not sure what point you're trying to make, here.  A flurry of traffic from
a residential IP address would probably indicate that a device has returned to
that network after an absence, sure, but how does the attacker know whether
that device was asleep while it was gone, or had some other (cell) connectivity?
And how does this flurry of activity help the attacker correlate the (connections
of the) device returning to the wifi network with the (connections of the) device
on some other network?

-Ben


From nobody Thu Apr 12 07:00:59 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A1912D77E for ; Thu, 12 Apr 2018 07:00: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6CC1Y59_wkaS for ; Thu, 12 Apr 2018 07:00:49 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (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 E0D0412D775 for ; Thu, 12 Apr 2018 07:00:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1523541645; s=strato-dkim-0002; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Date:Message-ID: From:References:To:Subject:X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject: Sender; bh=z8KvH3zLvw2pHuVZdRas5ikIdCdlHY0xHy6YaP8EIhA=; b=lBbaX9LoCYMfOAlN4uUOV070kTPGk53tKZvKVer8GuPeskSrwfscA6LyI9L/oCfXV1 2rfE0dwRn9kZyMS2eZhoq4erahjuL1VHqUTV34jW4CUIYQmFk3k9bxkSO4OXS4WCxD3L YEqgAOuyQfVruxIVSkzpk35uZ6OjrcJ1KyKh0oeK0oNwBBqMDjTsJnLSyGiS1xjaaLTr mUT5wQ9PqSnDxxAfM2xo8udJnHfRtxkLeI9GoRF9dvsdfbBch+SFjVDKwcCBIURSBgcW Djz/f4vkzAY1aCuXGTrtrUVQvV8+nPSYWQkY5Sgs7QDRSbpqaMDVdR3Jc5JuKtTyOzSh svqQ==
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1YaZ2OgvlDQIHaS9kr0=
X-RZG-CLASS-ID: mo00
Received: from [10.33.22.7] by smtp.strato.de (RZmta 43.2 DYNA|AUTH) with ESMTPSA id 302523u3CE0j6Zh (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, 12 Apr 2018 16:00:45 +0200 (CEST)
Subject: Re: Migration privacy and NAT rebinding
To: quic@ietf.org
References: <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>    <46f22a3d-b2ad-8c1a-9149-7d69dcde003c@huitema.net> <6E58094ECC8D8344914996DAD28F1CCD8728E1@DGGEMM506-MBX.china.huawei.com> <20180412133923.GC20782@akamai.com>
From: Roland Zink 
Message-ID: 
Date: Thu, 12 Apr 2018 16:00:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180412133923.GC20782@akamai.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, 12 Apr 2018 14:00:57 -0000

Am 12.04.2018 um 15:39 schrieb Benjamin Kaduk:
> On Thu, Apr 12, 2018 at 06:16:39AM +0000, Roni Even (A) wrote:
>> Hi Christian,
>> On the voluntary migration, what about when walking from the parking lot towards the house, will connect to Wifi and the IP address of the home router will probably be the same as when going out.  There will suddenly be a lot of traffic from the home router (not only QUIC), for example synchronizing all applications that were defined to download only on wifi. The migration will be easy to spot in this case.
> I'm not sure what point you're trying to make, here.  A flurry of traffic from
> a residential IP address would probably indicate that a device has returned to
> that network after an absence, sure, but how does the attacker know whether
> that device was asleep while it was gone, or had some other (cell) connectivity?
Assuming there is a difference between new connections and migrating 
connections then you can discover if a device was asleep if most of the 
connections are newly established. If you have enough power then you may 
even get the position / cell of the device, e.g. you may also be able to 
match the location.

> And how does this flurry of activity help the attacker correlate the (connections
> of the) device returning to the wifi network with the (connections of the) device
> on some other network?
To match the previous connections you have the time and the destination 
address / port. If there are two to the same server then you probably 
can't distinguish between them immediately. The set of open connections 
is probably a good fingerprint of the device.

> -Ben
>
Roland


From nobody Thu Apr 12 09:16:25 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3292124BFA for ; Thu, 12 Apr 2018 09:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 FuE8pK3pOVkg for ; Thu, 12 Apr 2018 09:16:22 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0092.outbound.protection.outlook.com [104.47.34.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3362A127010 for ; Thu, 12 Apr 2018 09:16: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=ICj3SSGv0AmibW/kw6KO62WWc2gQWOwmfSJMwteGgXE=; b=OHH/3FJQ8o3SKMWCsfcT60esSt500PVRBnbX5gTVUdUiVVtENxO/pj0tP47QTSgietgHtHflQIUfMtKgiP9FubQoapwnqiGEINAQwk1zPg40QWcKWZW1ctOVPy9hW67KIsG5AsppHWmqycwqYKH+jkPlJA94DksZ1t4W/EU+2fk=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0118.namprd21.prod.outlook.com (10.173.189.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Thu, 12 Apr 2018 16:16:20 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.007; Thu, 12 Apr 2018 16:16:20 +0000
From: Praveen Balasubramanian 
To: Martin Thomson , Kazuho Oku 
CC: "Fossati, Thomas (Nokia - GB/Cambridge)" , Victor Vasiliev , "Brian Trammell (IETF)" , IETF QUIC WG , Ryan Hamilton 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAuyyQAACzPhAAAC9p6AAAKcBQAAIR0fgAABLEIAAB0ugpA=
Date: Thu, 12 Apr 2018 16:16:20 +0000
Message-ID: 
References:         <60955AE8-7637-4CC4-9FD8-56201685EE03@nokia.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0118; 7:tE7/5B2RjHy/PgD88djly/LdQ0sPDcPfDWJzx/leWmpTG2nHY/Fgq8nWO7zX32djKqNbpxZ2xSF6gNVR9ajy9UaYcbnq+78Fw/KMxOtbMqogHxIv8V7UTahQOgqgSCoAYHqZzcHrlHtffQbWP+YUDdzFpA35XKO6yYYvzkr/M+pBh3bSoSK0oSQG+uGZpVNvWX856mgOc7wL+Ty6HlSHKHUmBeWEqxtJfF1UyEtttgqRRCg5Toz8o/PUWQ2GgrLF; 20:SJOZ8DfvG6bMrhfQ2IwyvYX50zGR6ZSGoee/xDS99dMM+pcaP410j4ly91ypFIrMh53GELDDH2/ZDXuRNsE+iF89p1JTD3YyaJon1eSBJ1/T21lfR7eRuj5eBnRbh1vzgz2rwzPdVrTK/U0qkQOQIo0Jdplc2uy8ljm3p+2NO2c=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(2017052603328)(7193020); SRVR:CY4PR21MB0118; 
x-ms-traffictypediagnostic: CY4PR21MB0118:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(82608151540597)(85827821059158)(211936372134217)(153496737603132);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231225)(944501343)(52105095)(3002001)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR21MB0118; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0118; 
x-forefront-prvs: 06400060E1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39380400002)(346002)(396003)(39860400002)(366004)(13464003)(189003)(199004)(39060400002)(316002)(8676002)(81156014)(81166006)(74316002)(10090500001)(4326008)(5250100002)(22452003)(93886005)(25786009)(55016002)(76176011)(33656002)(7696005)(7736002)(305945005)(10290500003)(106356001)(105586002)(14454004)(446003)(3660700001)(8936002)(476003)(5660300001)(46003)(229853002)(11346002)(486006)(6506007)(68736007)(53936002)(53546011)(8656006)(59450400001)(3280700002)(2900100001)(6436002)(102836004)(8990500004)(186003)(9686003)(6246003)(97736004)(86612001)(478600001)(110136005)(86362001)(99286004)(2906002)(6116002)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0118; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: c1816178-eb34-4841-813a-08d5a090ba80
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c1816178-eb34-4841-813a-08d5a090ba80
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2018 16:16:20.6730 (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: Thu, 12 Apr 2018 16:16:25 -0000

SSBhZ3JlZSB0aGF0IHRoZXJlIGlzIGEgcG90ZW50aWFsIHByb2JsZW0gd2l0aCBtb25vdG9uaWMg
aW5jcmVhc2UuIE1ha2luZyBpdCBhIG5vbi1tb25vdG9uaWMgaW5jcmVhc2UgaG93ZXZlciBkb2Vz
buKAmXQgaGF2ZSB0byBnbyBhbGwgdGhlIHdheSB0byBlbmNyeXB0aW9uLiBGb3IgZXhhbXBsZSB3
aXRoIHRoZSBzaHVmZmxlIHNjaGVtZSwgUE4gY2Fubm90IGJlIHRyZWF0ZWQgYXMgYSBzZXF1ZW5j
ZSBudW1iZXIgc2luY2UgbWlkZGxlYm94IGRvZXMgbm90IGtub3cgdGhlIG9mZnNldHMgaW4gdGhl
IGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBoZWFkZXIuIA0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFp
bC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMSwgMjAxOCA3OjE4IFBNDQpUbzogS2F6
dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbT4NCkNjOiBGb3NzYXRpLCBUaG9tYXMgKE5va2lh
IC0gR0IvQ2FtYnJpZGdlKSA8dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tPjsgVmljdG9yIFZhc2ls
aWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBCcmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJh
bW1lbGwuY2g+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBSeWFuIEhhbWlsdG9uIDxy
Y2hAZ29vZ2xlLmNvbT47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQu
Y29tPg0KU3ViamVjdDogUmU6IFNpbXBsZSB0cmFuc2Zvcm0gZm9yIGltcHJvdmluZyBQTiBvc3Np
ZmljYXRpb24gcHJldmVudGlvbg0KDQpPbiBUaHUsIEFwciAxMiwgMjAxOCBhdCAxMTo0NCBBTSwg
S2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbT4gd3JvdGU6DQo+PiBJJ20gbm90IGF3YXJl
IG9mIGFueSB0ZWNobmlxdWUgdGhhdCB1c2VzIGFuIHVudGFtcGVyYWJsZSBQTiB0byANCj4+IGFj
aGlldmUgYmFuZHdpZHRoIG9wdGltaXNhdGlvbi4NCj4NCj4gV2VsbCwgYXNzdW1pbmcgdGhhdCB0
aGUgbWFqb3JpdHkgb2YgdGhlIHNlbmRlcnMgd2lsbCB1c2UgUE4gaW4gYSANCj4gbW9ub3Rvbm91
c2x5IGluY3JlYXNpbmcgbWFubmVyIGFuZCB0aGF0IHNraXBzIHdpbGwgYmUgaW5zZXJ0ZWQgDQo+
IGluZnJlcXVlbnRseSwgYW5kIGFzc3VtaW5nIHRoYXQgc3VjaCBzZW5kZXJzIHdpbGwgaW1wbGVt
ZW50IEFDSy1iYXNlZCANCj4gbG9zcyBkZXRlY3Rpb24sIEkgd291bGQgYW50aWNpcGF0ZSB0aGF0
IGl0IHdvdWxkIG1ha2Ugc2Vuc2UgZm9yIGEgDQo+IG1pZGRsZWJveCB0byByZW9yZGVyIHRoZSBw
YWNrZXQgYnkgdGhlIFBOIChieSBidWZmZXJpbmcgb3V0LW9mLW9yZGVyIA0KPiBwYWNrZXRzIGZv
ciB1cCB0byBzb21lIHNob3J0IGFtb3VudCBvZiB0aW1lIChlLmcuLCAxLzE2IFJUVCkpLCBzaW5j
ZSANCj4gaXQgd291bGQgcmVkdWNlIHRoZSBwcm9iYWJpbGl0eSBvZiBmYXN0IHJldHJhbnNtaXRz
IHRoYXQgY291bGQgYmUgDQo+IHNwdXJpb3VzLg0KDQpXaGlsZSBpdCBtaWdodCBzZWVtIGxpa2Ug
dGhlIGxhdGVuY3kgaGl0IGhlcmUgd291bGQgYmUgbm90aWNlYWJsZSBhbmQgdGh1cyB0aGlzIG9w
dGltaXphdGlvbiB3b3VsZCBiZSBvYnZpb3VzbHkgdW5kZXNpcmFibGUsIGNvbnNpZGVyIGEgbmV0
d29yayBvcGVyYXRvciB0aGF0IGhhcyB0byB0cmFkZSBvZmYgYmV0d2VlbiBwZWFrIGhvdXIgdXRp
bGl6YXRpb24gYW5kIGxhdGVuY3kuICBJZiB0aGlzIGxpdHRsZSBiaXQgb2YgSG9MQiBnZXRzIHRo
ZWlyIGVmZmljaWVuY3kgbnVtYmVycyB1cCBieSByZWR1Y2luZyByZXRyYW5zbWlzc2lvbnMsIG1h
eWJlIHRoZXkgd2lsbCBjb25zaWRlciB0aGF0IGEgZ29vZCB0cmFkZS4NCg0KVGhlIG90aGVyIHBv
aW50IGlzIHRoYXQgaW4gVExTLCB3ZSBoYXZlIGRpcmVjdCBleHBlcmllbmNlIHdpdGggbWlkZGxl
Ym94ZXMgInBvbGljaW5nIiB0aGUgcHJvdG9jb2wuICBUaGF0IGlzLCBpZiBpdCBkb2Vzbid0IGxv
b2sgbGlrZSBUTFMsIHRoZSBmbG93IGlzIHN0b3BwZWQuICBXZSBrbm93IGZvciBzdXJlIHRoYXQg
dGhpcyBpbmNsdWRlcyBjaGVja2luZyB0aGUgcmVjb3JkIGhlYWRlciwgd2hpY2ggbWVhbnMgdGhh
dCBUTFMgMS4zIHVzZXMgMyBtb3JlIG9jdGV0cyBwZXIgcmVjb3JkIHRoYW4gaXQgbmVlZHMgdG8u
ICBJdCBhbHNvIGluY2x1ZGVzIGEgd2hvbGUgYnVuY2ggb2YgaGFuZHNoYWtlIGZpZWxkcyBhcyB3
ZWxsLCB3aGljaCB3ZSBoYXZlIGxlc3MgaW5mb3JtYXRpb24gb24gYXMgYSB3aG9sZS4gIEV2ZW4g
aWYgd2UgZGlzY291bnQgdGhlIFFVSUM9PTcgZmlhc2NvIGFzIGFiZXJyYW50LCB0aGlzIGlzIGEg
Y29zdCBJJ2QgcmF0aGVyIG5vdCBoYXZlIHRvIHdvcnJ5IGFib3V0IHBheWluZyBzb21lIHRpbWUg
aW4gdGhlIGZ1dHVyZS4NCg0KU28sIGZyb20gbXkgcGVyc3BlY3RpdmUsIGluIGFkZGl0aW9uIHRv
IHRoZSBwcml2YWN5ICJpbnRhbmdpYmxlcyIgdGhhdCBDaHJpc3RpYW4gYW5kIFN0ZXBoZW4gaGF2
ZSB0YWxrZWQgYWJvdXQsIHRoZXJlIGlzIGEgcmVhbCBkZWZlbnNpdmUgdmFsdWUgaW4gdGhpcy4g
IFRoYXQncyB3aXRob3V0IGNvbnNpZGVyaW5nIHRoYXQgd2UndmUgYWxyZWFkeSBkZWNpZGVkIHRo
YXQgdm9sdW50YXJ5IG1pZ3JhdGlvbiBpcyBhIGZlYXR1cmUgd2UgbmVlZCB0byBoYXZlLg0K


From nobody Thu Apr 12 09:22:01 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAF412DA01 for ; Thu, 12 Apr 2018 09:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdXrqka5D3hl for ; Thu, 12 Apr 2018 09:21:59 -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 0E64012D96B for ; Thu, 12 Apr 2018 09:21:59 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id q85-v6so7788526itc.0 for ; Thu, 12 Apr 2018 09:21:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=k5Dmtv4+VP4rqQIM4yhWf8TwxhIiY6JR0f7dwbq6FEU=; b=e5W05P2b+wEb21Yz+h8m427Dmn2DUin7MVSCvRYt2Y6OUzyJbuIiapQfc1lBLJqYFO doNl04YI2lx1kp0Dj2bR8Zm1lsZg8CsSuWnodLZwKlLLV4EKtlpUNxevVvG/rlQS4w6x SsEpcroqUd0pDBEOJhxLWcRlVMqRhSmYV+WIftc392XuThXL0GjM5/7Z9MVekEGej9De 3dM/GKp4BAF+IpUWe9vCqeZnpu505iDgPWX+gaUJaWn6/k8FyTIlwUFYfb5OY66xBNEE C4X1XSSxcYDGYHWWki1sqi7iml/oeOkCQtZxqkOAuAA9OlpIOGH37geLNgeTYYgCwEfx ggnA==
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=k5Dmtv4+VP4rqQIM4yhWf8TwxhIiY6JR0f7dwbq6FEU=; b=Yj7cbQHRc0RzNVnUtOjIzeZhZlfh67LhKxbgVYVB1eIZzct+p7/SuJxlyD8BcD4VyF +yGIHgMlL5NpDmm3tKtaX3D6O0UITH8N6DcY2wzYuhxTJV3aNqafjGb/1eh/Y3D2KCrd w+1VdENT859oRnrh8YpaT0C/9dVaL43GPLUaBegXUeUi5jxtO6xBxbLWPtDKWQDgWjo3 YaUIec5B/mnDobjB5oxiwryXpC3VCEYHGNkfikvBuWWcfl71LLi9GVYnnlGHyz21BpM6 7D9V1i3FUMMdm3XMgU9rPW1/xmtRAoz8tpXtw8M1UzaAZHb7EOrtiNofMClooqDnd+yB 4WwQ==
X-Gm-Message-State: ALQs6tAlCFK79eZEjuXTYlQ71st6DY5euGAIgGefQNFCMlLGcQz+GPH/ 0LtKGNcXqabk9rUwb3JbjOFvRfSbVGJTUMUmG8U=
X-Google-Smtp-Source: AIpwx4/KBGwcK8BaUAePAl2vRbCl5KclR2GF7LC7fWNTEaeo2yXoCLGRWvzg4y4+L5Iucfc0lkIGL9SW7tvsBm4QTQQ=
X-Received: by 2002:a24:e4f:: with SMTP id 76-v6mr1685373ite.80.1523550118389;  Thu, 12 Apr 2018 09:21:58 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 12 Apr 2018 09:21:57 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:         <60955AE8-7637-4CC4-9FD8-56201685EE03@nokia.com>     
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 12 Apr 2018 09:21:57 -0700
Message-ID: 
Subject: Re: Simple transform for improving PN ossification prevention
To: Martin Thomson 
Cc: IETF QUIC WG , "Brian Trammell (IETF)" ,  Ryan Hamilton , Victor Vasiliev ,  "Fossati, Thomas (Nokia - GB/Cambridge)" , Kazuho Oku ,  Praveen Balasubramanian 
Content-Type: multipart/alternative; boundary="0000000000009abc7e0569a927a1"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 12 Apr 2018 16:22:00 -0000

--0000000000009abc7e0569a927a1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It was pointed out to me that there is indeed an encryption scheme based on
a permutation such as the one I sent earlier modified so a key is xor=E2=80=
=99ed in
the mix. This makes 32-bit or 64-bit encryption is possible without
depending on packet content, and hence the encrypted result can be used as
IV directly.

It might not be hard enough to truly secure privacy, but balanced against
all other leaks it could be workable. The encrypted PN can be used as IV
directly.

This should be compared to doing just a few AES rounds encrypting the AEAD
tag and then xor that with PN. This is faster than the full 10 round and
most processors support single round AES in hardware these days. It is
likely just as fast as a 32-bit xor multiply scheme.

Both schemes only use the actual size of the PN.

The main difference between the two is that packet decryption with the AES
scheme cannot take place before PN has been decrypted while this is not the
case with 32-bit crypto. Likewise, encryption can start before the full
content is known(*) when using 32-bit crypto.

(*) with the new length field introduced, it is not possible to encrypt on
the fly - at least not the Authenticated Data part - but this only apply to
the initial handshake.


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


On 12 April 2018 at 12.52.17, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@g=
mail.com)
wrote:


On 12 April 2018 at 11.05.17, Martin Thomson (martin.thomson@gmail.com)
wrote:

The clean per-path packet number doesn't defend against "helpfulness"
of the nature I described. Those problems exist if the signal exists
at all.


True. But these are still the options as I see it. Half-baked obfuscation
will only make it worse.

There is the holy grail of fast 32-bit permutations that can be used
directly as IV, which are sufficiently safe wrt. privacy, and where the
permutation does not depend on the packet content.

The following function is useful to disperse a low-quality hash - it is a
perfect permutation. Unfortunately, or fortunately, it can be trivially
reversed - see stack overflow article. There are also 64-bit variants, and
it could also be just a single multiplication. Martin T. already hinted at
something similar in an earlier mail.

The benefit of this over lower octet permutation is that stupid
middle-boxes don=E2=80=99t have a chance, while slightly intelligent middle=
-boxes
can use it is loss / reordering signal, and QUIC hardware offload
decryptors can use the value unmodified as IV rather than computing the
inverse first. From a privacy perspective this is no better than plain
sequential numbers.

But it still serves as fingerprinting a given QUIC version. I=E2=80=99d say=
 full
encryption or clear text sequential are the only viable choices.



    /* http://stackoverflow.com/a/12996028 */

    uint32_t x =3D type_hash;


    x =3D ((x >> 16) ^ x) * 0x45d9f3bUL;

    x =3D ((x >> 16) ^ x) * 0x45d9f3bUL;

    x =3D ((x >> 16) ^ x);

    return x;

--0000000000009abc7e0569a927a1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
It was pointed out t=
o me that there is indeed an encryption scheme based on a permutation such =
as the one I sent earlier modified so a key is xor=E2=80=99ed in the mix. T=
his makes 32-bit or 64-bit encryption is possible without depending on pack=
et content, and hence the encrypted result can be used as IV directly.

It might not be hard enou=
gh to truly secure privacy, but balanced against all other leaks it could b=
e workable. The encrypted PN can be used as IV directly.

This should be compared to doing just a=
 few AES rounds encrypting the AEAD tag and then xor that with PN. This is =
faster than the full 10 round and most processors support single round AES =
in hardware these days. It is likely just as fast as a 32-bit xor multiply =
scheme.

<=
/div>
Both schemes =
only use the actual size of the PN.

The main difference between the two is that packet decryptio=
n with the AES scheme cannot take place before PN has been decrypted while =
this is not the case with 32-bit crypto. Likewise, encryption can start bef=
ore the full content is known(*) when using 32-bit crypto.

(*) with the new length field introdu=
ced, it is not possible to encrypt on the fly - at least not the Authentica=
ted Data part - but this only apply to the initial handshake.
 

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

 
On 1=
2 April 2018 at 12.52.17, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:
 














On 12 April 2018 at 11.05.17, Martin Thomson
(martin.thomson@gmail.com)
wrote:







The clean per-path packet number doesn't defend against
"helpfulness"=C2=A0<=
/span>



of the nature I described. Those problems exist if the signal
exists=C2=A0



at all.









True. But these are still the options as I see it. Half-baked
obfuscation will only make it worse.


There is the holy grail of fast 32-bit permutations that can be
used directly as IV, which are sufficiently safe wrt. privacy, and
where the permutation does not depend on the packet content.


The following function is useful to disperse a low-quality hash
- it is a perfect permutation. Unfortunately, or fortunately, it
can be trivially reversed - see stack overflow article. There are
also 64-bit variants, and it could also be just a single
multiplication. Martin T. already hinted at something similar in an
earlier mail.


The benefit of this over lower octet permutation is that stupid
middle-boxes don=E2=80=99t have a chance, while slightly intelligent
middle-boxes can use it is loss / reordering signal, and QUIC
hardware offload decryptors can use the value unmodified as IV
rather than computing the inverse first. From a privacy perspective
this is no better than plain sequential numbers.


But it still serves as fingerprinting a given QUIC version. I=E2=80=99d
say full encryption or clear text sequential are the only viable
choices.








=C2=A0 =C2=A0 /*
http://stackoverflow.com/a/=
12996028 */


=C2=A0 =C2=A0 uint32_t x
=3D type_hash;





=C2=A0 =C2=A0 x =3D ((x
>> 16) ^ x) * 0x45d9f3bUL;


=C2=A0 =C2=A0 x =3D ((x
>> 16) ^ x) * 0x45d9f3bUL;


=C2=A0 =C2=A0 x =3D ((x
>> 16) ^ x);


=C2=A0 =C2=A0 return
x;










--0000000000009abc7e0569a927a1--


From nobody Thu Apr 12 09:28:59 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16312D96B for ; Thu, 12 Apr 2018 09:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 un8hW1uzwWL6 for ; Thu, 12 Apr 2018 09:28:54 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0124.outbound.protection.outlook.com [104.47.36.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD931275FD for ; Thu, 12 Apr 2018 09:28:54 -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=wlaIQ9SU9u6nup3g9gdMR3SbD7xgM8k2iyZ0PeADomE=; b=kkHvVd7w3Lb6WMq8QhY3swfjrXLArL1x4n8JN4mBtjWqxw8CcZOWxublC8yp62h8JekhzOMi9YXDzMYdmWxhgwDOL3GrRHd1mZq5wFF16j6d08XrhxprhmfklK6WAeECiX6DOwWaP9zv6Pn/KvLLcV0BQnGw6xNZv4mQ51+ABJQ=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.2; Thu, 12 Apr 2018 16:28:52 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0696.007; Thu, 12 Apr 2018 16:28:52 +0000
From: Praveen Balasubramanian 
To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Martin Thomson 
CC: IETF QUIC WG , "Brian Trammell (IETF)" ,  Ryan Hamilton , Victor Vasiliev , "Fossati, Thomas (Nokia - GB/Cambridge)" , Kazuho Oku 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAuyyQAACzPhAAAC9p6AAAKcBQAAIR0fgAABLEIAAAn14wAABEW/AAADvM2AAAsF2kA=
Date: Thu, 12 Apr 2018 16:28:51 +0000
Message-ID: 
References:         <60955AE8-7637-4CC4-9FD8-56201685EE03@nokia.com>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:8::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0630; 7:B8UC1C9OKy6qvuKrca3BQNpIHCYoDTm7p26MM/LTCQKq1ZseJ5srXo0kjPRLloVNBLXHc+Vmyre5GiQsbNiqoX7J3ZjL+eNKeWMlnIwbcgZ2fJsIjERmJUcSyqOiiPq9f4gwMK7jHJIBGyQeu599fJ6koMLA1Zmn6pSW2XLSssZT4YFFH2QnJY1g6RS+MoYaqIw3/Rh4hr6qUdWq7+j06d7TIilPDvf2VzvNSslYcudwDfyjHzRkXsgiDh1foQYm; 20:eK6dP5WmnYYBr9R9dkvt7FVBM5T9np3q0Ee4gYniMzErf8vpGWDWMr3LkheUHsOeTOfEqgNs0rhAw3C7n+nWJlGd5+buU7rOaz+AaQvjyoDyaRzGaFwK3FsS49gxB98q1cUeZSyeu7gri/W8CRgkcIc2yb9TeTRLKY4zSx+rkxI=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0630; 
x-ms-traffictypediagnostic: CY4PR21MB0630:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(189930954265078)(82608151540597)(85827821059158)(15185016700835)(211936372134217)(153496737603132)(219752817060721);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3231225)(944501343)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR21MB0630; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0630; 
x-forefront-prvs: 06400060E1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39380400002)(39860400002)(376002)(346002)(199004)(189003)(476003)(606006)(7736002)(10090500001)(446003)(11346002)(110136005)(74316002)(8990500004)(54906003)(86362001)(2900100001)(46003)(22452003)(55016002)(53936002)(39060400002)(93886005)(316002)(14454004)(236005)(54896002)(5250100002)(6246003)(486006)(6306002)(9686003)(53376002)(229853002)(10290500003)(86612001)(790700001)(6436002)(7696005)(105586002)(3280700002)(76176011)(3660700001)(6116002)(25786009)(8656006)(2906002)(478600001)(97736004)(186003)(68736007)(5660300001)(33656002)(99286004)(4326008)(81156014)(53546011)(8676002)(102836004)(6506007)(81166006)(106356001)(8936002)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0630; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
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_CY4PR21MB06309EAC254A087F5D3304B0B6BC0CY4PR21MB0630namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 208e2742-eadb-4fe8-3589-08d5a0927a56
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 208e2742-eadb-4fe8-3589-08d5a0927a56
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2018 16:28:52.0307 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0630
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 12 Apr 2018 16:28:57 -0000

--_000_CY4PR21MB06309EAC254A087F5D3304B0B6BC0CY4PR21MB0630namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UmUuICMxMDc5LCBmb2xsb3dpbmcgc2VlbXMgbGlrZSBhIHdheSBmb3J3YXJkIHNvIHdlIGdldCB0
byBkbyBzb21lIGltcGxlbWVudGF0aW9ucyBhbmQgZ2V0IGRhdGE6DQoNCiAgMS4gIFBOIHRyYW5z
Zm9ybSBpcyBuZWdvdGlhdGVkIHVzaW5nIHRyYW5zcG9ydCBwYXJhbXMuDQogIDIuICBGb2xsb3dp
bmcgUE4gdHJhbnNmb3JtcyBhcmUgc3VwcG9ydGVkOg0KICAgICAqICAgUE5FDQoNCkNvbm5lY3Rp
b25zIGV4cGVjdGluZyB0byB1c2UgbXVsdGlwbGUgcGF0aHMgZHVlIHRvIGdyYXR1aXRvdXMvdm9s
dW50YXJ5IG1pZ3JhdGlvbiBNVVNUIG5lZ290aWF0ZSBhbmQgdXNlIFBORSB0cmFuc2Zvcm0uIFNl
ZSBpc3N1ZSAxMjcxIHdoZXJlIG9wdGlvbnMgYXJlIGJlaW5nIGRpc2N1c3NlZCBvbiBob3cgbWln
cmF0aW9uIGNvdWxkIGJlIG5lZ290aWF0ZWQuDQoNClJldmlzaXQgdGhpcyBzb2x1dGlvbiBmb3Ig
cHJvcGVyIG11bHRpLXBhdGggYWZ0ZXIgZGVzaWduaW5nIG11bHRpcGxlIFBOIHNwYWNlcy4gSSBh
bSBmaW5lIGlmIHRoaXMgaXMgZG9uZSBmb3IgVjIuDQoNCiAgICAgKiAgIExvdyBjb3N0IG9zc2lm
aWNhdGlvbiBwcmV2ZW50aW9uIHRyYW5zZm9ybSAobGlrZSBzaHVmZmxlKS4NCg0KRm9yIGNvbm5l
Y3Rpb25zIG9uIHRoZSBJbnRlcm5ldCBvbiBzaW5nbGUgcGF0aCByZXF1aXJlIHRoZW0gdG8gbmVn
b3RpYXRlIHRoaXMgdHJhbnNmb3JtLiBFdmVuIGJldHRlciBpZiB3ZSBmaW5kIGFub3RoZXIgbG93
IGNvc3Qgc2NoZW1lIHdpdGggYmV0dGVyIHByb3BlcnRpZXMgYmVmb3JlIHdlIHNoaXAgVjEuDQoN
CiAgICAgKiAgIE5vLW9wIChjdXJyZW50IGRyYWZ0KQ0KDQpGb3IgaW50cmEtZGF0YWNlbnRlciBv
ciBzaW5nbGUgZG9tYWluIHByaXZhdGUgbmV0d29yayBzY2VuYXJpb3MgYWxsb3cgdXNhZ2Ugb2Yg
dGhlIG5vLW9wIHRyYW5zZm9ybS4NCg0KSWYgc2VydmVyIGZhaWxzIHRvIG5lZ290aWF0ZSBQTkUg
YW5kIHN1cHBsaWVzIG11bHRpcGxlIGNvbm5lY3Rpb24gSURzIGZvciBtaWdyYXRpb24sIGNsaWVu
dCBmYWlsIHRoZSBjb25uZWN0aW9uLg0KSWYgdGhlIHNlcnZlciBmYWlscyB0byBuZWdvdGlhdGUg
YSBsb3cgY29zdCB0cmFuc2Zvcm0gb24gdGhlIEludGVybmV0LCBjbGllbnQgZmFpbHMgdGhlIGNv
bm5lY3Rpb24uDQoNClBsZWFzZSBub3RlIHRoYXQgc2VydmVycyBhcmUgZnJlZSB0byBwaWNrIFBO
RSBhbGwgdGhlIHRpbWUuIFRoaXMgYWxsb3dzIHNlcnZlciBkZXBsb3ltZW50cyB3aGljaCBoYXZl
IG5vIHBlcmZvcm1hbmNlIGNvbmNlcm4gdG8gYWx3YXlzIHVzZSBQTkUuIEkgZG8gaGF2ZSBzb21l
IGJhdHRlcnkgbGlmZSBjb25jZXJucyBvbiBjbGllbnQgc2lkZSwgYnV0IEkgZG8gdGhpbmsgdGhl
IG1ham9yIHBlcmYgY29uY2VybiBpcyBvbiBzZXJ2ZXIgc2lkZS4NCg0KSWYgdGhlIGRlcGxveW1l
bnRzIHVzaW5nIGxvdyBjb3N0IHRyYW5zZm9ybSBoaXQgbWlkZGxlYm94IGlzc3VlcyB0aGV5IHdp
bGwgc3VmZmVyIGFuZCBwYXkgdGhlIGNvc3QgdG8gZG8gUE5FLg0KDQpGcm9tOiBNaWtrZWwgRmFo
bsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86bWlra2VsZmpAZ21haWwuY29tXQ0KU2VudDogVGh1cnNk
YXksIEFwcmlsIDEyLCAyMDE4IDM6NTIgQU0NClRvOiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRo
b21zb25AZ21haWwuY29tPg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IEJyaWFu
IFRyYW1tZWxsIChJRVRGKSA8aWV0ZkB0cmFtbWVsbC5jaD47IFJ5YW4gSGFtaWx0b24gPHJjaEBn
b29nbGUuY29tPjsgVmljdG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBGb3NzYXRp
LCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlKSA8dGhvbWFzLmZvc3NhdGlAbm9raWEuY29t
PjsgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbT47IFByYXZlZW4gQmFsYXN1YnJhbWFu
aWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPg0KU3ViamVjdDogUmU6IFNpbXBsZSB0cmFuc2Zvcm0g
Zm9yIGltcHJvdmluZyBQTiBvc3NpZmljYXRpb24gcHJldmVudGlvbg0KDQoNCg0KT24gMTIgQXBy
aWwgMjAxOCBhdCAxMS4wNS4xNywgTWFydGluIFRob21zb24gKG1hcnRpbi50aG9tc29uQGdtYWls
LmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPikgd3JvdGU6DQpUaGUgY2xlYW4g
cGVyLXBhdGggcGFja2V0IG51bWJlciBkb2Vzbid0IGRlZmVuZCBhZ2FpbnN0ICJoZWxwZnVsbmVz
cyINCm9mIHRoZSBuYXR1cmUgSSBkZXNjcmliZWQuIFRob3NlIHByb2JsZW1zIGV4aXN0IGlmIHRo
ZSBzaWduYWwgZXhpc3RzDQphdCBhbGwuDQoNCg0KDQpUcnVlLiBCdXQgdGhlc2UgYXJlIHN0aWxs
IHRoZSBvcHRpb25zIGFzIEkgc2VlIGl0LiBIYWxmLWJha2VkIG9iZnVzY2F0aW9uIHdpbGwgb25s
eSBtYWtlIGl0IHdvcnNlLg0KDQpUaGVyZSBpcyB0aGUgaG9seSBncmFpbCBvZiBmYXN0IDMyLWJp
dCBwZXJtdXRhdGlvbnMgdGhhdCBjYW4gYmUgdXNlZCBkaXJlY3RseSBhcyBJViwgd2hpY2ggYXJl
IHN1ZmZpY2llbnRseSBzYWZlIHdydC4gcHJpdmFjeSwgYW5kIHdoZXJlIHRoZSBwZXJtdXRhdGlv
biBkb2VzIG5vdCBkZXBlbmQgb24gdGhlIHBhY2tldCBjb250ZW50Lg0KDQpUaGUgZm9sbG93aW5n
IGZ1bmN0aW9uIGlzIHVzZWZ1bCB0byBkaXNwZXJzZSBhIGxvdy1xdWFsaXR5IGhhc2ggLSBpdCBp
cyBhIHBlcmZlY3QgcGVybXV0YXRpb24uIFVuZm9ydHVuYXRlbHksIG9yIGZvcnR1bmF0ZWx5LCBp
dCBjYW4gYmUgdHJpdmlhbGx5IHJldmVyc2VkIC0gc2VlIHN0YWNrIG92ZXJmbG93IGFydGljbGUu
IFRoZXJlIGFyZSBhbHNvIDY0LWJpdCB2YXJpYW50cywgYW5kIGl0IGNvdWxkIGFsc28gYmUganVz
dCBhIHNpbmdsZSBtdWx0aXBsaWNhdGlvbi4gTWFydGluIFQuIGFscmVhZHkgaGludGVkIGF0IHNv
bWV0aGluZyBzaW1pbGFyIGluIGFuIGVhcmxpZXIgbWFpbC4NCg0KVGhlIGJlbmVmaXQgb2YgdGhp
cyBvdmVyIGxvd2VyIG9jdGV0IHBlcm11dGF0aW9uIGlzIHRoYXQgc3R1cGlkIG1pZGRsZS1ib3hl
cyBkb27igJl0IGhhdmUgYSBjaGFuY2UsIHdoaWxlIHNsaWdodGx5IGludGVsbGlnZW50IG1pZGRs
ZS1ib3hlcyBjYW4gdXNlIGl0IGlzIGxvc3MgLyByZW9yZGVyaW5nIHNpZ25hbCwgYW5kIFFVSUMg
aGFyZHdhcmUgb2ZmbG9hZCBkZWNyeXB0b3JzIGNhbiB1c2UgdGhlIHZhbHVlIHVubW9kaWZpZWQg
YXMgSVYgcmF0aGVyIHRoYW4gY29tcHV0aW5nIHRoZSBpbnZlcnNlIGZpcnN0LiBGcm9tIGEgcHJp
dmFjeSBwZXJzcGVjdGl2ZSB0aGlzIGlzIG5vIGJldHRlciB0aGFuIHBsYWluIHNlcXVlbnRpYWwg
bnVtYmVycy4NCg0KQnV0IGl0IHN0aWxsIHNlcnZlcyBhcyBmaW5nZXJwcmludGluZyBhIGdpdmVu
IFFVSUMgdmVyc2lvbi4gSeKAmWQgc2F5IGZ1bGwgZW5jcnlwdGlvbiBvciBjbGVhciB0ZXh0IHNl
cXVlbnRpYWwgYXJlIHRoZSBvbmx5IHZpYWJsZSBjaG9pY2VzLg0KDQoNCg0KDQoNCiAgICAvKiBo
dHRwOi8vc3RhY2tvdmVyZmxvdy5jb20vYS8xMjk5NjAyODxodHRwczovL25hMDEuc2FmZWxpbmtz
LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGc3RhY2tvdmVyZmxvdy5j
b20lMkZhJTJGMTI5OTYwMjgmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdD
YTJjODhkY2JiMTUxNDY0NjQ4OWUwOGQ1YTA2Mzc2MjMlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk
N2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTkxMjcxNDA0NTM4MTIxJnNkYXRhPVZBOERwVmN5aFZL
eVdPTUtTY25ob21VUXlTR2I5cTN4MXJkWUtzY3R3ZjAlM0QmcmVzZXJ2ZWQ9MD4gKi8NCg0KICAg
IHVpbnQzMl90IHggPSB0eXBlX2hhc2g7DQoNCg0KDQogICAgeCA9ICgoeCA+PiAxNikgXiB4KSAq
IDB4NDVkOWYzYlVMOw0KDQogICAgeCA9ICgoeCA+PiAxNikgXiB4KSAqIDB4NDVkOWYzYlVMOw0K
DQogICAgeCA9ICgoeCA+PiAxNikgXiB4KTsNCg0KICAgIHJldHVybiB4Ow0KDQoNCg==

--_000_CY4PR21MB06309EAC254A087F5D3304B0B6BC0CY4PR21MB0630namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC
My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv
ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S
RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj
b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt
LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2
ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJJbmNvbnNvbGF0YSBm
b3IgUG93ZXJsaW5lIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxl
IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs
DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2
Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7
DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9
DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls
ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln
aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN
Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
CnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsN
Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFpbG9uLCBsaS5haXJt
YWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9vbjsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw
YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWls
U3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh
Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp
biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM4MjEwMTU1
ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTMzODY2
NjYyMCA4MTQzODI0NzggNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3
MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6
bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl
bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4
dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s
b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw
dDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs
MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDEN
Cgl7bXNvLWxpc3QtaWQ6ODY2MzI5MTk2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNTk1NTkz
Nzg4O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6
MzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxNjU1MTQxNzMwOw0KCW1zby1s
aXN0LXRlbXBsYXRlLWlkczotMjM5MzEwMTkyO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9
DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoyMDc2MTk0NzA4Ow0KCW1zby1saXN0LXRlbXBsYXRl
LWlkczotMTE4NjAzNzc2NDt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0
OjI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxl
dmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN
Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPlJlLiAjMTA3OSwgZm9sbG93aW5nIHNlZW1zIGxpa2UgYSB3
YXkgZm9yd2FyZCBzbyB3ZSBnZXQgdG8gZG8gc29tZSBpbXBsZW1lbnRhdGlvbnMgYW5kIGdldCBk
YXRhOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEi
IHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZl
bDEgbGZvMyI+UE4gdHJhbnNmb3JtIGlzIG5lZ290aWF0ZWQgdXNpbmcgdHJhbnNwb3J0IHBhcmFt
cy4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0
OmwwIGxldmVsMSBsZm8zIj5Gb2xsb3dpbmcgUE4gdHJhbnNmb3JtcyBhcmUgc3VwcG9ydGVkOjxv
OnA+PC9vOnA+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iYSI+
DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMiBsZm8zIj5Q
TkUgPG86cD48L286cD48L2xpPjwvb2w+DQo8L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkNvbm5lY3Rpb25zIGV4cGVjdGluZyB0byB1
c2UgbXVsdGlwbGUgcGF0aHMgZHVlIHRvIGdyYXR1aXRvdXMvdm9sdW50YXJ5IG1pZ3JhdGlvbiBN
VVNUIG5lZ290aWF0ZSBhbmQgdXNlIFBORSB0cmFuc2Zvcm0uIFNlZSBpc3N1ZSAxMjcxIHdoZXJl
IG9wdGlvbnMgYXJlIGJlaW5nIGRpc2N1c3NlZCBvbiBob3cgbWlncmF0aW9uIGNvdWxkIGJlIG5l
Z290aWF0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i
bWFyZ2luLWxlZnQ6MS4waW4iPlJldmlzaXQgdGhpcyBzb2x1dGlvbiBmb3IgcHJvcGVyIG11bHRp
LXBhdGggYWZ0ZXIgZGVzaWduaW5nIG11bHRpcGxlIFBOIHNwYWNlcy4gSSBhbSBmaW5lIGlmIHRo
aXMgaXMgZG9uZSBmb3IgVjIuPG86cD48L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6
MGluIiBzdGFydD0iMiIgdHlwZT0iMSI+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFy
dD0iMiIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omww
IGxldmVsMiBsZm8zIj5Mb3cgY29zdCBvc3NpZmljYXRpb24gcHJldmVudGlvbiB0cmFuc2Zvcm0g
KGxpa2Ugc2h1ZmZsZSkuDQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvb2w+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkZvciBjb25uZWN0aW9ucyBv
biB0aGUgSW50ZXJuZXQgb24gc2luZ2xlIHBhdGggcmVxdWlyZSB0aGVtIHRvIG5lZ290aWF0ZSB0
aGlzIHRyYW5zZm9ybS4gRXZlbiBiZXR0ZXIgaWYgd2UgZmluZCBhbm90aGVyIGxvdyBjb3N0IHNj
aGVtZSB3aXRoIGJldHRlciBwcm9wZXJ0aWVzIGJlZm9yZSB3ZSBzaGlwIFYxLjxvOnA+PC9vOnA+
PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIiIHR5cGU9IjEiPg0KPG9s
IHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjMiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDIgbGZvMyI+Tm8tb3AgKGN1cnJlbnQg
ZHJhZnQpIDxvOnA+DQo8L286cD48L2xpPjwvb2w+DQo8L29sPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5Gb3IgaW50cmEtZGF0YWNlbnRlciBvciBz
aW5nbGUgZG9tYWluIHByaXZhdGUgbmV0d29yayBzY2VuYXJpb3MgYWxsb3cgdXNhZ2Ugb2YgdGhl
IG5vLW9wIHRyYW5zZm9ybS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgc2VydmVyIGZhaWxz
IHRvIG5lZ290aWF0ZSBQTkUgYW5kIHN1cHBsaWVzIG11bHRpcGxlIGNvbm5lY3Rpb24gSURzIGZv
ciBtaWdyYXRpb24sIGNsaWVudCBmYWlsIHRoZSBjb25uZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIHNlcnZlciBmYWlscyB0byBuZWdvdGlhdGUgYSBs
b3cgY29zdCB0cmFuc2Zvcm0gb24gdGhlIEludGVybmV0LCBjbGllbnQgZmFpbHMgdGhlIGNvbm5l
Y3Rpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIG5vdGUgdGhhdCBzZXJ2ZXJz
IGFyZSBmcmVlIHRvIHBpY2sgUE5FIGFsbCB0aGUgdGltZS4gVGhpcyBhbGxvd3Mgc2VydmVyIGRl
cGxveW1lbnRzIHdoaWNoIGhhdmUgbm8gcGVyZm9ybWFuY2UgY29uY2VybiB0byBhbHdheXMgdXNl
IFBORS4gSSBkbyBoYXZlIHNvbWUgYmF0dGVyeSBsaWZlIGNvbmNlcm5zIG9uIGNsaWVudCBzaWRl
LCBidXQgSSBkbyB0aGluayB0aGUgbWFqb3IgcGVyZiBjb25jZXJuIGlzDQogb24gc2VydmVyIHNp
ZGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBkZXBsb3ltZW50cyB1c2luZyBsb3cg
Y29zdCB0cmFuc2Zvcm0gaGl0IG1pZGRsZWJveCBpc3N1ZXMgdGhleSB3aWxsIHN1ZmZlciBhbmQg
cGF5IHRoZSBjb3N0IHRvIGRvIFBORS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hy
Z2Vuc2VuIFttYWlsdG86bWlra2VsZmpAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRo
dXJzZGF5LCBBcHJpbCAxMiwgMjAxOCAzOjUyIEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gVGhv
bXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVU
RiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgQnJpYW4gVHJhbW1lbGwgKElFVEYpICZs
dDtpZXRmQHRyYW1tZWxsLmNoJmd0OzsgUnlhbiBIYW1pbHRvbiAmbHQ7cmNoQGdvb2dsZS5jb20m
Z3Q7OyBWaWN0b3IgVmFzaWxpZXYgJmx0O3Zhc2lsdnZAZ29vZ2xlLmNvbSZndDs7IEZvc3NhdGks
IFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UpICZsdDt0aG9tYXMuZm9zc2F0aUBub2tpYS5j
b20mZ3Q7OyBLYXp1aG8gT2t1ICZsdDtrYXp1aG9va3VAZ21haWwuY29tJmd0OzsgUHJhdmVlbg0K
IEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5TdWJq
ZWN0OjwvYj4gUmU6IFNpbXBsZSB0cmFuc2Zvcm0gZm9yIGltcHJvdmluZyBQTiBvc3NpZmljYXRp
b24gcHJldmVudGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9u
dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+T24gMTIgQXByaWwgMjAxOCBhdCAxMS4wNS4xNywgTWFydGluIFRob21zb24gKDwv
c3Bhbj48YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+KQ0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFu
dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tn
cm91bmQ6d2hpdGUiPlRoZSBjbGVhbiBwZXItcGF0aCBwYWNrZXQgbnVtYmVyIGRvZXNuJ3QgZGVm
ZW5kIGFnYWluc3QgJnF1b3Q7aGVscGZ1bG5lc3MmcXVvdDs8c3BhbiBjbGFzcz0iYXBwbGUtY29u
dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OmJsYWNrIj48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+b2YgdGhlIG5hdHVy
ZSBJIGRlc2NyaWJlZC4gVGhvc2UgcHJvYmxlbXMgZXhpc3QgaWYgdGhlIHNpZ25hbCBleGlzdHM8
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxi
cj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5hdCBhbGwuPC9zcGFuPjwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VHJ1ZS4gQnV0IHRoZXNlIGFyZSBzdGls
bCB0aGUgb3B0aW9ucyBhcyBJIHNlZSBpdC4gSGFsZi1iYWtlZCBvYmZ1c2NhdGlvbiB3aWxsIG9u
bHkgbWFrZSBpdCB3b3JzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+VGhlcmUgaXMgdGhlIGhvbHkgZ3JhaWwgb2YgZmFzdCAzMi1iaXQgcGVybXV0YXRpb25z
IHRoYXQgY2FuIGJlIHVzZWQgZGlyZWN0bHkgYXMgSVYsIHdoaWNoIGFyZSBzdWZmaWNpZW50bHkg
c2FmZSB3cnQuIHByaXZhY3ksIGFuZCB3aGVyZSB0aGUgcGVybXV0YXRpb24gZG9lcyBub3QgZGVw
ZW5kIG9uIHRoZSBwYWNrZXQgY29udGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+VGhlIGZvbGxvd2luZyBmdW5jdGlvbiBpcyB1c2VmdWwgdG8gZGlzcGVy
c2UgYSBsb3ctcXVhbGl0eSBoYXNoIC0gaXQgaXMgYSBwZXJmZWN0IHBlcm11dGF0aW9uLiBVbmZv
cnR1bmF0ZWx5LCBvciBmb3J0dW5hdGVseSwgaXQgY2FuIGJlIHRyaXZpYWxseSByZXZlcnNlZCAt
IHNlZSBzdGFjayBvdmVyZmxvdyBhcnRpY2xlLiBUaGVyZQ0KIGFyZSBhbHNvIDY0LWJpdCB2YXJp
YW50cywgYW5kIGl0IGNvdWxkIGFsc28gYmUganVzdCBhIHNpbmdsZSBtdWx0aXBsaWNhdGlvbi4g
TWFydGluIFQuIGFscmVhZHkgaGludGVkIGF0IHNvbWV0aGluZyBzaW1pbGFyIGluIGFuIGVhcmxp
ZXIgbWFpbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhl
IGJlbmVmaXQgb2YgdGhpcyBvdmVyIGxvd2VyIG9jdGV0IHBlcm11dGF0aW9uIGlzIHRoYXQgc3R1
cGlkIG1pZGRsZS1ib3hlcyBkb27igJl0IGhhdmUgYSBjaGFuY2UsIHdoaWxlIHNsaWdodGx5IGlu
dGVsbGlnZW50IG1pZGRsZS1ib3hlcyBjYW4gdXNlIGl0IGlzIGxvc3MgLyByZW9yZGVyaW5nIHNp
Z25hbCwgYW5kIFFVSUMgaGFyZHdhcmUNCiBvZmZsb2FkIGRlY3J5cHRvcnMgY2FuIHVzZSB0aGUg
dmFsdWUgdW5tb2RpZmllZCBhcyBJViByYXRoZXIgdGhhbiBjb21wdXRpbmcgdGhlIGludmVyc2Ug
Zmlyc3QuIEZyb20gYSBwcml2YWN5IHBlcnNwZWN0aXZlIHRoaXMgaXMgbm8gYmV0dGVyIHRoYW4g
cGxhaW4gc2VxdWVudGlhbCBudW1iZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj5CdXQgaXQgc3RpbGwgc2VydmVzIGFzIGZpbmdlcnByaW50aW5nIGEgZ2l2
ZW4gUVVJQyB2ZXJzaW9uLiBJ4oCZZCBzYXkgZnVsbCBlbmNyeXB0aW9uIG9yIGNsZWFyIHRleHQg
c2VxdWVudGlhbCBhcmUgdGhlIG9ubHkgdmlhYmxlIGNob2ljZXMuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtJbmNvbnNvbGF0
YSBmb3IgUG93ZXJsaW5lJnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7IC8qDQo8L3NwYW4+PGEg
aHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9
aHR0cCUzQSUyRiUyRnN0YWNrb3ZlcmZsb3cuY29tJTJGYSUyRjEyOTk2MDI4JmFtcDtkYXRhPTAy
JTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0NhMmM4OGRjYmIxNTE0NjQ2NDg5ZTA4ZDVh
MDYzNzYyMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY1
OTEyNzE0MDQ1MzgxMjEmYW1wO3NkYXRhPVZBOERwVmN5aFZLeVdPTUtTY25ob21VUXlTR2I5cTN4
MXJkWUtzY3R3ZjAlM0QmYW1wO3Jlc2VydmVkPTAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0luY29uc29sYXRhIGZvciBQb3dlcmxpbmUmcXVvdDssc2Vy
aWYiPmh0dHA6Ly9zdGFja292ZXJmbG93LmNvbS9hLzEyOTk2MDI4PC9zcGFuPjwvYT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtJbmNvbnNvbGF0YSBmb3Ig
UG93ZXJsaW5lJnF1b3Q7LHNlcmlmIj4NCiAqLzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SW5jb25zb2xhdGEgZm9yIFBvd2VybGluZSZxdW90OyxzZXJpZiI+Jm5i
c3A7ICZuYnNwOyB1aW50MzJfdCB4ID0gdHlwZV9oYXNoOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0luY29uc29sYXRhIGZvciBQb3dlcmxpbmUmcXVvdDssc2VyaWYiPiZu
YnNwOyAmbmJzcDsgeCA9ICgoeCAmZ3Q7Jmd0OyAxNikgXiB4KSAqIDB4NDVkOWYzYlVMOzwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SW5jb25zb2xhdGEgZm9yIFBv
d2VybGluZSZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyB4ID0gKCh4ICZndDsmZ3Q7IDE2KSBe
IHgpICogMHg0NWQ5ZjNiVUw7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtJbmNvbnNvbGF0YSBmb3IgUG93ZXJsaW5lJnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7
IHggPSAoKHggJmd0OyZndDsgMTYpIF4geCk7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtJbmNvbnNvbGF0YSBmb3IgUG93ZXJsaW5lJnF1b3Q7LHNlcmlmIj4mbmJz
cDsgJm5ic3A7IHJldHVybiB4Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs
c3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJib3JkZXItY29sbGFwc2U6Y29sbGFw
c2U7Ym94LXNpemluZzpib3JkZXItYm94O2JvcmRlci1zcGFjaW5nOjBweCI+DQo8dGJvZHk+DQo8
dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8
L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_CY4PR21MB06309EAC254A087F5D3304B0B6BC0CY4PR21MB0630namp_--


From nobody Thu Apr 12 11:08:22 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA8E127775 for ; Thu, 12 Apr 2018 11:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLZLp1JoxZjE for ; Thu, 12 Apr 2018 11:08:17 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C732512762F for ; Thu, 12 Apr 2018 11:08:17 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w3CHvgxF019268; Thu, 12 Apr 2018 19:08:17 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=67qcreLZld85cxmIZKjBYM38L5yneLGgnuSKr43GmxI=; b=dQd9ZVaEYbXXGL7BM5K5nXcCRcmDIWQ++sC2UFJ2saZHI/Ic+TaDcwSVb9Lju2gIRAcv qPEvhIk5xe813+X12PX4P9giRhYZqstRAtO4GlIFINifHCpNsgjv5wqoxTkmBZfDL+IO J+yrnkXcnLHcmaIyuczoDv3AEDarZBdyjBaNybzLzek0nSZIG00kX2H2OEqn7gFXBhU4 lOaUR9A5+BWbSzZyZ911W0koJX90Ii7YZoyK6SBH02VP5oiq4F6owqlvIN+GzBY3RViW wiqFScfQ+D9wN6qcDQDXN3dOWaDQ1ax714MiypbqdDsmC8QyJKqtg0GzMPrYoXAJRCyY 4A== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2h9educub4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Apr 2018 19:08:17 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3CHtxN7030400; Thu, 12 Apr 2018 14:08:15 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2h78pj2ynm-1; Thu, 12 Apr 2018 14:08:15 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id A83F72007F; Thu, 12 Apr 2018 18:08:15 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1f6gdq-0000DN-Q8; Thu, 12 Apr 2018 13:08:14 -0500
Date: Thu, 12 Apr 2018 13:08:14 -0500
From: Benjamin Kaduk 
To: Roland Zink 
Cc: quic@ietf.org
Subject: Re: Migration privacy and NAT rebinding
Message-ID: <20180412180814.GF20782@akamai.com>
References: <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>    <46f22a3d-b2ad-8c1a-9149-7d69dcde003c@huitema.net> <6E58094ECC8D8344914996DAD28F1CCD8728E1@DGGEMM506-MBX.china.huawei.com> <20180412133923.GC20782@akamai.com> 
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)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-12_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=926 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804120176
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-12_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=904 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804120176
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 12 Apr 2018 18:08:20 -0000

On Thu, Apr 12, 2018 at 04:00:43PM +0200, Roland Zink wrote:
> 
> Am 12.04.2018 um 15:39 schrieb Benjamin Kaduk:
> >On Thu, Apr 12, 2018 at 06:16:39AM +0000, Roni Even (A) wrote:
> >>Hi Christian,
> >>On the voluntary migration, what about when walking from the parking lot towards the house, will connect to Wifi and the IP address of the home router will probably be the same as when going out.  There will suddenly be a lot of traffic from the home router (not only QUIC), for example synchronizing all applications that were defined to download only on wifi. The migration will be easy to spot in this case.
> >I'm not sure what point you're trying to make, here.  A flurry of traffic from
> >a residential IP address would probably indicate that a device has returned to
> >that network after an absence, sure, but how does the attacker know whether
> >that device was asleep while it was gone, or had some other (cell) connectivity?
> Assuming there is a difference between new connections and migrating
> connections then you can discover if a device was asleep if most of the
> connections are newly established. If you have enough power then you may

If I have my phone set to "wifi-only" for a bunch of services, I wonder
whether those would show up as new connections or continuing ones when
I come back on wifi.

> even get the position / cell of the device, e.g. you may also be able to
> match the location.

True, but there's a potentially pretty big difference in attacker capabilities
between just snooping on the residential ISP and also having cell-level
visibility into the wireless carrier's network.  Certainly there are some
attackers who can do both, but is there an order-of-magnitude difference from
those only able to do one?

> >And how does this flurry of activity help the attacker correlate the (connections
> >of the) device returning to the wifi network with the (connections of the) device
> >on some other network?
> To match the previous connections you have the time and the destination
> address / port. If there are two to the same server then you probably can't
> distinguish between them immediately. The set of open connections is
> probably a good fingerprint of the device.

As was mentioned in the other subthread, the server address/port may not have
much information value, but sure, the set of open connections probably has
usable fingerprinting value.

Thanks,

Ben


From nobody Thu Apr 12 16:36:32 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2141F1277BB for ; Thu, 12 Apr 2018 16:36:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_JEoLbZxKCO for ; Thu, 12 Apr 2018 16:36:27 -0700 (PDT)
Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD09124D6C for ; Thu, 12 Apr 2018 16:36:27 -0700 (PDT)
Received: by mail-yb0-x22d.google.com with SMTP id g197-v6so3109845ybf.6 for ; Thu, 12 Apr 2018 16:36:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t6vitA2BLW8GMCj6GRlNanf5/yV8MeLxtsmNvKwXQRM=; b=gl6F43wep8mQaDwKFau+pUKEIpO5dLbrHVzhioyjGrnUYNaTpgbtltGCC7vbNu3f65 fpprnxKsHziVGZnwbThTWelob1/31RRRkrGbDtwjGHuRnDI48vD4YxWZUmnjtlG205IH g6BRNZ5+1CN0fTZVdln7svdIBzXOIA5g4UZWxXT8gpJd++vLtIaC6Ou9zVOaKoAbbEzM +D4AyTSJ6VdNEthWH6Gm+aJ2m4PyyU40ahFde26WDsmYlLbJD1dyEhl9zi5f7j9/R9ku m0lcvDMib9JJ9yU96MjX9+2y8Qzd4b7KfPJnyqVRDOjNkOS6ZO8T1YbvJIt8iYQIpClo MN2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t6vitA2BLW8GMCj6GRlNanf5/yV8MeLxtsmNvKwXQRM=; b=jAutBkJoFNlLxgNsKTOXaCkjAGF5SQkdRaxtg6tHco2GBliVFJ3vRX9XJ3ygxDsYM8 4bHFM2FqiXlWxYt6j9yXz0ekS+LYE5rOesl2RAIx/vfnsWfbDyz8TfFo068agIkkEfbM f9X4VF1S7Xf3N/UKESMWCyRc3LkkrMSw8LGh6q6AHBPfVwqrGwlwM0VERxLCYtqn+0d/ cWB7Ougba44CgOlkyPMY8T3NAmJTa2e3UznlzzIg0T/+aircJ7JutsyU3Q81qkKediV+ dej8cZCaPpb0csncWXsJhkNV3fVN7kQBp82YAGuRuB5gTtYVg8vMPUhUJlIk+63QtBcv WmGg==
X-Gm-Message-State: ALQs6tBsw5Rpp7yxC6BGJnPHLD2X97K5RF4F6j+w8rsbeyTlZSyzfK4G lqFO5y/lFts68aAeqFjMnOID8GVwAB5TJTg5r5V06SYw
X-Google-Smtp-Source: AIpwx4+Hq48XVujDpkmZ5kIyxYMuW6ApjnQjuc6KV/4qCITgVr4hsFPMn+LKj5o+KX6kz8EdDA7QIEmOzFielpw9GNk=
X-Received: by 2002:a25:386:: with SMTP id 128-v6mr2265801ybd.241.1523576186619;  Thu, 12 Apr 2018 16:36:26 -0700 (PDT)
MIME-Version: 1.0
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>       <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>   
In-Reply-To: 
From: Ian Swett 
Date: Thu, 12 Apr 2018 23:36:15 +0000
Message-ID: 
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)
To: pravb=40microsoft.com@dmarc.ietf.org
Cc: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000006505580569af39ed"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 12 Apr 2018 23:36:30 -0000

--0000000000006505580569af39ed
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, for a powerful adversary, this seems fairly tractable.

Making connection migration look like a new connection would likely help a
lot.

On Wed, Apr 11, 2018 at 3:18 PM Praveen Balasubramanian  wrote:

> Going back to Christian's original question on privacy holes, there is an
> attack for linking IP addresses in the voluntary migration case.
>
> Let's consider the parking lot problem or in general case losing one
> network and roaming to another network. This is the primary use case for
> connection migration. In this case all active QUIC connections that can
> migrate, will do so. When these connections migrate they can change the
> CID, the local port number and packet numbers. However do notice that onl=
y
> the local 2-tuple changes for each connection, the server's 2-tuple remai=
ns
> the same.
>
> Let's assume a powerful adversary can collect a network sniff of all this
> traffic and builds a massive dataset. The adversary can then run a machin=
e
> learning algorithm to identify time instants where a bunch of connections
> change their local 2-tuple at near the same time instant but continue goi=
ng
> to the same server side 2-tuples. This will allow the adversary to link t=
wo
> IP addresses. The more times the user roams between networks back and for=
th
> the richer the correlation. The more open connections to different server=
s,
> the richer the correlation. Geolocation information can minimize the numb=
er
> of addresses the adversary needs to correlate.
>
> The fundamental problem seems to be that the substrate is UDP/IP and it i=
s
> in the clear and allows linkability.
>
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
> Sent: Thursday, April 5, 2018 8:34 AM
> To: Mirja K=C3=BChlewind 
> Cc: quic@ietf.org
> Subject: Privacy holes (was: Re: Getting to consensus on packet number
> encryption)
>
>
>
> > On Apr 5, 2018, at 2:26 AM, Mirja K=C3=BChlewind <
> mirja.kuehlewind@tik.ee.ethz.ch> wrote:
> > ...
> > Timing doesn=E2=80=99t help here either because you still have the same
> destination IP, both port numbers and the fact that a migrated connection
> does not have a handshake. If we want to address the linkability problem,
> we would need to do much more, probably baring more hits on performance.
>
> Mirja,
>
> You rightly point out that the connection ID and the Packet Number are no=
t
> the only elements that provide linkability. There is also of course the U=
DP
> source port. That one is not much of an issue for servers, but it is an
> issue for clients. We are not spelling that out in the draft. We should,
> because clients can trivially close that hole when doing migration.
>
> I am not sure that the absence of negotiation divulges much data. It mark=
s
> the path as originating from a migration, but it does not tell from where=
.
> But there might be an ossification issue. We will get that ossification i=
f
> we train middleboxes to believe that connection always start with an
> observable negotiation. So maybe we should explore ways to grease that.
>
> Any other privacy hole that we should fix?
>
> -- Christian Huitema
>

--0000000000006505580569af39ed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yes, for a powerful adversary, this seems fairly tractable=
.

Making connection migration look like a new connection=
 would likely help a lot.

On Wed, Apr 11, 2018 at 3:18 PM Praveen Balasubramanian <pravb=
=3D40microsoft.com@dmarc.=
ietf.org> wrote:
Going back =
to Christian's original question on privacy holes, there is an attack f=
or linking IP addresses in the voluntary migration case.



Let's consider the parking lot problem or in general case losing one ne=
twork and roaming to another network. This is the primary use case for conn=
ection migration. In this case all active QUIC connections that can migrate=
, will do so. When these connections migrate they can change the CID, the l=
ocal port number and packet numbers. However do notice that only the local =
2-tuple changes for each connection, the server's 2-tuple remains the s=
ame. 



Let's assume a powerful adversary can collect a network sniff of all th=
is traffic and builds a massive dataset. The adversary can then run a machi=
ne learning algorithm to identify time instants where a bunch of connection=
s change their local 2-tuple at near the same time instant but continue goi=
ng to the same server side 2-tuples. This will allow the adversary to link =
two IP addresses. The more times the user roams between networks back and f=
orth the richer the correlation. The more open connections to different ser=
vers, the richer the correlation. Geolocation information can minimize the =
number of addresses the adversary needs to correlate. 



The fundamental problem seems to be that the substrate is UDP/IP and it is =
in the clear and allows linkability. 



-----Original Message-----

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema

Sent: Thursday, April 5, 2018 8:34 AM

To: Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch>

Cc: quic@ietf.org
Subject: Privacy holes (was: Re: Getting to consensus on packet number encr=
yption)







> On Apr 5, 2018, at 2:26 AM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee=
.ethz.ch> wrote:

> ...

> Timing doesn=E2=80=99t help here either because you still have the sam=
e destination IP, both port numbers and the fact that a migrated connection=
 does not have a handshake. If we want to address the linkability problem, =
we would need to do much more, probably baring more hits on performance. 


Mirja,



You rightly point out that the connection ID and the Packet Number are not =
the only elements that provide linkability. There is also of course the UDP=
 source port. That one is not much of an issue for servers, but it is an is=
sue for clients. We are not spelling that out in the draft. We should, beca=
use clients can trivially close that hole when doing migration.



I am not sure that the absence of negotiation divulges much data. It marks =
the path as originating from a migration, but it does not tell from where. =
But there might be an ossification issue. We will get that ossification if =
we train middleboxes to believe that connection always start with an observ=
able negotiation. So maybe we should explore ways to grease that.



Any other privacy hole that we should fix?



-- Christian Huitema 




--0000000000006505580569af39ed--


From nobody Thu Apr 12 16:36:38 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE65124D6C for ; Thu, 12 Apr 2018 16:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523576191; bh=wVGs4QFEi1agDDWULSV3Qy+0K2Q14NJpib6Zdu9eDns=; h=References:In-Reply-To:From:Date:Subject:Cc:To; b=H6H37/VmKXl+gHqTfEZYwOdtsS2cf6jJYINn1jt/jL3lft9I7UMQri0WEH3hwPqNq /WyD6TI8o9KP3lxlWJv1BhzpvtzNbwTxaT49H7y+D7FO5MX07lIUkw8Hn/PYsbBYvZ YHFAaW1UYC8dkeRkBrh96gIuYIMfQnRGizmUkCoQ=
X-Mailbox-Line: From ianswett@google.com  Thu Apr 12 16:36:31 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF82126CBF for ; Thu, 12 Apr 2018 16:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523576191; bh=t6vitA2BLW8GMCj6GRlNanf5/yV8MeLxtsmNvKwXQRM=; h=References:In-Reply-To:From:Date:Subject:Cc:To; b=U2yOHS8YfS8g39/3kh3aXOGB+H8uRefuwO3mbRw2J5tT7y/HiSAzJqxVOgvHem3gh btzLsWedOjapkXJniQTGmApSzMzeOGtZYtMhJfG0sRWdqe+HEA0wYEvP9Rg2atdldy E/6XysuU/Tb5TlW5sT2n8HE9DP1Lao3WLCyLjNps=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396AF124D6C for ; Thu, 12 Apr 2018 16:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 M73cBMDpPdQt for ; Thu, 12 Apr 2018 16:36:28 -0700 (PDT)
Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34AB126CBF for ; Thu, 12 Apr 2018 16:36:27 -0700 (PDT)
Received: by mail-yb0-x233.google.com with SMTP id k199-v6so3105382ybk.12 for ; Thu, 12 Apr 2018 16:36:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t6vitA2BLW8GMCj6GRlNanf5/yV8MeLxtsmNvKwXQRM=; b=gl6F43wep8mQaDwKFau+pUKEIpO5dLbrHVzhioyjGrnUYNaTpgbtltGCC7vbNu3f65 fpprnxKsHziVGZnwbThTWelob1/31RRRkrGbDtwjGHuRnDI48vD4YxWZUmnjtlG205IH g6BRNZ5+1CN0fTZVdln7svdIBzXOIA5g4UZWxXT8gpJd++vLtIaC6Ou9zVOaKoAbbEzM +D4AyTSJ6VdNEthWH6Gm+aJ2m4PyyU40ahFde26WDsmYlLbJD1dyEhl9zi5f7j9/R9ku m0lcvDMib9JJ9yU96MjX9+2y8Qzd4b7KfPJnyqVRDOjNkOS6ZO8T1YbvJIt8iYQIpClo MN2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t6vitA2BLW8GMCj6GRlNanf5/yV8MeLxtsmNvKwXQRM=; b=FiZe3/X6Q3Q/VibX2T/T+IRHYNIDbCPmdUeFt5UxQ+MeoEGzsJ2nuDFoXXHdjymjGs lALBSt+OrUY/j8ibK+fP7PdOJ5se+s4YsgWSIr6Id9Ms3wg8tvM8xcm+Jr+P0kbNC3ch gMf4LKLR3JZclXvJveasZNzuCUBsTem1uWCl834MdlCycTpEEJCc2KIedQb6bvq3wOf7 C/WkrrcveP5sFrkfagDtW6dC9ZRC06OKStfEkEKo80F0s70Lezv36mqXXSoriZb/bYWR MyL7GV6y0YTcI89NwK2MXZ42VcP9THCmv5d1cYUvDgPWlUPk8mW0XzRTHeZtvkz+Jqq3 O2nA==
X-Gm-Message-State: ALQs6tCXEwd1kB60BvOcgiZ9vMZzVD7AncQHaJYM19Y4gxLDvcLrvUA4 zidulaCIwP10LYSvUTeq+D3ekraHgVJpRH8sn5r2GK9s
X-Google-Smtp-Source: AIpwx4+Hq48XVujDpkmZ5kIyxYMuW6ApjnQjuc6KV/4qCITgVr4hsFPMn+LKj5o+KX6kz8EdDA7QIEmOzFielpw9GNk=
X-Received: by 2002:a25:386:: with SMTP id 128-v6mr2265801ybd.241.1523576186619;  Thu, 12 Apr 2018 16:36:26 -0700 (PDT)
MIME-Version: 1.0
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>       <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>   
In-Reply-To: 
From: Ian Swett 
Date: Thu, 12 Apr 2018 23:36:15 +0000
Message-ID: 
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Cc: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000006505580569af39ed"
To: pravb@microsoft.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, 12 Apr 2018 23:36:32 -0000

--0000000000006505580569af39ed
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, for a powerful adversary, this seems fairly tractable.

Making connection migration look like a new connection would likely help a
lot.

On Wed, Apr 11, 2018 at 3:18 PM Praveen Balasubramanian  wrote:

> Going back to Christian's original question on privacy holes, there is an
> attack for linking IP addresses in the voluntary migration case.
>
> Let's consider the parking lot problem or in general case losing one
> network and roaming to another network. This is the primary use case for
> connection migration. In this case all active QUIC connections that can
> migrate, will do so. When these connections migrate they can change the
> CID, the local port number and packet numbers. However do notice that onl=
y
> the local 2-tuple changes for each connection, the server's 2-tuple remai=
ns
> the same.
>
> Let's assume a powerful adversary can collect a network sniff of all this
> traffic and builds a massive dataset. The adversary can then run a machin=
e
> learning algorithm to identify time instants where a bunch of connections
> change their local 2-tuple at near the same time instant but continue goi=
ng
> to the same server side 2-tuples. This will allow the adversary to link t=
wo
> IP addresses. The more times the user roams between networks back and for=
th
> the richer the correlation. The more open connections to different server=
s,
> the richer the correlation. Geolocation information can minimize the numb=
er
> of addresses the adversary needs to correlate.
>
> The fundamental problem seems to be that the substrate is UDP/IP and it i=
s
> in the clear and allows linkability.
>
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
> Sent: Thursday, April 5, 2018 8:34 AM
> To: Mirja K=C3=BChlewind 
> Cc: quic@ietf.org
> Subject: Privacy holes (was: Re: Getting to consensus on packet number
> encryption)
>
>
>
> > On Apr 5, 2018, at 2:26 AM, Mirja K=C3=BChlewind <
> mirja.kuehlewind@tik.ee.ethz.ch> wrote:
> > ...
> > Timing doesn=E2=80=99t help here either because you still have the same
> destination IP, both port numbers and the fact that a migrated connection
> does not have a handshake. If we want to address the linkability problem,
> we would need to do much more, probably baring more hits on performance.
>
> Mirja,
>
> You rightly point out that the connection ID and the Packet Number are no=
t
> the only elements that provide linkability. There is also of course the U=
DP
> source port. That one is not much of an issue for servers, but it is an
> issue for clients. We are not spelling that out in the draft. We should,
> because clients can trivially close that hole when doing migration.
>
> I am not sure that the absence of negotiation divulges much data. It mark=
s
> the path as originating from a migration, but it does not tell from where=
..
> But there might be an ossification issue. We will get that ossification i=
f
> we train middleboxes to believe that connection always start with an
> observable negotiation. So maybe we should explore ways to grease that.
>
> Any other privacy hole that we should fix?
>
> -- Christian Huitema
>

--0000000000006505580569af39ed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yes, for a powerful adversary, this seems fairly tractable=
..

Making connection migration look like a new connection=
 would likely help a lot.

On Wed, Apr 11, 2018 at 3:18 PM Praveen Balasubramanian <pravb=
=3D40microsoft.com@dmarc.=
ietf.org> wrote:
Going back =
to Christian's original question on privacy holes, there is an attack f=
or linking IP addresses in the voluntary migration case.



Let's consider the parking lot problem or in general case losing one ne=
twork and roaming to another network. This is the primary use case for conn=
ection migration. In this case all active QUIC connections that can migrate=
, will do so. When these connections migrate they can change the CID, the l=
ocal port number and packet numbers. However do notice that only the local =
2-tuple changes for each connection, the server's 2-tuple remains the s=
ame. 



Let's assume a powerful adversary can collect a network sniff of all th=
is traffic and builds a massive dataset. The adversary can then run a machi=
ne learning algorithm to identify time instants where a bunch of connection=
s change their local 2-tuple at near the same time instant but continue goi=
ng to the same server side 2-tuples. This will allow the adversary to link =
two IP addresses. The more times the user roams between networks back and f=
orth the richer the correlation. The more open connections to different ser=
vers, the richer the correlation. Geolocation information can minimize the =
number of addresses the adversary needs to correlate. 



The fundamental problem seems to be that the substrate is UDP/IP and it is =
in the clear and allows linkability. 



-----Original Message-----

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema

Sent: Thursday, April 5, 2018 8:34 AM

To: Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch>

Cc: quic@ietf.org
Subject: Privacy holes (was: Re: Getting to consensus on packet number encr=
yption)







> On Apr 5, 2018, at 2:26 AM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee=
..ethz.ch> wrote:

> ...

> Timing doesn=E2=80=99t help here either because you still have the sam=
e destination IP, both port numbers and the fact that a migrated connection=
 does not have a handshake. If we want to address the linkability problem, =
we would need to do much more, probably baring more hits on performance. 


Mirja,



You rightly point out that the connection ID and the Packet Number are not =
the only elements that provide linkability. There is also of course the UDP=
 source port. That one is not much of an issue for servers, but it is an is=
sue for clients. We are not spelling that out in the draft. We should, beca=
use clients can trivially close that hole when doing migration.



I am not sure that the absence of negotiation divulges much data. It marks =
the path as originating from a migration, but it does not tell from where. =
But there might be an ossification issue. We will get that ossification if =
we train middleboxes to believe that connection always start with an observ=
able negotiation. So maybe we should explore ways to grease that.



Any other privacy hole that we should fix?



-- Christian Huitema 




--0000000000006505580569af39ed--


From nobody Thu Apr 12 17:32:34 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DD4127876 for ; Thu, 12 Apr 2018 17:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfbMvBhOwgSS for ; Thu, 12 Apr 2018 17:32:31 -0700 (PDT)
Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::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 1753A126D3F for ; Thu, 12 Apr 2018 17:32:30 -0700 (PDT)
Received: by mail-pl0-x22b.google.com with SMTP id 59-v6so5020400plc.13 for ; Thu, 12 Apr 2018 17:32:30 -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=dDxlPvMPp1tT1oWmmeNc5lVL76h/WRa+idpt+SNKLz8=; b=p3WacuAobU/JJTSoL33JgAPMfvHbwiNsSskvNoj+YW9EcDwNgu+RolVZWgEjDceqff O+fKm05R0MBnm4Arg2GQG/hZmyTUspxsWDOaTiDut2L5U46MsFap502t5i4CSa/zoCWa c5CZ4W1jaAdk8b0t/oZqKSiKWnoFc5RnbmLnOganJDsiSsW5//0Z9Ld5yjejfkyklJmt uNKxUX7gjv5MnUFpAoz6vwtwDOB0Cv1CSXFoyAPbOsC4m4Q6xX3VymFMAbnhOFfr2pdZ iNkAE070AfUVFeGyAUii0780JlTljdQDREuqmK+2T87knfR6lMPQtDrUsrBUs7xFvu2b JM+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dDxlPvMPp1tT1oWmmeNc5lVL76h/WRa+idpt+SNKLz8=; b=PA5ZTEj9Zkmy6fL2nW3LyS9B4qSliwV7VPEV4AwPTXgvXR0NYDjA7dCnS7RpyNkMOe 44Z48fOi3VKIegDXTqqPTl5DXr46PhFVhC47SsxNO0uQTwuSphJtSF2onTDNILd/vE1M eAFIhOHB+J2uGGtUIQwF0uFLEATw070jHD9GWxGVdTEpK1PBzz+y39pxy09t4deJld9B Qf00FYjK1zKR48GKV1U3ae/uCqAYUgPn5pjje1zBrp4GeHcJr0CtJklXWE0sVgPK7P2e HLJR+UURV96K+iHHTirAtZaHh87maLRyJ3gIlzpQwI9PPM5Ta7VhJPtWPE65Iqg6npv3 VTFg==
X-Gm-Message-State: ALQs6tBB9e5yCJV2LxzfZR8mA1iNJ9Xxj0nSSXxbhYCZlDnLQQgrJWjO 0tFkxK6bHtJxXXBI1RVUBo+1RhlOkh+PzYGcjyTA3874
X-Google-Smtp-Source: AIpwx4+dsb++6KX1iYJqefxTYjJlEzxGHVK2kdJCX68U3miLIbIwkijZUkyA8TKKjJZCeoZOLvNonmxF65VXUbnrjqw=
X-Received: by 2002:a17:902:102c:: with SMTP id b41-v6mr3154874pla.39.1523579550455;  Thu, 12 Apr 2018 17:32:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Thu, 12 Apr 2018 17:32:29 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>       <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>    
From: Kazuho Oku 
Date: Fri, 13 Apr 2018 09:32:29 +0900
Message-ID: 
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)
To: Ian Swett 
Cc: Praveen Balasubramanian , 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: Fri, 13 Apr 2018 00:32:32 -0000

2018-04-13 8:36 GMT+09:00 Ian Swett :
> Yes, for a powerful adversary, this seems fairly tractable..
>
> Making connection migration look like a new connection would likely help =
a
> lot.

I am not sure if that is the right path.

We have three ways in which a new set of 5-tuple starts getting used.

* new connection
* voluntary migration
* involuntary migration (i.e. NAT rebinding)

For the involuntary migration case, the first packet will always be a
short header packet.

If we make voluntary migration look like a new connection, the chance
of involuntary migration getting blocked by a middlebox becomes higher
(as we have seen gateways blocking the TLS 1.3 records, or the '07'
case).

Therefore, my preference goes to making all the three cases
indistinguishable (which is ideal but hard), or keeping voluntary and
non-voluntary migration look the same (as we do now) at the same time
making sure that the middlebox developers understand migration happens
[1].

[1] https://www.ietf.org/mail-archive/web/quic/current/msg03820.html

> On Wed, Apr 11, 2018 at 3:18 PM Praveen Balasubramanian
>  wrote:
>>
>> Going back to Christian's original question on privacy holes, there is a=
n
>> attack for linking IP addresses in the voluntary migration case.
>>
>> Let's consider the parking lot problem or in general case losing one
>> network and roaming to another network. This is the primary use case for
>> connection migration. In this case all active QUIC connections that can
>> migrate, will do so. When these connections migrate they can change the =
CID,
>> the local port number and packet numbers. However do notice that only th=
e
>> local 2-tuple changes for each connection, the server's 2-tuple remains =
the
>> same.
>>
>> Let's assume a powerful adversary can collect a network sniff of all thi=
s
>> traffic and builds a massive dataset. The adversary can then run a machi=
ne
>> learning algorithm to identify time instants where a bunch of connection=
s
>> change their local 2-tuple at near the same time instant but continue go=
ing
>> to the same server side 2-tuples. This will allow the adversary to link =
two
>> IP addresses. The more times the user roams between networks back and fo=
rth
>> the richer the correlation. The more open connections to different serve=
rs,
>> the richer the correlation. Geolocation information can minimize the num=
ber
>> of addresses the adversary needs to correlate.
>>
>> The fundamental problem seems to be that the substrate is UDP/IP and it =
is
>> in the clear and allows linkability.
>>
>> -----Original Message-----
>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
>> Sent: Thursday, April 5, 2018 8:34 AM
>> To: Mirja K=C3=BChlewind 
>> Cc: quic@ietf.org
>> Subject: Privacy holes (was: Re: Getting to consensus on packet number
>> encryption)
>>
>>
>>
>> > On Apr 5, 2018, at 2:26 AM, Mirja K=C3=BChlewind
>> >  wrote:
>> > ...
>> > Timing doesn=E2=80=99t help here either because you still have the sam=
e
>> > destination IP, both port numbers and the fact that a migrated connect=
ion
>> > does not have a handshake. If we want to address the linkability probl=
em, we
>> > would need to do much more, probably baring more hits on performance.
>>
>> Mirja,
>>
>> You rightly point out that the connection ID and the Packet Number are n=
ot
>> the only elements that provide linkability. There is also of course the =
UDP
>> source port. That one is not much of an issue for servers, but it is an
>> issue for clients. We are not spelling that out in the draft. We should,
>> because clients can trivially close that hole when doing migration.
>>
>> I am not sure that the absence of negotiation divulges much data. It mar=
ks
>> the path as originating from a migration, but it does not tell from wher=
e.
>> But there might be an ossification issue. We will get that ossification =
if
>> we train middleboxes to believe that connection always start with an
>> observable negotiation. So maybe we should explore ways to grease that.
>>
>> Any other privacy hole that we should fix?
>>
>> -- Christian Huitema



--=20
Kazuho Oku


From nobody Thu Apr 12 17:32:50 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 974B0126D3F for ; Thu, 12 Apr 2018 17:32:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523579553; bh=dDxlPvMPp1tT1oWmmeNc5lVL76h/WRa+idpt+SNKLz8=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=CROFtrPOSMx6rmBAHVjxvkBpW95TX/YKhoJsHvVN7fflxlv1cltod4t7nTO5joNXx 4Sk67T62wgoYIzRAr4xV/y4j3QyG3u1r2DllT3aKuBDUoaWms9xFo1uMDmtz0vNiHE BaMTp7cOaHCGJ8ytqTLcpMOmmPqH3uR5yAIk8Aug=
X-Mailbox-Line: From kazuhooku@gmail.com  Thu Apr 12 17:32:33 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 716341277BB; Thu, 12 Apr 2018 17:32:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523579553; bh=dDxlPvMPp1tT1oWmmeNc5lVL76h/WRa+idpt+SNKLz8=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=CROFtrPOSMx6rmBAHVjxvkBpW95TX/YKhoJsHvVN7fflxlv1cltod4t7nTO5joNXx 4Sk67T62wgoYIzRAr4xV/y4j3QyG3u1r2DllT3aKuBDUoaWms9xFo1uMDmtz0vNiHE BaMTp7cOaHCGJ8ytqTLcpMOmmPqH3uR5yAIk8Aug=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2FD126D3F; Thu, 12 Apr 2018 17:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 smPIi4PFDXWD; Thu, 12 Apr 2018 17:32:31 -0700 (PDT)
Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::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 4BE8B1277BB; Thu, 12 Apr 2018 17:32:31 -0700 (PDT)
Received: by mail-pl0-x236.google.com with SMTP id t20-v6so5031261ply.9; Thu, 12 Apr 2018 17:32: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:content-transfer-encoding; bh=dDxlPvMPp1tT1oWmmeNc5lVL76h/WRa+idpt+SNKLz8=; b=p3WacuAobU/JJTSoL33JgAPMfvHbwiNsSskvNoj+YW9EcDwNgu+RolVZWgEjDceqff O+fKm05R0MBnm4Arg2GQG/hZmyTUspxsWDOaTiDut2L5U46MsFap502t5i4CSa/zoCWa c5CZ4W1jaAdk8b0t/oZqKSiKWnoFc5RnbmLnOganJDsiSsW5//0Z9Ld5yjejfkyklJmt uNKxUX7gjv5MnUFpAoz6vwtwDOB0Cv1CSXFoyAPbOsC4m4Q6xX3VymFMAbnhOFfr2pdZ iNkAE070AfUVFeGyAUii0780JlTljdQDREuqmK+2T87knfR6lMPQtDrUsrBUs7xFvu2b JM+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dDxlPvMPp1tT1oWmmeNc5lVL76h/WRa+idpt+SNKLz8=; b=quJk4UJX7g8QTwZnbCjm1V1MznlcbwZT01rbnZ/rZMyKlXnbTFXfoSPO6qH8P05PwN M2EipqvvFt5+vx7PnocYNUKoGIzJr1rFzR+YpAfqP9YNvKm5o3uOi7aTuPGwprDdc953 ancqu9RYNn7aNxhNv0TwKhDBsjThWwNSKL4U3wztCQmuJy2Qz8ztU73J8qxwfamryKo/ BvYEYdXm+YyS93y13lrxzYyTbUSKlmP2rM/2uJbSak2U3nrmLbyBdZgQebSJ0Yr3V6Vu FH7bW08N2duTlDHzjXzHNeXwBbq+Ot/ktUSFZXZTNH6xBWS+DBaQ0gg5tz8hXlf9g5y+ BVNg==
X-Gm-Message-State: ALQs6tByDuvvUEonl5AoHF9OGKVCUGZF70u8Hrcn4r1JkMq+GB2DUqRX BPBk1ZmTgecOY+jqnvu4L47GFR7RDMgRtGQkt+gbiuun
X-Google-Smtp-Source: AIpwx4+dsb++6KX1iYJqefxTYjJlEzxGHVK2kdJCX68U3miLIbIwkijZUkyA8TKKjJZCeoZOLvNonmxF65VXUbnrjqw=
X-Received: by 2002:a17:902:102c:: with SMTP id b41-v6mr3154874pla.39.1523579550455;  Thu, 12 Apr 2018 17:32:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Thu, 12 Apr 2018 17:32:29 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>       <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>    
From: Kazuho Oku 
Date: Fri, 13 Apr 2018 09:32:29 +0900
Message-ID: 
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
To: Ian Swett 
Cc: Praveen Balasubramanian 
Cc: IETF QUIC WG 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Apr 2018 00:32:34 -0000

2018-04-13 8:36 GMT+09:00 Ian Swett :
> Yes, for a powerful adversary, this seems fairly tractable..
>
> Making connection migration look like a new connection would likely help =
a
> lot.

I am not sure if that is the right path.

We have three ways in which a new set of 5-tuple starts getting used.

* new connection
* voluntary migration
* involuntary migration (i.e. NAT rebinding)

For the involuntary migration case, the first packet will always be a
short header packet.

If we make voluntary migration look like a new connection, the chance
of involuntary migration getting blocked by a middlebox becomes higher
(as we have seen gateways blocking the TLS 1.3 records, or the '07'
case).

Therefore, my preference goes to making all the three cases
indistinguishable (which is ideal but hard), or keeping voluntary and
non-voluntary migration look the same (as we do now) at the same time
making sure that the middlebox developers understand migration happens
[1].

[1] https://www.ietf.org/mail-archive/web/quic/current/msg03820.html

> On Wed, Apr 11, 2018 at 3:18 PM Praveen Balasubramanian
>  wrote:
>>
>> Going back to Christian's original question on privacy holes, there is a=
n
>> attack for linking IP addresses in the voluntary migration case.
>>
>> Let's consider the parking lot problem or in general case losing one
>> network and roaming to another network. This is the primary use case for
>> connection migration. In this case all active QUIC connections that can
>> migrate, will do so. When these connections migrate they can change the =
CID,
>> the local port number and packet numbers. However do notice that only th=
e
>> local 2-tuple changes for each connection, the server's 2-tuple remains =
the
>> same.
>>
>> Let's assume a powerful adversary can collect a network sniff of all thi=
s
>> traffic and builds a massive dataset. The adversary can then run a machi=
ne
>> learning algorithm to identify time instants where a bunch of connection=
s
>> change their local 2-tuple at near the same time instant but continue go=
ing
>> to the same server side 2-tuples. This will allow the adversary to link =
two
>> IP addresses. The more times the user roams between networks back and fo=
rth
>> the richer the correlation. The more open connections to different serve=
rs,
>> the richer the correlation. Geolocation information can minimize the num=
ber
>> of addresses the adversary needs to correlate.
>>
>> The fundamental problem seems to be that the substrate is UDP/IP and it =
is
>> in the clear and allows linkability.
>>
>> -----Original Message-----
>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
>> Sent: Thursday, April 5, 2018 8:34 AM
>> To: Mirja K=C3=BChlewind 
>> Cc: quic@ietf.org
>> Subject: Privacy holes (was: Re: Getting to consensus on packet number
>> encryption)
>>
>>
>>
>> > On Apr 5, 2018, at 2:26 AM, Mirja K=C3=BChlewind
>> >  wrote:
>> > ...
>> > Timing doesn=E2=80=99t help here either because you still have the sam=
e
>> > destination IP, both port numbers and the fact that a migrated connect=
ion
>> > does not have a handshake. If we want to address the linkability probl=
em, we
>> > would need to do much more, probably baring more hits on performance.
>>
>> Mirja,
>>
>> You rightly point out that the connection ID and the Packet Number are n=
ot
>> the only elements that provide linkability. There is also of course the =
UDP
>> source port. That one is not much of an issue for servers, but it is an
>> issue for clients. We are not spelling that out in the draft. We should,
>> because clients can trivially close that hole when doing migration.
>>
>> I am not sure that the absence of negotiation divulges much data. It mar=
ks
>> the path as originating from a migration, but it does not tell from wher=
e.
>> But there might be an ossification issue. We will get that ossification =
if
>> we train middleboxes to believe that connection always start with an
>> observable negotiation. So maybe we should explore ways to grease that.
>>
>> Any other privacy hole that we should fix?
>>
>> -- Christian Huitema



--=20
Kazuho Oku


From nobody Thu Apr 12 18:09:15 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A3712D86B for ; Thu, 12 Apr 2018 18:09:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 oXlgmREStKxx for ; Thu, 12 Apr 2018 18:09:06 -0700 (PDT)
Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB5012DA43 for ; Thu, 12 Apr 2018 18:09:06 -0700 (PDT)
Received: by mail-ot0-x231.google.com with SMTP id n40-v6so8154492otd.3 for ; Thu, 12 Apr 2018 18:09: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:content-transfer-encoding; bh=hzEQHkEJyPonp6AvhlmbjhoOWa1hrArbSeNKU2fhY+Q=; b=KwFIowOyJn082pp8hVn1PeOn7RJQMsm3sTnGTJTlUD4Zv/hJozEd82rpDPATbthJmI ovNRtJZ9qwQo/mSBZO2jCHUUsNHVLONAbim+csJbsqJaGusIiyhMiymhuF0oCcm7KPXS a4EkYDo9ZsLr6pnqBx491fp3QHA94mGSGHxFIewxWFE36tMsL+BEfAoHd12kH4XzE+ki WLvJ1DnlHNU2b9nRNmwHEugNqOgGFS7vLAqa/MCyHUpZnMkBdRxJEOF0XYfmdNSP62es ivP+mahMH1L2qBJjfr6XqFgwwzBAE7H66INeTCficRwJxgZKWpXJVRAIu4Q72u0kKXsc beIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=hzEQHkEJyPonp6AvhlmbjhoOWa1hrArbSeNKU2fhY+Q=; b=VGPz67Y+VFSBFitzlo65xLDbkIylbl/mJfLM859y7JfcgIHKZFRfSbujP9b11xgtG4 08T9S7/mgwABFF6/OiUx3Yuw6f5Eaafgw9/GR6a4aHCU8425uisWiee9HfdEDfZkzWyC dXa4YJNFdfg2sSbVkkkGHl/oGucFwYKryiFpdpd2L3pEMlDOfe++ttQjH4T+bfV8Vb/N RyyIV2NJ0Hy4BPMn/M0nAGDcU219M2UR8vk4Scgyi1v09lFTr0Q4FGcAAzlsry1K/ipN ++ONcBe1AvPM3ILsayiqmNokn2KQUILWITg3LPOkNjSb/gfBXhmO8dxCSebr67UL/muI p6Qw==
X-Gm-Message-State: ALQs6tAZmsB0OBbST+BoJYAtvwtMC3WkJtwJFfAJmtB4Sl1rt6S/LuG1 BtCNBQCuwT79nmt6k14K1XIwVi003RY+pvwepuI=
X-Google-Smtp-Source: AIpwx48S71QZTfAdoT8FmXAuKuOFa6uRZW7tVp8gCK3KLc/uKnn+uTpSufmD96QBwB3kY0MoZ7LyEtYCMuNu9PkXHpU=
X-Received: by 2002:a9d:7405:: with SMTP id n5-v6mr2098449otk.283.1523581741078;  Thu, 12 Apr 2018 18:09:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 12 Apr 2018 18:09:00 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>       <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>     
From: Martin Thomson 
Date: Fri, 13 Apr 2018 11:09:00 +1000
Message-ID: 
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)
To: Kazuho Oku 
Cc: Ian Swett ,  Praveen Balasubramanian , 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: Fri, 13 Apr 2018 01:09:13 -0000

This is also my preference, in full realization of the downsides of
that.  Trying to make migration look like a handshake is also really
hard to get right.

On Fri, Apr 13, 2018 at 10:32 AM, Kazuho Oku  wrote:
> 2018-04-13 8:36 GMT+09:00 Ian Swett :
>> Yes, for a powerful adversary, this seems fairly tractable..
>>
>> Making connection migration look like a new connection would likely help=
 a
>> lot.
>
> I am not sure if that is the right path.
>
> We have three ways in which a new set of 5-tuple starts getting used.
>
> * new connection
> * voluntary migration
> * involuntary migration (i.e. NAT rebinding)
>
> For the involuntary migration case, the first packet will always be a
> short header packet.
>
> If we make voluntary migration look like a new connection, the chance
> of involuntary migration getting blocked by a middlebox becomes higher
> (as we have seen gateways blocking the TLS 1.3 records, or the '07'
> case).
>
> Therefore, my preference goes to making all the three cases
> indistinguishable (which is ideal but hard), or keeping voluntary and
> non-voluntary migration look the same (as we do now) at the same time
> making sure that the middlebox developers understand migration happens
> [1].
>
> [1] https://www.ietf.org/mail-archive/web/quic/current/msg03820.html
>
>> On Wed, Apr 11, 2018 at 3:18 PM Praveen Balasubramanian
>>  wrote:
>>>
>>> Going back to Christian's original question on privacy holes, there is =
an
>>> attack for linking IP addresses in the voluntary migration case.
>>>
>>> Let's consider the parking lot problem or in general case losing one
>>> network and roaming to another network. This is the primary use case fo=
r
>>> connection migration. In this case all active QUIC connections that can
>>> migrate, will do so. When these connections migrate they can change the=
 CID,
>>> the local port number and packet numbers. However do notice that only t=
he
>>> local 2-tuple changes for each connection, the server's 2-tuple remains=
 the
>>> same.
>>>
>>> Let's assume a powerful adversary can collect a network sniff of all th=
is
>>> traffic and builds a massive dataset. The adversary can then run a mach=
ine
>>> learning algorithm to identify time instants where a bunch of connectio=
ns
>>> change their local 2-tuple at near the same time instant but continue g=
oing
>>> to the same server side 2-tuples. This will allow the adversary to link=
 two
>>> IP addresses. The more times the user roams between networks back and f=
orth
>>> the richer the correlation. The more open connections to different serv=
ers,
>>> the richer the correlation. Geolocation information can minimize the nu=
mber
>>> of addresses the adversary needs to correlate.
>>>
>>> The fundamental problem seems to be that the substrate is UDP/IP and it=
 is
>>> in the clear and allows linkability.
>>>
>>> -----Original Message-----
>>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitem=
a
>>> Sent: Thursday, April 5, 2018 8:34 AM
>>> To: Mirja K=C3=BChlewind 
>>> Cc: quic@ietf.org
>>> Subject: Privacy holes (was: Re: Getting to consensus on packet number
>>> encryption)
>>>
>>>
>>>
>>> > On Apr 5, 2018, at 2:26 AM, Mirja K=C3=BChlewind
>>> >  wrote:
>>> > ...
>>> > Timing doesn=E2=80=99t help here either because you still have the sa=
me
>>> > destination IP, both port numbers and the fact that a migrated connec=
tion
>>> > does not have a handshake. If we want to address the linkability prob=
lem, we
>>> > would need to do much more, probably baring more hits on performance.
>>>
>>> Mirja,
>>>
>>> You rightly point out that the connection ID and the Packet Number are =
not
>>> the only elements that provide linkability. There is also of course the=
 UDP
>>> source port. That one is not much of an issue for servers, but it is an
>>> issue for clients. We are not spelling that out in the draft. We should=
,
>>> because clients can trivially close that hole when doing migration.
>>>
>>> I am not sure that the absence of negotiation divulges much data. It ma=
rks
>>> the path as originating from a migration, but it does not tell from whe=
re.
>>> But there might be an ossification issue. We will get that ossification=
 if
>>> we train middleboxes to believe that connection always start with an
>>> observable negotiation. So maybe we should explore ways to grease that.
>>>
>>> Any other privacy hole that we should fix?
>>>
>>> -- Christian Huitema
>
>
>
> --
> Kazuho Oku
>


From nobody Thu Apr 12 18:09:32 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1453212E055 for ; Thu, 12 Apr 2018 18:09:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523581750; bh=D+VHqM40WiPdmMm9IJS5/HVhJ+sBABIwzpPTmWwQjSs=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc:Cc; b=Pdwashh28dz9FCTuhCH9kgLy8MLiPNpDxQ1+CbFonNxaeqQWfz7AJ83vUXzL1SVDc 6waBvI5xsz6H6+GoslDTXvx84txPSu/LQvsVzFjWYlI2GIdwwzHFEntyDXKz+VGHGR bYjowHLEzxbMPrQVwkH9/ccJgpyoxHSsr8NHyX+E=
X-Mailbox-Line: From martin.thomson@gmail.com  Thu Apr 12 18:09:07 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA7E12DA16; Thu, 12 Apr 2018 18:09:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523581747; bh=D+VHqM40WiPdmMm9IJS5/HVhJ+sBABIwzpPTmWwQjSs=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc:Cc; b=ULsnzCFini6nj7ulB8/hxPktB5/rA89LuD3PWVVKEEV3JnaY19Xl3XhhwUo33rN1W CGnyDoNjZ2ATv5ts8Rmbhf5o1+pcppABR6KlsGGZWeIl0SoalbD5fmdI7sLiUay3S3 349r53wFELwKBIMR+nIvM7O/DmvLtEmabps5K4xE=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932FF12E046; Thu, 12 Apr 2018 18:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 IyxsucrRu-BQ; Thu, 12 Apr 2018 18:09:02 -0700 (PDT)
Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5ACE12D86D; Thu, 12 Apr 2018 18:09:01 -0700 (PDT)
Received: by mail-ot0-x22a.google.com with SMTP id d9-v6so8141925oth.10; Thu, 12 Apr 2018 18:09: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=hzEQHkEJyPonp6AvhlmbjhoOWa1hrArbSeNKU2fhY+Q=; b=KwFIowOyJn082pp8hVn1PeOn7RJQMsm3sTnGTJTlUD4Zv/hJozEd82rpDPATbthJmI ovNRtJZ9qwQo/mSBZO2jCHUUsNHVLONAbim+csJbsqJaGusIiyhMiymhuF0oCcm7KPXS a4EkYDo9ZsLr6pnqBx491fp3QHA94mGSGHxFIewxWFE36tMsL+BEfAoHd12kH4XzE+ki WLvJ1DnlHNU2b9nRNmwHEugNqOgGFS7vLAqa/MCyHUpZnMkBdRxJEOF0XYfmdNSP62es ivP+mahMH1L2qBJjfr6XqFgwwzBAE7H66INeTCficRwJxgZKWpXJVRAIu4Q72u0kKXsc beIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=hzEQHkEJyPonp6AvhlmbjhoOWa1hrArbSeNKU2fhY+Q=; b=CUz3OpEKk1Mo2HG+AWw5E+0V5p0oSy47WEv/MTiK7QksrWHvSxVrap6x4HuKeYJoPw ciqgYdIIhG7c4fEsokYu9bBdPHNINPJt0qxDGcM2XgITmrAWGSTel5z3sCQItTlaSEWA GLwauUT0apqfNdgcInW4uIJq3dBPVomp/ExKohmGqGqsh0Fh6akVvNE2EMvTVDb5QZq2 adrX967LxFobf1A2h4OINJlB4DYfOi3poTodOV6yUXwlSb/JnyDKy0piyKSAij+03BfK nttAt5AV+oFz/JL44DvH5pzlm2AN+ACEafPDQQ8a0MGhozxKVbus+eD4P1fEYfB99SDS NY6A==
X-Gm-Message-State: ALQs6tDYf0179Uh1z6DFEzicM4/yg6YSptZYRArj0Cvd1W3x80g8hPjz DGEnhLPrF6+gFMpXY9RsrTfgTK4iNUEA2+vtOQE=
X-Google-Smtp-Source: AIpwx48S71QZTfAdoT8FmXAuKuOFa6uRZW7tVp8gCK3KLc/uKnn+uTpSufmD96QBwB3kY0MoZ7LyEtYCMuNu9PkXHpU=
X-Received: by 2002:a9d:7405:: with SMTP id n5-v6mr2098449otk.283.1523581741078;  Thu, 12 Apr 2018 18:09:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 12 Apr 2018 18:09:00 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>       <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>     
From: Martin Thomson 
Date: Fri, 13 Apr 2018 11:09:00 +1000
Message-ID: 
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)
To: Kazuho Oku 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Ian Swett 
Cc: Praveen Balasubramanian 
Cc: IETF QUIC WG 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Apr 2018 01:09:14 -0000

This is also my preference, in full realization of the downsides of
that.  Trying to make migration look like a handshake is also really
hard to get right.

On Fri, Apr 13, 2018 at 10:32 AM, Kazuho Oku  wrote:
> 2018-04-13 8:36 GMT+09:00 Ian Swett :
>> Yes, for a powerful adversary, this seems fairly tractable..
>>
>> Making connection migration look like a new connection would likely help=
 a
>> lot.
>
> I am not sure if that is the right path.
>
> We have three ways in which a new set of 5-tuple starts getting used.
>
> * new connection
> * voluntary migration
> * involuntary migration (i.e. NAT rebinding)
>
> For the involuntary migration case, the first packet will always be a
> short header packet.
>
> If we make voluntary migration look like a new connection, the chance
> of involuntary migration getting blocked by a middlebox becomes higher
> (as we have seen gateways blocking the TLS 1.3 records, or the '07'
> case).
>
> Therefore, my preference goes to making all the three cases
> indistinguishable (which is ideal but hard), or keeping voluntary and
> non-voluntary migration look the same (as we do now) at the same time
> making sure that the middlebox developers understand migration happens
> [1].
>
> [1] https://www.ietf.org/mail-archive/web/quic/current/msg03820.html
>
>> On Wed, Apr 11, 2018 at 3:18 PM Praveen Balasubramanian
>>  wrote:
>>>
>>> Going back to Christian's original question on privacy holes, there is =
an
>>> attack for linking IP addresses in the voluntary migration case.
>>>
>>> Let's consider the parking lot problem or in general case losing one
>>> network and roaming to another network. This is the primary use case fo=
r
>>> connection migration. In this case all active QUIC connections that can
>>> migrate, will do so. When these connections migrate they can change the=
 CID,
>>> the local port number and packet numbers. However do notice that only t=
he
>>> local 2-tuple changes for each connection, the server's 2-tuple remains=
 the
>>> same.
>>>
>>> Let's assume a powerful adversary can collect a network sniff of all th=
is
>>> traffic and builds a massive dataset. The adversary can then run a mach=
ine
>>> learning algorithm to identify time instants where a bunch of connectio=
ns
>>> change their local 2-tuple at near the same time instant but continue g=
oing
>>> to the same server side 2-tuples. This will allow the adversary to link=
 two
>>> IP addresses. The more times the user roams between networks back and f=
orth
>>> the richer the correlation. The more open connections to different serv=
ers,
>>> the richer the correlation. Geolocation information can minimize the nu=
mber
>>> of addresses the adversary needs to correlate.
>>>
>>> The fundamental problem seems to be that the substrate is UDP/IP and it=
 is
>>> in the clear and allows linkability.
>>>
>>> -----Original Message-----
>>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitem=
a
>>> Sent: Thursday, April 5, 2018 8:34 AM
>>> To: Mirja K=C3=BChlewind 
>>> Cc: quic@ietf.org
>>> Subject: Privacy holes (was: Re: Getting to consensus on packet number
>>> encryption)
>>>
>>>
>>>
>>> > On Apr 5, 2018, at 2:26 AM, Mirja K=C3=BChlewind
>>> >  wrote:
>>> > ...
>>> > Timing doesn=E2=80=99t help here either because you still have the sa=
me
>>> > destination IP, both port numbers and the fact that a migrated connec=
tion
>>> > does not have a handshake. If we want to address the linkability prob=
lem, we
>>> > would need to do much more, probably baring more hits on performance.
>>>
>>> Mirja,
>>>
>>> You rightly point out that the connection ID and the Packet Number are =
not
>>> the only elements that provide linkability. There is also of course the=
 UDP
>>> source port. That one is not much of an issue for servers, but it is an
>>> issue for clients. We are not spelling that out in the draft. We should=
,
>>> because clients can trivially close that hole when doing migration.
>>>
>>> I am not sure that the absence of negotiation divulges much data. It ma=
rks
>>> the path as originating from a migration, but it does not tell from whe=
re.
>>> But there might be an ossification issue. We will get that ossification=
 if
>>> we train middleboxes to believe that connection always start with an
>>> observable negotiation. So maybe we should explore ways to grease that.
>>>
>>> Any other privacy hole that we should fix?
>>>
>>> -- Christian Huitema
>
>
>
> --
> Kazuho Oku
>


From nobody Thu Apr 12 19:42:14 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782461243F6 for ; Thu, 12 Apr 2018 19:42:12 -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 dVUYJHBTrrXy for ; Thu, 12 Apr 2018 19:42:10 -0700 (PDT)
Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::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 B37F012D7F6 for ; Thu, 12 Apr 2018 19:42:10 -0700 (PDT)
Received: by mail-ot0-x235.google.com with SMTP id f47-v6so8333888oth.2 for ; Thu, 12 Apr 2018 19:42:10 -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=dqKj7/a3/p8WLstfzcAxbRt+7GA91L5oNYbQncQYi74=; b=GaEOIAdnxm6xRd4YU7X7JpGJGKdwdYt8pw46+BaNo0Jj2MoHSQDwkAxlOBU/H1a89o /wkM02BbALOGvN9M2VfUMAqlckbxkALLzWGVHh6vowdt15hsoiMViYmTjIKfrJ4DWMlx uGd5MlJa0RpBLIJOKOgLrxn1hrVMqzXf6B0nsgLeg0U6t37+jMhUxkagojb7gM1MJUon iqtHz+HjS9kvhGZutZ9rbJnnX38arHG4uG1EyxgkXJFkIvf/8T8LgF+zoO62JKJVT3UY ppvyDcIwkFgYAbbiWC7nIysHT7DlaADpYBFqVpb//15e+p2WvCVl9uakrFHpyZo4Tu8u dZlw==
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=dqKj7/a3/p8WLstfzcAxbRt+7GA91L5oNYbQncQYi74=; b=OytawTrCOTopUWHtqfCcziqCVw0P3z1HhKLOz6S3XgDgUsu3sqJYS3+S/4+8FY7IiV mo3iMQlU5PcQBxhxbfrEfjVZuutzSVm7rarPhf1mP7tjgtImlrRoZ876oO9cdhubNdvZ 7qHdJk7Oydcmg3vBVMKy/pV1WlpJXkzPVPiVJ8aJP2B2hFoBSCNpAwwGf2orlxqCyeof X/nkA9nHE46HNgke3f6ADWYrAJcGaPrp60HFfYJP+EIMc/HOrk65NqMgoXhHFYdDY3NI iq6NNZ/1B/DkmfWAz5yR1oUmRYvs4dYoOUm1mL7KBQ7swgQkYM6kbYwpUR0l0ki5nrk3 YyWg==
X-Gm-Message-State: ALQs6tD4+jifJASeGVW9xEKIO3fcCbJrE9qLVEPZ2/Uwn08oMCU7zbRe m9NQUiZ2MslYBeyJgKoZ/7ts8rzmBmyYNioIQZfJGA==
X-Google-Smtp-Source: AIpwx48c6Xk7I8ijtgjjaX/5Q6LhiS+a+UofJ2P1dloG5SQNnNZxiYuJQPbpOdCSfHLqaWBfWcXQH5MYlveoV7BZWtw=
X-Received: by 2002:a9d:1071:: with SMTP id o46-v6mr2201016oto.396.1523587329867;  Thu, 12 Apr 2018 19:42:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 12 Apr 2018 19:42:09 -0700 (PDT)
From: Martin Thomson 
Date: Fri, 13 Apr 2018 12:42:09 +1000
Message-ID: 
Subject: Extension frame design question
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, 13 Apr 2018 02:42:12 -0000

We agreed to add the ability to extend QUIC in Melbourne (I know, it's
so long ago, but it seems like just yesterday).  But we never never
sealed the deal.

While we agree in principle, and have agreed that the use of
extensions will be signaled during the handshake using transport
parameters (as opposed to the h2 model where they can just appear),
we're locked in disagreement about the precise colour to use.  Right
now there are three options:

1. As Victor originally proposed, provide a map from a large
identifier space to the smaller space of extension frame types.  PR
#1068 does that, mapping a 16-bit identifier into the 128-255 range of
frame types.  Cost: indirection, complexity.  Advantage: It has a PR
(i.e., nothing significant).

2. Use a varint for frame types. Cost: non-trivial change to the wire
format for frames; large(r) overhead for sending a frame unless you
get one of the privileged frame types that encode to a single octet
(and we have used 3/8 of those already, so we'd probably want to be
strict about registration policies in that space).  Advantage: simple.

3. A modification to PR #1068 proposed by Kazuho which would have
every transport parameter carry a list of frame types with it.  Cost:
similar indirection to PR #1068, and every transport parameter would
carry this list.  The advantage being that an extension that defines a
transport parameter would only touch a single transport parameter and
not have to register an extension frame type as well.

Now I prefer the first, but could live with either alternative if only
we could decide.  So I'm asking for help.


From nobody Thu Apr 12 20:20:57 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD491241F8 for ; Thu, 12 Apr 2018 20:20:55 -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 LtRgvY3qtPTd for ; Thu, 12 Apr 2018 20:20:54 -0700 (PDT)
Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::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 219121205D3 for ; Thu, 12 Apr 2018 20:20:54 -0700 (PDT)
Received: by mail-pl0-x22a.google.com with SMTP id w12-v6so4347231plp.0 for ; Thu, 12 Apr 2018 20:20:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pWGfsv++0MfbfslP7LqEqgZAhkEjAhnioy21L5nx47M=; b=LN4po4914v+C1IUtBjPxybS+pwzdctJb3wYCj2tUoFjnLyOfhCoXk3XVMeakZvZ5tf mb8bgxfxG4nrdtfZxYThgaJ5q4O3XLcErUbNIll40VKNbD2qNtcE5HMdYH0nETXoesk4 9wt6s9JBQD2K3lcL3OwTeZrPeriu1kRlRnO/VVyhLDABn6Kz/5PVxqi5vgl8TAvLDWoN 46C4C8gIzsccCPxUh4Es3laBQFERHPMka0nmVCB3+N0Nn6qEBIxMtQvnJxuvwR1wEMWo lRiA7L83dNrX4S6bbBf29R2g2tqA+6BrCCXXvtCiK1ZDqa3F9pG9+3lDuBxL3kbcfIJM iZsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=pWGfsv++0MfbfslP7LqEqgZAhkEjAhnioy21L5nx47M=; b=c7bJeif2dhKdTp9xB68KDhC5B/mK3y7bXtEFb8Hjk4PzWvHGU2qlaxMR1Domc0ei1Q A2SWeo0cU2Mzt4O29XMArncnJ5JJgC1BptjotKsvOLXdwTvW4IEMCEAAiQ6yfqCixSfA z8vRtEpmok6NKWvWJgULO+b6IX95gK0J19btYan+cxPdo6v6Tc7leB5dgW2HKfUnpCkA RGK8/ZRoZxpSroJ1RLSn4WcBg5v/5uf1TQ9Alcu6yMtYgZ7V+Mf2PmxT0RSa29NLsgGq viMqbZF40b2Chm0xJDy7BIkStgJQZ1p1BpEfd+IzeOzBmFrGcRvV/T9iMPAIAm2E5BF0 wZcw==
X-Gm-Message-State: ALQs6tA1sc7LYxapKM5bNsteiboc3M3RaTsvT1maC7cQL555SP8dArGg 7l2VyRX37UjGNwTITLbJVUK3KQ4xxGr4ug/GMws=
X-Google-Smtp-Source: AIpwx49LiZHITvqCpXDZu3xbGDkT8ws3+lqv8JEP6NRSkdlMFiIW+HBWdt6zt3WqNr7K1sRhXAb3FGenv9lF4+hfiuI=
X-Received: by 2002:a17:902:3225:: with SMTP id y34-v6mr3694840plb.180.1523589653638;  Thu, 12 Apr 2018 20:20:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Thu, 12 Apr 2018 20:20:53 -0700 (PDT)
In-Reply-To: 
References: 
From: Kazuho Oku 
Date: Fri, 13 Apr 2018 12:20:53 +0900
Message-ID: 
Subject: Re: Extension frame design question
To: Martin Thomson 
Cc: QUIC WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2018 03:20:56 -0000

Hi Martin,

Thank you for brining the issue to the list.

My view is that there are two orthogonal issues here:

a) whether if we should have two ways to extend the protocol; one by
declaring the use of a extension frame type and one by sending a
transport parameter (note: you cannot declare a feature that does not
add a new frame type by declaring the use of a frame type)

b) whether if the extended frame type is negotiated to fit into 1
octet or not (i.e. use varint)

For point a, my preference is to have only one way of extending the
protocol (by sending a transport parameter), having one IANA registry
instead of two.

I do not have a strong opinion on point b, though I described one
possible approach that could be used under the assumption that we
prefer to negotiate a frame type that fits into 1 octet.

2018-04-13 11:42 GMT+09:00 Martin Thomson :
> We agreed to add the ability to extend QUIC in Melbourne (I know, it's
> so long ago, but it seems like just yesterday).  But we never never
> sealed the deal.
>
> While we agree in principle, and have agreed that the use of
> extensions will be signaled during the handshake using transport
> parameters (as opposed to the h2 model where they can just appear),
> we're locked in disagreement about the precise colour to use.  Right
> now there are three options:
>
> 1. As Victor originally proposed, provide a map from a large
> identifier space to the smaller space of extension frame types.  PR
> #1068 does that, mapping a 16-bit identifier into the 128-255 range of
> frame types.  Cost: indirection, complexity.  Advantage: It has a PR
> (i.e., nothing significant).
>
> 2. Use a varint for frame types. Cost: non-trivial change to the wire
> format for frames; large(r) overhead for sending a frame unless you
> get one of the privileged frame types that encode to a single octet
> (and we have used 3/8 of those already, so we'd probably want to be
> strict about registration policies in that space).  Advantage: simple.
>
> 3. A modification to PR #1068 proposed by Kazuho which would have
> every transport parameter carry a list of frame types with it.  Cost:
> similar indirection to PR #1068, and every transport parameter would
> carry this list.  The advantage being that an extension that defines a
> transport parameter would only touch a single transport parameter and
> not have to register an extension frame type as well.
>
> Now I prefer the first, but could live with either alternative if only
> we could decide.  So I'm asking for help.
>



-- 
Kazuho Oku


From nobody Fri Apr 13 04:06:49 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99FA126B6D for ; Fri, 13 Apr 2018 04:06:47 -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 cSJei0wtrSOX for ; Fri, 13 Apr 2018 04:06:45 -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 BCB4F1252BA for ; Fri, 13 Apr 2018 04:06:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 40Mw2V6KsGzMqR7; Fri, 13 Apr 2018 13:06:42 +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 O9vYuq4oz7Og; Fri, 13 Apr 2018 13:06:41 +0200 (CEST)
X-MtScore: NO score=0
Received: from [192.168.178.24] (i577BCE4C.versanet.de [87.123.206.76]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 13 Apr 2018 13:06:41 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Getting to consensus on packet number encryption
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= 
In-Reply-To: <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com>
Date: Fri, 13 Apr 2018 13:06:40 +0200
Cc: Christian Huitema , "quic@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com>
To: Roberto Peon 
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Apr 2018 11:06:48 -0000

Hi Roberto,

see below.

> Am 10.04.2018 um 03:04 schrieb Roberto Peon :
>=20
> Adding another PN would probably not be sufficient-- one would need to =
ensure that the ossified PN was presented with the right sequencing as =
well, which might be difficult, or expensive.

Yes, that is easy. Why do you think that is difficult or expensive?

> Ossification is surprisingly difficult to work around once it sets in, =
as even figuring out how it is impacting you can be substantial work.

That is true for a protocol like TCP very the invariant is large and non =
of the bits are encrypted. For QUIC we have a completely different =
situation.

Mirja


>=20
> -=3DR
>=20
> =EF=BB=BFOn 4/5/18, 2:27 AM, "QUIC on behalf of Mirja K=C3=BChlewind" =
 =
wrote:
>=20
>    Let me repeat another position then as well:
>=20
>> Am 05.04.2018 um 02:44 schrieb Christian Huitema =
:
>>=20
>> If we are in the business of repeating our positions, so be it. I am =
pretty much on the same line as Patrick and others:
>>=20
>> 1) Privacy is not optional. And yes, removing "linkability through =
PN" is important, because when the connection ID and the source address =
also change, the only other cue for linkability is timing. Timing can be =
addressed by having overlapping connections.
>>=20
>    Timing doesn=E2=80=99t help here either because you still have the =
same destination IP, both port numbers and the fact that a migrated =
connection does not have a handshake. If we want to address the =
linkability problem, we would need to do much more, probably baring more =
hits on performance.=20
>=20
>    I thought we discussed this already endlessly and concluded that =
PNE does not help linkability.
>=20
>    Then an argument for ossification was broad up. However, we really =
cannot compare the situation here with TCP. With TCP everything is in =
the clear incl. also the retransmissions. In case of MPTCP this was =
rather the problem the the seq# because if you=E2=80=99d use the same =
seq# number space on both connections it would like loss but without a =
retransmission. Further boxes that reorder, usually do that in situation =
where packets were transmitted for a known reason out-of order =
previously, e.g. when multiple paths are used in the network. The =
recommendation we still give in the IETF transport area is that in such =
a situation the scheduling should not be done on a per-packet level but =
per-flow. However, those scheme that do per-packet scheduling usually =
also apply mechanism to re-order afterwards. They can just use the TCP =
seq# for that but for non-TCP they would simply add their own =
encapsulation with a seq#=E2=80=A6
>=20
>    Please keep in mind that even if an (unencrypted) PN gets ossified =
by the network,
>    in case of QUIC that does not mean that we can=E2=80=99t change the =
transport machinery anymore. Currently the exposed PN is also used for =
congestion control and retransmission, however, we can still add another =
PN in the encrypted part and resolved the fact that the current PN is =
overloaded for different functions.
>=20
>    Currently, I really still don=E2=80=99t see the benefit of PNE but =
only additional complexity and known performance degradation.
>=20
>    Mirja
>=20
>=20
>=20
>=20
>=20


From nobody Fri Apr 13 04:44:50 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEB812D7ED for ; Fri, 13 Apr 2018 04:44: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] 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 kcfGWpqRFriL for ; Fri, 13 Apr 2018 04:44:46 -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 76CF51274D2 for ; Fri, 13 Apr 2018 04:44:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 40MwtN0VwwzMqRr; Fri, 13 Apr 2018 13:44:44 +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 KnEtHOLp6weS; Fri, 13 Apr 2018 13:44:42 +0200 (CEST)
X-MtScore: NO score=0
Received: from [192.168.178.24] (i577BCE4C.versanet.de [87.123.206.76]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 13 Apr 2018 13:44:42 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Simple transform for improving PN ossification prevention
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= 
In-Reply-To: 
Date: Fri, 13 Apr 2018 13:44:40 +0200
Cc: huitema , "quic@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>  
To: Praveen Balasubramanian 
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Apr 2018 11:44:49 -0000

+1 if QUIC doesn=E2=80=99t get deployed large-scale because the =
performance impact is too high for certain use case, or is blocked on =
many paths by middleboxes that prefer the traffic to fall back to TCP, =
then no user will benefit from any privacy improvements with build into =
quic.

> Am 11.04.2018 um 19:06 schrieb Praveen Balasubramanian =
:
>=20
> Not just users, but web service providers are affected. As an =
implementer and someone who will need to convince workloads to adopt =
QUIC at scale, I have the view that we should minimize complexity and =
cost unless properly justified. Performance is going to be a key factor =
in getting adoption for this protocol. Whether we like It or not, =
HTTPS/QUIC will be judged against the stack HTTPS/TCP we have today. If =
90+ percentile latency improvements come at a large CPU cost, the =
incentive to move away from TCP will be less. Same holds if more battery =
is spent loading web pages on low power devices.=20
>=20
> I thought this discussion was focused on ossification but if we are =
talking about privacy, it is a complex topic and then we need an =
adversarial model, possible attacks, and clearly list the trade-offs for =
getting marginal improvements in privacy. The more mechanisms we add for =
preventing leakage of side channel information, the more complex the =
implementations and the cost.=20
>=20
> Before we make endpoints add perf overhead, create problems for =
hardware implementations, just plain break network signaling and health =
scenarios that work with TCP today, and make no attempts to mitigate =
aggressive UDP NAT timeouts, let's justify why. Also solutions may not =
be universally applicable - what is needed on the Internet (and across =
multiple paths) is very different from what is needed in constrained =
networks like datacenters or private single admin domain networks. This =
is a general purpose transport - so IMO we need to define mechanisms =
that support a range of trade-offs and make policy recommendations.
>=20
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian =
Huitema
> Sent: Wednesday, April 11, 2018 9:33 AM
> To: quic@ietf.org
> Subject: Re: Simple transform for improving PN ossification prevention
>=20
> On 4/11/2018 8:37 AM, Stephen Farrell wrote:
>=20
>> Personally, as a future user of QUIC (but not an implementer), I'd=20
>> really prefer that the WG prioritise privacy-friendly mechanisms if =
at=20
>> all possible, even if the direct benefits aren't completely clear.
>=20
> Second that. Praveen and Igor are making a fine point about =
performance, but in my book performance optimization should be done =
after we have the agreed functionality going. So, I would see the =
following sequence:
>=20
> 1) Agree that we want to prevent PN tracking, middlebox shenanigans, =
and ossification. I think we do have rough consensus on that.
>=20
> 2) Check in PR #1079 as a basic way to accomplish this now.
>=20
> 3) Study higher performance alternative and a negotiation mechanism =
later.
>=20
> -- Christian Huitema
>=20
>=20
>=20
>=20


From nobody Fri Apr 13 04:45:08 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAB012DA15 for ; Fri, 13 Apr 2018 04:44:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523619895; bh=XEGocPMzs0dVyHXqzNj2QZQKrxkxUzCQhRFP4PMWpm8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=wsuaFNOOKJEn8H9CbskEWVf355EPqa2IBRtWj4Gnod0JY8JriO452jVqOG60zA/Yq yq5iUW392FmR0esf1HaVXaKk0rN5mpoAmMKHJcoUkqwS5DQb4y72TH06q1j3FCNMNR 4jQroEawFxIS9v680PSQEa3tqBS4ijG+PG2f6WtM=
X-Mailbox-Line: From mirja.kuehlewind@tik.ee.ethz.ch Fri Apr 13 04:44:52 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3BA12D94B; Fri, 13 Apr 2018 04:44:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523619892; bh=XEGocPMzs0dVyHXqzNj2QZQKrxkxUzCQhRFP4PMWpm8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=WKLVS9c/PiX5B5ZM2rnwcb3PFWyiE6Khswwz+Zh7YaY578pdcjB2PDq3K2n9YzaaZ kMNpz5TcdfzB5RCNxdgvTwvPs9x0xHCgLn5vT0Kp5uRsF6KTz5NIZtaWoJiJ6uy2cj HO6wi4p0Dgl9q+3y9ZZXwyeN1C4Fl+rwdZodl2bY=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAB512D869 for ; Fri, 13 Apr 2018 04:44:50 -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=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF0xdBBGk8mA for ; Fri, 13 Apr 2018 04:44:47 -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 76A5B12711B for ; Fri, 13 Apr 2018 04:44:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 40MwtN0VwwzMqRr; Fri, 13 Apr 2018 13:44:44 +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 KnEtHOLp6weS; Fri, 13 Apr 2018 13:44:42 +0200 (CEST)
X-MtScore: NO score=0
Received: from [192.168.178.24] (i577BCE4C.versanet.de [87.123.206.76]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 13 Apr 2018 13:44:42 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Simple transform for improving PN ossification prevention
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= 
In-Reply-To: 
Date: Fri, 13 Apr 2018 13:44:40 +0200
Cc: huitema , "quic@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:       <0B77E9AA-A0D2-4E12-8349-7C35471AD346@fb.com>  <45FD804B-4CEC-439E-8296-D119C37D6CCB@fb.com> <04f541bb34ed4f87995641c0d95c866c@usma1ex-dag1mb5.msg.corp.akamai.com> <73e7e2e6-ce61-838e-89a7-b5b81e33035d@cs.tcd.ie>  
X-Mailer: Apple Mail (2.3445.6.18)
To: Praveen Balasubramanian 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Apr 2018 11:44:57 -0000

+1 if QUIC doesn=E2=80=99t get deployed large-scale because the =
performance impact is too high for certain use case, or is blocked on =
many paths by middleboxes that prefer the traffic to fall back to TCP, =
then no user will benefit from any privacy improvements with build into =
quic.

> Am 11.04.2018 um 19:06 schrieb Praveen Balasubramanian =
:
>=20
> Not just users, but web service providers are affected. As an =
implementer and someone who will need to convince workloads to adopt =
QUIC at scale, I have the view that we should minimize complexity and =
cost unless properly justified. Performance is going to be a key factor =
in getting adoption for this protocol. Whether we like It or not, =
HTTPS/QUIC will be judged against the stack HTTPS/TCP we have today. If =
90+ percentile latency improvements come at a large CPU cost, the =
incentive to move away from TCP will be less. Same holds if more battery =
is spent loading web pages on low power devices.=20
>=20
> I thought this discussion was focused on ossification but if we are =
talking about privacy, it is a complex topic and then we need an =
adversarial model, possible attacks, and clearly list the trade-offs for =
getting marginal improvements in privacy. The more mechanisms we add for =
preventing leakage of side channel information, the more complex the =
implementations and the cost.=20
>=20
> Before we make endpoints add perf overhead, create problems for =
hardware implementations, just plain break network signaling and health =
scenarios that work with TCP today, and make no attempts to mitigate =
aggressive UDP NAT timeouts, let's justify why. Also solutions may not =
be universally applicable - what is needed on the Internet (and across =
multiple paths) is very different from what is needed in constrained =
networks like datacenters or private single admin domain networks. This =
is a general purpose transport - so IMO we need to define mechanisms =
that support a range of trade-offs and make policy recommendations.
>=20
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian =
Huitema
> Sent: Wednesday, April 11, 2018 9:33 AM
> To: quic@ietf.org
> Subject: Re: Simple transform for improving PN ossification prevention
>=20
> On 4/11/2018 8:37 AM, Stephen Farrell wrote:
>=20
>> Personally, as a future user of QUIC (but not an implementer), I'd=20
>> really prefer that the WG prioritise privacy-friendly mechanisms if =
at=20
>> all possible, even if the direct benefits aren't completely clear.
>=20
> Second that. Praveen and Igor are making a fine point about =
performance, but in my book performance optimization should be done =
after we have the agreed functionality going. So, I would see the =
following sequence:
>=20
> 1) Agree that we want to prevent PN tracking, middlebox shenanigans, =
and ossification. I think we do have rough consensus on that.
>=20
> 2) Check in PR #1079 as a basic way to accomplish this now.
>=20
> 3) Study higher performance alternative and a negotiation mechanism =
later.
>=20
> -- Christian Huitema
>=20
>=20
>=20
>=20


From nobody Fri Apr 13 04:56:32 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596DF1270FC for ; Fri, 13 Apr 2018 04:56:30 -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 4WYYn4ksq21g for ; Fri, 13 Apr 2018 04:56:28 -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 062781242F7 for ; Fri, 13 Apr 2018 04:56:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 40Mx7t5ps3zMqS9; Fri, 13 Apr 2018 13:56:26 +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 OgIsiD3hmvNp; Fri, 13 Apr 2018 13:56:25 +0200 (CEST)
X-MtScore: NO score=0
Received: from [192.168.178.24] (i577BCE4C.versanet.de [87.123.206.76]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 13 Apr 2018 13:56:25 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Extension frame design question
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= 
In-Reply-To: 
Date: Fri, 13 Apr 2018 13:56:14 +0200
Cc: QUIC WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <8BE7205E-E65E-485E-96B9-7221EB78DEB5@tik.ee.ethz.ch>
References: 
To: Martin Thomson 
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Apr 2018 11:56:30 -0000

I guess another approach would be to have one extension frame type with =
a length field and an extension number (that is registered with IANA on =
a FCFS basis).

> Am 13.04.2018 um 04:42 schrieb Martin Thomson =
:
>=20
> We agreed to add the ability to extend QUIC in Melbourne (I know, it's
> so long ago, but it seems like just yesterday).  But we never never
> sealed the deal.
>=20
> While we agree in principle, and have agreed that the use of
> extensions will be signaled during the handshake using transport
> parameters (as opposed to the h2 model where they can just appear),
> we're locked in disagreement about the precise colour to use.  Right
> now there are three options:
>=20
> 1. As Victor originally proposed, provide a map from a large
> identifier space to the smaller space of extension frame types.  PR
> #1068 does that, mapping a 16-bit identifier into the 128-255 range of
> frame types.  Cost: indirection, complexity.  Advantage: It has a PR
> (i.e., nothing significant).
>=20
> 2. Use a varint for frame types. Cost: non-trivial change to the wire
> format for frames; large(r) overhead for sending a frame unless you
> get one of the privileged frame types that encode to a single octet
> (and we have used 3/8 of those already, so we'd probably want to be
> strict about registration policies in that space).  Advantage: simple.
>=20
> 3. A modification to PR #1068 proposed by Kazuho which would have
> every transport parameter carry a list of frame types with it.  Cost:
> similar indirection to PR #1068, and every transport parameter would
> carry this list.  The advantage being that an extension that defines a
> transport parameter would only touch a single transport parameter and
> not have to register an extension frame type as well.
>=20
> Now I prefer the first, but could live with either alternative if only
> we could decide.  So I'm asking for help.
>=20


From nobody Fri Apr 13 09:31:59 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71C112D88A for ; Fri, 13 Apr 2018 09:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dvyk9RBmr_x for ; Fri, 13 Apr 2018 09:31:48 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0096.outbound.protection.outlook.com [104.47.41.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E2C12DA00 for ; Fri, 13 Apr 2018 09:31:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SnI+z+V2cdJV66NzGBlNujpdAx0LlqAp16zt8Pmgjsk=; b=ln2weuy7v9t19HguqrMfXbYipvjzdqkyJLEpTvsHzV5za7MxlnHrvlTGRLauJUhMVUfZ+PTFTiUjCyOF/Uv97vibg7/mH4QOh6Bd0lbFYgzRSV1SnNKEPcJ2zXdFhSBe5R0fsc6UtOu8g/jbyRRUz/fTrWY9mIk96qL6zXQ26Wg=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1469.namprd08.prod.outlook.com (10.162.2.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.14; Fri, 13 Apr 2018 16:31:44 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0653.015; Fri, 13 Apr 2018 16:31:44 +0000
From: Mike Bishop 
To: Martin Thomson , Kazuho Oku 
CC: Praveen Balasubramanian , "IETF QUIC WG" , Ian Swett 
Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Thread-Index: AQHTzPOeIdtMxyMgr0ikidMd5Tq1W6P6QG/QgAAFTQCAACClkIADbdCAgAAPtoCAAAo0AIABAYXQ
Date: Fri, 13 Apr 2018 16:31:44 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>       <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; 
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1469; 7:wPE8DJaomijqmdNhIgJHU6a2uy7qVe/YdDTzp1iuCfivnlT5v6G6526Gsk0SuE5S/6EhsuC5hB4wgF4f9Hta6B3ORrrjFZpvTiAUFgNW23dmzcE4E7tjyMlE+okeRqWztF+diN7yhHLYDEQtjCIluebh1O3QUVEJcDvnkzPyM05GQUO+UVCGBfje+tyHPJhEv96zAUeAevulzBk3oHK/GH1vI+3qlT/XSXuqrC9cPS470hC67cpTe/8rH3cvNPle
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1469; 
x-ms-traffictypediagnostic: SN1PR08MB1469:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(131327999870524)(85827821059158)(100405760836317); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231232)(944501327)(52105095)(3002001)(10201501046)(6041310)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(2016111802025)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1469; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1469; 
x-forefront-prvs: 0641678E68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(346002)(376002)(366004)(39830400003)(377424004)(189003)(199004)(13464003)(6116002)(3846002)(476003)(446003)(11346002)(33656002)(74482002)(2900100001)(53936002)(99286004)(3660700001)(93886005)(59450400001)(97736004)(5250100002)(86362001)(14454004)(486006)(316002)(7696005)(478600001)(8676002)(2906002)(186003)(966005)(81156014)(81166006)(66066001)(4326008)(54906003)(110136005)(7736002)(76176011)(39060400002)(5660300001)(305945005)(74316002)(26005)(105586002)(6306002)(55016002)(9686003)(102836004)(6436002)(8936002)(25786009)(53546011)(6246003)(106356001)(3280700002)(6506007)(229853002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1469; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: qmo9j++I993o4oW9wM1Hi7JeLYGzwV7Qb5kXqXDMD3Jpb3YMHDwxDG2bQbyDzqqa9WFCRTBbC983fs5RET2HQYBk6KSF7xR2JeXlVuhN9hXMFCfE5CEwXvT+RuAj+slJWxyPyUakGnoqFQxycG/3CkvEOJjGTnYrcfGSabG0bei9bFApaUL1p0h0Zi1G20Ch
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: de428eee-ca9c-4124-77cd-08d5a15c0b91
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: de428eee-ca9c-4124-77cd-08d5a15c0b91
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2018 16:31:44.2970 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1469
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Apr 2018 16:31:57 -0000

KzEuICBUaGVyZSBhcmUgdG9vIG1hbnkgc2hhcnAgY29ybmVycyBvbiB0cnlpbmcgdG8gbWFrZSBt
aWdyYXRpb24gbG9vayBsaWtlIDAtUlRULCB3aGlsZSBzdGlsbCBlbmFibGluZyB0aGUgcmVjaXBp
ZW50IHRvIGtub3cgd2hpY2ggSW5pdGlhbC8wLVJUVCBwYWNrZXRzIGFyZSByZWFsbHkgSW5pdGlh
bC8wLVJUVCB3aXRoIGNvbnNpc3RlbmN5Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1h
cnRpbiBUaG9tc29uDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTIsIDIwMTggNjowOSBQTQ0KVG86
IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFt
YW5pYW4gPHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz47IElFVEYgUVVJQyBX
RyA8cXVpY0BpZXRmLm9yZz47IElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJj
LmlldGYub3JnPg0KU3ViamVjdDogUmU6IFByaXZhY3kgaG9sZXMgKHdhczogUmU6IEdldHRpbmcg
dG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbikNCg0KVGhpcyBpcyBhbHNv
IG15IHByZWZlcmVuY2UsIGluIGZ1bGwgcmVhbGl6YXRpb24gb2YgdGhlIGRvd25zaWRlcyBvZiB0
aGF0LiAgVHJ5aW5nIHRvIG1ha2UgbWlncmF0aW9uIGxvb2sgbGlrZSBhIGhhbmRzaGFrZSBpcyBh
bHNvIHJlYWxseSBoYXJkIHRvIGdldCByaWdodC4NCg0KT24gRnJpLCBBcHIgMTMsIDIwMTggYXQg
MTA6MzIgQU0sIEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+IHdyb3RlOg0KPiAyMDE4
LTA0LTEzIDg6MzYgR01UKzA5OjAwIElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRt
YXJjLmlldGYub3JnPjoNCj4+IFllcywgZm9yIGEgcG93ZXJmdWwgYWR2ZXJzYXJ5LCB0aGlzIHNl
ZW1zIGZhaXJseSB0cmFjdGFibGUuLg0KPj4NCj4+IE1ha2luZyBjb25uZWN0aW9uIG1pZ3JhdGlv
biBsb29rIGxpa2UgYSBuZXcgY29ubmVjdGlvbiB3b3VsZCBsaWtlbHkgDQo+PiBoZWxwIGEgbG90
Lg0KPg0KPiBJIGFtIG5vdCBzdXJlIGlmIHRoYXQgaXMgdGhlIHJpZ2h0IHBhdGguDQo+DQo+IFdl
IGhhdmUgdGhyZWUgd2F5cyBpbiB3aGljaCBhIG5ldyBzZXQgb2YgNS10dXBsZSBzdGFydHMgZ2V0
dGluZyB1c2VkLg0KPg0KPiAqIG5ldyBjb25uZWN0aW9uDQo+ICogdm9sdW50YXJ5IG1pZ3JhdGlv
bg0KPiAqIGludm9sdW50YXJ5IG1pZ3JhdGlvbiAoaS5lLiBOQVQgcmViaW5kaW5nKQ0KPg0KPiBG
b3IgdGhlIGludm9sdW50YXJ5IG1pZ3JhdGlvbiBjYXNlLCB0aGUgZmlyc3QgcGFja2V0IHdpbGwg
YWx3YXlzIGJlIGEgDQo+IHNob3J0IGhlYWRlciBwYWNrZXQuDQo+DQo+IElmIHdlIG1ha2Ugdm9s
dW50YXJ5IG1pZ3JhdGlvbiBsb29rIGxpa2UgYSBuZXcgY29ubmVjdGlvbiwgdGhlIGNoYW5jZSAN
Cj4gb2YgaW52b2x1bnRhcnkgbWlncmF0aW9uIGdldHRpbmcgYmxvY2tlZCBieSBhIG1pZGRsZWJv
eCBiZWNvbWVzIGhpZ2hlciANCj4gKGFzIHdlIGhhdmUgc2VlbiBnYXRld2F5cyBibG9ja2luZyB0
aGUgVExTIDEuMyByZWNvcmRzLCBvciB0aGUgJzA3Jw0KPiBjYXNlKS4NCj4NCj4gVGhlcmVmb3Jl
LCBteSBwcmVmZXJlbmNlIGdvZXMgdG8gbWFraW5nIGFsbCB0aGUgdGhyZWUgY2FzZXMgDQo+IGlu
ZGlzdGluZ3Vpc2hhYmxlICh3aGljaCBpcyBpZGVhbCBidXQgaGFyZCksIG9yIGtlZXBpbmcgdm9s
dW50YXJ5IGFuZCANCj4gbm9uLXZvbHVudGFyeSBtaWdyYXRpb24gbG9vayB0aGUgc2FtZSAoYXMg
d2UgZG8gbm93KSBhdCB0aGUgc2FtZSB0aW1lIA0KPiBtYWtpbmcgc3VyZSB0aGF0IHRoZSBtaWRk
bGVib3ggZGV2ZWxvcGVycyB1bmRlcnN0YW5kIG1pZ3JhdGlvbiBoYXBwZW5zIA0KPiBbMV0uDQo+
DQo+IFsxXSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3F1aWMvY3VycmVu
dC9tc2cwMzgyMC5odG1sDQo+DQo+PiBPbiBXZWQsIEFwciAxMSwgMjAxOCBhdCAzOjE4IFBNIFBy
YXZlZW4gQmFsYXN1YnJhbWFuaWFuIA0KPj4gPHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5p
ZXRmLm9yZz4gd3JvdGU6DQo+Pj4NCj4+PiBHb2luZyBiYWNrIHRvIENocmlzdGlhbidzIG9yaWdp
bmFsIHF1ZXN0aW9uIG9uIHByaXZhY3kgaG9sZXMsIHRoZXJlIA0KPj4+IGlzIGFuIGF0dGFjayBm
b3IgbGlua2luZyBJUCBhZGRyZXNzZXMgaW4gdGhlIHZvbHVudGFyeSBtaWdyYXRpb24gY2FzZS4N
Cj4+Pg0KPj4+IExldCdzIGNvbnNpZGVyIHRoZSBwYXJraW5nIGxvdCBwcm9ibGVtIG9yIGluIGdl
bmVyYWwgY2FzZSBsb3Npbmcgb25lIA0KPj4+IG5ldHdvcmsgYW5kIHJvYW1pbmcgdG8gYW5vdGhl
ciBuZXR3b3JrLiBUaGlzIGlzIHRoZSBwcmltYXJ5IHVzZSBjYXNlIA0KPj4+IGZvciBjb25uZWN0
aW9uIG1pZ3JhdGlvbi4gSW4gdGhpcyBjYXNlIGFsbCBhY3RpdmUgUVVJQyBjb25uZWN0aW9ucyAN
Cj4+PiB0aGF0IGNhbiBtaWdyYXRlLCB3aWxsIGRvIHNvLiBXaGVuIHRoZXNlIGNvbm5lY3Rpb25z
IG1pZ3JhdGUgdGhleSANCj4+PiBjYW4gY2hhbmdlIHRoZSBDSUQsIHRoZSBsb2NhbCBwb3J0IG51
bWJlciBhbmQgcGFja2V0IG51bWJlcnMuIA0KPj4+IEhvd2V2ZXIgZG8gbm90aWNlIHRoYXQgb25s
eSB0aGUgbG9jYWwgMi10dXBsZSBjaGFuZ2VzIGZvciBlYWNoIA0KPj4+IGNvbm5lY3Rpb24sIHRo
ZSBzZXJ2ZXIncyAyLXR1cGxlIHJlbWFpbnMgdGhlIHNhbWUuDQo+Pj4NCj4+PiBMZXQncyBhc3N1
bWUgYSBwb3dlcmZ1bCBhZHZlcnNhcnkgY2FuIGNvbGxlY3QgYSBuZXR3b3JrIHNuaWZmIG9mIGFs
bCANCj4+PiB0aGlzIHRyYWZmaWMgYW5kIGJ1aWxkcyBhIG1hc3NpdmUgZGF0YXNldC4gVGhlIGFk
dmVyc2FyeSBjYW4gdGhlbiANCj4+PiBydW4gYSBtYWNoaW5lIGxlYXJuaW5nIGFsZ29yaXRobSB0
byBpZGVudGlmeSB0aW1lIGluc3RhbnRzIHdoZXJlIGEgDQo+Pj4gYnVuY2ggb2YgY29ubmVjdGlv
bnMgY2hhbmdlIHRoZWlyIGxvY2FsIDItdHVwbGUgYXQgbmVhciB0aGUgc2FtZSANCj4+PiB0aW1l
IGluc3RhbnQgYnV0IGNvbnRpbnVlIGdvaW5nIHRvIHRoZSBzYW1lIHNlcnZlciBzaWRlIDItdHVw
bGVzLiANCj4+PiBUaGlzIHdpbGwgYWxsb3cgdGhlIGFkdmVyc2FyeSB0byBsaW5rIHR3byBJUCBh
ZGRyZXNzZXMuIFRoZSBtb3JlIA0KPj4+IHRpbWVzIHRoZSB1c2VyIHJvYW1zIGJldHdlZW4gbmV0
d29ya3MgYmFjayBhbmQgZm9ydGggdGhlIHJpY2hlciB0aGUgDQo+Pj4gY29ycmVsYXRpb24uIFRo
ZSBtb3JlIG9wZW4gY29ubmVjdGlvbnMgdG8gZGlmZmVyZW50IHNlcnZlcnMsIHRoZSANCj4+PiBy
aWNoZXIgdGhlIGNvcnJlbGF0aW9uLiBHZW9sb2NhdGlvbiBpbmZvcm1hdGlvbiBjYW4gbWluaW1p
emUgdGhlIG51bWJlciBvZiBhZGRyZXNzZXMgdGhlIGFkdmVyc2FyeSBuZWVkcyB0byBjb3JyZWxh
dGUuDQo+Pj4NCj4+PiBUaGUgZnVuZGFtZW50YWwgcHJvYmxlbSBzZWVtcyB0byBiZSB0aGF0IHRo
ZSBzdWJzdHJhdGUgaXMgVURQL0lQIGFuZCANCj4+PiBpdCBpcyBpbiB0aGUgY2xlYXIgYW5kIGFs
bG93cyBsaW5rYWJpbGl0eS4NCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
Pj4gRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IENocmlzdGlhbiANCj4+PiBIdWl0ZW1hDQo+Pj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDUsIDIw
MTggODozNCBBTQ0KPj4+IFRvOiBNaXJqYSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRp
ay5lZS5ldGh6LmNoPg0KPj4+IENjOiBxdWljQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUHJpdmFj
eSBob2xlcyAod2FzOiBSZTogR2V0dGluZyB0byBjb25zZW5zdXMgb24gcGFja2V0IA0KPj4+IG51
bWJlcg0KPj4+IGVuY3J5cHRpb24pDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gPiBPbiBBcHIgNSwgMjAx
OCwgYXQgMjoyNiBBTSwgTWlyamEgS8O8aGxld2luZCANCj4+PiA+IDxtaXJqYS5rdWVobGV3aW5k
QHRpay5lZS4uZXRoei5jaD4gd3JvdGU6DQo+Pj4gPiAuLi4NCj4+PiA+IFRpbWluZyBkb2VzbuKA
mXQgaGVscCBoZXJlIGVpdGhlciBiZWNhdXNlIHlvdSBzdGlsbCBoYXZlIHRoZSBzYW1lIA0KPj4+
ID4gZGVzdGluYXRpb24gSVAsIGJvdGggcG9ydCBudW1iZXJzIGFuZCB0aGUgZmFjdCB0aGF0IGEg
bWlncmF0ZWQgDQo+Pj4gPiBjb25uZWN0aW9uIGRvZXMgbm90IGhhdmUgYSBoYW5kc2hha2UuIElm
IHdlIHdhbnQgdG8gYWRkcmVzcyB0aGUgDQo+Pj4gPiBsaW5rYWJpbGl0eSBwcm9ibGVtLCB3ZSB3
b3VsZCBuZWVkIHRvIGRvIG11Y2ggbW9yZSwgcHJvYmFibHkgYmFyaW5nIG1vcmUgaGl0cyBvbiBw
ZXJmb3JtYW5jZS4NCj4+Pg0KPj4+IE1pcmphLA0KPj4+DQo+Pj4gWW91IHJpZ2h0bHkgcG9pbnQg
b3V0IHRoYXQgdGhlIGNvbm5lY3Rpb24gSUQgYW5kIHRoZSBQYWNrZXQgTnVtYmVyIA0KPj4+IGFy
ZSBub3QgdGhlIG9ubHkgZWxlbWVudHMgdGhhdCBwcm92aWRlIGxpbmthYmlsaXR5LiBUaGVyZSBp
cyBhbHNvIG9mIA0KPj4+IGNvdXJzZSB0aGUgVURQIHNvdXJjZSBwb3J0LiBUaGF0IG9uZSBpcyBu
b3QgbXVjaCBvZiBhbiBpc3N1ZSBmb3IgDQo+Pj4gc2VydmVycywgYnV0IGl0IGlzIGFuIGlzc3Vl
IGZvciBjbGllbnRzLiBXZSBhcmUgbm90IHNwZWxsaW5nIHRoYXQgDQo+Pj4gb3V0IGluIHRoZSBk
cmFmdC4gV2Ugc2hvdWxkLCBiZWNhdXNlIGNsaWVudHMgY2FuIHRyaXZpYWxseSBjbG9zZSB0aGF0
IGhvbGUgd2hlbiBkb2luZyBtaWdyYXRpb24uDQo+Pj4NCj4+PiBJIGFtIG5vdCBzdXJlIHRoYXQg
dGhlIGFic2VuY2Ugb2YgbmVnb3RpYXRpb24gZGl2dWxnZXMgbXVjaCBkYXRhLiBJdCANCj4+PiBt
YXJrcyB0aGUgcGF0aCBhcyBvcmlnaW5hdGluZyBmcm9tIGEgbWlncmF0aW9uLCBidXQgaXQgZG9l
cyBub3QgdGVsbCBmcm9tIHdoZXJlLg0KPj4+IEJ1dCB0aGVyZSBtaWdodCBiZSBhbiBvc3NpZmlj
YXRpb24gaXNzdWUuIFdlIHdpbGwgZ2V0IHRoYXQgDQo+Pj4gb3NzaWZpY2F0aW9uIGlmIHdlIHRy
YWluIG1pZGRsZWJveGVzIHRvIGJlbGlldmUgdGhhdCBjb25uZWN0aW9uIA0KPj4+IGFsd2F5cyBz
dGFydCB3aXRoIGFuIG9ic2VydmFibGUgbmVnb3RpYXRpb24uIFNvIG1heWJlIHdlIHNob3VsZCBl
eHBsb3JlIHdheXMgdG8gZ3JlYXNlIHRoYXQuDQo+Pj4NCj4+PiBBbnkgb3RoZXIgcHJpdmFjeSBo
b2xlIHRoYXQgd2Ugc2hvdWxkIGZpeD8NCj4+Pg0KPj4+IC0tIENocmlzdGlhbiBIdWl0ZW1hDQo+
DQo+DQo+DQo+IC0tDQo+IEthenVobyBPa3UNCj4NCg0K


From nobody Fri Apr 13 09:32:05 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8211273E2 for ; Fri, 13 Apr 2018 09:31:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523637119; bh=SnI+z+V2cdJV66NzGBlNujpdAx0LlqAp16zt8Pmgjsk=; h=From:To:Subject:Date:References:In-Reply-To:Cc:Cc:Cc; b=E2KNCTzg2pvSZsGVbauwsvuv2aaja5yHHv4Tdr/W7I48/NUcGSxPSggD1zL3ptxhw voOIqdT37KycBGDaVwVGc3gRRv8UgCRD8g+M0bbFxWVPTXzmW5Ucf1Ey4vZEhAO1JA uXpHdcIVA5AKatWSMPIYixbbD9skXoOZdK2Q0+0s=
X-Mailbox-Line: From mbishop@evequefou.be  Fri Apr 13 09:31:59 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E775412DA50; Fri, 13 Apr 2018 09:31:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523637119; bh=SnI+z+V2cdJV66NzGBlNujpdAx0LlqAp16zt8Pmgjsk=; h=From:To:Subject:Date:References:In-Reply-To:Cc:Cc:Cc; b=E2KNCTzg2pvSZsGVbauwsvuv2aaja5yHHv4Tdr/W7I48/NUcGSxPSggD1zL3ptxhw voOIqdT37KycBGDaVwVGc3gRRv8UgCRD8g+M0bbFxWVPTXzmW5Ucf1Ey4vZEhAO1JA uXpHdcIVA5AKatWSMPIYixbbD9skXoOZdK2Q0+0s=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B42412D7ED; Fri, 13 Apr 2018 09:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O4ztH8R5JJC; Fri, 13 Apr 2018 09:31:48 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E8B12DA04; Fri, 13 Apr 2018 09:31:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SnI+z+V2cdJV66NzGBlNujpdAx0LlqAp16zt8Pmgjsk=; b=ln2weuy7v9t19HguqrMfXbYipvjzdqkyJLEpTvsHzV5za7MxlnHrvlTGRLauJUhMVUfZ+PTFTiUjCyOF/Uv97vibg7/mH4QOh6Bd0lbFYgzRSV1SnNKEPcJ2zXdFhSBe5R0fsc6UtOu8g/jbyRRUz/fTrWY9mIk96qL6zXQ26Wg=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1469.namprd08.prod.outlook.com (10.162.2.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.14; Fri, 13 Apr 2018 16:31:44 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0653.015; Fri, 13 Apr 2018 16:31:44 +0000
From: Mike Bishop 
To: Martin Thomson , Kazuho Oku 
Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Thread-Index: AQHTzPOeIdtMxyMgr0ikidMd5Tq1W6P6QG/QgAAFTQCAACClkIADbdCAgAAPtoCAAAo0AIABAYXQ
Date: Fri, 13 Apr 2018 16:31:44 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>       <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; 
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1469; 7:wPE8DJaomijqmdNhIgJHU6a2uy7qVe/YdDTzp1iuCfivnlT5v6G6526Gsk0SuE5S/6EhsuC5hB4wgF4f9Hta6B3ORrrjFZpvTiAUFgNW23dmzcE4E7tjyMlE+okeRqWztF+diN7yhHLYDEQtjCIluebh1O3QUVEJcDvnkzPyM05GQUO+UVCGBfje+tyHPJhEv96zAUeAevulzBk3oHK/GH1vI+3qlT/XSXuqrC9cPS470hC67cpTe/8rH3cvNPle
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1469; 
x-ms-traffictypediagnostic: SN1PR08MB1469:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(131327999870524)(85827821059158)(100405760836317); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231232)(944501327)(52105095)(3002001)(10201501046)(6041310)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(2016111802025)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1469; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1469; 
x-forefront-prvs: 0641678E68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(346002)(376002)(366004)(39830400003)(377424004)(189003)(199004)(13464003)(6116002)(3846002)(476003)(446003)(11346002)(33656002)(74482002)(2900100001)(53936002)(99286004)(3660700001)(93886005)(59450400001)(97736004)(5250100002)(86362001)(14454004)(486006)(316002)(7696005)(478600001)(8676002)(2906002)(186003)(966005)(81156014)(81166006)(66066001)(4326008)(54906003)(110136005)(7736002)(76176011)(39060400002)(5660300001)(305945005)(74316002)(26005)(105586002)(6306002)(55016002)(9686003)(102836004)(6436002)(8936002)(25786009)(53546011)(6246003)(106356001)(3280700002)(6506007)(229853002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1469; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: qmo9j++I993o4oW9wM1Hi7JeLYGzwV7Qb5kXqXDMD3Jpb3YMHDwxDG2bQbyDzqqa9WFCRTBbC983fs5RET2HQYBk6KSF7xR2JeXlVuhN9hXMFCfE5CEwXvT+RuAj+slJWxyPyUakGnoqFQxycG/3CkvEOJjGTnYrcfGSabG0bei9bFApaUL1p0h0Zi1G20Ch
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: de428eee-ca9c-4124-77cd-08d5a15c0b91
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: de428eee-ca9c-4124-77cd-08d5a15c0b91
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2018 16:31:44.2970 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1469
Cc: Praveen Balasubramanian 
Cc: IETF QUIC WG 
Cc: Ian Swett 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Apr 2018 16:31:59 -0000

KzEuICBUaGVyZSBhcmUgdG9vIG1hbnkgc2hhcnAgY29ybmVycyBvbiB0cnlpbmcgdG8gbWFrZSBt
aWdyYXRpb24gbG9vayBsaWtlIDAtUlRULCB3aGlsZSBzdGlsbCBlbmFibGluZyB0aGUgcmVjaXBp
ZW50IHRvIGtub3cgd2hpY2ggSW5pdGlhbC8wLVJUVCBwYWNrZXRzIGFyZSByZWFsbHkgSW5pdGlh
bC8wLVJUVCB3aXRoIGNvbnNpc3RlbmN5Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1h
cnRpbiBUaG9tc29uDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTIsIDIwMTggNjowOSBQTQ0KVG86
IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFt
YW5pYW4gPHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz47IElFVEYgUVVJQyBX
RyA8cXVpY0BpZXRmLm9yZz47IElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJj
LmlldGYub3JnPg0KU3ViamVjdDogUmU6IFByaXZhY3kgaG9sZXMgKHdhczogUmU6IEdldHRpbmcg
dG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbikNCg0KVGhpcyBpcyBhbHNv
IG15IHByZWZlcmVuY2UsIGluIGZ1bGwgcmVhbGl6YXRpb24gb2YgdGhlIGRvd25zaWRlcyBvZiB0
aGF0LiAgVHJ5aW5nIHRvIG1ha2UgbWlncmF0aW9uIGxvb2sgbGlrZSBhIGhhbmRzaGFrZSBpcyBh
bHNvIHJlYWxseSBoYXJkIHRvIGdldCByaWdodC4NCg0KT24gRnJpLCBBcHIgMTMsIDIwMTggYXQg
MTA6MzIgQU0sIEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+IHdyb3RlOg0KPiAyMDE4
LTA0LTEzIDg6MzYgR01UKzA5OjAwIElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRt
YXJjLmlldGYub3JnPjoNCj4+IFllcywgZm9yIGEgcG93ZXJmdWwgYWR2ZXJzYXJ5LCB0aGlzIHNl
ZW1zIGZhaXJseSB0cmFjdGFibGUuLg0KPj4NCj4+IE1ha2luZyBjb25uZWN0aW9uIG1pZ3JhdGlv
biBsb29rIGxpa2UgYSBuZXcgY29ubmVjdGlvbiB3b3VsZCBsaWtlbHkgDQo+PiBoZWxwIGEgbG90
Lg0KPg0KPiBJIGFtIG5vdCBzdXJlIGlmIHRoYXQgaXMgdGhlIHJpZ2h0IHBhdGguDQo+DQo+IFdl
IGhhdmUgdGhyZWUgd2F5cyBpbiB3aGljaCBhIG5ldyBzZXQgb2YgNS10dXBsZSBzdGFydHMgZ2V0
dGluZyB1c2VkLg0KPg0KPiAqIG5ldyBjb25uZWN0aW9uDQo+ICogdm9sdW50YXJ5IG1pZ3JhdGlv
bg0KPiAqIGludm9sdW50YXJ5IG1pZ3JhdGlvbiAoaS5lLiBOQVQgcmViaW5kaW5nKQ0KPg0KPiBG
b3IgdGhlIGludm9sdW50YXJ5IG1pZ3JhdGlvbiBjYXNlLCB0aGUgZmlyc3QgcGFja2V0IHdpbGwg
YWx3YXlzIGJlIGEgDQo+IHNob3J0IGhlYWRlciBwYWNrZXQuDQo+DQo+IElmIHdlIG1ha2Ugdm9s
dW50YXJ5IG1pZ3JhdGlvbiBsb29rIGxpa2UgYSBuZXcgY29ubmVjdGlvbiwgdGhlIGNoYW5jZSAN
Cj4gb2YgaW52b2x1bnRhcnkgbWlncmF0aW9uIGdldHRpbmcgYmxvY2tlZCBieSBhIG1pZGRsZWJv
eCBiZWNvbWVzIGhpZ2hlciANCj4gKGFzIHdlIGhhdmUgc2VlbiBnYXRld2F5cyBibG9ja2luZyB0
aGUgVExTIDEuMyByZWNvcmRzLCBvciB0aGUgJzA3Jw0KPiBjYXNlKS4NCj4NCj4gVGhlcmVmb3Jl
LCBteSBwcmVmZXJlbmNlIGdvZXMgdG8gbWFraW5nIGFsbCB0aGUgdGhyZWUgY2FzZXMgDQo+IGlu
ZGlzdGluZ3Vpc2hhYmxlICh3aGljaCBpcyBpZGVhbCBidXQgaGFyZCksIG9yIGtlZXBpbmcgdm9s
dW50YXJ5IGFuZCANCj4gbm9uLXZvbHVudGFyeSBtaWdyYXRpb24gbG9vayB0aGUgc2FtZSAoYXMg
d2UgZG8gbm93KSBhdCB0aGUgc2FtZSB0aW1lIA0KPiBtYWtpbmcgc3VyZSB0aGF0IHRoZSBtaWRk
bGVib3ggZGV2ZWxvcGVycyB1bmRlcnN0YW5kIG1pZ3JhdGlvbiBoYXBwZW5zIA0KPiBbMV0uDQo+
DQo+IFsxXSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3F1aWMvY3VycmVu
dC9tc2cwMzgyMC5odG1sDQo+DQo+PiBPbiBXZWQsIEFwciAxMSwgMjAxOCBhdCAzOjE4IFBNIFBy
YXZlZW4gQmFsYXN1YnJhbWFuaWFuIA0KPj4gPHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5p
ZXRmLm9yZz4gd3JvdGU6DQo+Pj4NCj4+PiBHb2luZyBiYWNrIHRvIENocmlzdGlhbidzIG9yaWdp
bmFsIHF1ZXN0aW9uIG9uIHByaXZhY3kgaG9sZXMsIHRoZXJlIA0KPj4+IGlzIGFuIGF0dGFjayBm
b3IgbGlua2luZyBJUCBhZGRyZXNzZXMgaW4gdGhlIHZvbHVudGFyeSBtaWdyYXRpb24gY2FzZS4N
Cj4+Pg0KPj4+IExldCdzIGNvbnNpZGVyIHRoZSBwYXJraW5nIGxvdCBwcm9ibGVtIG9yIGluIGdl
bmVyYWwgY2FzZSBsb3Npbmcgb25lIA0KPj4+IG5ldHdvcmsgYW5kIHJvYW1pbmcgdG8gYW5vdGhl
ciBuZXR3b3JrLiBUaGlzIGlzIHRoZSBwcmltYXJ5IHVzZSBjYXNlIA0KPj4+IGZvciBjb25uZWN0
aW9uIG1pZ3JhdGlvbi4gSW4gdGhpcyBjYXNlIGFsbCBhY3RpdmUgUVVJQyBjb25uZWN0aW9ucyAN
Cj4+PiB0aGF0IGNhbiBtaWdyYXRlLCB3aWxsIGRvIHNvLiBXaGVuIHRoZXNlIGNvbm5lY3Rpb25z
IG1pZ3JhdGUgdGhleSANCj4+PiBjYW4gY2hhbmdlIHRoZSBDSUQsIHRoZSBsb2NhbCBwb3J0IG51
bWJlciBhbmQgcGFja2V0IG51bWJlcnMuIA0KPj4+IEhvd2V2ZXIgZG8gbm90aWNlIHRoYXQgb25s
eSB0aGUgbG9jYWwgMi10dXBsZSBjaGFuZ2VzIGZvciBlYWNoIA0KPj4+IGNvbm5lY3Rpb24sIHRo
ZSBzZXJ2ZXIncyAyLXR1cGxlIHJlbWFpbnMgdGhlIHNhbWUuDQo+Pj4NCj4+PiBMZXQncyBhc3N1
bWUgYSBwb3dlcmZ1bCBhZHZlcnNhcnkgY2FuIGNvbGxlY3QgYSBuZXR3b3JrIHNuaWZmIG9mIGFs
bCANCj4+PiB0aGlzIHRyYWZmaWMgYW5kIGJ1aWxkcyBhIG1hc3NpdmUgZGF0YXNldC4gVGhlIGFk
dmVyc2FyeSBjYW4gdGhlbiANCj4+PiBydW4gYSBtYWNoaW5lIGxlYXJuaW5nIGFsZ29yaXRobSB0
byBpZGVudGlmeSB0aW1lIGluc3RhbnRzIHdoZXJlIGEgDQo+Pj4gYnVuY2ggb2YgY29ubmVjdGlv
bnMgY2hhbmdlIHRoZWlyIGxvY2FsIDItdHVwbGUgYXQgbmVhciB0aGUgc2FtZSANCj4+PiB0aW1l
IGluc3RhbnQgYnV0IGNvbnRpbnVlIGdvaW5nIHRvIHRoZSBzYW1lIHNlcnZlciBzaWRlIDItdHVw
bGVzLiANCj4+PiBUaGlzIHdpbGwgYWxsb3cgdGhlIGFkdmVyc2FyeSB0byBsaW5rIHR3byBJUCBh
ZGRyZXNzZXMuIFRoZSBtb3JlIA0KPj4+IHRpbWVzIHRoZSB1c2VyIHJvYW1zIGJldHdlZW4gbmV0
d29ya3MgYmFjayBhbmQgZm9ydGggdGhlIHJpY2hlciB0aGUgDQo+Pj4gY29ycmVsYXRpb24uIFRo
ZSBtb3JlIG9wZW4gY29ubmVjdGlvbnMgdG8gZGlmZmVyZW50IHNlcnZlcnMsIHRoZSANCj4+PiBy
aWNoZXIgdGhlIGNvcnJlbGF0aW9uLiBHZW9sb2NhdGlvbiBpbmZvcm1hdGlvbiBjYW4gbWluaW1p
emUgdGhlIG51bWJlciBvZiBhZGRyZXNzZXMgdGhlIGFkdmVyc2FyeSBuZWVkcyB0byBjb3JyZWxh
dGUuDQo+Pj4NCj4+PiBUaGUgZnVuZGFtZW50YWwgcHJvYmxlbSBzZWVtcyB0byBiZSB0aGF0IHRo
ZSBzdWJzdHJhdGUgaXMgVURQL0lQIGFuZCANCj4+PiBpdCBpcyBpbiB0aGUgY2xlYXIgYW5kIGFs
bG93cyBsaW5rYWJpbGl0eS4NCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
Pj4gRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IENocmlzdGlhbiANCj4+PiBIdWl0ZW1hDQo+Pj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDUsIDIw
MTggODozNCBBTQ0KPj4+IFRvOiBNaXJqYSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRp
ay5lZS5ldGh6LmNoPg0KPj4+IENjOiBxdWljQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUHJpdmFj
eSBob2xlcyAod2FzOiBSZTogR2V0dGluZyB0byBjb25zZW5zdXMgb24gcGFja2V0IA0KPj4+IG51
bWJlcg0KPj4+IGVuY3J5cHRpb24pDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gPiBPbiBBcHIgNSwgMjAx
OCwgYXQgMjoyNiBBTSwgTWlyamEgS8O8aGxld2luZCANCj4+PiA+IDxtaXJqYS5rdWVobGV3aW5k
QHRpay5lZS4uZXRoei5jaD4gd3JvdGU6DQo+Pj4gPiAuLi4NCj4+PiA+IFRpbWluZyBkb2VzbuKA
mXQgaGVscCBoZXJlIGVpdGhlciBiZWNhdXNlIHlvdSBzdGlsbCBoYXZlIHRoZSBzYW1lIA0KPj4+
ID4gZGVzdGluYXRpb24gSVAsIGJvdGggcG9ydCBudW1iZXJzIGFuZCB0aGUgZmFjdCB0aGF0IGEg
bWlncmF0ZWQgDQo+Pj4gPiBjb25uZWN0aW9uIGRvZXMgbm90IGhhdmUgYSBoYW5kc2hha2UuIElm
IHdlIHdhbnQgdG8gYWRkcmVzcyB0aGUgDQo+Pj4gPiBsaW5rYWJpbGl0eSBwcm9ibGVtLCB3ZSB3
b3VsZCBuZWVkIHRvIGRvIG11Y2ggbW9yZSwgcHJvYmFibHkgYmFyaW5nIG1vcmUgaGl0cyBvbiBw
ZXJmb3JtYW5jZS4NCj4+Pg0KPj4+IE1pcmphLA0KPj4+DQo+Pj4gWW91IHJpZ2h0bHkgcG9pbnQg
b3V0IHRoYXQgdGhlIGNvbm5lY3Rpb24gSUQgYW5kIHRoZSBQYWNrZXQgTnVtYmVyIA0KPj4+IGFy
ZSBub3QgdGhlIG9ubHkgZWxlbWVudHMgdGhhdCBwcm92aWRlIGxpbmthYmlsaXR5LiBUaGVyZSBp
cyBhbHNvIG9mIA0KPj4+IGNvdXJzZSB0aGUgVURQIHNvdXJjZSBwb3J0LiBUaGF0IG9uZSBpcyBu
b3QgbXVjaCBvZiBhbiBpc3N1ZSBmb3IgDQo+Pj4gc2VydmVycywgYnV0IGl0IGlzIGFuIGlzc3Vl
IGZvciBjbGllbnRzLiBXZSBhcmUgbm90IHNwZWxsaW5nIHRoYXQgDQo+Pj4gb3V0IGluIHRoZSBk
cmFmdC4gV2Ugc2hvdWxkLCBiZWNhdXNlIGNsaWVudHMgY2FuIHRyaXZpYWxseSBjbG9zZSB0aGF0
IGhvbGUgd2hlbiBkb2luZyBtaWdyYXRpb24uDQo+Pj4NCj4+PiBJIGFtIG5vdCBzdXJlIHRoYXQg
dGhlIGFic2VuY2Ugb2YgbmVnb3RpYXRpb24gZGl2dWxnZXMgbXVjaCBkYXRhLiBJdCANCj4+PiBt
YXJrcyB0aGUgcGF0aCBhcyBvcmlnaW5hdGluZyBmcm9tIGEgbWlncmF0aW9uLCBidXQgaXQgZG9l
cyBub3QgdGVsbCBmcm9tIHdoZXJlLg0KPj4+IEJ1dCB0aGVyZSBtaWdodCBiZSBhbiBvc3NpZmlj
YXRpb24gaXNzdWUuIFdlIHdpbGwgZ2V0IHRoYXQgDQo+Pj4gb3NzaWZpY2F0aW9uIGlmIHdlIHRy
YWluIG1pZGRsZWJveGVzIHRvIGJlbGlldmUgdGhhdCBjb25uZWN0aW9uIA0KPj4+IGFsd2F5cyBz
dGFydCB3aXRoIGFuIG9ic2VydmFibGUgbmVnb3RpYXRpb24uIFNvIG1heWJlIHdlIHNob3VsZCBl
eHBsb3JlIHdheXMgdG8gZ3JlYXNlIHRoYXQuDQo+Pj4NCj4+PiBBbnkgb3RoZXIgcHJpdmFjeSBo
b2xlIHRoYXQgd2Ugc2hvdWxkIGZpeD8NCj4+Pg0KPj4+IC0tIENocmlzdGlhbiBIdWl0ZW1hDQo+
DQo+DQo+DQo+IC0tDQo+IEthenVobyBPa3UNCj4NCg0K


From nobody Fri Apr 13 09:37:41 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B043212741D for ; Fri, 13 Apr 2018 09:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 T1G7VV8ZuQPL for ; Fri, 13 Apr 2018 09:37:38 -0700 (PDT)
Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824ED1273E2 for ; Fri, 13 Apr 2018 09:37:38 -0700 (PDT)
Received: by mail-ot0-x236.google.com with SMTP id m22-v6so10508676otf.8 for ; Fri, 13 Apr 2018 09:37:38 -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=ZBWxzG4ISU77kt2oB8AfjHEoiVTXP2LJWwAMGp16WHY=; b=jWxKJt3eh/0ei1iJXT4+9g6zPc01LaObH2DlE6Andw14AEJS1/bVKQAPguKInxRIUB 0ZaPwGeWPNCaoUpM7QqehTWs8QqlZ0AQOiGYPdV3+9SEvR84vZGx7WWI7ADDdQvTtbCy Zdgb5nBwxxsWX7k2VDwjMU+bOrhPao6qfW7RSdqsMhoNZ5dXUFvWgfhze8Se2PcyQ5aw VaG8QtsFiTFSLvfUhkGJtT90eCO3wtjw9W0rzy0E5YmSvHLGlYwl26GypmtyftxIXYUe yALT3W5EddMi2nk1Ltb+EjjZaPVU3sJuZNxIcILdAi9Su1/jPum9epEEdkyL5/8QQoKX tz8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=ZBWxzG4ISU77kt2oB8AfjHEoiVTXP2LJWwAMGp16WHY=; b=R5ZKADmwLA02RS4iA4fa3ZPXuLUwpwhP92agOu7XtRSu3V9TGV5XLGtor7BQNu01M9 LO/dY+lU8wuP3enM2V9Wp4sQiV/vsOx+neuRW2rOi1tzzT5q/iIzgkR+btGyEXSEAVTe 0/nToNNsnmDay3PFV2Y6MUzvwx+tSrythZarkK12+jJrTo5HqGqsDV9pkiIlgcX6cmN/ B+tYCuXhziHdeV2lxCYCIgdsfiNzIRJUUvOesNe8opNUrnx5k0xemKnrx71UBpcCzjrW t1/O3qyMURNfxI3Is+d5JBl5wfo9kXwcrTZVRDKIFvKIG2gnwh+vBjr0iw3VEC5mg/Sq FzcA==
X-Gm-Message-State: ALQs6tBgLl46iwcY5B2P8ki/ivqsQJsuH6/7qFJ5MRXTwxSHHOp/opYQ XImJOPQShipsz0y3ZGgyOJMn1IyppNONQtK3LgDgVg==
X-Google-Smtp-Source: AIpwx4/6X+BFIN5dbmSz8AIfO5DRLtP2VFlA9udIhFqJbybN83ycP4xqRcOb2hE9qhcpJ0eNLEUCVt9SXfR2ebJe3ko=
X-Received: by 2002:a9d:36dc:: with SMTP id s28-v6mr19229otd.214.1523637457779;  Fri, 13 Apr 2018 09:37:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.138.18.130 with HTTP; Fri, 13 Apr 2018 09:36:57 -0700 (PDT)
In-Reply-To: 
References: 
From: Eric Rescorla 
Date: Fri, 13 Apr 2018 09:36:57 -0700
Message-ID: 
Subject: Re: Extension frame design question
To: Martin Thomson 
Cc: QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000007011120569bd7d8b"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Apr 2018 16:37:41 -0000

--0000000000007011120569bd7d8b
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 12, 2018 at 7:42 PM, Martin Thomson 
wrote:

> We agreed to add the ability to extend QUIC in Melbourne (I know, it's
> so long ago, but it seems like just yesterday).  But we never never
> sealed the deal.
>
> While we agree in principle, and have agreed that the use of
> extensions will be signaled during the handshake using transport
> parameters (as opposed to the h2 model where they can just appear),
> we're locked in disagreement about the precise colour to use.  Right
> now there are three options:
>

As I said in my email, I do think that this is more than just a purely
aesthetic
issue. The fundamental question is whether one wants to be able to negotiate
(or signal or whatever) extensions which involve both a new frame type
and some parameter negotiation. For instance "I support message frames,
but don't make them longer than 200 bytes". In that case, with the design
in PR#1068 that just contains a map table, you either have to have a second
transport parameter to negotiate the per-extension parameter (with the
risk of mismatch) or you need two ways to establish the mapping table.

It might be useful to talk a bit about principles and constraints. My basic
assumption is that it's not important for non-standardized extensions to
have *very* short frames. I.e., it would be fine if their frame type
identifiers
were 4 bytes. If that's so, then we have a lot of room and we don't need
to worry about mapping. This would be compatible with either a varint
or a "extension" frame as Mirja suggests. And then when you wanted to
standardize you would get a short type (varint is slightly better here).

On the other hand, if you think it's important to have very short frames
for non-standardized extensions then you need some sort of mapping
thing.

-Ekr


> 1. As Victor originally proposed, provide a map from a large
> identifier space to the smaller space of extension frame types.  PR
> #1068 does that, mapping a 16-bit identifier into the 128-255 range of
> frame types.  Cost: indirection, complexity.  Advantage: It has a PR
> (i.e., nothing significant).
>
> 2. Use a varint for frame types. Cost: non-trivial change to the wire
> format for frames; large(r) overhead for sending a frame unless you
> get one of the privileged frame types that encode to a single octet
> (and we have used 3/8 of those already, so we'd probably want to be
> strict about registration policies in that space).  Advantage: simple.
>
> 3. A modification to PR #1068 proposed by Kazuho which would have
> every transport parameter carry a list of frame types with it.  Cost:
> similar indirection to PR #1068, and every transport parameter would
> carry this list.  The advantage being that an extension that defines a
> transport parameter would only touch a single transport parameter and
> not have to register an extension frame type as well.
>
> Now I prefer the first, but could live with either alternative if only
> we could decide.  So I'm asking for help.
>
>

--0000000000007011120569bd7d8b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Apr 12, 2018 at 7:42 PM, Martin Thomson <<=
a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson=
@gmail.com> wrote:
We agree=
d to add the ability to extend QUIC in Melbourne (I know, it's

so long ago, but it seems like just yesterday).=C2=A0 But we never never
sealed the deal.



While we agree in principle, and have agreed that the use of

extensions will be signaled during the handshake using transport

parameters (as opposed to the h2 model where they can just appear),

we're locked in disagreement about the precise colour to use.=C2=A0 Rig=
ht

now there are three options:

As I said =
in my email, I do think that this is more than just a purely aesthetic
issue. The fundamental question is whether one wants to be able to ne=
gotiate
(or signal or whatever) extensions which involve both a n=
ew frame type
and some parameter negotiation. For instance "=
I support message frames,
but don't make them longer than 200=
 bytes". In that case, with the design
in PR#1068 that just =
contains a map table, you either have to have a second
transport =
parameter to negotiate the per-extension parameter (with the
risk of mismatch) or you need two ways to establish the m=
apping table.

It might be useful to talk a bit about principles and constraints. =
My basic
assumption is that it's not im=
portant for non-standardized extensions to
=
have *very* short frames. I.e., it would be fine if their frame type identi=
fiers
were 4 bytes. If that's so, then =
we have a lot of room and we don't need
to worry about mapping. This would be compatible with either a varint
or a "extension" frame as Mirja sugge=
sts. And then when you wanted to
standardiz=
e you would get a short type (varint is slightly better here).

On the other h=
and, if you think it's important to have very short frames
for non-standardized extensions then you need some sort=
 of mapping
thing.

-Ekr




1. As Victor originally proposed, provide a map from a large

identifier space to the smaller space of extension frame types.=C2=A0 PR
#1068 does that, mapping a 16-bit identifier into the 128-255 range of

frame types.=C2=A0 Cost: indirection, complexity.=C2=A0 Advantage: It has a=
 PR

(i.e., nothing significant).



2. Use a varint for frame types. Cost: non-trivial change to the wire

format for frames; large(r) overhead for sending a frame unless you

get one of the privileged frame types that encode to a single octet

(and we have used 3/8 of those already, so we'd probably want to be

strict about registration policies in that space).=C2=A0 Advantage: simple.=




3. A modification to PR #1068 proposed by Kazuho which would have

every transport parameter carry a list of frame types with it.=C2=A0 Cost:<=
br>
similar indirection to PR #1068, and every transport parameter would

carry this list.=C2=A0 The advantage being that an extension that defines a=


transport parameter would only touch a single transport parameter and

not have to register an extension frame type as well.



Now I prefer the first, but could live with either alternative if only

we could decide.=C2=A0 So I'm asking for help.







--0000000000007011120569bd7d8b--


From nobody Fri Apr 13 09:54:00 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03247126CE8 for ; Fri, 13 Apr 2018 09:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 FF5TJ6xY40Sy for ; Fri, 13 Apr 2018 09:53:55 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10112.outbound.protection.outlook.com [40.107.1.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D9D124234 for ; Fri, 13 Apr 2018 09:53:54 -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=HPWePwqzQM4ds76bi8lGezQq6/84avQC3Bj4hxV5Bl0=; b=U13dUS+FLv0M4nQoVagNMnL4z0Qu3Iop4zcfSzWinVs2ppzyV/m5JFvXYufhkCeQlby7YwzxqOfb2brm0cmlLYc0wytANL3gYiGy2P+u05rUvKHJHaOkjPA+xSaSgpZ9DThoRI6BczGstopU0WbJca3J9maz40fxSl+hlubuBOg=
Received: from VI1PR0702MB3613.eurprd07.prod.outlook.com (52.134.1.138) by VI1PR0702MB3583.eurprd07.prod.outlook.com (52.134.6.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.4; Fri, 13 Apr 2018 16:53:51 +0000
Received: from VI1PR0702MB3613.eurprd07.prod.outlook.com ([fe80::c03c:d251:49e1:e7e4]) by VI1PR0702MB3613.eurprd07.prod.outlook.com ([fe80::c03c:d251:49e1:e7e4%4]) with mapi id 15.20.0675.006; Fri, 13 Apr 2018 16:53:51 +0000
From: "Swindells, Thomas (Nokia - GB/Cambridge)" 
To: Eric Rescorla , Martin Thomson 
CC: QUIC WG 
Subject: RE: Extension frame design question
Thread-Topic: Extension frame design question
Thread-Index: AQHT0tELhkzr66rBFkqMeGepqCRXqaP+5aSAgAADX8A=
Date: Fri, 13 Apr 2018 16:53:51 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.swindells@nokia.com; 
x-originating-ip: [82.69.101.84]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0702MB3583; 7:pJr/XvIbcyws0Gm1lg6RiXGcO2Db3xyigdQMRil5fqpo2N2DV7X2qnFb+9bcAdZ19V8VpZpmh+15/S3tNZ5FcQqJZT3fS+b53pD5JDGe1C4tCSP+UFYvGPbwb2/o7g6iyhUjyzLcLrG28tH2RfcW49byMf3oWnSallKj2/Fkq2YU4W1O7Gm92XRFheCKeITeBA3aqPPuG5s6D1jIbDJROA6JpafpR6hGUnvGugdUVmFkxAtjMBoMmRyB6420oRJe
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:VI1PR0702MB3583; 
x-ms-traffictypediagnostic: VI1PR0702MB3583:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231232)(11241501184)(806099)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR0702MB3583; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0702MB3583; 
x-forefront-prvs: 0641678E68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(376002)(346002)(366004)(39860400002)(199004)(189003)(105586002)(446003)(66066001)(39060400002)(6116002)(106356001)(7736002)(5660300001)(68736007)(3846002)(5250100002)(3660700001)(3280700002)(97736004)(102836004)(33656002)(229853002)(8676002)(186003)(4326008)(26005)(8936002)(74316002)(790700001)(3480700004)(2906002)(25786009)(81156014)(81166006)(2900100001)(99286004)(86362001)(53936002)(6246003)(14454004)(236005)(486006)(59450400001)(53546011)(316002)(6436002)(478600001)(54896002)(6506007)(6306002)(7696005)(55016002)(76176011)(476003)(110136005)(11346002)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0702MB3583; H:VI1PR0702MB3613.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: HprxQr/uJuIjf0LcZNwdH5g3//f4KBCHFc4UelqGdwPk88nX26tV6ke9cdhYBfVbZgLNhA/Yq/dnt+CI7cC8y+BUWMwPCP84auZEUBMlJL/NFhh1IqpP2xWrwCIjR9YdiMhPWdXxvGXmgKX24yvkqomz9IOQ1IRqilfTgzVokO0Jg/036ULIToj4+bRcl7Aewcm+qKgXlBoEX4kLh59zH/kx5ZgC4yoJhQhqwC67NBs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR0702MB3613CECA79C9B3D522ADD3D584B30VI1PR0702MB3613_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 0e093b08-42b7-40d5-3236-08d5a15f22bd
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e093b08-42b7-40d5-3236-08d5a15f22bd
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2018 16:53:51.8612 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0702MB3583
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Apr 2018 16:53:59 -0000

--_000_VI1PR0702MB3613CECA79C9B3D522ADD3D584B30VI1PR0702MB3613_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

T25lIG9mIHRoZSBsZXNzb25zIGxlYXJudCBmcm9tIEhUVFAgaXMgdGhhdCB5b3UgZG9u4oCZdCBn
ZXQgdGhlIG9wdGlvbiB0byBzdGFuZGFyZGl6ZSBvbmNlIGFuIOKAmGV4cGVyaW1lbnRhbOKAmSBm
ZWF0dXJlIGlzIHdpZGVseSBkZXBsb3llZC4gVGhhdCBpcyB3aHkgWC0gcHJlZml4ZXMgb24gaHR0
cCBoZWFkZXJzIHdhcyBkZXByZWNhdGVkOiBpdCB3YXMgcmVhbGlzZWQgY2xpZW50cyBoYWQgYWxy
ZWFkeSBvc3NpZmllZCBvbiB1c2luZyB0aGUgZXhwZXJpbWVudGFsIHZhbHVlIGFuZCB5b3Ugd2Vy
ZSBzdHVjayB3aXRoIGl0IGZvciBhIHZlcnkgbG9uZyB0aW1lLCBldmVuIGlmIHlvdSBpbnRyb2R1
Y2VkIGEgc3RhbmRhcmRpemVkIHZlcnNpb24gb2YgdGhlIGZlYXR1cmUgdGhlIG5vbi1zdGFuZGFy
ZCB1c2FnZSBzdGlsbCBsaXZlcyBvbiBhbmQgaGFzIHRvIGJlIHN1cHBvcnRlZC4NCg0KQmFzZWQg
b24gdGhpcywgSSBkb27igJl0IHRoaW5rIHdlIGNhbiBkaXN0aW5ndWlzaCBzdWZmaWNpZW50bHkg
YmV0d2VlbiDigJhub24tc3RhbmRhcmRpemVk4oCZIGFuZCDigJhzdGFuZGFyZGl6ZWTigJkgZXh0
ZW5zaW9ucywgYW5kIGlmIHdlIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBoYXZlIHZlcnkgc2hv
cnQgZnJhbWVzIGF0IGFsbCAoSeKAmW0gbm90IG1ha2luZyBhIGNhbGwgb24gdGhhdCkgdGhlbiB0
aGUgbWFwcGluZyB0aGluZyBpcyByZXF1aXJlZC4NCg0KVGhvbWFzDQoNCkZyb206IFFVSUMgW21h
aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpT
ZW50OiBGcmlkYXksIEFwcmlsIDEzLCAyMDE4IDU6MzcgUE0NClRvOiBNYXJ0aW4gVGhvbXNvbiA8
bWFydGluLnRob21zb25AZ21haWwuY29tPg0KQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpT
dWJqZWN0OiBSZTogRXh0ZW5zaW9uIGZyYW1lIGRlc2lnbiBxdWVzdGlvbg0KDQoNCg0KT24gVGh1
LCBBcHIgMTIsIDIwMTggYXQgNzo0MiBQTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29u
QGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpXZSBh
Z3JlZWQgdG8gYWRkIHRoZSBhYmlsaXR5IHRvIGV4dGVuZCBRVUlDIGluIE1lbGJvdXJuZSAoSSBr
bm93LCBpdCdzDQpzbyBsb25nIGFnbywgYnV0IGl0IHNlZW1zIGxpa2UganVzdCB5ZXN0ZXJkYXkp
LiAgQnV0IHdlIG5ldmVyIG5ldmVyDQpzZWFsZWQgdGhlIGRlYWwuDQoNCldoaWxlIHdlIGFncmVl
IGluIHByaW5jaXBsZSwgYW5kIGhhdmUgYWdyZWVkIHRoYXQgdGhlIHVzZSBvZg0KZXh0ZW5zaW9u
cyB3aWxsIGJlIHNpZ25hbGVkIGR1cmluZyB0aGUgaGFuZHNoYWtlIHVzaW5nIHRyYW5zcG9ydA0K
cGFyYW1ldGVycyAoYXMgb3Bwb3NlZCB0byB0aGUgaDIgbW9kZWwgd2hlcmUgdGhleSBjYW4ganVz
dCBhcHBlYXIpLA0Kd2UncmUgbG9ja2VkIGluIGRpc2FncmVlbWVudCBhYm91dCB0aGUgcHJlY2lz
ZSBjb2xvdXIgdG8gdXNlLiAgUmlnaHQNCm5vdyB0aGVyZSBhcmUgdGhyZWUgb3B0aW9uczoNCg0K
QXMgSSBzYWlkIGluIG15IGVtYWlsLCBJIGRvIHRoaW5rIHRoYXQgdGhpcyBpcyBtb3JlIHRoYW4g
anVzdCBhIHB1cmVseSBhZXN0aGV0aWMNCmlzc3VlLiBUaGUgZnVuZGFtZW50YWwgcXVlc3Rpb24g
aXMgd2hldGhlciBvbmUgd2FudHMgdG8gYmUgYWJsZSB0byBuZWdvdGlhdGUNCihvciBzaWduYWwg
b3Igd2hhdGV2ZXIpIGV4dGVuc2lvbnMgd2hpY2ggaW52b2x2ZSBib3RoIGEgbmV3IGZyYW1lIHR5
cGUNCmFuZCBzb21lIHBhcmFtZXRlciBuZWdvdGlhdGlvbi4gRm9yIGluc3RhbmNlICJJIHN1cHBv
cnQgbWVzc2FnZSBmcmFtZXMsDQpidXQgZG9uJ3QgbWFrZSB0aGVtIGxvbmdlciB0aGFuIDIwMCBi
eXRlcyIuIEluIHRoYXQgY2FzZSwgd2l0aCB0aGUgZGVzaWduDQppbiBQUiMxMDY4IHRoYXQganVz
dCBjb250YWlucyBhIG1hcCB0YWJsZSwgeW91IGVpdGhlciBoYXZlIHRvIGhhdmUgYSBzZWNvbmQN
CnRyYW5zcG9ydCBwYXJhbWV0ZXIgdG8gbmVnb3RpYXRlIHRoZSBwZXItZXh0ZW5zaW9uIHBhcmFt
ZXRlciAod2l0aCB0aGUNCnJpc2sgb2YgbWlzbWF0Y2gpIG9yIHlvdSBuZWVkIHR3byB3YXlzIHRv
IGVzdGFibGlzaCB0aGUgbWFwcGluZyB0YWJsZS4NCg0KSXQgbWlnaHQgYmUgdXNlZnVsIHRvIHRh
bGsgYSBiaXQgYWJvdXQgcHJpbmNpcGxlcyBhbmQgY29uc3RyYWludHMuIE15IGJhc2ljDQphc3N1
bXB0aW9uIGlzIHRoYXQgaXQncyBub3QgaW1wb3J0YW50IGZvciBub24tc3RhbmRhcmRpemVkIGV4
dGVuc2lvbnMgdG8NCmhhdmUgKnZlcnkqIHNob3J0IGZyYW1lcy4gSS5lLiwgaXQgd291bGQgYmUg
ZmluZSBpZiB0aGVpciBmcmFtZSB0eXBlIGlkZW50aWZpZXJzDQp3ZXJlIDQgYnl0ZXMuIElmIHRo
YXQncyBzbywgdGhlbiB3ZSBoYXZlIGEgbG90IG9mIHJvb20gYW5kIHdlIGRvbid0IG5lZWQNCnRv
IHdvcnJ5IGFib3V0IG1hcHBpbmcuIFRoaXMgd291bGQgYmUgY29tcGF0aWJsZSB3aXRoIGVpdGhl
ciBhIHZhcmludA0Kb3IgYSAiZXh0ZW5zaW9uIiBmcmFtZSBhcyBNaXJqYSBzdWdnZXN0cy4gQW5k
IHRoZW4gd2hlbiB5b3Ugd2FudGVkIHRvDQpzdGFuZGFyZGl6ZSB5b3Ugd291bGQgZ2V0IGEgc2hv
cnQgdHlwZSAodmFyaW50IGlzIHNsaWdodGx5IGJldHRlciBoZXJlKS4NCg0KT24gdGhlIG90aGVy
IGhhbmQsIGlmIHlvdSB0aGluayBpdCdzIGltcG9ydGFudCB0byBoYXZlIHZlcnkgc2hvcnQgZnJh
bWVzDQpmb3Igbm9uLXN0YW5kYXJkaXplZCBleHRlbnNpb25zIHRoZW4geW91IG5lZWQgc29tZSBz
b3J0IG9mIG1hcHBpbmcNCnRoaW5nLg0KDQotRWtyDQoNCg0KMS4gQXMgVmljdG9yIG9yaWdpbmFs
bHkgcHJvcG9zZWQsIHByb3ZpZGUgYSBtYXAgZnJvbSBhIGxhcmdlDQppZGVudGlmaWVyIHNwYWNl
IHRvIHRoZSBzbWFsbGVyIHNwYWNlIG9mIGV4dGVuc2lvbiBmcmFtZSB0eXBlcy4gIFBSDQojMTA2
OCBkb2VzIHRoYXQsIG1hcHBpbmcgYSAxNi1iaXQgaWRlbnRpZmllciBpbnRvIHRoZSAxMjgtMjU1
IHJhbmdlIG9mDQpmcmFtZSB0eXBlcy4gIENvc3Q6IGluZGlyZWN0aW9uLCBjb21wbGV4aXR5LiAg
QWR2YW50YWdlOiBJdCBoYXMgYSBQUg0KKGkuZS4sIG5vdGhpbmcgc2lnbmlmaWNhbnQpLg0KDQoy
LiBVc2UgYSB2YXJpbnQgZm9yIGZyYW1lIHR5cGVzLiBDb3N0OiBub24tdHJpdmlhbCBjaGFuZ2Ug
dG8gdGhlIHdpcmUNCmZvcm1hdCBmb3IgZnJhbWVzOyBsYXJnZShyKSBvdmVyaGVhZCBmb3Igc2Vu
ZGluZyBhIGZyYW1lIHVubGVzcyB5b3UNCmdldCBvbmUgb2YgdGhlIHByaXZpbGVnZWQgZnJhbWUg
dHlwZXMgdGhhdCBlbmNvZGUgdG8gYSBzaW5nbGUgb2N0ZXQNCihhbmQgd2UgaGF2ZSB1c2VkIDMv
OCBvZiB0aG9zZSBhbHJlYWR5LCBzbyB3ZSdkIHByb2JhYmx5IHdhbnQgdG8gYmUNCnN0cmljdCBh
Ym91dCByZWdpc3RyYXRpb24gcG9saWNpZXMgaW4gdGhhdCBzcGFjZSkuICBBZHZhbnRhZ2U6IHNp
bXBsZS4NCg0KMy4gQSBtb2RpZmljYXRpb24gdG8gUFIgIzEwNjggcHJvcG9zZWQgYnkgS2F6dWhv
IHdoaWNoIHdvdWxkIGhhdmUNCmV2ZXJ5IHRyYW5zcG9ydCBwYXJhbWV0ZXIgY2FycnkgYSBsaXN0
IG9mIGZyYW1lIHR5cGVzIHdpdGggaXQuICBDb3N0Og0Kc2ltaWxhciBpbmRpcmVjdGlvbiB0byBQ
UiAjMTA2OCwgYW5kIGV2ZXJ5IHRyYW5zcG9ydCBwYXJhbWV0ZXIgd291bGQNCmNhcnJ5IHRoaXMg
bGlzdC4gIFRoZSBhZHZhbnRhZ2UgYmVpbmcgdGhhdCBhbiBleHRlbnNpb24gdGhhdCBkZWZpbmVz
IGENCnRyYW5zcG9ydCBwYXJhbWV0ZXIgd291bGQgb25seSB0b3VjaCBhIHNpbmdsZSB0cmFuc3Bv
cnQgcGFyYW1ldGVyIGFuZA0Kbm90IGhhdmUgdG8gcmVnaXN0ZXIgYW4gZXh0ZW5zaW9uIGZyYW1l
IHR5cGUgYXMgd2VsbC4NCg0KTm93IEkgcHJlZmVyIHRoZSBmaXJzdCwgYnV0IGNvdWxkIGxpdmUg
d2l0aCBlaXRoZXIgYWx0ZXJuYXRpdmUgaWYgb25seQ0Kd2UgY291bGQgZGVjaWRlLiAgU28gSSdt
IGFza2luZyBmb3IgaGVscC4NCg0K

--_000_VI1PR0702MB3613CECA79C9B3D522ADD3D584B30VI1PR0702MB3613_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K
ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h
eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9
IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl
YXN0LWxhbmd1YWdlOkVOLVVTIj5PbmUgb2YgdGhlIGxlc3NvbnMgbGVhcm50IGZyb20gSFRUUCBp
cyB0aGF0IHlvdSBkb27igJl0IGdldCB0aGUgb3B0aW9uIHRvIHN0YW5kYXJkaXplIG9uY2UgYW4g
4oCYZXhwZXJpbWVudGFs4oCZIGZlYXR1cmUgaXMgd2lkZWx5IGRlcGxveWVkLiBUaGF0IGlzIHdo
eSBYLSBwcmVmaXhlcyBvbiBodHRwIGhlYWRlcnMgd2FzIGRlcHJlY2F0ZWQ6IGl0IHdhcw0KIHJl
YWxpc2VkIGNsaWVudHMgaGFkIGFscmVhZHkgb3NzaWZpZWQgb24gdXNpbmcgdGhlIGV4cGVyaW1l
bnRhbCB2YWx1ZSBhbmQgeW91IHdlcmUgc3R1Y2sgd2l0aCBpdCBmb3IgYSB2ZXJ5IGxvbmcgdGlt
ZSwgZXZlbiBpZiB5b3UgaW50cm9kdWNlZCBhIHN0YW5kYXJkaXplZCB2ZXJzaW9uIG9mIHRoZSBm
ZWF0dXJlIHRoZSBub24tc3RhbmRhcmQgdXNhZ2Ugc3RpbGwgbGl2ZXMgb24gYW5kIGhhcyB0byBi
ZSBzdXBwb3J0ZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1VUyI+QmFzZWQgb24gdGhpcywgSSBkb27igJl0IHRoaW5rIHdlIGNh
biBkaXN0aW5ndWlzaCBzdWZmaWNpZW50bHkgYmV0d2VlbiDigJhub24tc3RhbmRhcmRpemVk4oCZ
IGFuZCDigJhzdGFuZGFyZGl6ZWTigJkgZXh0ZW5zaW9ucywgYW5kIGlmIHdlIHRoaW5rIGl0IGlz
IGltcG9ydGFudCB0byBoYXZlIHZlcnkgc2hvcnQgZnJhbWVzIGF0IGFsbCAoSeKAmW0gbm90IG1h
a2luZw0KIGEgY2FsbCBvbiB0aGF0KSB0aGVuIHRoZSBtYXBwaW5nIHRoaW5nIGlzIHJlcXVpcmVk
LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn
ZTpFTi1VUyI+VGhvbWFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHls
ZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF
Ti1VUyI+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg
T2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAxMywg
MjAxOCA1OjM3IFBNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRo
b21zb25AZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUVVJQyBXRyAmbHQ7cXVpY0BpZXRm
Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEV4dGVuc2lvbiBmcmFtZSBkZXNpZ24g
cXVlc3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEFwciAxMiwgMjAxOCBh
dCA3OjQyIFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9t
c29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwv
YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2
LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPldlIGFncmVlZCB0byBhZGQgdGhlIGFiaWxpdHkgdG8gZXh0ZW5kIFFVSUMgaW4gTWVs
Ym91cm5lIChJIGtub3csIGl0J3M8YnI+DQpzbyBsb25nIGFnbywgYnV0IGl0IHNlZW1zIGxpa2Ug
anVzdCB5ZXN0ZXJkYXkpLiZuYnNwOyBCdXQgd2UgbmV2ZXIgbmV2ZXI8YnI+DQpzZWFsZWQgdGhl
IGRlYWwuPGJyPg0KPGJyPg0KV2hpbGUgd2UgYWdyZWUgaW4gcHJpbmNpcGxlLCBhbmQgaGF2ZSBh
Z3JlZWQgdGhhdCB0aGUgdXNlIG9mPGJyPg0KZXh0ZW5zaW9ucyB3aWxsIGJlIHNpZ25hbGVkIGR1
cmluZyB0aGUgaGFuZHNoYWtlIHVzaW5nIHRyYW5zcG9ydDxicj4NCnBhcmFtZXRlcnMgKGFzIG9w
cG9zZWQgdG8gdGhlIGgyIG1vZGVsIHdoZXJlIHRoZXkgY2FuIGp1c3QgYXBwZWFyKSw8YnI+DQp3
ZSdyZSBsb2NrZWQgaW4gZGlzYWdyZWVtZW50IGFib3V0IHRoZSBwcmVjaXNlIGNvbG91ciB0byB1
c2UuJm5ic3A7IFJpZ2h0PGJyPg0Kbm93IHRoZXJlIGFyZSB0aHJlZSBvcHRpb25zOjxvOnA+PC9v
OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMg
SSBzYWlkIGluIG15IGVtYWlsLCBJIGRvIHRoaW5rIHRoYXQgdGhpcyBpcyBtb3JlIHRoYW4ganVz
dCBhIHB1cmVseSBhZXN0aGV0aWM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPmlzc3VlLiBUaGUgZnVuZGFtZW50YWwgcXVlc3Rpb24gaXMgd2hldGhl
ciBvbmUgd2FudHMgdG8gYmUgYWJsZSB0byBuZWdvdGlhdGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihvciBzaWduYWwgb3Igd2hhdGV2ZXIpIGV4
dGVuc2lvbnMgd2hpY2ggaW52b2x2ZSBib3RoIGEgbmV3IGZyYW1lIHR5cGU8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCBzb21lIHBhcmFtZXRl
ciBuZWdvdGlhdGlvbi4gRm9yIGluc3RhbmNlICZxdW90O0kgc3VwcG9ydCBtZXNzYWdlIGZyYW1l
cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1
dCBkb24ndCBtYWtlIHRoZW0gbG9uZ2VyIHRoYW4gMjAwIGJ5dGVzJnF1b3Q7LiBJbiB0aGF0IGNh
c2UsIHdpdGggdGhlIGRlc2lnbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+aW4gUFIjMTA2OCB0aGF0IGp1c3QgY29udGFpbnMgYSBtYXAgdGFibGUs
IHlvdSBlaXRoZXIgaGF2ZSB0byBoYXZlIGEgc2Vjb25kPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50cmFuc3BvcnQgcGFyYW1ldGVyIHRvIG5lZ290
aWF0ZSB0aGUgcGVyLWV4dGVuc2lvbiBwYXJhbWV0ZXIgKHdpdGggdGhlPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yaXNrIG9mIG1pc21hdGNoKSBv
ciB5b3UgbmVlZCB0d28gd2F5cyB0byBlc3RhYmxpc2ggdGhlIG1hcHBpbmcgdGFibGUuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IG1pZ2h0
IGJlIHVzZWZ1bCB0byB0YWxrIGEgYml0IGFib3V0IHByaW5jaXBsZXMgYW5kIGNvbnN0cmFpbnRz
LiBNeSBiYXNpYzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+YXNzdW1wdGlvbiBpcyB0aGF0IGl0J3Mgbm90IGltcG9ydGFudCBmb3Igbm9uLXN0YW5k
YXJkaXplZCBleHRlbnNpb25zIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5oYXZlICp2ZXJ5KiBzaG9ydCBmcmFtZXMuIEkuZS4sIGl0IHdvdWxk
IGJlIGZpbmUgaWYgdGhlaXIgZnJhbWUgdHlwZSBpZGVudGlmaWVyczxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2VyZSA0IGJ5dGVzLiBJZiB0aGF0
J3Mgc28sIHRoZW4gd2UgaGF2ZSBhIGxvdCBvZiByb29tIGFuZCB3ZSBkb24ndCBuZWVkPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50byB3b3JyeSBh
Ym91dCBtYXBwaW5nLiBUaGlzIHdvdWxkIGJlIGNvbXBhdGlibGUgd2l0aCBlaXRoZXIgYSB2YXJp
bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9y
IGEgJnF1b3Q7ZXh0ZW5zaW9uJnF1b3Q7IGZyYW1lIGFzIE1pcmphIHN1Z2dlc3RzLiBBbmQgdGhl
biB3aGVuIHlvdSB3YW50ZWQgdG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPnN0YW5kYXJkaXplIHlvdSB3b3VsZCBnZXQgYSBzaG9ydCB0eXBlICh2
YXJpbnQgaXMgc2xpZ2h0bHkgYmV0dGVyIGhlcmUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiB0aGUgb3RoZXIgaGFuZCwgaWYgeW91IHRo
aW5rIGl0J3MgaW1wb3J0YW50IHRvIGhhdmUgdmVyeSBzaG9ydCBmcmFtZXM8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZvciBub24tc3RhbmRhcmRp
emVkIGV4dGVuc2lvbnMgdGhlbiB5b3UgbmVlZCBzb21lIHNvcnQgb2YgbWFwcGluZzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhpbmcuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t
RWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2
LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KMS4gQXMgVmljdG9yIG9y
aWdpbmFsbHkgcHJvcG9zZWQsIHByb3ZpZGUgYSBtYXAgZnJvbSBhIGxhcmdlPGJyPg0KaWRlbnRp
ZmllciBzcGFjZSB0byB0aGUgc21hbGxlciBzcGFjZSBvZiBleHRlbnNpb24gZnJhbWUgdHlwZXMu
Jm5ic3A7IFBSPGJyPg0KIzEwNjggZG9lcyB0aGF0LCBtYXBwaW5nIGEgMTYtYml0IGlkZW50aWZp
ZXIgaW50byB0aGUgMTI4LTI1NSByYW5nZSBvZjxicj4NCmZyYW1lIHR5cGVzLiZuYnNwOyBDb3N0
OiBpbmRpcmVjdGlvbiwgY29tcGxleGl0eS4mbmJzcDsgQWR2YW50YWdlOiBJdCBoYXMgYSBQUjxi
cj4NCihpLmUuLCBub3RoaW5nIHNpZ25pZmljYW50KS48YnI+DQo8YnI+DQoyLiBVc2UgYSB2YXJp
bnQgZm9yIGZyYW1lIHR5cGVzLiBDb3N0OiBub24tdHJpdmlhbCBjaGFuZ2UgdG8gdGhlIHdpcmU8
YnI+DQpmb3JtYXQgZm9yIGZyYW1lczsgbGFyZ2Uocikgb3ZlcmhlYWQgZm9yIHNlbmRpbmcgYSBm
cmFtZSB1bmxlc3MgeW91PGJyPg0KZ2V0IG9uZSBvZiB0aGUgcHJpdmlsZWdlZCBmcmFtZSB0eXBl
cyB0aGF0IGVuY29kZSB0byBhIHNpbmdsZSBvY3RldDxicj4NCihhbmQgd2UgaGF2ZSB1c2VkIDMv
OCBvZiB0aG9zZSBhbHJlYWR5LCBzbyB3ZSdkIHByb2JhYmx5IHdhbnQgdG8gYmU8YnI+DQpzdHJp
Y3QgYWJvdXQgcmVnaXN0cmF0aW9uIHBvbGljaWVzIGluIHRoYXQgc3BhY2UpLiZuYnNwOyBBZHZh
bnRhZ2U6IHNpbXBsZS48YnI+DQo8YnI+DQozLiBBIG1vZGlmaWNhdGlvbiB0byBQUiAjMTA2OCBw
cm9wb3NlZCBieSBLYXp1aG8gd2hpY2ggd291bGQgaGF2ZTxicj4NCmV2ZXJ5IHRyYW5zcG9ydCBw
YXJhbWV0ZXIgY2FycnkgYSBsaXN0IG9mIGZyYW1lIHR5cGVzIHdpdGggaXQuJm5ic3A7IENvc3Q6
PGJyPg0Kc2ltaWxhciBpbmRpcmVjdGlvbiB0byBQUiAjMTA2OCwgYW5kIGV2ZXJ5IHRyYW5zcG9y
dCBwYXJhbWV0ZXIgd291bGQ8YnI+DQpjYXJyeSB0aGlzIGxpc3QuJm5ic3A7IFRoZSBhZHZhbnRh
Z2UgYmVpbmcgdGhhdCBhbiBleHRlbnNpb24gdGhhdCBkZWZpbmVzIGE8YnI+DQp0cmFuc3BvcnQg
cGFyYW1ldGVyIHdvdWxkIG9ubHkgdG91Y2ggYSBzaW5nbGUgdHJhbnNwb3J0IHBhcmFtZXRlciBh
bmQ8YnI+DQpub3QgaGF2ZSB0byByZWdpc3RlciBhbiBleHRlbnNpb24gZnJhbWUgdHlwZSBhcyB3
ZWxsLjxicj4NCjxicj4NCk5vdyBJIHByZWZlciB0aGUgZmlyc3QsIGJ1dCBjb3VsZCBsaXZlIHdp
dGggZWl0aGVyIGFsdGVybmF0aXZlIGlmIG9ubHk8YnI+DQp3ZSBjb3VsZCBkZWNpZGUuJm5ic3A7
IFNvIEknbSBhc2tpbmcgZm9yIGhlbHAuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_VI1PR0702MB3613CECA79C9B3D522ADD3D584B30VI1PR0702MB3613_--


From nobody Fri Apr 13 09:57:55 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB1D126CE8 for ; Fri, 13 Apr 2018 09:57:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 YQEPuSwpoXxE for ; Fri, 13 Apr 2018 09:57:50 -0700 (PDT)
Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B7D124234 for ; Fri, 13 Apr 2018 09:57:50 -0700 (PDT)
Received: by mail-ot0-x233.google.com with SMTP id m3-v6so1477131ote.12 for ; Fri, 13 Apr 2018 09:57:50 -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=vDI3v7hwDerFC7QR2AhY4yoQ4GrLAGOqlbTRIXiO670=; b=LbuERio4FKLGQjAiFjlvWwjnz70ol6GS4D6+uVd2E/IJcH/qmCQN1npt6DTfBOy4GD p+CnW+5bdVY32zoaGsyx4tEVEJlK+yMu3q4RScylHB97qchByRaERt1h9EWCJGheozDH +AG1Q4U1l+GOAc8qvT6ylhikrblfqHngc0iwFR5AmuLS/5Nk5lcfNkXH/sMXMBhckSe/ 1ALRuZHtNxeciR6WYMgw9a3evtJxxIuleaIxS89FvCS4cXcdVx4np/3BrNyoXblLtjPz DjgzzWjKIMxvW5qOBxV7ZJO670sLawEfJyGE7MA5zjmLNCE38t0FHi4z1LcDjOaGCDBo eiqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=vDI3v7hwDerFC7QR2AhY4yoQ4GrLAGOqlbTRIXiO670=; b=EwBdFj2//jo0o7IEtw0Tl5bDzfPrA2gak5KXeWKOV1DtcHkEpVOgJhjWu+JWuoi1Vj gtVbRvRoln9oNs+Hnecn874Ml0c+umxqwiwOzycvTECd7MaXHcYdsNWF0Rd9hmUdFmrM eV/bfevoYS1ht+m3p/eT9HwEUiFY+mvgIRK/hwtM59+391jLI3RlY5m6MYDNVdIOP3Pj LB6ZUZpLmkJ0k5cw0vy94Mgup7kCeNGtm5F6EONtuKWFjfFofK0RSwx1/qm4nlfGeCXU 9sEL+Fo3tnjGA/OyysfolN2va21d41rKW9wcEZxZJ9tzIY7kT7O9UctprySM08HQBzs1 ctxA==
X-Gm-Message-State: ALQs6tALMiy1wP2zD40z8G3l63cHj+2QHM8MjUPfyPobePc5912L2Amm o+oU6PhKjYP4jdb5hhgfTu73pUhxAds9FQETeVD8aw==
X-Google-Smtp-Source: AIpwx49qHKH75WrGg/A3hOcgNqGia0oyh8F253Vv+5RhwFiLKBahX/BtuAT6/JyMqUrs/IijpryZC1LUkelqN8YV1wo=
X-Received: by 2002:a9d:5919:: with SMTP id t25-v6mr577846oth.217.1523638670128;  Fri, 13 Apr 2018 09:57:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.138.18.130 with HTTP; Fri, 13 Apr 2018 09:57:09 -0700 (PDT)
In-Reply-To: 
References:   
From: Eric Rescorla 
Date: Fri, 13 Apr 2018 09:57:09 -0700
Message-ID: 
Subject: Re: Extension frame design question
To: "Swindells, Thomas (Nokia - GB/Cambridge)" 
Cc: Martin Thomson , QUIC WG 
Content-Type: multipart/alternative; boundary="000000000000b30fcc0569bdc57d"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Apr 2018 16:57:53 -0000

--000000000000b30fcc0569bdc57d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I can understand how someone might draw that conclusion, but i don't think
it's really applicable here because these values are negotiated, not just
announced. Thus, it's not problematic to use one code point in initial
deployment and then define a new, short code point upon standardization.
It's true you probably have to support both code points in perpetuity, but
that's mostly just a matter of a small number of bytes in the parameter
negotiation

-Ekr


On Fri, Apr 13, 2018 at 9:53 AM, Swindells, Thomas (Nokia - GB/Cambridge) <
thomas.swindells@nokia.com> wrote:

> One of the lessons learnt from HTTP is that you don=E2=80=99t get the opt=
ion to
> standardize once an =E2=80=98experimental=E2=80=99 feature is widely depl=
oyed. That is why
> X- prefixes on http headers was deprecated: it was realised clients had
> already ossified on using the experimental value and you were stuck with =
it
> for a very long time, even if you introduced a standardized version of th=
e
> feature the non-standard usage still lives on and has to be supported.
>
>
>
> Based on this, I don=E2=80=99t think we can distinguish sufficiently betw=
een
> =E2=80=98non-standardized=E2=80=99 and =E2=80=98standardized=E2=80=99 ext=
ensions, and if we think it is
> important to have very short frames at all (I=E2=80=99m not making a call=
 on that)
> then the mapping thing is required.
>
>
>
> Thomas
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Friday, April 13, 2018 5:37 PM
> *To:* Martin Thomson 
> *Cc:* QUIC WG 
> *Subject:* Re: Extension frame design question
>
>
>
>
>
>
>
> On Thu, Apr 12, 2018 at 7:42 PM, Martin Thomson 
> wrote:
>
> We agreed to add the ability to extend QUIC in Melbourne (I know, it's
> so long ago, but it seems like just yesterday).  But we never never
> sealed the deal.
>
> While we agree in principle, and have agreed that the use of
> extensions will be signaled during the handshake using transport
> parameters (as opposed to the h2 model where they can just appear),
> we're locked in disagreement about the precise colour to use.  Right
> now there are three options:
>
>
>
> As I said in my email, I do think that this is more than just a purely
> aesthetic
>
> issue. The fundamental question is whether one wants to be able to
> negotiate
>
> (or signal or whatever) extensions which involve both a new frame type
>
> and some parameter negotiation. For instance "I support message frames,
>
> but don't make them longer than 200 bytes". In that case, with the design
>
> in PR#1068 that just contains a map table, you either have to have a seco=
nd
>
> transport parameter to negotiate the per-extension parameter (with the
>
> risk of mismatch) or you need two ways to establish the mapping table.
>
>
>
> It might be useful to talk a bit about principles and constraints. My bas=
ic
>
> assumption is that it's not important for non-standardized extensions to
>
> have *very* short frames. I.e., it would be fine if their frame type
> identifiers
>
> were 4 bytes. If that's so, then we have a lot of room and we don't need
>
> to worry about mapping. This would be compatible with either a varint
>
> or a "extension" frame as Mirja suggests. And then when you wanted to
>
> standardize you would get a short type (varint is slightly better here).
>
>
>
> On the other hand, if you think it's important to have very short frames
>
> for non-standardized extensions then you need some sort of mapping
>
> thing.
>
>
>
> -Ekr
>
>
>
>
> 1. As Victor originally proposed, provide a map from a large
> identifier space to the smaller space of extension frame types.  PR
> #1068 does that, mapping a 16-bit identifier into the 128-255 range of
> frame types.  Cost: indirection, complexity.  Advantage: It has a PR
> (i.e., nothing significant).
>
> 2. Use a varint for frame types. Cost: non-trivial change to the wire
> format for frames; large(r) overhead for sending a frame unless you
> get one of the privileged frame types that encode to a single octet
> (and we have used 3/8 of those already, so we'd probably want to be
> strict about registration policies in that space).  Advantage: simple.
>
> 3. A modification to PR #1068 proposed by Kazuho which would have
> every transport parameter carry a list of frame types with it.  Cost:
> similar indirection to PR #1068, and every transport parameter would
> carry this list.  The advantage being that an extension that defines a
> transport parameter would only touch a single transport parameter and
> not have to register an extension frame type as well.
>
> Now I prefer the first, but could live with either alternative if only
> we could decide.  So I'm asking for help.
>
>
>

--000000000000b30fcc0569bdc57d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I can understand how someone might draw that conclusi=
on, but i don't think it's really applicable here because these val=
ues are negotiated, not just announced. Thus, it's not problematic to u=
se one code point in initial deployment and then define a new, short code p=
oint upon standardization. It's true you probably have to support both =
code points in perpetuity, but that's mostly just a matter of a small n=
umber of bytes in the parameter negotiation

-E=
kr


On Fri, Apr 13, 2018 at 9:53 AM, Swindells, Thomas (Nokia - GB/C=
ambridge) <thomas.swindells@nokia.com> wrote:











One of the lessons learnt from HTTP is that yo=
u don=E2=80=99t get the option to standardize once an =E2=80=98experimental=
=E2=80=99 feature is widely deployed. That is why X- prefixes on http heade=
rs was deprecated: it was
 realised clients had already ossified on using the experimental value and =
you were stuck with it for a very long time, even if you introduced a stand=
ardized version of the feature the non-standard usage still lives on and ha=
s to be supported.



=C2=A0


Based on this, I don=E2=80=99t think we can di=
stinguish sufficiently between =E2=80=98non-standardized=E2=80=99 and =E2=
=80=98standardized=E2=80=99 extensions, and if we think it is important to =
have very short frames at all (I=E2=80=99m not making
 a call on that) then the mapping thing is required. <=
/p>

=C2=A0


Thomas


<=
span>=C2=A0



From: QUIC [mailto:quic-bounces@ietf.org]
On Behalf Of Eric Rescorla

Sent: Friday, April 13, 2018 5:37 PM

To: Martin Thomson <martin.thomson@gmail.com>

Cc: QUIC WG <q=
uic@ietf.org>

Subject: Re: Extension frame design question


=C2=A0




=C2=A0




=C2=A0




On Thu, Apr 12, 2018 at 7:42 PM, Martin Thomson <=
martin.thomso=
n@gmail.com> wrote:




We agreed to add the ability to extend QUIC in Melbo=
urne (I know, it's

so long ago, but it seems like just yesterday).=C2=A0 But we never never
sealed the deal.



While we agree in principle, and have agreed that the use of

extensions will be signaled during the handshake using transport

parameters (as opposed to the h2 model where they can just appear),

we're locked in disagreement about the precise colour to use.=C2=A0 Rig=
ht

now there are three options:






=C2=A0






As I said in my email, I do think that this is more =
than just a purely aesthetic






issue. The fundamental question is whether one wants=
 to be able to negotiate






(or signal or whatever) extensions which involve bot=
h a new frame type






and some parameter negotiation. For instance "I=
 support message frames,






but don't make them longer than 200 bytes".=
 In that case, with the design






in PR#1068 that just contains a map table, you eithe=
r have to have a second






transport parameter to negotiate the per-extension p=
arameter (with the






risk of mismatch) or you need two ways to establish =
the mapping table.






=C2=A0






It might be useful to talk a bit about principles an=
d constraints. My basic






assumption is that it's not important for non-st=
andardized extensions to






have *very* short frames. I.e., it would be fine if =
their frame type identifiers






were 4 bytes. If that's so, then we have a lot o=
f room and we don't need






to worry about mapping. This would be compatible wit=
h either a varint






or a "extension" frame as Mirja suggests. =
And then when you wanted to






standardize you would get a short type (varint is sl=
ightly better here).






=C2=A0






On the other hand, if you think it's important t=
o have very short frames






for non-standardized extensions then you need some s=
ort of mapping






thing.






=C2=A0








-Ekr






=C2=A0








1. As Victor originally proposed, provide a map from a large

identifier space to the smaller space of extension frame types.=C2=A0 PR
#1068 does that, mapping a 16-bit identifier into the 128-255 range of

frame types.=C2=A0 Cost: indirection, complexity.=C2=A0 Advantage: It has a=
 PR

(i.e., nothing significant).



2. Use a varint for frame types. Cost: non-trivial change to the wire

format for frames; large(r) overhead for sending a frame unless you

get one of the privileged frame types that encode to a single octet

(and we have used 3/8 of those already, so we'd probably want to be

strict about registration policies in that space).=C2=A0 Advantage: simple.=




3. A modification to PR #1068 proposed by Kazuho which would have

every transport parameter carry a list of frame types with it.=C2=A0 Cost:<=
br>
similar indirection to PR #1068, and every transport parameter would

carry this list.=C2=A0 The advantage being that an extension that defines a=


transport parameter would only touch a single transport parameter and

not have to register an extension frame type as well.



Now I prefer the first, but could live with either alternative if only

we could decide.=C2=A0 So I'm asking for help.








=C2=A0














--000000000000b30fcc0569bdc57d--


From nobody Fri Apr 13 11:48:06 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2C012D952 for ; Fri, 13 Apr 2018 11:48: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, 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 0NJLzlQPE0Y4 for ; Fri, 13 Apr 2018 11:47:53 -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 5F6FD12D86F for ; Fri, 13 Apr 2018 11:47:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 40N6Gb4g1pz15P17; Fri, 13 Apr 2018 20:47:51 +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 ROgZorA_xeDf; Fri, 13 Apr 2018 20:47:50 +0200 (CEST)
X-MtScore: NO score=0
Received: from [192.168.178.24] (i577BCE4C.versanet.de [87.123.206.76]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 13 Apr 2018 20:47:50 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Extension frame design question
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= 
In-Reply-To: 
Date: Fri, 13 Apr 2018 20:47:48 +0200
Cc: "Swindells, Thomas (Nokia - GB/Cambridge)" , QUIC WG , Martin Thomson 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    
To: Eric Rescorla 
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Apr 2018 18:48:05 -0000

I guess the standardized version means part of the new quic protocol =
version. Given the intent is to change versions for quic more often than =
for HTTP, I don=E2=80=99t think we will have the same problem.

> Am 13.04.2018 um 18:57 schrieb Eric Rescorla :
>=20
> I can understand how someone might draw that conclusion, but i don't =
think it's really applicable here because these values are negotiated, =
not just announced. Thus, it's not problematic to use one code point in =
initial deployment and then define a new, short code point upon =
standardization. It's true you probably have to support both code points =
in perpetuity, but that's mostly just a matter of a small number of =
bytes in the parameter negotiation
>=20
> -Ekr
>=20
>=20
> On Fri, Apr 13, 2018 at 9:53 AM, Swindells, Thomas (Nokia - =
GB/Cambridge)  wrote:
> One of the lessons learnt from HTTP is that you don=E2=80=99t get the =
option to standardize once an =E2=80=98experimental=E2=80=99 feature is =
widely deployed. That is why X- prefixes on http headers was deprecated: =
it was realised clients had already ossified on using the experimental =
value and you were stuck with it for a very long time, even if you =
introduced a standardized version of the feature the non-standard usage =
still lives on and has to be supported.
>=20
> =20
>=20
> Based on this, I don=E2=80=99t think we can distinguish sufficiently =
between =E2=80=98non-standardized=E2=80=99 and =E2=80=98standardized=E2=80=
=99 extensions, and if we think it is important to have very short =
frames at all (I=E2=80=99m not making a call on that) then the mapping =
thing is required.
>=20
> =20
>=20
> Thomas
>=20
> =20
>=20
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla
> Sent: Friday, April 13, 2018 5:37 PM
> To: Martin Thomson 
> Cc: QUIC WG 
> Subject: Re: Extension frame design question
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> On Thu, Apr 12, 2018 at 7:42 PM, Martin Thomson =
 wrote:
>=20
> We agreed to add the ability to extend QUIC in Melbourne (I know, it's
> so long ago, but it seems like just yesterday).  But we never never
> sealed the deal.
>=20
> While we agree in principle, and have agreed that the use of
> extensions will be signaled during the handshake using transport
> parameters (as opposed to the h2 model where they can just appear),
> we're locked in disagreement about the precise colour to use.  Right
> now there are three options:
>=20
> =20
>=20
> As I said in my email, I do think that this is more than just a purely =
aesthetic
>=20
> issue. The fundamental question is whether one wants to be able to =
negotiate
>=20
> (or signal or whatever) extensions which involve both a new frame type
>=20
> and some parameter negotiation. For instance "I support message =
frames,
>=20
> but don't make them longer than 200 bytes". In that case, with the =
design
>=20
> in PR#1068 that just contains a map table, you either have to have a =
second
>=20
> transport parameter to negotiate the per-extension parameter (with the
>=20
> risk of mismatch) or you need two ways to establish the mapping table.
>=20
> =20
>=20
> It might be useful to talk a bit about principles and constraints. My =
basic
>=20
> assumption is that it's not important for non-standardized extensions =
to
>=20
> have *very* short frames. I.e., it would be fine if their frame type =
identifiers
>=20
> were 4 bytes. If that's so, then we have a lot of room and we don't =
need
>=20
> to worry about mapping. This would be compatible with either a varint
>=20
> or a "extension" frame as Mirja suggests. And then when you wanted to
>=20
> standardize you would get a short type (varint is slightly better =
here).
>=20
> =20
>=20
> On the other hand, if you think it's important to have very short =
frames
>=20
> for non-standardized extensions then you need some sort of mapping
>=20
> thing.
>=20
> =20
>=20
> -Ekr
>=20
> =20
>=20
>=20
> 1. As Victor originally proposed, provide a map from a large
> identifier space to the smaller space of extension frame types.  PR
> #1068 does that, mapping a 16-bit identifier into the 128-255 range of
> frame types.  Cost: indirection, complexity.  Advantage: It has a PR
> (i.e., nothing significant).
>=20
> 2. Use a varint for frame types. Cost: non-trivial change to the wire
> format for frames; large(r) overhead for sending a frame unless you
> get one of the privileged frame types that encode to a single octet
> (and we have used 3/8 of those already, so we'd probably want to be
> strict about registration policies in that space).  Advantage: simple.
>=20
> 3. A modification to PR #1068 proposed by Kazuho which would have
> every transport parameter carry a list of frame types with it.  Cost:
> similar indirection to PR #1068, and every transport parameter would
> carry this list.  The advantage being that an extension that defines a
> transport parameter would only touch a single transport parameter and
> not have to register an extension frame type as well.
>=20
> Now I prefer the first, but could live with either alternative if only
> we could decide.  So I'm asking for help.
>=20
> =20
>=20
>=20


From nobody Fri Apr 13 12:30:41 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5AD127863 for ; Fri, 13 Apr 2018 12:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 64wmFUAxFYwv for ; Fri, 13 Apr 2018 12:30:37 -0700 (PDT)
Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32856126C89 for ; Fri, 13 Apr 2018 12:30:37 -0700 (PDT)
Received: by mail-ot0-x22a.google.com with SMTP id m22-v6so11054009otf.8 for ; Fri, 13 Apr 2018 12:30:37 -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=TH6Y1YBtx22IDspyvIAr5UAbwFq/AGRg5zl1yoDtWkw=; b=ykgjWXf9jykKvYjYl2xYa68ihlH9tdSYI7+Zp7DFppojo85W49lP2dhtZzTs9SH3Qc dfRGgreP4F0Q+corcdYVcNEg82lnz2CN8oO5fWbTqp8WJVJTh0r/DNoqGfnTOJHfQINR NJnoCS/3xB99bI2P1k+aj18y5A/fOYpEpIZ+Xg1MOrFvxX/F1Ggr1CkyHF20Wh4Zyq5E +FjBiKfiLwA5003RV5ujmT2XlwebvwtWzg4aPAkWTsaekuZllAL5+xhU1P/2eggB/dxy UMHzd2eKIDdSv5kFkFvgs75VVkpwVEqbV59zFCK05dO5XqEDopUC+ElTehJ3HeqK6daM /RAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=TH6Y1YBtx22IDspyvIAr5UAbwFq/AGRg5zl1yoDtWkw=; b=NkCrhiMmBDSc7QEEd2RmmlYu2A2Wc/kjzKzCBA1n+jXBmswH3jJK3CpAOamKwrnw0u SJ8NuMjO8xvChBQY+X//hJdgFSkUIqt9zIgClyakIdquLGikwtQ8poXnmkDkTVNEsSX8 f68NdWbK2iqmpLJCzlUeQ4S8f7BGH7Y/QbErHY+3y08n7+EHqciKbTsvDT55KeKiA6Vq h8hBkB1s+2XCtG0jsqDOS1xir9xFnZ8kMl93cFBMn2e+Gf4xgem+UKq6GbB9fWieprId UaV3c3XwEY6VRZOm+mBEYzxKChTrsDXujQn3qoXpW3FFNoRalKYEbGG3bIOn4fdnj6IT Vx4w==
X-Gm-Message-State: ALQs6tArXJE8/nsxbMmcuXepFtBeNE+xs1v+0W0WpCv+yPk7Ml07GAiJ kFniCXIjeOhT7KYfGiU++e8wnKoPf7AghPU1HPO2RA==
X-Google-Smtp-Source: AIpwx4/5UasSt1nGqOPoB0bfk4X66FI8Xl3FntfRzuFSg5NJSKwf4wX7x2m4MCMNalxkhCoU4AgvceDGs9J5PlKtUvw=
X-Received: by 2002:a9d:5919:: with SMTP id t25-v6mr950512oth.217.1523647836513;  Fri, 13 Apr 2018 12:30:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.138.18.130 with HTTP; Fri, 13 Apr 2018 12:29:56 -0700 (PDT)
In-Reply-To: 
References:     
From: Eric Rescorla 
Date: Fri, 13 Apr 2018 12:29:56 -0700
Message-ID: 
Subject: Re: Extension frame design question
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= 
Cc: "Swindells, Thomas (Nokia - GB/Cambridge)" , QUIC WG , Martin Thomson 
Content-Type: multipart/alternative; boundary="0000000000000f003b0569bfe871"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Apr 2018 19:30:40 -0000

--0000000000000f003b0569bfe871
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 13, 2018 at 11:47 AM, Mirja K=C3=BChlewind <
mirja.kuehlewind@tik.ee.ethz.ch> wrote:

> I guess the standardized version means part of the new quic protocol
> version. Given the intent is to change versions for quic more often than
> for HTTP, I don=E2=80=99t think we will have the same problem.
>

That would work, but if you're negotiating them, we could also just publish
an RFC wit the extension definition and assign a short code point.

-Ekr


> > Am 13.04.2018 um 18:57 schrieb Eric Rescorla :
> >
> > I can understand how someone might draw that conclusion, but i don't
> think it's really applicable here because these values are negotiated, no=
t
> just announced. Thus, it's not problematic to use one code point in initi=
al
> deployment and then define a new, short code point upon standardization.
> It's true you probably have to support both code points in perpetuity, bu=
t
> that's mostly just a matter of a small number of bytes in the parameter
> negotiation
> >
> > -Ekr
> >
> >
> > On Fri, Apr 13, 2018 at 9:53 AM, Swindells, Thomas (Nokia -
> GB/Cambridge)  wrote:
> > One of the lessons learnt from HTTP is that you don=E2=80=99t get the o=
ption to
> standardize once an =E2=80=98experimental=E2=80=99 feature is widely depl=
oyed. That is why
> X- prefixes on http headers was deprecated: it was realised clients had
> already ossified on using the experimental value and you were stuck with =
it
> for a very long time, even if you introduced a standardized version of th=
e
> feature the non-standard usage still lives on and has to be supported.
> >
> >
> >
> > Based on this, I don=E2=80=99t think we can distinguish sufficiently be=
tween
> =E2=80=98non-standardized=E2=80=99 and =E2=80=98standardized=E2=80=99 ext=
ensions, and if we think it is
> important to have very short frames at all (I=E2=80=99m not making a call=
 on that)
> then the mapping thing is required.
> >
> >
> >
> > Thomas
> >
> >
> >
> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla
> > Sent: Friday, April 13, 2018 5:37 PM
> > To: Martin Thomson 
> > Cc: QUIC WG 
> > Subject: Re: Extension frame design question
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Apr 12, 2018 at 7:42 PM, Martin Thomson <
> martin.thomson@gmail.com> wrote:
> >
> > We agreed to add the ability to extend QUIC in Melbourne (I know, it's
> > so long ago, but it seems like just yesterday).  But we never never
> > sealed the deal.
> >
> > While we agree in principle, and have agreed that the use of
> > extensions will be signaled during the handshake using transport
> > parameters (as opposed to the h2 model where they can just appear),
> > we're locked in disagreement about the precise colour to use.  Right
> > now there are three options:
> >
> >
> >
> > As I said in my email, I do think that this is more than just a purely
> aesthetic
> >
> > issue. The fundamental question is whether one wants to be able to
> negotiate
> >
> > (or signal or whatever) extensions which involve both a new frame type
> >
> > and some parameter negotiation. For instance "I support message frames,
> >
> > but don't make them longer than 200 bytes". In that case, with the desi=
gn
> >
> > in PR#1068 that just contains a map table, you either have to have a
> second
> >
> > transport parameter to negotiate the per-extension parameter (with the
> >
> > risk of mismatch) or you need two ways to establish the mapping table.
> >
> >
> >
> > It might be useful to talk a bit about principles and constraints. My
> basic
> >
> > assumption is that it's not important for non-standardized extensions t=
o
> >
> > have *very* short frames. I.e., it would be fine if their frame type
> identifiers
> >
> > were 4 bytes. If that's so, then we have a lot of room and we don't nee=
d
> >
> > to worry about mapping. This would be compatible with either a varint
> >
> > or a "extension" frame as Mirja suggests. And then when you wanted to
> >
> > standardize you would get a short type (varint is slightly better here)=
.
> >
> >
> >
> > On the other hand, if you think it's important to have very short frame=
s
> >
> > for non-standardized extensions then you need some sort of mapping
> >
> > thing.
> >
> >
> >
> > -Ekr
> >
> >
> >
> >
> > 1. As Victor originally proposed, provide a map from a large
> > identifier space to the smaller space of extension frame types.  PR
> > #1068 does that, mapping a 16-bit identifier into the 128-255 range of
> > frame types.  Cost: indirection, complexity.  Advantage: It has a PR
> > (i.e., nothing significant).
> >
> > 2. Use a varint for frame types. Cost: non-trivial change to the wire
> > format for frames; large(r) overhead for sending a frame unless you
> > get one of the privileged frame types that encode to a single octet
> > (and we have used 3/8 of those already, so we'd probably want to be
> > strict about registration policies in that space).  Advantage: simple.
> >
> > 3. A modification to PR #1068 proposed by Kazuho which would have
> > every transport parameter carry a list of frame types with it.  Cost:
> > similar indirection to PR #1068, and every transport parameter would
> > carry this list.  The advantage being that an extension that defines a
> > transport parameter would only touch a single transport parameter and
> > not have to register an extension frame type as well.
> >
> > Now I prefer the first, but could live with either alternative if only
> > we could decide.  So I'm asking for help.
> >
> >
> >
> >
>
>

--0000000000000f003b0569bfe871
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, Apr 13, 2018 at 11:47 AM, Mirja K=C3=BChlewind <=
mirja.kuehlewind@tik.ee.ethz.ch> wrote:
I guess the standardized version means part of the new quic p=
rotocol version. Given the intent is to change versions for quic more often=
 than for HTTP, I don=E2=80=99t think we will have the same problem.

That would work, but if you're negotiatin=
g them, we could also just publish an RFC wit the extension definition and =
assign a short code point.

-Ekr

=





> Am 13.04.2018 um 18:57 schrieb Eric Rescorla <ekr@rtfm.com>:

> 

> I can understand how someone might draw that conclusion, but i don'=
;t think it's really applicable here because these values are negotiate=
d, not just announced. Thus, it's not problematic to use one code point=
 in initial deployment and then define a new, short code point upon standar=
dization. It's true you probably have to support both code points in pe=
rpetuity, but that's mostly just a matter of a small number of bytes in=
 the parameter negotiation

> 

> -Ekr

> 

> 

> On Fri, Apr 13, 2018 at 9:53 AM, Swindells, Thomas (Nokia - GB/Cambrid=
ge) <thomas.swindells@noki=
a.com> wrote:

> One of the lessons learnt from HTTP is that you don=E2=80=99t get the =
option to standardize once an =E2=80=98experimental=E2=80=99 feature is wid=
ely deployed. That is why X- prefixes on http headers was deprecated: it wa=
s realised clients had already ossified on using the experimental value and=
 you were stuck with it for a very long time, even if you introduced a stan=
dardized version of the feature the non-standard usage still lives on and h=
as to be supported.

> 

>=C2=A0 

> 

> Based on this, I don=E2=80=99t think we can distinguish sufficiently b=
etween =E2=80=98non-standardized=E2=80=99 and =E2=80=98standardized=E2=80=
=99 extensions, and if we think it is important to have very short frames a=
t all (I=E2=80=99m not making a call on that) then the mapping thing is req=
uired.

> 

>=C2=A0 

> 

> Thomas

> 

>=C2=A0 

> 

> From: QUIC [mailto:quic-bounc=
es@ietf.org] On Behalf Of Eric Rescorla

> Sent: Friday, April 13, 2018 5:37 PM

> To: Martin Thomson <mar=
tin.thomson@gmail.com>

> Cc: QUIC WG <quic@ietf.org>=


> Subject: Re: Extension frame design question

> 

>=C2=A0 

> 

>=C2=A0 

> 

>=C2=A0 

> 

> On Thu, Apr 12, 2018 at 7:42 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> 

> We agreed to add the ability to extend QUIC in Melbourne (I know, it&#=
39;s

> so long ago, but it seems like just yesterday).=C2=A0 But we never nev=
er

> sealed the deal.

> 

> While we agree in principle, and have agreed that the use of

> extensions will be signaled during the handshake using transport

> parameters (as opposed to the h2 model where they can just appear),
> we're locked in disagreement about the precise colour to use.=C2=
=A0 Right

> now there are three options:

> 

>=C2=A0 

> 

> As I said in my email, I do think that this is more than just a purely=
 aesthetic

> 

> issue. The fundamental question is whether one wants to be able to neg=
otiate

> 

> (or signal or whatever) extensions which involve both a new frame type=


> 

> and some parameter negotiation. For instance "I support message f=
rames,

> 

> but don't make them longer than 200 bytes". In that case, wit=
h the design

> 

> in PR#1068 that just contains a map table, you either have to have a s=
econd

> 

> transport parameter to negotiate the per-extension parameter (with the=


> 

> risk of mismatch) or you need two ways to establish the mapping table.=


> 

>=C2=A0 

> 

> It might be useful to talk a bit about principles and constraints. My =
basic

> 

> assumption is that it's not important for non-standardized extensi=
ons to

> 

> have *very* short frames. I.e., it would be fine if their frame type i=
dentifiers

> 

> were 4 bytes. If that's so, then we have a lot of room and we don&=
#39;t need

> 

> to worry about mapping. This would be compatible with either a varint<=
br>
> 

> or a "extension" frame as Mirja suggests. And then when you =
wanted to

> 

> standardize you would get a short type (varint is slightly better here=
).

> 

>=C2=A0 

> 

> On the other hand, if you think it's important to have very short =
frames

> 

> for non-standardized extensions then you need some sort of mapping

> 

> thing.

> 

>=C2=A0 

> 

> -Ekr

> 

>=C2=A0 

> 

> 

> 1. As Victor originally proposed, provide a map from a large

> identifier space to the smaller space of extension frame types.=C2=A0 =
PR

> #1068 does that, mapping a 16-bit identifier into the 128-255 range of=


> frame types.=C2=A0 Cost: indirection, complexity.=C2=A0 Advantage: It =
has a PR

> (i.e., nothing significant).

> 

> 2. Use a varint for frame types. Cost: non-trivial change to the wire<=
br>
> format for frames; large(r) overhead for sending a frame unless you
> get one of the privileged frame types that encode to a single octet
> (and we have used 3/8 of those already, so we'd probably want to b=
e

> strict about registration policies in that space).=C2=A0 Advantage: si=
mple.

> 

> 3. A modification to PR #1068 proposed by Kazuho which would have

> every transport parameter carry a list of frame types with it.=C2=A0 C=
ost:

> similar indirection to PR #1068, and every transport parameter would
> carry this list.=C2=A0 The advantage being that an extension that defi=
nes a

> transport parameter would only touch a single transport parameter and<=
br>
> not have to register an extension frame type as well.

> 

> Now I prefer the first, but could live with either alternative if only=


> we could decide.=C2=A0 So I'm asking for help.

> 

>=C2=A0 

> 

> 







--0000000000000f003b0569bfe871--


From nobody Sat Apr 14 17:45:26 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3FB120726 for ; Sat, 14 Apr 2018 17:45:24 -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=mnot.net header.b=IR/uKPHe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iGvuovbe
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UH0rrfslSutg for ; Sat, 14 Apr 2018 17:45:21 -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 0E847120724 for ; Sat, 14 Apr 2018 17:45:21 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2712122189 for ; Sat, 14 Apr 2018 20:45:20 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 14 Apr 2018 20:45:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=6/UC0qjEOmPAvtni3 8ldnggQKadYZCA9rDFXQ5NeECQ=; b=IR/uKPHeUszjZHrHYJpexiJfbRtI0YxEh uWHkwCZtJ2Dmk0XhF9BSv8Ov8oK/2aeBXzJVMrvbkP++dbPS2mv2DbXjOUuMzegx yBpeJg0yr26lOc4TSJqunu7+avxXI6pYk/QQrweNS7YGbFS0x3qfXS2U4/Gf4xj0 VvwjEG1RjJJpQvu8Bu0uCKaXBdr7DsysbTRhERHGHwlU8stcTv/oozAwWSS+8wjT 0XPVvPn8eJvY6cCjDEMBNi5CMbeCpgRqnSSUWDNqhhXEJMGoD9ApG4kiafIuCxur y1NLbE6wUvtcu9GzwUdg0XWUsPe8IswqTiRarhW7f/fsrzS/rth4g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=6/UC0qjEOmPAvtni38ldnggQKadYZCA9rDFXQ5NeECQ=; b=iGvuovbe W+UTQw9rAAqXcpCvpyy6L5qJgtN1XYnOPhN8/IkCC9b7gytb1HvyDrWB5K9Bo5u7 delO/+h9j/yawC1IjyXdzH6ejV4JsHtp9vA6/k14kALzH84FgsFEl0wVQW+j2UmA EC6q5wkCRKkBW22Wlky3n/KtwUgnh4zpLJKPCmpJt/QXk97K5CkV0sBg6BuVZZP5 RpzIo+eRPkb80baWr+Wc/pTEwEItCxvePY3oPzfGOVZGVPM92TjuxJ+oejctetYo DjrmIHNFcsHyvWa5H5znH4uLlfrk5SXrxjLPDDOufxNIhilZVC6VDTF+sT/wBq+B mbnfCZJE0LRawA==
X-ME-Sender: 
Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 087AAE446D for ; Sat, 14 Apr 2018 20:45:19 -0400 (EDT)
Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 251D6C7FBD for ; Sun, 15 Apr 2018 00:45:16 +0000 (UTC)
Content-Type: multipart/alternative; boundary="===============4949341716200307831=="
MIME-Version: 1.0
From: =?utf-8?q?Github_Notifications?= 
To: quic@ietf.org
Subject: Weekly github digest (QUIC Working Group Specifications)
Message-Id: <20180415004516.251D6C7FBD@cloud.mnot.net>
Date: Sun, 15 Apr 2018 00:45:16 +0000 (UTC)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 00:45:24 -0000

--===============4949341716200307831==
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; format="flowed"




Events without label "editorial"

Issues
------
* quicwg/base-drafts (+5/-1/=F0=9F=92=AC38)
  5 issues created:
  - Payload length in header encrypted with sequence number (by huitema)
    https://github.com/quicwg/base-drafts/issues/1293 =

  - Can Retry or VNego be compound with other packets? (by huitema)
    https://github.com/quicwg/base-drafts/issues/1292 =

  - Order of Compound Packets (by nibanks)
    https://github.com/quicwg/base-drafts/issues/1287 =

  - HoLB from NCID frames (by MikeBishop)
    https://github.com/quicwg/base-drafts/issues/1280 =

  - [Congestion control] How to decrease the congestion window (by scw00)
    https://github.com/quicwg/base-drafts/issues/1272 =


  12 issues received 38 new comments:
  - #1287 Order of Compound Packets (7 by dtikhonov, martinthomson, kazuho,=
 nibanks)
    https://github.com/quicwg/base-drafts/issues/1287 =

  - #1230 Stateless Reset needs "on-path" proof (7 by martinthomson, kazuho)
    https://github.com/quicwg/base-drafts/issues/1230 [-transport] [design] =

  - #1252 Stream Flow Control on Stream 0 (6 by RyanAtGoogle, siyengar, mar=
tinduke)
    https://github.com/quicwg/base-drafts/issues/1252 [-transport] [design] =

  - #1271 Connection migration optional? (4 by kazuho, martinthomson, pravb=
, ianswett)
    https://github.com/quicwg/base-drafts/issues/1271 [-transport] [design] =

  - #1280 HoLB from NCID frames (3 by martinthomson, mikkelfj, MikeBishop)
    https://github.com/quicwg/base-drafts/issues/1280 [-transport] [design] =

  - #1255 Gratuitous change of QHKDF-Expand in draft 10 (3 by kazuho, mcman=
us, martinthomson)
    https://github.com/quicwg/base-drafts/issues/1255 [-tls] [design] =

  - #1276 Exhausting a supply of connection IDs (3 by kazuho, ianswett, Mik=
eBishop)
    https://github.com/quicwg/base-drafts/issues/1276 [-transport] [design] =

  - #1293 Payload length in header encrypted with sequence number (1 by hui=
tema)
    https://github.com/quicwg/base-drafts/issues/1293 =

  - #1246 Version Negotiation packet extensibility (1 by mnot)
    https://github.com/quicwg/base-drafts/issues/1246 [-invariants] [design=
] =

  - #1258 Stateless Reset during Path Migration (1 by MikeBishop)
    https://github.com/quicwg/base-drafts/issues/1258 [-transport] [design] =

  - #1265 error handling for path_response (1 by martinthomson)
    https://github.com/quicwg/base-drafts/issues/1265 [-transport] [design] =

  - #1272 [Congestion control] How to decrease the congestion window (1 by =
martinthomson)
    https://github.com/quicwg/base-drafts/issues/1272 =


  1 issues closed:
  - [Congestion control] How to decrease the congestion window https://gith=
ub.com/quicwg/base-drafts/issues/1272 =




Pull requests
-------------
* quicwg/base-drafts (+14/-14/=F0=9F=92=AC51)
  14 pull requests submitted:
  - Swap payload length (by huitema)
    https://github.com/quicwg/base-drafts/pull/1294 =

  - Changelog for -11 (by martinthomson)
    https://github.com/quicwg/base-drafts/pull/1291 =

  - Various spin-exp nits (by britram)
    https://github.com/quicwg/base-drafts/pull/1290 =

  - Removed contractions from text (by ariel-anieli)
    https://github.com/quicwg/base-drafts/pull/1289 =

  - Add Note to Readers, update status (by mnot)
    https://github.com/quicwg/base-drafts/pull/1288 =

  - add draft-ietf-quic-spin-exp (by britram)
    https://github.com/quicwg/base-drafts/pull/1286 =

  - Some editorial cleanup for #1262 (by martinthomson)
    https://github.com/quicwg/base-drafts/pull/1285 =

  - Grammar fix: contents "determine," not "determines." (by dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1284 =

  - Spin Bit Reservation (by britram)
    https://github.com/quicwg/base-drafts/pull/1283 =

  - QUIC is QUIC, and does not stay for anything. (by ariel-anieli)
    https://github.com/quicwg/base-drafts/pull/1282 =

  - transport: tls 5.2.2 is now 5.3.2 (by reschke)
    https://github.com/quicwg/base-drafts/pull/1279 =

  - Key bit bug (by huitema)
    https://github.com/quicwg/base-drafts/pull/1275 =

  - Permit CONNECTION_CLOSE in Handshake (by martinthomson)
    https://github.com/quicwg/base-drafts/pull/1274 =

  - tls: "Packet Number Gap" in transport has moved (by reschke)
    https://github.com/quicwg/base-drafts/pull/1273 =


  16 pull requests received 51 new comments:
  - #1262 define compound packets (12 by kazuho, janaiyengar, mikkelfj, mar=
tinthomson, ianswett, ekr)
    https://github.com/quicwg/base-drafts/pull/1262 =

  - #1068 Extension frames (8 by martinthomson, kazuho, ekr, mikkelfj)
    https://github.com/quicwg/base-drafts/pull/1068 [-transport] =

  - #1282 QUIC is QUIC, and does not stand for anything. (6 by martinthomso=
n, ariel-anieli, MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1282 =

  - #1288 Add Note to Readers, update status (4 by britram, mnot, martintho=
mson)
    https://github.com/quicwg/base-drafts/pull/1288 =

  - #1274 Permit CONNECTION_CLOSE in Handshake (4 by nibanks, ianswett, Mik=
eBishop)
    https://github.com/quicwg/base-drafts/pull/1274 =

  - #1283 Spin Bit Reservation (3 by martinthomson, mnot, britram)
    https://github.com/quicwg/base-drafts/pull/1283 =

  - #1284 Grammar fix: contents "determine," not "determines." (2 by martin=
thomson, dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1284 =

  - #1289 Removed contractions from text (2 by martinthomson, ariel-anieli)
    https://github.com/quicwg/base-drafts/pull/1289 =

  - #1259 Stateless Reset during Path Migration (2 by martinthomson, MikeBi=
shop)
    https://github.com/quicwg/base-drafts/pull/1259 [-transport] [design] =

  - #1263 Avoid failure from spoofed/delayed PATH_RESPONSE (2 by martinduke=
, MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1263 [-transport] [design] =

  - #1294 Swap payload length (1 by mikkelfj)
    https://github.com/quicwg/base-drafts/pull/1294 =

  - #1046 Latency Spin Bit, 2018 edition (1 by britram)
    https://github.com/quicwg/base-drafts/pull/1046 =

  - #1079 Packet number encryption (1 by mikkelfj)
    https://github.com/quicwg/base-drafts/pull/1079 [-tls] [-transport] =

  - #1245 Reference RFC5681 and RFC6928 (1 by martinthomson)
    https://github.com/quicwg/base-drafts/pull/1245 =

  - #1269 Change the UDP port sometimes too (1 by martinthomson)
    https://github.com/quicwg/base-drafts/pull/1269 [-transport] [design] =

  - #1273 tls: "Packet Number Gap" in transport has moved (1 by martinthoms=
on)
    https://github.com/quicwg/base-drafts/pull/1273 =


  14 pull requests merged:
  - Various spin-exp nits
    https://github.com/quicwg/base-drafts/pull/1290 =

  - Add Note to Readers, update status
    https://github.com/quicwg/base-drafts/pull/1288 =

  - Some editorial cleanup for #1262
    https://github.com/quicwg/base-drafts/pull/1285 =

  - QUIC is QUIC, and does not stand for anything.
    https://github.com/quicwg/base-drafts/pull/1282 =

  - add draft-ietf-quic-spin-exp
    https://github.com/quicwg/base-drafts/pull/1286 =

  - Grammar fix: contents "determine," not "determines."
    https://github.com/quicwg/base-drafts/pull/1284 =

  - define compound packets
    https://github.com/quicwg/base-drafts/pull/1262 =

  - Spin Bit Reservation
    https://github.com/quicwg/base-drafts/pull/1283 =

  - Permit CONNECTION_CLOSE in Handshake
    https://github.com/quicwg/base-drafts/pull/1274 =

  - Change the UDP port sometimes too
    https://github.com/quicwg/base-drafts/pull/1269 [-transport] [design] =

  - transport: tls 5.2.2 is now 5.3.2
    https://github.com/quicwg/base-drafts/pull/1279 =

  - Restrict ACK-clocking to ACK-only frames.
    https://github.com/quicwg/base-drafts/pull/1231 [-transport] =

  - Key bit bug
    https://github.com/quicwg/base-drafts/pull/1275 =

  - tls: "Packet Number Gap" in transport has moved
    https://github.com/quicwg/base-drafts/pull/1273 =



Repositories tracked by this digest:
-----------------------------------
* https://github.com/quicwg/base-drafts

--===============4949341716200307831==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable





Weekly github digest (QUIC Working Group Specifications)





Sunday April 15, 2018



Events without label "editorial"



Issues



quicwg/base-drafts (+5/-1/=F0=9F=92=AC38)

  
5 issues created:

  

  
12 issues received 38 new comments:

  

  
1 issues closed:

  




Pull requests


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

  
14 pull requests submitted:

  

  
16 pull requests received 51 new comments:

  

  
14 pull requests merged:

  



Repositories tracked by this digest:





--===============4949341716200307831==--


From nobody Sun Apr 15 09:43:24 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3525B124BE8 for ; Sun, 15 Apr 2018 09:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7x5VVCfs9CG for ; Sun, 15 Apr 2018 09:43:21 -0700 (PDT)
Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A9A12426E for ; Sun, 15 Apr 2018 09:43:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,455,1517904000";  d="asc'?scan'208";a="247958325"
Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx142-out.netapp.com with ESMTP; 15 Apr 2018 09:43:11 -0700
Received: from VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 15 Apr 2018 09:43:11 -0700
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Sun, 15 Apr 2018 09:43:11 -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=4EAnQ5kePdZ7w4UO9hobYpRTJN741Qbk4HKOX/nti94=; b=MWtvTxMjJ4Ly/wrbCcDXmZVRVZ8ATfquYPsMMW31WhX/plMoWAzg43Nw02UWJUY/w7esOK4aHMl58/KJg5RzzXQCd3l7FFDUSyv41k+de+YI4v4UTyxaBQO3T2g/t0eVnAUHtAq6lVbbEiHlkud+kbn2cU7+MniaNHmP401WvVo=
Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB449.namprd06.prod.outlook.com (10.141.202.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.9; Sun, 15 Apr 2018 16:43:08 +0000
Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::5520:2312:30a8:6bd2]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::5520:2312:30a8:6bd2%6]) with mapi id 15.20.0675.015; Sun, 15 Apr 2018 16:43:07 +0000
From: "Eggert, Lars" 
To: QUIC WG 
Subject: Re: Doodle poll for May 2018 remote interop day
Thread-Topic: Doodle poll for May 2018 remote interop day
Thread-Index: AQHTxZiTQvN4V8CATE+TRAFkrR9/OaPx63yAgBA6+wA=
Date: Sun, 15 Apr 2018 16:43:07 +0000
Message-ID: 
References: <9C605165-D6F0-4ECC-9C49-41C059324603@netapp.com> <5D489CC6-2C35-4486-86DE-95CCC7A3C21D@netapp.com>  <5BBA8305-8870-4F74-9456-A4232CA5C3C2@netapp.com>
In-Reply-To: <5BBA8305-8870-4F74-9456-A4232CA5C3C2@netapp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.6.18)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; 
x-originating-ip: [2001:a61:360d:b01:c434:9b4f:208c:22e6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR06MB449; 7:RkN8e9o5KZRDGUSxxb/jyahVMyDih1g019xC/C9nBroEbgK6ME7FQ8AgcIEI+WjGBaiJsP6GnFeY6s6wBr3Oa8brMtXZYmJPOHddcz3yv4AGxQJGwyAgDFjjou788BTJPqZ0VyfTfYzaEZw65Wg/rDAvLABEtxoJ7H0Kh3u1DxNZ4uszSTtOh4i8lSucZl0REWv9neifx/LJRQdj+iy3+oyf9VeXnXobQY6rgmpZj3c6PT80+FLIRTJyQrr9az3g
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(49563074)(7193020); SRVR:BLUPR06MB449; 
x-ms-traffictypediagnostic: BLUPR06MB449:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231232)(944501327)(52105095)(10201501046)(3002001)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:BLUPR06MB449; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB449; 
x-forefront-prvs: 0643BDA83C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(39380400002)(396003)(376002)(377424004)(189003)(199004)(93886005)(53546011)(68736007)(59450400001)(57306001)(6506007)(106356001)(558084003)(33656002)(76176011)(5250100002)(8936002)(81166006)(50226002)(6486002)(36756003)(14454004)(6246003)(8676002)(81156014)(4001150100001)(105586002)(229853002)(82746002)(97736004)(99286004)(316002)(53936002)(6436002)(486006)(5660300001)(2900100001)(6512007)(3280700002)(2616005)(478600001)(86362001)(6916009)(476003)(3660700001)(186003)(2906002)(11346002)(46003)(446003)(83716003)(102836004)(99936001)(305945005)(7736002)(6116002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB449; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: DksV7swlnGr8mvjWPOm+EThLDdIM308lDBvIeaW6MnvE3NJnwQ/WYg5a1XybKxNiutXD/0KAQmAFrJXM8y90FPWxUmqLedV6qzA3Co8GdaKkS95+OiCXALVAkIe8QwYGGnVBmMdZ1KcPBQVCBb6+I5/9Swxh76dziXnV3rLF5Ok+ffFzc162ygjvFWHnDFTJ
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_2E7F0292-07E5-4D4F-B52F-096ED7EFD574"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 3b4180ae-5dd9-45a8-5061-08d5a2eff7bb
X-MS-Exchange-CrossTenant-Network-Message-Id: 3b4180ae-5dd9-45a8-5061-08d5a2eff7bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2018 16:43:07.7893 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB449
X-OriginatorOrg: netapp.com
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Apr 2018 16:43:23 -0000

--Apple-Mail=_2E7F0292-07E5-4D4F-B52F-096ED7EFD574
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

On 2018-4-5, at 10:51, Eggert, Lars  wrote:
> reminder to please fill this out ASAP, if you have a stack to test. At =
the moment, May 17 is in the lead.

I'm closing the poll, and May 17 is the best day. Please mark your =
calendars.

Lars

--Apple-Mail=_2E7F0292-07E5-4D4F-B52F-096ED7EFD574
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-----

iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlrTgRoACgkQVLXDCb9w
wVfswRAAoNL1kpKW1dHl1Xtw/dyJoxXwygmY6VPZPLHKwJEA0H4zuyengG+qSAUz
Y+uIeB0CXP8it+qHFrn+T8w5Q1Au0L/IJyPvMaj4o0VYqihe+EagO5a7MXUWmHF7
mFD67Nry+e5oopWkMjYfnoq5KBAayBWCEz+n02jQM2CUQXzoPaJQnb7JW1HUX2Yt
kd00eP/h9NOzUfQQ3OHeUitjyAir8UZumbz8jh6Gd4zjHrJzpT+wbOOIUC2/J4v8
694K8WPMAPeGq/MwBzK1FdWmzwSQ5ZrTWrnwISqDK9U7Yo9tOy1JTOHZMhJvn5z4
tJkKFtZoF1V5dn/gC+saqCxbio/XevNd08HLCJDowNFTKKEjye8XGm+sRRpdRSF+
l2qI/JK/9reOEIPFlEpDItnVVT04tvXIaRN5gsLFFk5TfyDNZUIX/WK8gtPIeupG
FVnCQITp/GsQiT/WE8AuNNresFeBJg7fJ2czriKZLOmatrPpXwb8bCh82Cto+hzm
dTJQbY0K7DBvNoEqtcYkzUg2tdIprfrkjO4xYmuQ+xIB8OgtmDHYx7V+8U4l6043
W4UCzihF59odOEO0ZKyKFYjaL0CCFslB74l2zbYQfYqsjnFx908tqpLHqugusAZb
0yidXVjb8Eoh5SElDjqB/MY+fRm3h2ZrdamDvFldErxgy2WFEAo=
=8eA0
-----END PGP SIGNATURE-----

--Apple-Mail=_2E7F0292-07E5-4D4F-B52F-096ED7EFD574--


From nobody Mon Apr 16 12:57:35 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3717512D883 for ; Mon, 16 Apr 2018 12:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=oJgQPKlX; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=OEuXVD46
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1h36lyqFdDl for ; Mon, 16 Apr 2018 12:57:10 -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 47F8A1241F3 for ; Mon, 16 Apr 2018 12:57:07 -0700 (PDT)
Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3GJsmJi008826; Mon, 16 Apr 2018 12:56:39 -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=D7v90Ezkh/xKBWJ5VWNzxHKpIIEPqa6tkkq92b1vt18=; b=oJgQPKlXyL9YplR3oqCLlkOv+2CgxfjsPginTF7BSHAMIzqDmIVMrIb/n+Xl6hTUbUon w6BHHVPD2MtqZVhIQu9SwhgT6pYotRIqawYCLJRWnhYr2rkvZ2yng76SwNg8+1pdVI6q Er88c983AWcCYRQtu/emzwZ5sfDS831PgQ0= 
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2hd1vhg2vx-20 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Apr 2018 12:56:39 -0700
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.31) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 16 Apr 2018 15:56:21 -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=D7v90Ezkh/xKBWJ5VWNzxHKpIIEPqa6tkkq92b1vt18=; b=OEuXVD46DP3geD1SJXuAvdHWK+jBtInaKejfI8sDw+gk9O/6VJTzIXEh3CoUSeq0vPSyrlawCCX1wdLpQ/q+egDqgvbackhKkMU9AZyb2r4078LyA/YjR4gjTV2rFf5UulU9tEO0ETz6oxROFxpvI53hIJsPZJbhm3m3tjuC1eU=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0359.namprd15.prod.outlook.com (10.163.109.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.10; Mon, 16 Apr 2018 19:56:19 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::6c4c:bbf3:ec3b:d45e]) by BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::6c4c:bbf3:ec3b:d45e%14]) with mapi id 15.20.0675.015; Mon, 16 Apr 2018 19:56:19 +0000
From: Roberto Peon 
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= 
CC: "quic@ietf.org" , Christian Huitema 
Subject: Re: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GjyGQaKf4GI0anNhXTngANsKPwZ0sAgAC4ugCAAARcAIAAG5CAgAAFCACAAACJgIAAEVkAgACR+ICAAVFHAIALXUEAgAVKTpU=
Date: Mon, 16 Apr 2018 19:56:19 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com>, <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>
In-Reply-To: <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2620:10d:c090:200::4:b3ef]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0359; 7:xJrcMIgtSE2h9i8RwI7TqProOGTPDS5CUx+fbw+ja3z8e5npyrUgCZiJmsqqdvYAWjfB8sk59j7bkYDfdd3v9nANs16limAESQvSpI0Intpy9PFkbn0xVfDJLhh8XvlDJh6XNItP2uUpBj6npJla+oAqOGL4zdyfR4R4OK6izizC8c+L64hTG5ydhxOq2jX+a4WIoBFWwwDCHr1rsaUEmKUB54T33FHeYC3rvkGP4uA+SvH7gWTD9xiRxFI1oqSx; 20:q2C7YbilmuDMQL0Y18NLQacqcqbW84JyBKivs9owVGdIxS+JXWtZXFn50c6T9K1MEUFlGnPofjFPOGVBwlwnsAYuJUiE/1Tt1klnKUWA6oZlo3YiD7lrt4lO4lqGS2FCk/bQCU5kmLflmrRlDiwZ4LDsfyNIYkdeqK3Y3LFDpnw=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR15MB0359; 
x-ms-traffictypediagnostic: BY2PR15MB0359:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(67672495146484)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231232)(11241501184)(944501327)(52105095)(93006095)(93001095)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BY2PR15MB0359; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0359; 
x-forefront-prvs: 0644578634
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(366004)(39380400002)(396003)(54014002)(199004)(189003)(14454004)(19627405001)(6116002)(446003)(476003)(68736007)(46003)(11346002)(81166006)(81156014)(8676002)(486006)(186003)(53936002)(102836004)(53546011)(5250100002)(99286004)(59450400001)(6506007)(7696005)(74316002)(9686003)(54896002)(316002)(7736002)(93886005)(54906003)(5660300001)(106356001)(6606003)(105586002)(86362001)(6916009)(2900100001)(229853002)(97736004)(6246003)(33656002)(76176011)(4326008)(25786009)(3280700002)(2906002)(55016002)(6436002)(8936002)(478600001)(3660700001)(427584002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0359; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: QJO4Arp6xcQs09f6mtnM62WD0+/+MeDOBLbgRBsFMrDMoP8UT9SGZflGyRrdEm5L0+0MUBBRslIU1ORolS7lpVomfyUCQVQ82w9JFr0Ua2fiwrIWUp3ICkwGi6n+QrTb79MqBknbckT96nZMC3lyR2lVkXr4CLA8+6WeM106JBHRcNvpcK8kAOUdpbDN3WrF
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR15MB0775B4ACF7DB9124E89016F0CDB00BY2PR15MB0775namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 8d5d9f0e-4a95-47ac-cc8a-08d5a3d41f5e
X-MS-Exchange-CrossTenant-Network-Message-Id: 8d5d9f0e-4a95-47ac-cc8a-08d5a3d41f5e
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2018 19:56:19.6556 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0359
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-16_10:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 19:57:14 -0000

--_000_BY2PR15MB0775B4ACF7DB9124E89016F0CDB00BY2PR15MB0775namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UGFyYXBocmFzaW5nOg0KDQo+IFBOIGluc3VmZmljaWVudCB0byBmaXggb3NzaWZpY2F0aW9uLCB3
aHkgaXMgdGhhdCBkaWZmaWN1bHQvZXhwZW5zaXZlPw0KDQpBcyBkZXNjcmliZWQgaW4gdGhlIG90
aGVyIHN1YnRocmVhZCwgeW91J2QgaGF2ZSB0byBlbXVsYXRlIHRoZSBzYW1lIG9yZGVyaW5nIG9m
IHRoZSBwcmV2aW91c2x5LW9zc2lmaWVkIFBOIHdoaWxlIGFsc28gZG9pbmcgd2hhdGV2ZXIgbmV3
bmVzcyB5b3Ugd2FudCB3aXRoIHRoZSBuZXcgUE4uDQpUaGF0IHNvdW5kcyBmYWJ1bG91c2x5IGNv
bXBsZXguIFlvdSdkIGVuZCB1cCBydW5uaW5nIHR3byBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25z
IHNpbXVsdGFuZW91c2x5Lg0KDQo+IE9zc2lmaWNhdGlvbi9pbnZhcmlhbnQgd2l0aG91dCBlbmNy
eXB0aW9uOg0KRW5jcnlwdGlvbiBzb2x2ZXMgaXQsIHNvdW5kcyBsaWtlIHdlIGFncmVlIG9uIHRo
YXQg8J+Yig0KDQoNCi09Ug0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJv
bTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgTWlyamEgS8O8aGxl
d2luZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4NClNlbnQ6IEZyaWRheSwgQXBy
aWwgMTMsIDIwMTggNDowNjo0MCBBTQ0KVG86IFJvYmVydG8gUGVvbg0KQ2M6IHF1aWNAaWV0Zi5v
cmc7IENocmlzdGlhbiBIdWl0ZW1hDQpTdWJqZWN0OiBSZTogR2V0dGluZyB0byBjb25zZW5zdXMg
b24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCkhpIFJvYmVydG8sDQoNCnNlZSBiZWxvdy4N
Cg0KPiBBbSAxMC4wNC4yMDE4IHVtIDAzOjA0IHNjaHJpZWIgUm9iZXJ0byBQZW9uIDxmZW5peEBm
Yi5jb20+Og0KPg0KPiBBZGRpbmcgYW5vdGhlciBQTiB3b3VsZCBwcm9iYWJseSBub3QgYmUgc3Vm
ZmljaWVudC0tIG9uZSB3b3VsZCBuZWVkIHRvIGVuc3VyZSB0aGF0IHRoZSBvc3NpZmllZCBQTiB3
YXMgcHJlc2VudGVkIHdpdGggdGhlIHJpZ2h0IHNlcXVlbmNpbmcgYXMgd2VsbCwgd2hpY2ggbWln
aHQgYmUgZGlmZmljdWx0LCBvciBleHBlbnNpdmUuDQoNClllcywgdGhhdCBpcyBlYXN5LiBXaHkg
ZG8geW91IHRoaW5rIHRoYXQgaXMgZGlmZmljdWx0IG9yIGV4cGVuc2l2ZT8NCg0KPiBPc3NpZmlj
YXRpb24gaXMgc3VycHJpc2luZ2x5IGRpZmZpY3VsdCB0byB3b3JrIGFyb3VuZCBvbmNlIGl0IHNl
dHMgaW4sIGFzIGV2ZW4gZmlndXJpbmcgb3V0IGhvdyBpdCBpcyBpbXBhY3RpbmcgeW91IGNhbiBi
ZSBzdWJzdGFudGlhbCB3b3JrLg0KDQpUaGF0IGlzIHRydWUgZm9yIGEgcHJvdG9jb2wgbGlrZSBU
Q1AgdmVyeSB0aGUgaW52YXJpYW50IGlzIGxhcmdlIGFuZCBub24gb2YgdGhlIGJpdHMgYXJlIGVu
Y3J5cHRlZC4gRm9yIFFVSUMgd2UgaGF2ZSBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IHNpdHVhdGlv
bi4NCg0KTWlyamENCg0KDQo+DQo+IC09Ug0KPg0KPiDvu79PbiA0LzUvMTgsIDI6MjcgQU0sICJR
VUlDIG9uIGJlaGFsZiBvZiBNaXJqYSBLw7xobGV3aW5kIiA8cXVpYy1ib3VuY2VzQGlldGYub3Jn
IG9uIGJlaGFsZiBvZiBtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPiB3cm90ZToNCj4N
Cj4gICAgTGV0IG1lIHJlcGVhdCBhbm90aGVyIHBvc2l0aW9uIHRoZW4gYXMgd2VsbDoNCj4NCj4+
IEFtIDA1LjA0LjIwMTggdW0gMDI6NDQgc2NocmllYiBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVt
YUBodWl0ZW1hLm5ldD46DQo+Pg0KPj4gSWYgd2UgYXJlIGluIHRoZSBidXNpbmVzcyBvZiByZXBl
YXRpbmcgb3VyIHBvc2l0aW9ucywgc28gYmUgaXQuIEkgYW0gcHJldHR5IG11Y2ggb24gdGhlIHNh
bWUgbGluZSBhcyBQYXRyaWNrIGFuZCBvdGhlcnM6DQo+Pg0KPj4gMSkgUHJpdmFjeSBpcyBub3Qg
b3B0aW9uYWwuIEFuZCB5ZXMsIHJlbW92aW5nICJsaW5rYWJpbGl0eSB0aHJvdWdoIFBOIiBpcyBp
bXBvcnRhbnQsIGJlY2F1c2Ugd2hlbiB0aGUgY29ubmVjdGlvbiBJRCBhbmQgdGhlIHNvdXJjZSBh
ZGRyZXNzIGFsc28gY2hhbmdlLCB0aGUgb25seSBvdGhlciBjdWUgZm9yIGxpbmthYmlsaXR5IGlz
IHRpbWluZy4gVGltaW5nIGNhbiBiZSBhZGRyZXNzZWQgYnkgaGF2aW5nIG92ZXJsYXBwaW5nIGNv
bm5lY3Rpb25zLg0KPj4NCj4gICAgVGltaW5nIGRvZXNu4oCZdCBoZWxwIGhlcmUgZWl0aGVyIGJl
Y2F1c2UgeW91IHN0aWxsIGhhdmUgdGhlIHNhbWUgZGVzdGluYXRpb24gSVAsIGJvdGggcG9ydCBu
dW1iZXJzIGFuZCB0aGUgZmFjdCB0aGF0IGEgbWlncmF0ZWQgY29ubmVjdGlvbiBkb2VzIG5vdCBo
YXZlIGEgaGFuZHNoYWtlLiBJZiB3ZSB3YW50IHRvIGFkZHJlc3MgdGhlIGxpbmthYmlsaXR5IHBy
b2JsZW0sIHdlIHdvdWxkIG5lZWQgdG8gZG8gbXVjaCBtb3JlLCBwcm9iYWJseSBiYXJpbmcgbW9y
ZSBoaXRzIG9uIHBlcmZvcm1hbmNlLg0KPg0KPiAgICBJIHRob3VnaHQgd2UgZGlzY3Vzc2VkIHRo
aXMgYWxyZWFkeSBlbmRsZXNzbHkgYW5kIGNvbmNsdWRlZCB0aGF0IFBORSBkb2VzIG5vdCBoZWxw
IGxpbmthYmlsaXR5Lg0KPg0KPiAgICBUaGVuIGFuIGFyZ3VtZW50IGZvciBvc3NpZmljYXRpb24g
d2FzIGJyb2FkIHVwLiBIb3dldmVyLCB3ZSByZWFsbHkgY2Fubm90IGNvbXBhcmUgdGhlIHNpdHVh
dGlvbiBoZXJlIHdpdGggVENQLiBXaXRoIFRDUCBldmVyeXRoaW5nIGlzIGluIHRoZSBjbGVhciBp
bmNsLiBhbHNvIHRoZSByZXRyYW5zbWlzc2lvbnMuIEluIGNhc2Ugb2YgTVBUQ1AgdGhpcyB3YXMg
cmF0aGVyIHRoZSBwcm9ibGVtIHRoZSB0aGUgc2VxIyBiZWNhdXNlIGlmIHlvdeKAmWQgdXNlIHRo
ZSBzYW1lIHNlcSMgbnVtYmVyIHNwYWNlIG9uIGJvdGggY29ubmVjdGlvbnMgaXQgd291bGQgbGlr
ZSBsb3NzIGJ1dCB3aXRob3V0IGEgcmV0cmFuc21pc3Npb24uIEZ1cnRoZXIgYm94ZXMgdGhhdCBy
ZW9yZGVyLCB1c3VhbGx5IGRvIHRoYXQgaW4gc2l0dWF0aW9uIHdoZXJlIHBhY2tldHMgd2VyZSB0
cmFuc21pdHRlZCBmb3IgYSBrbm93biByZWFzb24gb3V0LW9mIG9yZGVyIHByZXZpb3VzbHksIGUu
Zy4gd2hlbiBtdWx0aXBsZSBwYXRocyBhcmUgdXNlZCBpbiB0aGUgbmV0d29yay4gVGhlIHJlY29t
bWVuZGF0aW9uIHdlIHN0aWxsIGdpdmUgaW4gdGhlIElFVEYgdHJhbnNwb3J0IGFyZWEgaXMgdGhh
dCBpbiBzdWNoIGEgc2l0dWF0aW9uIHRoZSBzY2hlZHVsaW5nIHNob3VsZCBub3QgYmUgZG9uZSBv
biBhIHBlci1wYWNrZXQgbGV2ZWwgYnV0IHBlci1mbG93LiBIb3dldmVyLCB0aG9zZSBzY2hlbWUg
dGhhdCBkbyBwZXItcGFja2V0IHNjaGVkdWxpbmcgdXN1YWxseSBhbHNvIGFwcGx5IG1lY2hhbmlz
bSB0byByZS1vcmRlciBhZnRlcndhcmRzLiBUaGV5IGNhbiBqdXN0IHVzZSB0aGUgVENQIHNlcSMg
Zm9yIHRoYXQgYnV0IGZvciBub24tVENQIHRoZXkgd291bGQgc2ltcGx5IGFkZCB0aGVpciBvd24g
ZW5jYXBzdWxhdGlvbiB3aXRoIGEgc2VxI+KApg0KPg0KPiAgICBQbGVhc2Uga2VlcCBpbiBtaW5k
IHRoYXQgZXZlbiBpZiBhbiAodW5lbmNyeXB0ZWQpIFBOIGdldHMgb3NzaWZpZWQgYnkgdGhlIG5l
dHdvcmssDQo+ICAgIGluIGNhc2Ugb2YgUVVJQyB0aGF0IGRvZXMgbm90IG1lYW4gdGhhdCB3ZSBj
YW7igJl0IGNoYW5nZSB0aGUgdHJhbnNwb3J0IG1hY2hpbmVyeSBhbnltb3JlLiBDdXJyZW50bHkg
dGhlIGV4cG9zZWQgUE4gaXMgYWxzbyB1c2VkIGZvciBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIHJl
dHJhbnNtaXNzaW9uLCBob3dldmVyLCB3ZSBjYW4gc3RpbGwgYWRkIGFub3RoZXIgUE4gaW4gdGhl
IGVuY3J5cHRlZCBwYXJ0IGFuZCByZXNvbHZlZCB0aGUgZmFjdCB0aGF0IHRoZSBjdXJyZW50IFBO
IGlzIG92ZXJsb2FkZWQgZm9yIGRpZmZlcmVudCBmdW5jdGlvbnMuDQo+DQo+ICAgIEN1cnJlbnRs
eSwgSSByZWFsbHkgc3RpbGwgZG9u4oCZdCBzZWUgdGhlIGJlbmVmaXQgb2YgUE5FIGJ1dCBvbmx5
IGFkZGl0aW9uYWwgY29tcGxleGl0eSBhbmQga25vd24gcGVyZm9ybWFuY2UgZGVncmFkYXRpb24u
DQo+DQo+ICAgIE1pcmphDQo+DQo+DQo+DQo+DQo+DQoNCg==

--_000_BY2PR15MB0775B4ACF7DB9124E89016F0CDB00BY2PR15MB0775namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9
ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t
Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh
dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1p
bHk6Q2FsaWJyaSxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsiIGRpcj0ibHRyIj4NCjxwIHN0eWxlPSJt
YXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5QYXJhcGhyYXNpbmc6PGJyPg0KPGJyPg0KJmd0
OyBQTiBpbnN1ZmZpY2llbnQgdG8gZml4IG9zc2lmaWNhdGlvbiwgd2h5IGlzIHRoYXQgZGlmZmlj
dWx0L2V4cGVuc2l2ZT88YnI+DQo8YnI+DQpBcyBkZXNjcmliZWQgaW4gdGhlIG90aGVyIHN1YnRo
cmVhZCwgeW91J2QgaGF2ZSB0byBlbXVsYXRlIHRoZSBzYW1lIG9yZGVyaW5nIG9mIHRoZSBwcmV2
aW91c2x5LW9zc2lmaWVkIFBOIHdoaWxlIGFsc28gZG9pbmcgd2hhdGV2ZXIgbmV3bmVzcyB5b3Ug
d2FudCB3aXRoIHRoZSBuZXcgUE4uPGJyPg0KVGhhdCBzb3VuZHMgZmFidWxvdXNseSBjb21wbGV4
LiBZb3UnZCBlbmQgdXAgcnVubmluZyB0d28gZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBzaW11
bHRhbmVvdXNseS48YnI+DQo8YnI+DQomZ3Q7IE9zc2lmaWNhdGlvbi9pbnZhcmlhbnQgd2l0aG91
dCBlbmNyeXB0aW9uOjxicj4NCkVuY3J5cHRpb24gc29sdmVzIGl0LCBzb3VuZHMgbGlrZSB3ZSBh
Z3JlZSBvbiB0aGF0IDxzcGFuPvCfmIo8L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6
MDttYXJnaW4tYm90dG9tOjAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFy
Z2luLWJvdHRvbTowIj4tPVI8YnI+DQo8L3A+DQo8L2Rpdj4NCjxociBzdHlsZT0iZGlzcGxheTpp
bmxpbmUtYmxvY2s7d2lkdGg6OTglIiB0YWJpbmRleD0iLTEiPg0KPGRpdiBpZD0iZGl2UnBseUZ3
ZE1zZyIgZGlyPSJsdHIiPjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIHN0eWxlPSJm
b250LXNpemU6MTFwdCIgY29sb3I9IiMwMDAwMDAiPjxiPkZyb206PC9iPiBRVUlDICZsdDtxdWlj
LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBNaXJqYSBLw7xobGV3aW5kICZsdDtt
aXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoJmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk
YXksIEFwcmlsIDEzLCAyMDE4IDQ6MDY6NDAgQU08YnI+DQo8Yj5Ubzo8L2I+IFJvYmVydG8gUGVv
bjxicj4NCjxiPkNjOjwvYj4gcXVpY0BpZXRmLm9yZzsgQ2hyaXN0aWFuIEh1aXRlbWE8YnI+DQo8
Yj5TdWJqZWN0OjwvYj4gUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIg
ZW5jcnlwdGlvbjwvZm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9
IkJvZHlGcmFnbWVudCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0
OyI+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPkhpIFJvYmVydG8sPGJyPg0KPGJyPg0Kc2VlIGJl
bG93Ljxicj4NCjxicj4NCiZndDsgQW0gMTAuMDQuMjAxOCB1bSAwMzowNCBzY2hyaWViIFJvYmVy
dG8gUGVvbiAmbHQ7ZmVuaXhAZmIuY29tJmd0Ozo8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWRkaW5n
IGFub3RoZXIgUE4gd291bGQgcHJvYmFibHkgbm90IGJlIHN1ZmZpY2llbnQtLSBvbmUgd291bGQg
bmVlZCB0byBlbnN1cmUgdGhhdCB0aGUgb3NzaWZpZWQgUE4gd2FzIHByZXNlbnRlZCB3aXRoIHRo
ZSByaWdodCBzZXF1ZW5jaW5nIGFzIHdlbGwsIHdoaWNoIG1pZ2h0IGJlIGRpZmZpY3VsdCwgb3Ig
ZXhwZW5zaXZlLjxicj4NCjxicj4NClllcywgdGhhdCBpcyBlYXN5LiBXaHkgZG8geW91IHRoaW5r
IHRoYXQgaXMgZGlmZmljdWx0IG9yIGV4cGVuc2l2ZT88YnI+DQo8YnI+DQomZ3Q7IE9zc2lmaWNh
dGlvbiBpcyBzdXJwcmlzaW5nbHkgZGlmZmljdWx0IHRvIHdvcmsgYXJvdW5kIG9uY2UgaXQgc2V0
cyBpbiwgYXMgZXZlbiBmaWd1cmluZyBvdXQgaG93IGl0IGlzIGltcGFjdGluZyB5b3UgY2FuIGJl
IHN1YnN0YW50aWFsIHdvcmsuPGJyPg0KPGJyPg0KVGhhdCBpcyB0cnVlIGZvciBhIHByb3RvY29s
IGxpa2UgVENQIHZlcnkgdGhlIGludmFyaWFudCBpcyBsYXJnZSBhbmQgbm9uIG9mIHRoZSBiaXRz
IGFyZSBlbmNyeXB0ZWQuIEZvciBRVUlDIHdlIGhhdmUgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBz
aXR1YXRpb24uPGJyPg0KPGJyPg0KTWlyamE8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZn
dDsgLT1SPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IO+7v09uIDQvNS8xOCwgMjoyNyBBTSwgJnF1b3Q7
UVVJQyBvbiBiZWhhbGYgb2YgTWlyamEgS8O8aGxld2luZCZxdW90OyAmbHQ7cXVpYy1ib3VuY2Vz
QGlldGYub3JnIG9uIGJlaGFsZiBvZiBtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoJmd0
OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgTGV0IG1lIHJl
cGVhdCBhbm90aGVyIHBvc2l0aW9uIHRoZW4gYXMgd2VsbDo8YnI+DQomZ3Q7IDxicj4NCiZndDsm
Z3Q7IEFtIDA1LjA0LjIwMTggdW0gMDI6NDQgc2NocmllYiBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7
aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs6PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSWYg
d2UgYXJlIGluIHRoZSBidXNpbmVzcyBvZiByZXBlYXRpbmcgb3VyIHBvc2l0aW9ucywgc28gYmUg
aXQuIEkgYW0gcHJldHR5IG11Y2ggb24gdGhlIHNhbWUgbGluZSBhcyBQYXRyaWNrIGFuZCBvdGhl
cnM6PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgMSkgUHJpdmFjeSBpcyBub3Qgb3B0aW9u
YWwuIEFuZCB5ZXMsIHJlbW92aW5nICZxdW90O2xpbmthYmlsaXR5IHRocm91Z2ggUE4mcXVvdDsg
aXMgaW1wb3J0YW50LCBiZWNhdXNlIHdoZW4gdGhlIGNvbm5lY3Rpb24gSUQgYW5kIHRoZSBzb3Vy
Y2UgYWRkcmVzcyBhbHNvIGNoYW5nZSwgdGhlIG9ubHkgb3RoZXIgY3VlIGZvciBsaW5rYWJpbGl0
eSBpcyB0aW1pbmcuIFRpbWluZyBjYW4gYmUgYWRkcmVzc2VkIGJ5IGhhdmluZyBvdmVybGFwcGlu
ZyBjb25uZWN0aW9ucy48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IFRpbWluZyBkb2VzbuKAmXQgaGVscCBoZXJlIGVpdGhlciBiZWNhdXNlIHlvdSBzdGlsbCBoYXZl
IHRoZSBzYW1lIGRlc3RpbmF0aW9uIElQLCBib3RoIHBvcnQgbnVtYmVycyBhbmQgdGhlIGZhY3Qg
dGhhdCBhIG1pZ3JhdGVkIGNvbm5lY3Rpb24gZG9lcyBub3QgaGF2ZSBhIGhhbmRzaGFrZS4gSWYg
d2Ugd2FudCB0byBhZGRyZXNzIHRoZSBsaW5rYWJpbGl0eSBwcm9ibGVtLCB3ZSB3b3VsZCBuZWVk
IHRvIGRvIG11Y2ggbW9yZSwgcHJvYmFibHkNCiBiYXJpbmcgbW9yZSBoaXRzIG9uIHBlcmZvcm1h
bmNlLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB0aG91Z2h0IHdl
IGRpc2N1c3NlZCB0aGlzIGFscmVhZHkgZW5kbGVzc2x5IGFuZCBjb25jbHVkZWQgdGhhdCBQTkUg
ZG9lcyBub3QgaGVscCBsaW5rYWJpbGl0eS48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJz
cDsmbmJzcDsgVGhlbiBhbiBhcmd1bWVudCBmb3Igb3NzaWZpY2F0aW9uIHdhcyBicm9hZCB1cC4g
SG93ZXZlciwgd2UgcmVhbGx5IGNhbm5vdCBjb21wYXJlIHRoZSBzaXR1YXRpb24gaGVyZSB3aXRo
IFRDUC4gV2l0aCBUQ1AgZXZlcnl0aGluZyBpcyBpbiB0aGUgY2xlYXIgaW5jbC4gYWxzbyB0aGUg
cmV0cmFuc21pc3Npb25zLiBJbiBjYXNlIG9mIE1QVENQIHRoaXMgd2FzIHJhdGhlciB0aGUgcHJv
YmxlbSB0aGUgdGhlIHNlcSMgYmVjYXVzZSBpZiB5b3XigJlkDQogdXNlIHRoZSBzYW1lIHNlcSMg
bnVtYmVyIHNwYWNlIG9uIGJvdGggY29ubmVjdGlvbnMgaXQgd291bGQgbGlrZSBsb3NzIGJ1dCB3
aXRob3V0IGEgcmV0cmFuc21pc3Npb24uIEZ1cnRoZXIgYm94ZXMgdGhhdCByZW9yZGVyLCB1c3Vh
bGx5IGRvIHRoYXQgaW4gc2l0dWF0aW9uIHdoZXJlIHBhY2tldHMgd2VyZSB0cmFuc21pdHRlZCBm
b3IgYSBrbm93biByZWFzb24gb3V0LW9mIG9yZGVyIHByZXZpb3VzbHksIGUuZy4gd2hlbiBtdWx0
aXBsZSBwYXRocw0KIGFyZSB1c2VkIGluIHRoZSBuZXR3b3JrLiBUaGUgcmVjb21tZW5kYXRpb24g
d2Ugc3RpbGwgZ2l2ZSBpbiB0aGUgSUVURiB0cmFuc3BvcnQgYXJlYSBpcyB0aGF0IGluIHN1Y2gg
YSBzaXR1YXRpb24gdGhlIHNjaGVkdWxpbmcgc2hvdWxkIG5vdCBiZSBkb25lIG9uIGEgcGVyLXBh
Y2tldCBsZXZlbCBidXQgcGVyLWZsb3cuIEhvd2V2ZXIsIHRob3NlIHNjaGVtZSB0aGF0IGRvIHBl
ci1wYWNrZXQgc2NoZWR1bGluZyB1c3VhbGx5IGFsc28gYXBwbHkgbWVjaGFuaXNtDQogdG8gcmUt
b3JkZXIgYWZ0ZXJ3YXJkcy4gVGhleSBjYW4ganVzdCB1c2UgdGhlIFRDUCBzZXEjIGZvciB0aGF0
IGJ1dCBmb3Igbm9uLVRDUCB0aGV5IHdvdWxkIHNpbXBseSBhZGQgdGhlaXIgb3duIGVuY2Fwc3Vs
YXRpb24gd2l0aCBhIHNlcSPigKY8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz
cDsgUGxlYXNlIGtlZXAgaW4gbWluZCB0aGF0IGV2ZW4gaWYgYW4gKHVuZW5jcnlwdGVkKSBQTiBn
ZXRzIG9zc2lmaWVkIGJ5IHRoZSBuZXR3b3JrLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsg
aW4gY2FzZSBvZiBRVUlDIHRoYXQgZG9lcyBub3QgbWVhbiB0aGF0IHdlIGNhbuKAmXQgY2hhbmdl
IHRoZSB0cmFuc3BvcnQgbWFjaGluZXJ5IGFueW1vcmUuIEN1cnJlbnRseSB0aGUgZXhwb3NlZCBQ
TiBpcyBhbHNvIHVzZWQgZm9yIGNvbmdlc3Rpb24gY29udHJvbCBhbmQgcmV0cmFuc21pc3Npb24s
IGhvd2V2ZXIsIHdlIGNhbiBzdGlsbCBhZGQgYW5vdGhlciBQTiBpbiB0aGUgZW5jcnlwdGVkIHBh
cnQgYW5kIHJlc29sdmVkIHRoZSBmYWN0IHRoYXQNCiB0aGUgY3VycmVudCBQTiBpcyBvdmVybG9h
ZGVkIGZvciBkaWZmZXJlbnQgZnVuY3Rpb25zLjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZu
YnNwOyZuYnNwOyBDdXJyZW50bHksIEkgcmVhbGx5IHN0aWxsIGRvbuKAmXQgc2VlIHRoZSBiZW5l
Zml0IG9mIFBORSBidXQgb25seSBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgYW5kIGtub3duIHBlcmZv
cm1hbmNlIGRlZ3JhZGF0aW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw
OyBNaXJqYTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K
Jmd0OyA8YnI+DQo8YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_BY2PR15MB0775B4ACF7DB9124E89016F0CDB00BY2PR15MB0775namp_--


From nobody Mon Apr 16 21:47:16 2018
Return-Path: 
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEBF1204DA; Mon, 16 Apr 2018 21:47:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: quic@ietf.org, lars@netapp.com, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org
Subject: quic - New Meeting Session Request for IETF 102
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152394043545.26198.14918502171494990759.idtracker@ietfa.amsl.com>
Date: Mon, 16 Apr 2018 21:47: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: Tue, 17 Apr 2018 04:47:15 -0000

A new meeting session request has just been submitted by Lars Eggert, a Chair of the quic working group.


---------------------------------------------------------
Working Group Name: QUIC
Area Name: Transport Area
Session Requester: Lars Eggert

Number of Sessions: 2
Length of Session(s):  2.5 Hours, 2.5 Hours
Number of Attendees: 200
Conflicts to Avoid: 
 First Priority: tsvarea tsvwg tcpm iccrg httpbis tls dispatch
 Second Priority: mptcp saag
 Third Priority: irtfopen maprg


People who must be present:
  Sean Turner
  Mark Nottingham
  Patrick R. McManus
  Jana Iyengar
  Martin Thomson
  Spencer Dawkins
  Brian Trammell
  Lars Eggert
  Mike Bishop
  Ian Swett
  Alan Frindell

Resources Requested:
  Experimental Room Setup (U-Shape and classroom, subject to availability)

Special Requests:
  Two consecutive days early in the week, if possible; 2 hour slot(s) fine too, if that makes it easier.
---------------------------------------------------------


From nobody Mon Apr 16 22:06:07 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F6612EAB7 for ; Mon, 16 Apr 2018 22:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p6bpw81Xndf for ; Mon, 16 Apr 2018 22:06:02 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8549D124205 for ; Mon, 16 Apr 2018 22:06:01 -0700 (PDT)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx60.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1f8IoO-000Eeq-7G for quic@ietf.org; Tue, 17 Apr 2018 07:05:55 +0200
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1f8Int-0005i8-L2 for quic@ietf.org; Tue, 17 Apr 2018 01:05:22 -0400
Received: (qmail 9495 invoked from network); 17 Apr 2018 05:05:14 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.78]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Apr 2018 05:05:13 -0000
To: Roberto Peon , =?UTF-8?Q?Mirja_K=c3=bchlewind?= 
Cc: "quic@ietf.org" 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>    <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch> 
From: Christian Huitema 
Openpgp: preference=signencrypt
Message-ID: 
Date: Mon, 16 Apr 2018 22:05:04 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------4E7EB142F9BC0209D4AF845D"
Content-Language: en-US
Subject: Re: Getting to consensus on packet number encryption
X-Originating-IP: 168.144.250.232
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.11)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5i0MmRrb6ml6B1n7BThbRXd602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViWLaTxHvbm0E6QFpGGJDnSs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB6b6XZpNC1wnpsGpZepb/px/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpX8nIu6prlMU9qLY4Lxa6TDZO4QNCMqLJSDylLzK7xkvvwKHH8RRuLX z1PhqHAL0sOO98fck6astPPFccqiLCixm7xl+RQ3vIZqfBpLwZArl3I1g+tBSv0B+cgW7VoPEiDI +8QkA7WZKXURE/tHtZ/u9H4DectLaqn7kLktZo9lq1hNqyux1yaQvYroLJ1yFFoLB6985QCOnb53 dgbGIuRzQZs4iXA/pTuddAL2KCGOjKaoYeoLX/yEBEWAApw66TomM5/SMi121Scyc6igqIaHZhUF HKbUZMv7c3cOU/0VEib1mfTPzunlam64tUNDvP/bMcctPzMPLiqwr8e+aie3zxvdN0leIxaNIjs7 cbPZdZnckpWaLvahyBjmQxBKOztcoEJy5JI/WnEUTEvEJGtKRioNM4YdAO5dQww9T9HjAWtJl6pO HngTL5HKgxzCo5M=
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 05:06:05 -0000

This is a multi-part message in MIME format.
--------------4E7EB142F9BC0209D4AF845D
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Since you all want to read more text, I wrote a summary of the various
proposals in the QUIC Wiki:
https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-issues-and-alternatives.


Of course, that summary reflects my own modest understanding. But then
it's a wiki, so you can easily correct me.


-- Christian Huitema



On 4/16/2018 12:56 PM, Roberto Peon wrote:
>
> Paraphrasing:
>
> > PN insufficient to fix ossification, why is that difficult/expensive?
>
> As described in the other subthread, you'd have to emulate the same
> ordering of the previously-ossified PN while also doing whatever
> newness you want with the new PN.
> That sounds fabulously complex. You'd end up running two different
> implementations simultaneously.
>
> > Ossification/invariant without encryption:
> Encryption solves it, sounds like we agree on that 😊
>
>
> -=R
>
> ------------------------------------------------------------------------
> *From:* QUIC  on behalf of Mirja Kühlewind
> 
> *Sent:* Friday, April 13, 2018 4:06:40 AM
> *To:* Roberto Peon
> *Cc:* quic@ietf.org; Christian Huitema
> *Subject:* Re: Getting to consensus on packet number encryption
>  
> Hi Roberto,
>
> see below.
>
> > Am 10.04.2018 um 03:04 schrieb Roberto Peon :
> >
> > Adding another PN would probably not be sufficient-- one would need
> to ensure that the ossified PN was presented with the right sequencing
> as well, which might be difficult, or expensive.
>
> Yes, that is easy. Why do you think that is difficult or expensive?
>
> > Ossification is surprisingly difficult to work around once it sets
> in, as even figuring out how it is impacting you can be substantial work.
>
> That is true for a protocol like TCP very the invariant is large and
> non of the bits are encrypted. For QUIC we have a completely different
> situation.
>
> Mirja
>
>
> >
> > -=R
> >
> > On 4/5/18, 2:27 AM, "QUIC on behalf of Mirja Kühlewind"
> 
> wrote:
> >
> >    Let me repeat another position then as well:
> >
> >> Am 05.04.2018 um 02:44 schrieb Christian Huitema :
> >>
> >> If we are in the business of repeating our positions, so be it. I
> am pretty much on the same line as Patrick and others:
> >>
> >> 1) Privacy is not optional. And yes, removing "linkability through
> PN" is important, because when the connection ID and the source
> address also change, the only other cue for linkability is timing.
> Timing can be addressed by having overlapping connections.
> >>
> >    Timing doesn’t help here either because you still have the same
> destination IP, both port numbers and the fact that a migrated
> connection does not have a handshake. If we want to address the
> linkability problem, we would need to do much more, probably baring
> more hits on performance.
> >
> >    I thought we discussed this already endlessly and concluded that
> PNE does not help linkability.
> >
> >    Then an argument for ossification was broad up. However, we
> really cannot compare the situation here with TCP. With TCP everything
> is in the clear incl. also the retransmissions. In case of MPTCP this
> was rather the problem the the seq# because if you’d use the same seq#
> number space on both connections it would like loss but without a
> retransmission. Further boxes that reorder, usually do that in
> situation where packets were transmitted for a known reason out-of
> order previously, e.g. when multiple paths are used in the network.
> The recommendation we still give in the IETF transport area is that in
> such a situation the scheduling should not be done on a per-packet
> level but per-flow. However, those scheme that do per-packet
> scheduling usually also apply mechanism to re-order afterwards. They
> can just use the TCP seq# for that but for non-TCP they would simply
> add their own encapsulation with a seq#…
> >
> >    Please keep in mind that even if an (unencrypted) PN gets
> ossified by the network,
> >    in case of QUIC that does not mean that we can’t change the
> transport machinery anymore. Currently the exposed PN is also used for
> congestion control and retransmission, however, we can still add
> another PN in the encrypted part and resolved the fact that the
> current PN is overloaded for different functions.
> >
> >    Currently, I really still don’t see the benefit of PNE but only
> additional complexity and known performance degradation.
> >
> >    Mirja
> >
> >
> >
> >
> >
>


--------------4E7EB142F9BC0209D4AF845D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Since you all want to read more text, I wrote a summary of the
      various proposals in the QUIC Wiki:
https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-issues-and-alternatives.

    


    

    
Of course, that summary reflects my own modest understanding. But
      then it's a wiki, so you can easily correct me.

    


    

    
-- Christian Huitema

    

    
 

    

    

    
On 4/16/2018 12:56 PM, Roberto Peon
      wrote:

    

    

      
      
      

        
Paraphrasing:

          

          > PN insufficient to fix ossification, why is that
          difficult/expensive?

          

          As described in the other subthread, you'd have to emulate the
          same ordering of the previously-ossified PN while also doing
          whatever newness you want with the new PN.

          That sounds fabulously complex. You'd end up running two
          different implementations simultaneously.

          

          > Ossification/invariant without encryption:

          Encryption solves it, sounds like we agree on that 😊

        


        

        
-=R

        

      

      

      
From: QUIC
          <quic-bounces@ietf.org> on behalf of Mirja Kühlewind
          <mirja.kuehlewind@tik.ee.ethz.ch>

          Sent: Friday, April 13, 2018 4:06:40 AM

          To: Roberto Peon

          Cc: quic@ietf.org; Christian Huitema

          Subject: Re: Getting to consensus on packet number
          encryption
        
 

      

      

            
Hi Roberto,

              

              see below.

              

              > Am 10.04.2018 um 03:04 schrieb Roberto Peon
              <fenix@fb.com>:

              > 

              > Adding another PN would probably not be sufficient--
              one would need to ensure that the ossified PN was
              presented with the right sequencing as well, which might
              be difficult, or expensive.

              

              Yes, that is easy. Why do you think that is difficult or
              expensive?

              

              > Ossification is surprisingly difficult to work around
              once it sets in, as even figuring out how it is impacting
              you can be substantial work.

              

              That is true for a protocol like TCP very the invariant is
              large and non of the bits are encrypted. For QUIC we have
              a completely different situation.

              

              Mirja

              

              

              > 

              > -=R

              > 

              > On 4/5/18, 2:27 AM, "QUIC on behalf of Mirja
              Kühlewind" <quic-bounces@ietf.org on behalf of
              mirja.kuehlewind@tik.ee.ethz.ch> wrote:

              > 

              >    Let me repeat another position then as well:

              > 

              >> Am 05.04.2018 um 02:44 schrieb Christian Huitema
              <huitema@huitema.net>:

              >> 

              >> If we are in the business of repeating our
              positions, so be it. I am pretty much on the same line as
              Patrick and others:

              >> 

              >> 1) Privacy is not optional. And yes, removing
              "linkability through PN" is important, because when the
              connection ID and the source address also change, the only
              other cue for linkability is timing. Timing can be
              addressed by having overlapping connections.

              >> 

              >    Timing doesn’t help here either because you still
              have the same destination IP, both port numbers and the
              fact that a migrated connection does not have a handshake.
              If we want to address the linkability problem, we would
              need to do much more, probably baring more hits on
              performance. 

              > 

              >    I thought we discussed this already endlessly and
              concluded that PNE does not help linkability.

              > 

              >    Then an argument for ossification was broad up.
              However, we really cannot compare the situation here with
              TCP. With TCP everything is in the clear incl. also the
              retransmissions. In case of MPTCP this was rather the
              problem the the seq# because if you’d use the same seq#
              number space on both connections it would like loss but
              without a retransmission. Further boxes that reorder,
              usually do that in situation where packets were
              transmitted for a known reason out-of order previously,
              e.g. when multiple paths are used in the network. The
              recommendation we still give in the IETF transport area is
              that in such a situation the scheduling should not be done
              on a per-packet level but per-flow. However, those scheme
              that do per-packet scheduling usually also apply mechanism
              to re-order afterwards. They can just use the TCP seq# for
              that but for non-TCP they would simply add their own
              encapsulation with a seq#…

              > 

              >    Please keep in mind that even if an (unencrypted)
              PN gets ossified by the network,

              >    in case of QUIC that does not mean that we can’t
              change the transport machinery anymore. Currently the
              exposed PN is also used for congestion control and
              retransmission, however, we can still add another PN in
              the encrypted part and resolved the fact that the current
              PN is overloaded for different functions.

              > 

              >    Currently, I really still don’t see the benefit of
              PNE but only additional complexity and known performance
              degradation.

              > 

              >    Mirja

              > 

              > 

              > 

              > 

              > 

              

            

          

    

    

  


--------------4E7EB142F9BC0209D4AF845D--


From nobody Mon Apr 16 23:15:16 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A1712EACA for ; Mon, 16 Apr 2018 23:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTjGsIa9BTjK for ; Mon, 16 Apr 2018 23:15:11 -0700 (PDT)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D3C126B6D for ; Mon, 16 Apr 2018 23:15:11 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id p6so11679725pfn.4 for ; Mon, 16 Apr 2018 23:15:11 -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=/QB/PD44JwTDeURvy3Mobiw9fguKaP7Oc0BdE4QnZ3g=; b=hn1/5GiEWF9ad/uPQijsG7Fnj4+bGZ9+NCpXO2eqo4u2UgEUGSVSyPtCjYeFUVFrS9 xffH3wcNFQXbsv8VpAkYsbPG3WdZjLRClqSghfQW088dlJ6OY3ZvXf7ny6rj8NPHKbvA 8GAh0UKRhLNZO1XpgOn6HFrcV5ooRutYcvLyKz2yyeV4sFfVatVigM+/iWc7vBNFiUJk G054nqlRuA534m/iXilUaNX9TpOsa12zVORoqMSBlXIUTEjqWaQ1oyNI2RvtD2JoOaPv SaAM9GNrvlRCC339SsxyqLQ0+S1qgP3QttsT6pCtb+WmUV6o5tX0pLDK2zNmCIu4HInP EkPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=/QB/PD44JwTDeURvy3Mobiw9fguKaP7Oc0BdE4QnZ3g=; b=psMdKQCS0XfCCboNz4pyLoASboZRofIC4b8TMQfMvxiYxD7n2TO3UsfOAUlc2ELnKA j/w1fUqPkFb3SBSRqzew+9OfMXg7Rf7c88hymCftaaciRmOTbkasC7Jr9GuEmbf2N4i0 ZpEDF17aysPNOcTH/6t3dRtArRn3LcSpSvJepJ9sqg0QFEhCE8QnqTf/u8WG62si00Hl OrRTD/1q45YE6VTq/2yYVsw1Rz7an/yt6sbQizURFYg0khoedo17/HIEBsXUBqvgV0eB Aba5CK68QTZa9BAnlDvHT1xEMeWmRXxJShJZGYc0Hd/WK2JEgOWGQGOBjeVpbouZrU0A PBlQ==
X-Gm-Message-State: ALQs6tC3qbyJno9Gmdq1+mcjE8pcNqo+xPDrMh+O9QYteUGv0yZHknqv GRKHyYJXHhhLDY0zXBiNbahqwPEtR6F5jNcFkxg=
X-Google-Smtp-Source: AIpwx48qsx/0pzU8En9YQnLZ9sR4vrvE7cEOWakoFMtCfsMlFRNRAPn2WVdd5O0QLXs/RM745k567r5TDdK57OE/5pU=
X-Received: by 10.99.124.68 with SMTP id l4mr721576pgn.67.1523945710615; Mon, 16 Apr 2018 23:15:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Mon, 16 Apr 2018 23:15:09 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>    <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>  
From: Kazuho Oku 
Date: Tue, 17 Apr 2018 15:15:09 +0900
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Christian Huitema 
Cc: Roberto Peon , =?UTF-8?Q?Mirja_K=C3=BChlewind?= ,  "quic@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045da9a2bd0067056a0542b8"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Apr 2018 06:15:14 -0000

--f403045da9a2bd0067056a0542b8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Christian,

Thank you for writing the wonderful summary.

Reading it, I think that I now see two issues with the alternative
approaches that use a weaker cipher (i.e. alternative PN encryption, 64bit
encrypted PN).

> We can argue that the algorithm does not have to be as robust as AES. The
main requirement is to prevent real time analysis of sequence numbers by
middle-boxes. This is achieved as long as the encryption key cannot be
retrieved in a short time by the middle-boxes. If they could do that, we
would be once again on the path to ossification. XOR and simple obfuscation
probably don't meet that goal, but IPCrypt probably does, and a more robust
algorithm certainly would.

As you state, it is true that preventing real time analysis is important.
But are we sure that we do not need to consider offline attacks? I would be
interested in arguing about the other requirement than ossification:
privacy.

A pervasive monitor might collect CIDs and encrypted PNs that were being
used, and then use the encrypted PNs as a source to correlate CIDs to
reconstruct a QUIC connection. Are we sure that a weak cipher does not leak
such trace?

Considering that, I think that the alternative approaches should have
per-CID PN encryption keys, even though I am not sure if there are no other
privacy-related issues.

The other issue is about crypto agility. #1179 has agility in sense that
the corresponding CTR mode is used for encrypting the PN. OTOH, the two
alternatives using a simple cipher are not agile. So we might need to
define two types of simpler ciphers for PN encryption, if consider that
privacy issues (like the one above) might arise in the future.

2018-04-17 14:05 GMT+09:00 Christian Huitema :

> Since you all want to read more text, I wrote a summary of the various
> proposals in the QUIC Wiki: https://github.com/quicwg/base
> -drafts/wiki/Summary-of-the-PN-encryption-issues-and-alternatives.
>
>
> Of course, that summary reflects my own modest understanding. But then
> it's a wiki, so you can easily correct me.
>
-- Christian Huitema
>
>
>
> On 4/16/2018 12:56 PM, Roberto Peon wrote:
>
> Paraphrasing:
>
> > PN insufficient to fix ossification, why is that difficult/expensive?
>
> As described in the other subthread, you'd have to emulate the same
> ordering of the previously-ossified PN while also doing whatever newness
> you want with the new PN.
> That sounds fabulously complex. You'd end up running two different
> implementations simultaneously.
>
> > Ossification/invariant without encryption:
> Encryption solves it, sounds like we agree on that =F0=9F=98=8A
>
>
> -=3DR
> ------------------------------
> *From:* QUIC   on behalf of
> Mirja K=C3=BChlewind 
> 
> *Sent:* Friday, April 13, 2018 4:06:40 AM
> *To:* Roberto Peon
> *Cc:* quic@ietf.org; Christian Huitema
> *Subject:* Re: Getting to consensus on packet number encryption
>
> Hi Roberto,
>
> see below.
>
> > Am 10.04.2018 um 03:04 schrieb Roberto Peon 
> :
> >
> > Adding another PN would probably not be sufficient-- one would need to
> ensure that the ossified PN was presented with the right sequencing as
> well, which might be difficult, or expensive.
>
> Yes, that is easy. Why do you think that is difficult or expensive?
>
> > Ossification is surprisingly difficult to work around once it sets in,
> as even figuring out how it is impacting you can be substantial work.
>
> That is true for a protocol like TCP very the invariant is large and non
> of the bits are encrypted. For QUIC we have a completely different
> situation.
>
> Mirja
>
>
> >
> > -=3DR
> >
> > =EF=BB=BFOn 4/5/18, 2:27 AM, "QUIC on behalf of Mirja K=C3=BChlewind" <=
quic-bounces@ietf.org
> on behalf of mirja.kuehlewind@tik.ee.ethz.ch>
>  wrote:
> >
> >    Let me repeat another position then as well:
> >
> >> Am 05.04.2018 um 02:44 schrieb Christian Huitema 
> :
> >>
> >> If we are in the business of repeating our positions, so be it. I am
> pretty much on the same line as Patrick and others:
> >>
> >> 1) Privacy is not optional. And yes, removing "linkability through PN"
> is important, because when the connection ID and the source address also
> change, the only other cue for linkability is timing. Timing can be
> addressed by having overlapping connections.
> >>
> >    Timing doesn=E2=80=99t help here either because you still have the s=
ame
> destination IP, both port numbers and the fact that a migrated connection
> does not have a handshake. If we want to address the linkability problem,
> we would need to do much more, probably baring more hits on performance.
> >
> >    I thought we discussed this already endlessly and concluded that PNE
> does not help linkability.
> >
> >    Then an argument for ossification was broad up. However, we really
> cannot compare the situation here with TCP. With TCP everything is in the
> clear incl. also the retransmissions. In case of MPTCP this was rather th=
e
> problem the the seq# because if you=E2=80=99d use the same seq# number sp=
ace on
> both connections it would like loss but without a retransmission. Further
> boxes that reorder, usually do that in situation where packets were
> transmitted for a known reason out-of order previously, e.g. when multipl=
e
> paths are used in the network. The recommendation we still give in the IE=
TF
> transport area is that in such a situation the scheduling should not be
> done on a per-packet level but per-flow. However, those scheme that do
> per-packet scheduling usually also apply mechanism to re-order afterwards=
.
> They can just use the TCP seq# for that but for non-TCP they would simply
> add their own encapsulation with a seq#=E2=80=A6
> >
> >    Please keep in mind that even if an (unencrypted) PN gets ossified b=
y
> the network,
> >    in case of QUIC that does not mean that we can=E2=80=99t change the =
transport
> machinery anymore. Currently the exposed PN is also used for congestion
> control and retransmission, however, we can still add another PN in the
> encrypted part and resolved the fact that the current PN is overloaded fo=
r
> different functions.
> >
> >    Currently, I really still don=E2=80=99t see the benefit of PNE but o=
nly
> additional complexity and known performance degradation.
> >
> >    Mirja
> >
> >
> >
> >
> >
>
>
>


--=20
Kazuho Oku

--f403045da9a2bd0067056a0542b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Christian,

Thank you for writing the=
 wonderful summary.

Reading it, I think that I now=
 see two issues with the alternative approaches that use a weaker cipher (i=
.e. alternative PN encryption, 64bit encrypted PN).

> We can argue that the algorithm does not have to be as robust as AES=
. The main requirement is to prevent real time analysis of sequence numbers=
 by middle-boxes. This is achieved as long as the encryption key cannot be =
retrieved in a short time by the middle-boxes. If they could do that, we wo=
uld be once again on the path to ossification. XOR and simple obfuscation p=
robably don't meet that goal, but IPCrypt probably does, and a more rob=
ust algorithm certainly would.

As you state, i=
t is true that preventing real time analysis is important. But are we sure =
that we do not need to consider offline attacks? I would be interested in a=
rguing about the other requirement than ossification: privacy.
A pervasive monitor might collect CIDs and encrypted PNs =
that were being used, and then use the encrypted PNs as a source to correla=
te CIDs to reconstruct a QUIC connection. Are we sure that a weak cipher do=
es not leak such trace?

Considering that, I =
think that the alternative approaches should have per-CID PN encryption key=
s, even though I am not sure if there are no other privacy-related issues.<=
/div>

The other issue is about crypto agility. #1179 has=
 agility in sense that the corresponding CTR mode is used for encrypting th=
e PN. OTOH, the two alternatives using a simple cipher are not agile. So we=
 might need to define two types of simpler ciphers for PN encryption, if co=
nsider that privacy issues (like the one above) might arise in the future.<=
/div>

2018-04-17 14:05 GMT+09:00 Christian Huitema <huitema@huitema.net>:

 =20
   =20
 =20
  

    
-- Christian Huitema

    

    
 

    

    

    
On 4/16/2018 12:56 PM, Roberto Peon
      wrote:

    

    

     =20
     =20
      

        
Paraphrasing:

          

          > PN insufficient to fix ossification, why is that
          difficult/expensive?

          

          As described in the other subthread, you'd have to emulate th=
e
          same ordering of the previously-ossified PN while also doing
          whatever newness you want with the new PN.

          That sounds fabulously complex. You'd end up running two
          different implementations simultaneously.

          

          > Ossification/invariant without encryption:

          Encryption solves it, sounds like we agree on that =F0=9F=
=98=8A

        


        

        
-=3DR

        

      

      

      
From: QUIC
          <quic-bounces@ietf.org> on behalf of Mirja K=C3=BChlewind
          <mirja.kuehlewind@tik.ee.ethz.ch>

          Sent: Friday, April 13, 2018 4:06:40 AM

          To: Roberto Peon

          Cc: quic@ietf.org; Christian Huitema

          Subject: Re: Getting to consensus on packet number
          encryption
        
=C2=A0

      

      

            
Hi Roberto,

              

              see below.

              

              > Am 10.04.2018 um 03:04 schrieb Roberto Peon
              =
<fenix@fb.com>:

              > 

              > Adding another PN would probably not be sufficient--
              one would need to ensure that the ossified PN was
              presented with the right sequencing as well, which might
              be difficult, or expensive.

              

              Yes, that is easy. Why do you think that is difficult or
              expensive?

              

              > Ossification is surprisingly difficult to work around
              once it sets in, as even figuring out how it is impacting
              you can be substantial work.

              

              That is true for a protocol like TCP very the invariant is
              large and non of the bits are encrypted. For QUIC we have
              a completely different situation.

              

              Mirja

              

              

              > 

              > -=3DR

              > 

              > =EF=BB=BFOn 4/5/18, 2:27 AM, "QUIC on behalf of Mir=
ja
              K=C3=BChlewind" <=
quic-bounces@ietf.org on behalf of
              mirja.kuehlewind@tik.ee.ethz.ch> wrote:

              > 

              >=C2=A0=C2=A0=C2=A0 Let me repeat another position then as=
 well:

              > 

              >> Am 05.04.2018 um 02:44 schrieb Christian Huitema
              <huitema@huitema.net>:

              >> 

              >> If we are in the business of repeating our
              positions, so be it. I am pretty much on the same line as
              Patrick and others:

              >> 

              >> 1) Privacy is not optional. And yes, removing
              "linkability through PN" is important, because when=
 the
              connection ID and the source address also change, the only
              other cue for linkability is timing. Timing can be
              addressed by having overlapping connections.

              >> 

              >=C2=A0=C2=A0=C2=A0 Timing doesn=E2=80=99t help here eithe=
r because you still
              have the same destination IP, both port numbers and the
              fact that a migrated connection does not have a handshake.
              If we want to address the linkability problem, we would
              need to do much more, probably baring more hits on
              performance. 

              > 

              >=C2=A0=C2=A0=C2=A0 I thought we discussed this already en=
dlessly and
              concluded that PNE does not help linkability.

              > 

              >=C2=A0=C2=A0=C2=A0 Then an argument for ossification was =
broad up.
              However, we really cannot compare the situation here with
              TCP. With TCP everything is in the clear incl. also the
              retransmissions. In case of MPTCP this was rather the
              problem the the seq# because if you=E2=80=99d use the same se=
q#
              number space on both connections it would like loss but
              without a retransmission. Further boxes that reorder,
              usually do that in situation where packets were
              transmitted for a known reason out-of order previously,
              e.g. when multiple paths are used in the network. The
              recommendation we still give in the IETF transport area is
              that in such a situation the scheduling should not be done
              on a per-packet level but per-flow. However, those scheme
              that do per-packet scheduling usually also apply mechanism
              to re-order afterwards. They can just use the TCP seq# for
              that but for non-TCP they would simply add their own
              encapsulation with a seq#=E2=80=A6

              > 

              >=C2=A0=C2=A0=C2=A0 Please keep in mind that even if an (u=
nencrypted)
              PN gets ossified by the network,

              >=C2=A0=C2=A0=C2=A0 in case of QUIC that does not mean tha=
t we can=E2=80=99t
              change the transport machinery anymore. Currently the
              exposed PN is also used for congestion control and
              retransmission, however, we can still add another PN in
              the encrypted part and resolved the fact that the current
              PN is overloaded for different functions.

              > 

              >=C2=A0=C2=A0=C2=A0 Currently, I really still don=E2=80=99=
t see the benefit of
              PNE but only additional complexity and known performance
              degradation.

              > 

              >=C2=A0=C2=A0=C2=A0 Mirja

              > 

              > 

              > 

              > 

              > 

              

            

          

    

    

  






-- 
Kazuho Oku




--f403045da9a2bd0067056a0542b8--


From nobody Tue Apr 17 11:59:18 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D6E12D95F for ; Tue, 17 Apr 2018 11:59:17 -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 wnhizbdWtQXS for ; Tue, 17 Apr 2018 11:59:14 -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 16DD1127909 for ; Tue, 17 Apr 2018 11:59:14 -0700 (PDT)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1f8Vos-0003om-7K for quic@ietf.org; Tue, 17 Apr 2018 20:59:11 +0200
Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1f8Voq-0006dy-CA for quic@ietf.org; Tue, 17 Apr 2018 14:59:08 -0400
Received: (qmail 23089 invoked from network); 17 Apr 2018 18:59:06 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.78]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Apr 2018 18:59:06 -0000
To: Kazuho Oku 
Cc: "quic@ietf.org" 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   
From: Christian Huitema 
Openpgp: preference=signencrypt
Message-ID: <1412f856-5eaf-1c7a-266f-2b4d77355647@huitema.net>
Date: Tue, 17 Apr 2018 11:58:58 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: Getting to consensus on packet number encryption
X-Originating-IP: 168.144.250.230
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.54)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5mCWEWvzJWIliBsvjgr9231602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViSl8/m5x/t9e5a8VLcvu9687i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1c1FPznmLv13i1NL5aXaHx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpU1moK5+umQAfdUHagyvOVYknoPWk5MqTqGy8eyW1C49Ln4bjYtAivC cFEEK40iaDBz1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAV5ZxrRnRt4PqMzH3k7hTkr1YE7tCqypI5WX0qWh4YQLAmBiF3PbpKUeSn XrfzBBAqbr8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLVBfU8ctw02+BCtWDMNtlI8QKHY 6H+wSCoVvwvquzDDiBiyp9ZnkUf43DmQkwMxjMGYdub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0=
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 18:59:17 -0000

On 4/16/2018 11:15 PM, Kazuho Oku wrote:
> Hi Christian,
>
> Thank you for writing the wonderful summary.
>
> Reading it, I think that I now see two issues with the alternative
> approaches that use a weaker cipher (i..e. alternative PN encryption,
> 64bit encrypted PN).
>
> > We can argue that the algorithm does not have to be as robust as
> AES.. The main requirement is to prevent real time analysis of
> sequence numbers by middle-boxes. This is achieved as long as the
> encryption key cannot be retrieved in a short time by the
> middle-boxes. If they could do that, we would be once again on the
> path to ossification. XOR and simple obfuscation probably don't meet
> that goal, but IPCrypt probably does, and a more robust algorithm
> certainly would.
>
> As you state, it is true that preventing real time analysis is
> important. But are we sure that we do not need to consider offline
> attacks? I would be interested in arguing about the other requirement
> than ossification: privacy.
>
> A pervasive monitor might collect CIDs and encrypted PNs that were
> being used, and then use the encrypted PNs as a source to correlate
> CIDs to reconstruct a QUIC connection. Are we sure that a weak cipher
> does not leak such trace?

Yes, you are right. The argument about tolerating weak algorithms only
applies if we have another solution to prevent linkability, such as
different sequence numbers and encryption keys for each Connection ID.
So it comes with a high cost in term of software complexity.


>
> Considering that, I think that the alternative approaches should have
> per-CID PN encryption keys, even though I am not sure if there are no
> other privacy-related issues.
Yes.
>
> The other issue is about crypto agility. #1179 has agility in sense
> that the corresponding CTR mode is used for encrypting the PN. OTOH,
> the two alternatives using a simple cipher are not agile. So we might
> need to define two types of simpler ciphers for PN encryption, if
> consider that privacy issues (like the one above) might arise in the
> future.
Yes.  I updated the Wiki page to reflect your comments.

-- Christian Huitema


From nobody Tue Apr 17 12:09:49 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0E412D878 for ; Tue, 17 Apr 2018 12:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 sw84XgUEd4km for ; Tue, 17 Apr 2018 12:09:45 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0133.outbound.protection.outlook.com [104.47.42.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCE3E127909 for ; Tue, 17 Apr 2018 12:09:44 -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=ILCrN11XgOkGSAVvI8mNgNSggG20NJd67n6x3aCf5KI=; b=mf+gPi5ozHo6W6OM7vNCZf1DSY85I8dYIzYPZeqoPXLgBXV76ot5Oxlicqsv4MncPeqoG3+8gZNfA34QkEYiXTNlEekUi/uSjdS/T8wKON4LxuxetHisd6S0p6T6SbQYXJmkmiHHKknljZE8USrZhi96UH+OgFr+hr0nCUAKyaY=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0741.namprd21.prod.outlook.com (10.173.189.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.715.7; Tue, 17 Apr 2018 19:09:43 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0715.004; Tue, 17 Apr 2018 19:09:43 +0000
From: Praveen Balasubramanian 
To: Praveen Balasubramanian , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Martin Thomson 
CC: Ryan Hamilton , "Fossati, Thomas (Nokia - GB/Cambridge)" , "Brian Trammell (IETF)" , Victor Vasiliev , IETF QUIC WG , Kazuho Oku 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAuyyQAACzPhAAAC9p6AAAKcBQAAIR0fgAABLEIAAAn14wAABEW/AAADvM2AAAsF2kAA+pZfUA==
Date: Tue, 17 Apr 2018 19:09:42 +0000
Message-ID: 
References:         <60955AE8-7637-4CC4-9FD8-56201685EE03@nokia.com>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:a::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0741; 7:sPei9kV+SxTxv13LA/7jwxBrEzY80aOt1EOqhmQUVlFYbmGndN5HjNeB5arijxEQMG9dYSYOn8IFYjWp8UFRmxWgv4mvRfOk6ggU1AveaR5QyG7RTjp4USD9S3lAYvfe7uUlLvPQRtmVaHvM7P5PuIE7hQD4x/M40WTda2ncnRwpkvd5/V4RCpCnYBgJusKMLMvA27WOq9NlAjtltd0iubEY18pf1gaN7kPPlrP5yCbxGoIohBBZKltoKrDLO0Ae; 20:1iBjALFpzosjFzdpuJ9uAmpeH2ZqPLDw45KhWKhRU39vR4LyoNhAlpgXNw21Sz0IB2AZBNUnZubUlw3QNA0Yk3A9cR8HE1EiJmIRAjOdJoRw3A1u/3TfFgkvs6uktpTQRmcMUdXRT7agECgUxUEKiYhHJUWqgvPLflXbJXNKUc0=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7193020); SRVR:CY4PR21MB0741; 
x-ms-traffictypediagnostic: CY4PR21MB0741:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(166708455590820)(189930954265078)(82608151540597)(85827821059158)(211936372134217)(153496737603132)(219752817060721);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231232)(944501361)(52105095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0741; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0741; 
x-forefront-prvs: 0645BEB7AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(346002)(39860400002)(366004)(376002)(396003)(199004)(189003)(446003)(97736004)(53546011)(10290500003)(6506007)(99286004)(478600001)(19609705001)(7736002)(6116002)(486006)(3660700001)(106356001)(790700001)(33656002)(8656006)(86612001)(7696005)(76176011)(229853002)(316002)(11346002)(22452003)(5660300001)(4326008)(3280700002)(25786009)(68736007)(476003)(606006)(5250100002)(966005)(10090500001)(93886005)(236005)(9686003)(54896002)(6306002)(8676002)(81156014)(81166006)(53936002)(46003)(39060400002)(14454004)(6246003)(53376002)(6436002)(54906003)(110136005)(86362001)(105586002)(2900100001)(74316002)(186003)(102836004)(8990500004)(8936002)(2906002)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0741; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: MnvEtCGzFZsnwJYIne/CC5XtQMXyd2HrF69V9zghNl5aWIux7TADXQMRj3P6J557PfbGRghcvJUMwHEP92cdXQ5dlRvWyWtinIjyquzkOiZ3pw4e+TNl3xhB3YzMSeaOPOQkE+lBAg5NOzzLGZNChKTCa7LG7HBD3uFdTybHap4OCo8yuQkUDzstpc32i68/
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630B7EE570FA57347E66D8EB6B70CY4PR21MB0630namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: a6678b53-2c71-432b-4f0b-08d5a496c6ef
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a6678b53-2c71-432b-4f0b-08d5a496c6ef
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2018 19:09:43.0323 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0741
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Apr 2018 19:09:49 -0000

--_000_CY4PR21MB0630B7EE570FA57347E66D8EB6B70CY4PR21MB0630namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBvcGVuZWQgaXNzdWUgIzEyOTY8aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0
cy9pc3N1ZXMvMTI5Nj4gZm9yIHRyYWNraW5nIFBOIHRyYW5zZm9ybSBuZWdvdGlhdGlvbi4NCg0K
RnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBy
YXZlZW4gQmFsYXN1YnJhbWFuaWFuDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTIsIDIwMTggOToy
OSBBTQ0KVG86IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT47
IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpDYzogUnlhbiBIYW1p
bHRvbiA8cmNoQGdvb2dsZS5jb20+OyBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJp
ZGdlKSA8dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tPjsgQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxp
ZXRmQHRyYW1tZWxsLmNoPjsgVmljdG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBJ
RVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwu
Y29tPg0KU3ViamVjdDogUkU6IFNpbXBsZSB0cmFuc2Zvcm0gZm9yIGltcHJvdmluZyBQTiBvc3Np
ZmljYXRpb24gcHJldmVudGlvbg0KDQoNClJlLiAjMTA3OSwgZm9sbG93aW5nIHNlZW1zIGxpa2Ug
YSB3YXkgZm9yd2FyZCBzbyB3ZSBnZXQgdG8gZG8gc29tZSBpbXBsZW1lbnRhdGlvbnMgYW5kIGdl
dCBkYXRhOg0KDQogIDEuICBQTiB0cmFuc2Zvcm0gaXMgbmVnb3RpYXRlZCB1c2luZyB0cmFuc3Bv
cnQgcGFyYW1zLg0KICAyLiAgRm9sbG93aW5nIFBOIHRyYW5zZm9ybXMgYXJlIHN1cHBvcnRlZDoN
CiAgICAgKiAgIFBORQ0KDQpDb25uZWN0aW9ucyBleHBlY3RpbmcgdG8gdXNlIG11bHRpcGxlIHBh
dGhzIGR1ZSB0byBncmF0dWl0b3VzL3ZvbHVudGFyeSBtaWdyYXRpb24gTVVTVCBuZWdvdGlhdGUg
YW5kIHVzZSBQTkUgdHJhbnNmb3JtLiBTZWUgaXNzdWUgMTI3MSB3aGVyZSBvcHRpb25zIGFyZSBi
ZWluZyBkaXNjdXNzZWQgb24gaG93IG1pZ3JhdGlvbiBjb3VsZCBiZSBuZWdvdGlhdGVkLg0KDQpS
ZXZpc2l0IHRoaXMgc29sdXRpb24gZm9yIHByb3BlciBtdWx0aS1wYXRoIGFmdGVyIGRlc2lnbmlu
ZyBtdWx0aXBsZSBQTiBzcGFjZXMuIEkgYW0gZmluZSBpZiB0aGlzIGlzIGRvbmUgZm9yIFYyLg0K
DQogICAgICogICBMb3cgY29zdCBvc3NpZmljYXRpb24gcHJldmVudGlvbiB0cmFuc2Zvcm0gKGxp
a2Ugc2h1ZmZsZSkuDQoNCkZvciBjb25uZWN0aW9ucyBvbiB0aGUgSW50ZXJuZXQgb24gc2luZ2xl
IHBhdGggcmVxdWlyZSB0aGVtIHRvIG5lZ290aWF0ZSB0aGlzIHRyYW5zZm9ybS4gRXZlbiBiZXR0
ZXIgaWYgd2UgZmluZCBhbm90aGVyIGxvdyBjb3N0IHNjaGVtZSB3aXRoIGJldHRlciBwcm9wZXJ0
aWVzIGJlZm9yZSB3ZSBzaGlwIFYxLg0KDQogICAgICogICBOby1vcCAoY3VycmVudCBkcmFmdCkN
Cg0KRm9yIGludHJhLWRhdGFjZW50ZXIgb3Igc2luZ2xlIGRvbWFpbiBwcml2YXRlIG5ldHdvcmsg
c2NlbmFyaW9zIGFsbG93IHVzYWdlIG9mIHRoZSBuby1vcCB0cmFuc2Zvcm0uDQoNCklmIHNlcnZl
ciBmYWlscyB0byBuZWdvdGlhdGUgUE5FIGFuZCBzdXBwbGllcyBtdWx0aXBsZSBjb25uZWN0aW9u
IElEcyBmb3IgbWlncmF0aW9uLCBjbGllbnQgZmFpbCB0aGUgY29ubmVjdGlvbi4NCklmIHRoZSBz
ZXJ2ZXIgZmFpbHMgdG8gbmVnb3RpYXRlIGEgbG93IGNvc3QgdHJhbnNmb3JtIG9uIHRoZSBJbnRl
cm5ldCwgY2xpZW50IGZhaWxzIHRoZSBjb25uZWN0aW9uLg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHNl
cnZlcnMgYXJlIGZyZWUgdG8gcGljayBQTkUgYWxsIHRoZSB0aW1lLiBUaGlzIGFsbG93cyBzZXJ2
ZXIgZGVwbG95bWVudHMgd2hpY2ggaGF2ZSBubyBwZXJmb3JtYW5jZSBjb25jZXJuIHRvIGFsd2F5
cyB1c2UgUE5FLiBJIGRvIGhhdmUgc29tZSBiYXR0ZXJ5IGxpZmUgY29uY2VybnMgb24gY2xpZW50
IHNpZGUsIGJ1dCBJIGRvIHRoaW5rIHRoZSBtYWpvciBwZXJmIGNvbmNlcm4gaXMgb24gc2VydmVy
IHNpZGUuDQoNCklmIHRoZSBkZXBsb3ltZW50cyB1c2luZyBsb3cgY29zdCB0cmFuc2Zvcm0gaGl0
IG1pZGRsZWJveCBpc3N1ZXMgdGhleSB3aWxsIHN1ZmZlciBhbmQgcGF5IHRoZSBjb3N0IHRvIGRv
IFBORS4NCg0KRnJvbTogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZq
QGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxMiwgMjAxOCAzOjUyIEFNDQpUbzog
TWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRo
b21zb25AZ21haWwuY29tPj4NCkNjOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRv
OnF1aWNAaWV0Zi5vcmc+PjsgQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxpZXRmQHRyYW1tZWxsLmNo
PG1haWx0bzppZXRmQHRyYW1tZWxsLmNoPj47IFJ5YW4gSGFtaWx0b24gPHJjaEBnb29nbGUuY29t
PG1haWx0bzpyY2hAZ29vZ2xlLmNvbT4+OyBWaWN0b3IgVmFzaWxpZXYgPHZhc2lsdnZAZ29vZ2xl
LmNvbTxtYWlsdG86dmFzaWx2dkBnb29nbGUuY29tPj47IEZvc3NhdGksIFRob21hcyAoTm9raWEg
LSBHQi9DYW1icmlkZ2UpIDx0aG9tYXMuZm9zc2F0aUBub2tpYS5jb208bWFpbHRvOnRob21hcy5m
b3NzYXRpQG5va2lhLmNvbT4+OyBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPG1haWx0
bzprYXp1aG9va3VAZ21haWwuY29tPj47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBt
aWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tPj4NClN1YmplY3Q6IFJlOiBT
aW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24N
Cg0KDQoNCk9uIDEyIEFwcmlsIDIwMTggYXQgMTEuMDUuMTcsIE1hcnRpbiBUaG9tc29uIChtYXJ0
aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4pIHdy
b3RlOg0KVGhlIGNsZWFuIHBlci1wYXRoIHBhY2tldCBudW1iZXIgZG9lc24ndCBkZWZlbmQgYWdh
aW5zdCAiaGVscGZ1bG5lc3MiDQpvZiB0aGUgbmF0dXJlIEkgZGVzY3JpYmVkLiBUaG9zZSBwcm9i
bGVtcyBleGlzdCBpZiB0aGUgc2lnbmFsIGV4aXN0cw0KYXQgYWxsLg0KDQoNCg0KVHJ1ZS4gQnV0
IHRoZXNlIGFyZSBzdGlsbCB0aGUgb3B0aW9ucyBhcyBJIHNlZSBpdC4gSGFsZi1iYWtlZCBvYmZ1
c2NhdGlvbiB3aWxsIG9ubHkgbWFrZSBpdCB3b3JzZS4NCg0KVGhlcmUgaXMgdGhlIGhvbHkgZ3Jh
aWwgb2YgZmFzdCAzMi1iaXQgcGVybXV0YXRpb25zIHRoYXQgY2FuIGJlIHVzZWQgZGlyZWN0bHkg
YXMgSVYsIHdoaWNoIGFyZSBzdWZmaWNpZW50bHkgc2FmZSB3cnQuIHByaXZhY3ksIGFuZCB3aGVy
ZSB0aGUgcGVybXV0YXRpb24gZG9lcyBub3QgZGVwZW5kIG9uIHRoZSBwYWNrZXQgY29udGVudC4N
Cg0KVGhlIGZvbGxvd2luZyBmdW5jdGlvbiBpcyB1c2VmdWwgdG8gZGlzcGVyc2UgYSBsb3ctcXVh
bGl0eSBoYXNoIC0gaXQgaXMgYSBwZXJmZWN0IHBlcm11dGF0aW9uLiBVbmZvcnR1bmF0ZWx5LCBv
ciBmb3J0dW5hdGVseSwgaXQgY2FuIGJlIHRyaXZpYWxseSByZXZlcnNlZCAtIHNlZSBzdGFjayBv
dmVyZmxvdyBhcnRpY2xlLiBUaGVyZSBhcmUgYWxzbyA2NC1iaXQgdmFyaWFudHMsIGFuZCBpdCBj
b3VsZCBhbHNvIGJlIGp1c3QgYSBzaW5nbGUgbXVsdGlwbGljYXRpb24uIE1hcnRpbiBULiBhbHJl
YWR5IGhpbnRlZCBhdCBzb21ldGhpbmcgc2ltaWxhciBpbiBhbiBlYXJsaWVyIG1haWwuDQoNClRo
ZSBiZW5lZml0IG9mIHRoaXMgb3ZlciBsb3dlciBvY3RldCBwZXJtdXRhdGlvbiBpcyB0aGF0IHN0
dXBpZCBtaWRkbGUtYm94ZXMgZG9u4oCZdCBoYXZlIGEgY2hhbmNlLCB3aGlsZSBzbGlnaHRseSBp
bnRlbGxpZ2VudCBtaWRkbGUtYm94ZXMgY2FuIHVzZSBpdCBpcyBsb3NzIC8gcmVvcmRlcmluZyBz
aWduYWwsIGFuZCBRVUlDIGhhcmR3YXJlIG9mZmxvYWQgZGVjcnlwdG9ycyBjYW4gdXNlIHRoZSB2
YWx1ZSB1bm1vZGlmaWVkIGFzIElWIHJhdGhlciB0aGFuIGNvbXB1dGluZyB0aGUgaW52ZXJzZSBm
aXJzdC4gRnJvbSBhIHByaXZhY3kgcGVyc3BlY3RpdmUgdGhpcyBpcyBubyBiZXR0ZXIgdGhhbiBw
bGFpbiBzZXF1ZW50aWFsIG51bWJlcnMuDQoNCkJ1dCBpdCBzdGlsbCBzZXJ2ZXMgYXMgZmluZ2Vy
cHJpbnRpbmcgYSBnaXZlbiBRVUlDIHZlcnNpb24uIEnigJlkIHNheSBmdWxsIGVuY3J5cHRpb24g
b3IgY2xlYXIgdGV4dCBzZXF1ZW50aWFsIGFyZSB0aGUgb25seSB2aWFibGUgY2hvaWNlcy4NCg0K
DQoNCg0KDQogICAgLyogaHR0cDovL3N0YWNrb3ZlcmZsb3cuY29tL2EvMTI5OTYwMjg8aHR0cHM6
Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUy
RnN0YWNrb3ZlcmZsb3cuY29tJTJGYSUyRjEyOTk2MDI4JmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQw
bWljcm9zb2Z0LmNvbSU3Q2EyYzg4ZGNiYjE1MTQ2NDY0ODllMDhkNWEwNjM3NjIzJTdDNzJmOTg4
YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjU5MTI3MTQwNDUzODEyMSZz
ZGF0YT1WQThEcFZjeWhWS3lXT01LU2NuaG9tVVF5U0diOXEzeDFyZFlLc2N0d2YwJTNEJnJlc2Vy
dmVkPTA+ICovDQoNCiAgICB1aW50MzJfdCB4ID0gdHlwZV9oYXNoOw0KDQoNCg0KICAgIHggPSAo
KHggPj4gMTYpIF4geCkgKiAweDQ1ZDlmM2JVTDsNCg0KICAgIHggPSAoKHggPj4gMTYpIF4geCkg
KiAweDQ1ZDlmM2JVTDsNCg0KICAgIHggPSAoKHggPj4gMTYpIF4geCk7DQoNCiAgICByZXR1cm4g
eDsNCg0KDQo=

--_000_CY4PR21MB0630B7EE570FA57347E66D8EB6B70CY4PR21MB0630namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSW5jb25zb2xh
dGEgZm9yIFBvd2VybGluZSI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBT
dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v
cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh
bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ
dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r
Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQs
IGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t
c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu
LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow
aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
Zjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hh
ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0
IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmFpcm1haWxvbiwgbGku
YWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1lOmFpcm1haWxfb247DQoJ
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRl
ZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUy
Mw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp
biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp
c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4MTk0MTk0OTsNCglt
c28tbGlzdC10ZW1wbGF0ZS1pZHM6MTcxMDIyODM3Njt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv
LWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps
ZXZlbDINCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNv
LWxpc3QtaWQ6MTgzNzkzMzgzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQyNDMxNDc1NDt9
DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7DQoJ
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w
OjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MzgyMTAxNTU4Ow0KCW1zby1saXN0LXR5
cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzM4NjY2NjIwIDgxNDM4MjQ3OCA2
NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5
ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v
bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp
bjt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93
ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7
fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6
bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl
bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyOmxl
dmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
O30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl
cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDox
NjA3MjI2MDMzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo2MTc3OTU2NzI7fQ0KQGxpc3QgbDM6
bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl
bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdp
bi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k
aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp
dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48
L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl
IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5JIG9wZW5lZCBpc3N1ZSA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVp
Y3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8xMjk2Ij4NCiMxMjk2PC9hPiBmb3IgdHJhY2tpbmcgUE4g
dHJhbnNmb3JtIG5lZ290aWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJv
dW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPlByYXZlZW4gQmFsYXN1YnJhbWFu
aWFuPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAxMiwgMjAxOCA5OjI5IEFNPGJy
Pg0KPGI+VG86PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFp
bC5jb20mZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0
Ozxicj4NCjxiPkNjOjwvYj4gUnlhbiBIYW1pbHRvbiAmbHQ7cmNoQGdvb2dsZS5jb20mZ3Q7OyBG
b3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlKSAmbHQ7dGhvbWFzLmZvc3NhdGlA
bm9raWEuY29tJmd0OzsgQnJpYW4gVHJhbW1lbGwgKElFVEYpICZsdDtpZXRmQHRyYW1tZWxsLmNo
Jmd0OzsgVmljdG9yIFZhc2lsaWV2ICZsdDt2YXNpbHZ2QGdvb2dsZS5jb20mZ3Q7OyBJRVRGIFFV
SUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBLYXp1aG8gT2t1ICZsdDtrYXp1aG9va3VAZ21h
aWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogU2ltcGxlIHRyYW5zZm9ybSBmb3Ig
aW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZS4gIzEwNzksIGZvbGxvd2luZyBzZWVtcyBsaWtlIGEg
d2F5IGZvcndhcmQgc28gd2UgZ2V0IHRvIGRvIHNvbWUgaW1wbGVtZW50YXRpb25zIGFuZCBnZXQg
ZGF0YTo8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIx
IiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2
ZWwxIGxmbzMiPlBOIHRyYW5zZm9ybSBpcyBuZWdvdGlhdGVkIHVzaW5nIHRyYW5zcG9ydCBwYXJh
bXMuDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlz
dDpsMiBsZXZlbDEgbGZvMyI+Rm9sbG93aW5nIFBOIHRyYW5zZm9ybXMgYXJlIHN1cHBvcnRlZDoN
CjxvOnA+PC9vOnA+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0i
YSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVsMiBsZm8z
Ij5QTkUgPG86cD48L286cD48L2xpPjwvb2w+DQo8L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkNvbm5lY3Rpb25zIGV4cGVjdGluZyB0
byB1c2UgbXVsdGlwbGUgcGF0aHMgZHVlIHRvIGdyYXR1aXRvdXMvdm9sdW50YXJ5IG1pZ3JhdGlv
biBNVVNUIG5lZ290aWF0ZSBhbmQgdXNlIFBORSB0cmFuc2Zvcm0uIFNlZSBpc3N1ZSAxMjcxIHdo
ZXJlIG9wdGlvbnMgYXJlIGJlaW5nIGRpc2N1c3NlZCBvbiBob3cgbWlncmF0aW9uIGNvdWxkIGJl
IG5lZ290aWF0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls
ZT0ibWFyZ2luLWxlZnQ6MS4waW4iPlJldmlzaXQgdGhpcyBzb2x1dGlvbiBmb3IgcHJvcGVyIG11
bHRpLXBhdGggYWZ0ZXIgZGVzaWduaW5nIG11bHRpcGxlIFBOIHNwYWNlcy4gSSBhbSBmaW5lIGlm
IHRoaXMgaXMgZG9uZSBmb3IgVjIuPG86cD48L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10
b3A6MGluIiBzdGFydD0iMiIgdHlwZT0iMSI+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBz
dGFydD0iMiIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0
OmwyIGxldmVsMiBsZm8zIj5Mb3cgY29zdCBvc3NpZmljYXRpb24gcHJldmVudGlvbiB0cmFuc2Zv
cm0gKGxpa2Ugc2h1ZmZsZSkuDQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvb2w+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkZvciBjb25uZWN0aW9u
cyBvbiB0aGUgSW50ZXJuZXQgb24gc2luZ2xlIHBhdGggcmVxdWlyZSB0aGVtIHRvIG5lZ290aWF0
ZSB0aGlzIHRyYW5zZm9ybS4gRXZlbiBiZXR0ZXIgaWYgd2UgZmluZCBhbm90aGVyIGxvdyBjb3N0
IHNjaGVtZSB3aXRoIGJldHRlciBwcm9wZXJ0aWVzIGJlZm9yZSB3ZSBzaGlwIFYxLjxvOnA+PC9v
OnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIiIHR5cGU9IjEiPg0K
PG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjMiIHR5cGU9ImEiPg0KPGxpIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMiBsZXZlbDIgbGZvMyI+Tm8tb3AgKGN1cnJl
bnQgZHJhZnQpIDxvOnA+DQo8L286cD48L2xpPjwvb2w+DQo8L29sPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5Gb3IgaW50cmEtZGF0YWNlbnRlciBv
ciBzaW5nbGUgZG9tYWluIHByaXZhdGUgbmV0d29yayBzY2VuYXJpb3MgYWxsb3cgdXNhZ2Ugb2Yg
dGhlIG5vLW9wIHRyYW5zZm9ybS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgc2VydmVyIGZh
aWxzIHRvIG5lZ290aWF0ZSBQTkUgYW5kIHN1cHBsaWVzIG11bHRpcGxlIGNvbm5lY3Rpb24gSURz
IGZvciBtaWdyYXRpb24sIGNsaWVudCBmYWlsIHRoZSBjb25uZWN0aW9uLjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIHNlcnZlciBmYWlscyB0byBuZWdvdGlhdGUg
YSBsb3cgY29zdCB0cmFuc2Zvcm0gb24gdGhlIEludGVybmV0LCBjbGllbnQgZmFpbHMgdGhlIGNv
bm5lY3Rpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIG5vdGUgdGhhdCBzZXJ2
ZXJzIGFyZSBmcmVlIHRvIHBpY2sgUE5FIGFsbCB0aGUgdGltZS4gVGhpcyBhbGxvd3Mgc2VydmVy
IGRlcGxveW1lbnRzIHdoaWNoIGhhdmUgbm8gcGVyZm9ybWFuY2UgY29uY2VybiB0byBhbHdheXMg
dXNlIFBORS4gSSBkbyBoYXZlIHNvbWUgYmF0dGVyeSBsaWZlIGNvbmNlcm5zIG9uIGNsaWVudCBz
aWRlLCBidXQgSSBkbyB0aGluayB0aGUgbWFqb3IgcGVyZiBjb25jZXJuIGlzDQogb24gc2VydmVy
IHNpZGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBkZXBsb3ltZW50cyB1c2luZyBs
b3cgY29zdCB0cmFuc2Zvcm0gaGl0IG1pZGRsZWJveCBpc3N1ZXMgdGhleSB3aWxsIHN1ZmZlciBh
bmQgcGF5IHRoZSBjb3N0IHRvIGRvIFBORS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNaWtrZWwgRmFobsO4ZSBK
w7hyZ2Vuc2VuIFs8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIj5tYWlsdG86bWlr
a2VsZmpAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwg
MTIsIDIwMTggMzo1MiBBTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIFRob21zb24gJmx0OzxhIGhy
ZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iPm1hcnRpbi50aG9tc29uQGdtYWls
LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1h
aWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZndDs7IEJyaWFuIFRyYW1tZWxs
IChJRVRGKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAdHJhbW1lbGwuY2giPmlldGZAdHJhbW1l
bGwuY2g8L2E+Jmd0OzsgUnlhbiBIYW1pbHRvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJjaEBnb29n
bGUuY29tIj5yY2hAZ29vZ2xlLmNvbTwvYT4mZ3Q7OyBWaWN0b3IgVmFzaWxpZXYgJmx0OzxhIGhy
ZWY9Im1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20iPnZhc2lsdnZAZ29vZ2xlLmNvbTwvYT4mZ3Q7
Ow0KIEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UpICZsdDs8YSBocmVmPSJt
YWlsdG86dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tIj50aG9tYXMuZm9zc2F0aUBub2tpYS5jb208
L2E+Jmd0OzsgS2F6dWhvIE9rdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5j
b20iPmthenVob29rdUBnbWFpbC5jb208L2E+Jmd0OzsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4g
Jmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIj5wcmF2YkBtaWNyb3NvZnQu
Y29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFNpbXBsZSB0cmFuc2Zvcm0gZm9y
IGltcHJvdmluZyBQTiBvc3NpZmljYXRpb24gcHJldmVudGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz
cz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMTIgQXByaWwgMjAxOCBhdCAxMS4w
NS4xNywgTWFydGluIFRob21zb24gKDwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWFydGluLnRob21z
b25AZ21haWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWFydGluLnRob21zb25AZ21haWwuY29t
PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+KQ0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv
cmQtc3BhY2luZzowcHgiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPlRoZSBjbGVhbiBwZXItcGF0aCBw
YWNrZXQgbnVtYmVyIGRvZXNuJ3QgZGVmZW5kIGFnYWluc3QgJnF1b3Q7aGVscGZ1bG5lc3MmcXVv
dDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+b2YgdGhlIG5hdHVyZSBJIGRlc2NyaWJlZC4gVGhvc2UgcHJvYmxlbXMgZXhp
c3QgaWYgdGhlIHNpZ25hbCBleGlzdHM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij5hdCBhbGwuPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
VHJ1ZS4gQnV0IHRoZXNlIGFyZSBzdGlsbCB0aGUgb3B0aW9ucyBhcyBJIHNlZSBpdC4gSGFsZi1i
YWtlZCBvYmZ1c2NhdGlvbiB3aWxsIG9ubHkgbWFrZSBpdCB3b3JzZS48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmUgaXMgdGhlIGhvbHkgZ3JhaWwgb2Yg
ZmFzdCAzMi1iaXQgcGVybXV0YXRpb25zIHRoYXQgY2FuIGJlIHVzZWQgZGlyZWN0bHkgYXMgSVYs
IHdoaWNoIGFyZSBzdWZmaWNpZW50bHkgc2FmZSB3cnQuIHByaXZhY3ksIGFuZCB3aGVyZSB0aGUg
cGVybXV0YXRpb24gZG9lcyBub3QgZGVwZW5kIG9uIHRoZSBwYWNrZXQgY29udGVudC48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGZvbGxvd2luZyBmdW5j
dGlvbiBpcyB1c2VmdWwgdG8gZGlzcGVyc2UgYSBsb3ctcXVhbGl0eSBoYXNoIC0gaXQgaXMgYSBw
ZXJmZWN0IHBlcm11dGF0aW9uLiBVbmZvcnR1bmF0ZWx5LCBvciBmb3J0dW5hdGVseSwgaXQgY2Fu
IGJlIHRyaXZpYWxseSByZXZlcnNlZCAtIHNlZSBzdGFjayBvdmVyZmxvdyBhcnRpY2xlLiBUaGVy
ZQ0KIGFyZSBhbHNvIDY0LWJpdCB2YXJpYW50cywgYW5kIGl0IGNvdWxkIGFsc28gYmUganVzdCBh
IHNpbmdsZSBtdWx0aXBsaWNhdGlvbi4gTWFydGluIFQuIGFscmVhZHkgaGludGVkIGF0IHNvbWV0
aGluZyBzaW1pbGFyIGluIGFuIGVhcmxpZXIgbWFpbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGJlbmVmaXQgb2YgdGhpcyBvdmVyIGxvd2VyIG9jdGV0
IHBlcm11dGF0aW9uIGlzIHRoYXQgc3R1cGlkIG1pZGRsZS1ib3hlcyBkb27igJl0IGhhdmUgYSBj
aGFuY2UsIHdoaWxlIHNsaWdodGx5IGludGVsbGlnZW50IG1pZGRsZS1ib3hlcyBjYW4gdXNlIGl0
IGlzIGxvc3MgLyByZW9yZGVyaW5nIHNpZ25hbCwgYW5kIFFVSUMgaGFyZHdhcmUNCiBvZmZsb2Fk
IGRlY3J5cHRvcnMgY2FuIHVzZSB0aGUgdmFsdWUgdW5tb2RpZmllZCBhcyBJViByYXRoZXIgdGhh
biBjb21wdXRpbmcgdGhlIGludmVyc2UgZmlyc3QuIEZyb20gYSBwcml2YWN5IHBlcnNwZWN0aXZl
IHRoaXMgaXMgbm8gYmV0dGVyIHRoYW4gcGxhaW4gc2VxdWVudGlhbCBudW1iZXJzLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5CdXQgaXQgc3RpbGwgc2VydmVz
IGFzIGZpbmdlcnByaW50aW5nIGEgZ2l2ZW4gUVVJQyB2ZXJzaW9uLiBJ4oCZZCBzYXkgZnVsbCBl
bmNyeXB0aW9uIG9yIGNsZWFyIHRleHQgc2VxdWVudGlhbCBhcmUgdGhlIG9ubHkgdmlhYmxlIGNo
b2ljZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtJbmNvbnNvbGF0YSBmb3IgUG93ZXJsaW5lJnF1b3Q7LHNlcmlmIj4mbmJz
cDsgJm5ic3A7IC8qDQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90
ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnN0YWNrb3ZlcmZsb3cuY29tJTJG
YSUyRjEyOTk2MDI4JmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0Nh
MmM4OGRjYmIxNTE0NjQ2NDg5ZTA4ZDVhMDYzNzYyMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3
Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY1OTEyNzE0MDQ1MzgxMjEmYW1wO3NkYXRhPVZBOERwVmN5
aFZLeVdPTUtTY25ob21VUXlTR2I5cTN4MXJkWUtzY3R3ZjAlM0QmYW1wO3Jlc2VydmVkPTAiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0luY29uc29sYXRh
IGZvciBQb3dlcmxpbmUmcXVvdDssc2VyaWYiPmh0dHA6Ly9zdGFja292ZXJmbG93LmNvbS9hLzEy
OTk2MDI4PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtJbmNvbnNvbGF0YSBmb3IgUG93ZXJsaW5lJnF1b3Q7LHNlcmlmIj4NCiAqLzwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SW5jb25zb2xhdGEgZm9yIFBv
d2VybGluZSZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyB1aW50MzJfdCB4ID0gdHlwZV9oYXNo
Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0luY29uc29sYXRhIGZvciBQ
b3dlcmxpbmUmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgeCA9ICgoeCAmZ3Q7Jmd0OyAxNikg
XiB4KSAqIDB4NDVkOWYzYlVMOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SW5jb25zb2xhdGEgZm9yIFBvd2VybGluZSZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNw
OyB4ID0gKCh4ICZndDsmZ3Q7IDE2KSBeIHgpICogMHg0NWQ5ZjNiVUw7PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtJbmNvbnNvbGF0YSBmb3IgUG93ZXJsaW5lJnF1
b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7IHggPSAoKHggJmd0OyZndDsgMTYpIF4geCk7PC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtJbmNvbnNvbGF0YSBmb3IgUG93
ZXJsaW5lJnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7IHJldHVybiB4Ozwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt
YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxl
PSJib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7Ym94LXNpemluZzpib3JkZXItYm94O2JvcmRlci1z
cGFjaW5nOjBweCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1
cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_CY4PR21MB0630B7EE570FA57347E66D8EB6B70CY4PR21MB0630namp_--


From nobody Tue Apr 17 12:09:57 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D115012D96B for ; Tue, 17 Apr 2018 12:09:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523992189; bh=ILCrN11XgOkGSAVvI8mNgNSggG20NJd67n6x3aCf5KI=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To; b=GCgzeJ48ZQe4mzz21bB6zhASDUdvF0xSkDhsr5oSg+3+xic8aN+DggIAteYDjqs+8 tzxjPzt8L50Z0vqabuM0aF6SbmLNuFLC/Ceq4gstUgIHOlt/5H+sO1nJ6m0mXaEWIj 1AC7GctzNPYfGV22fZD0p2bCZuXJht3FNsxYj5Es=
X-Mailbox-Line: From pravb@microsoft.com  Tue Apr 17 12:09:49 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C7F12420B; Tue, 17 Apr 2018 12:09:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523992189; bh=ILCrN11XgOkGSAVvI8mNgNSggG20NJd67n6x3aCf5KI=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To; b=GCgzeJ48ZQe4mzz21bB6zhASDUdvF0xSkDhsr5oSg+3+xic8aN+DggIAteYDjqs+8 tzxjPzt8L50Z0vqabuM0aF6SbmLNuFLC/Ceq4gstUgIHOlt/5H+sO1nJ6m0mXaEWIj 1AC7GctzNPYfGV22fZD0p2bCZuXJht3FNsxYj5Es=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AC1127909 for ; Tue, 17 Apr 2018 12:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Lcc6M-tF8fIC for ; Tue, 17 Apr 2018 12:09:45 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on070b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4a::70b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2861B12D965 for ; Tue, 17 Apr 2018 12:09: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=ILCrN11XgOkGSAVvI8mNgNSggG20NJd67n6x3aCf5KI=; b=mf+gPi5ozHo6W6OM7vNCZf1DSY85I8dYIzYPZeqoPXLgBXV76ot5Oxlicqsv4MncPeqoG3+8gZNfA34QkEYiXTNlEekUi/uSjdS/T8wKON4LxuxetHisd6S0p6T6SbQYXJmkmiHHKknljZE8USrZhi96UH+OgFr+hr0nCUAKyaY=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0741.namprd21.prod.outlook.com (10.173.189.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.715.7; Tue, 17 Apr 2018 19:09:43 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::fc65:cb01:17a1:639d%3]) with mapi id 15.20.0715.004; Tue, 17 Apr 2018 19:09:43 +0000
From: Praveen Balasubramanian 
CC: Ryan Hamilton , "Fossati, Thomas (Nokia - GB/Cambridge)" , "Brian Trammell (IETF)" , Victor Vasiliev , IETF QUIC WG , Kazuho Oku 
Subject: RE: Simple transform for improving PN ossification prevention
Thread-Topic: Simple transform for improving PN ossification prevention
Thread-Index: AdPQQ8p5pfJiY2+yR8ud9raMWX53bwAXp/KAABHOGxAAB+ZAgAAACqGQAAuyyQAACzPhAAAC9p6AAAKcBQAAIR0fgAABLEIAAAn14wAABEW/AAADvM2AAAsF2kAA+pZfUA==
Date: Tue, 17 Apr 2018 19:09:42 +0000
Message-ID: 
References:         <60955AE8-7637-4CC4-9FD8-56201685EE03@nokia.com>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:a::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0741; 7:sPei9kV+SxTxv13LA/7jwxBrEzY80aOt1EOqhmQUVlFYbmGndN5HjNeB5arijxEQMG9dYSYOn8IFYjWp8UFRmxWgv4mvRfOk6ggU1AveaR5QyG7RTjp4USD9S3lAYvfe7uUlLvPQRtmVaHvM7P5PuIE7hQD4x/M40WTda2ncnRwpkvd5/V4RCpCnYBgJusKMLMvA27WOq9NlAjtltd0iubEY18pf1gaN7kPPlrP5yCbxGoIohBBZKltoKrDLO0Ae; 20:1iBjALFpzosjFzdpuJ9uAmpeH2ZqPLDw45KhWKhRU39vR4LyoNhAlpgXNw21Sz0IB2AZBNUnZubUlw3QNA0Yk3A9cR8HE1EiJmIRAjOdJoRw3A1u/3TfFgkvs6uktpTQRmcMUdXRT7agECgUxUEKiYhHJUWqgvPLflXbJXNKUc0=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7193020); SRVR:CY4PR21MB0741; 
x-ms-traffictypediagnostic: CY4PR21MB0741:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(166708455590820)(189930954265078)(82608151540597)(85827821059158)(211936372134217)(153496737603132)(219752817060721);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231232)(944501361)(52105095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0741; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0741; 
x-forefront-prvs: 0645BEB7AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(346002)(39860400002)(366004)(376002)(396003)(199004)(189003)(446003)(97736004)(53546011)(10290500003)(6506007)(99286004)(478600001)(19609705001)(7736002)(6116002)(486006)(3660700001)(106356001)(790700001)(33656002)(8656006)(86612001)(7696005)(76176011)(229853002)(316002)(11346002)(22452003)(5660300001)(4326008)(3280700002)(25786009)(68736007)(476003)(606006)(5250100002)(966005)(10090500001)(93886005)(236005)(9686003)(54896002)(6306002)(8676002)(81156014)(81166006)(53936002)(46003)(39060400002)(14454004)(6246003)(53376002)(6436002)(54906003)(110136005)(86362001)(105586002)(2900100001)(74316002)(186003)(102836004)(8990500004)(8936002)(2906002)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0741; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: MnvEtCGzFZsnwJYIne/CC5XtQMXyd2HrF69V9zghNl5aWIux7TADXQMRj3P6J557PfbGRghcvJUMwHEP92cdXQ5dlRvWyWtinIjyquzkOiZ3pw4e+TNl3xhB3YzMSeaOPOQkE+lBAg5NOzzLGZNChKTCa7LG7HBD3uFdTybHap4OCo8yuQkUDzstpc32i68/
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630B7EE570FA57347E66D8EB6B70CY4PR21MB0630namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: a6678b53-2c71-432b-4f0b-08d5a496c6ef
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a6678b53-2c71-432b-4f0b-08d5a496c6ef
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2018 19:09:43.0323 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0741
To: Praveen Balasubramanian 
To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= 
To: Martin Thomson 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Apr 2018 19:09:51 -0000

--_000_CY4PR21MB0630B7EE570FA57347E66D8EB6B70CY4PR21MB0630namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBvcGVuZWQgaXNzdWUgIzEyOTY8aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0
cy9pc3N1ZXMvMTI5Nj4gZm9yIHRyYWNraW5nIFBOIHRyYW5zZm9ybSBuZWdvdGlhdGlvbi4NCg0K
RnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBy
YXZlZW4gQmFsYXN1YnJhbWFuaWFuDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTIsIDIwMTggOToy
OSBBTQ0KVG86IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT47
IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpDYzogUnlhbiBIYW1p
bHRvbiA8cmNoQGdvb2dsZS5jb20+OyBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJp
ZGdlKSA8dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tPjsgQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxp
ZXRmQHRyYW1tZWxsLmNoPjsgVmljdG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBJ
RVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwu
Y29tPg0KU3ViamVjdDogUkU6IFNpbXBsZSB0cmFuc2Zvcm0gZm9yIGltcHJvdmluZyBQTiBvc3Np
ZmljYXRpb24gcHJldmVudGlvbg0KDQoNClJlLiAjMTA3OSwgZm9sbG93aW5nIHNlZW1zIGxpa2Ug
YSB3YXkgZm9yd2FyZCBzbyB3ZSBnZXQgdG8gZG8gc29tZSBpbXBsZW1lbnRhdGlvbnMgYW5kIGdl
dCBkYXRhOg0KDQogIDEuICBQTiB0cmFuc2Zvcm0gaXMgbmVnb3RpYXRlZCB1c2luZyB0cmFuc3Bv
cnQgcGFyYW1zLg0KICAyLiAgRm9sbG93aW5nIFBOIHRyYW5zZm9ybXMgYXJlIHN1cHBvcnRlZDoN
CiAgICAgKiAgIFBORQ0KDQpDb25uZWN0aW9ucyBleHBlY3RpbmcgdG8gdXNlIG11bHRpcGxlIHBh
dGhzIGR1ZSB0byBncmF0dWl0b3VzL3ZvbHVudGFyeSBtaWdyYXRpb24gTVVTVCBuZWdvdGlhdGUg
YW5kIHVzZSBQTkUgdHJhbnNmb3JtLiBTZWUgaXNzdWUgMTI3MSB3aGVyZSBvcHRpb25zIGFyZSBi
ZWluZyBkaXNjdXNzZWQgb24gaG93IG1pZ3JhdGlvbiBjb3VsZCBiZSBuZWdvdGlhdGVkLg0KDQpS
ZXZpc2l0IHRoaXMgc29sdXRpb24gZm9yIHByb3BlciBtdWx0aS1wYXRoIGFmdGVyIGRlc2lnbmlu
ZyBtdWx0aXBsZSBQTiBzcGFjZXMuIEkgYW0gZmluZSBpZiB0aGlzIGlzIGRvbmUgZm9yIFYyLg0K
DQogICAgICogICBMb3cgY29zdCBvc3NpZmljYXRpb24gcHJldmVudGlvbiB0cmFuc2Zvcm0gKGxp
a2Ugc2h1ZmZsZSkuDQoNCkZvciBjb25uZWN0aW9ucyBvbiB0aGUgSW50ZXJuZXQgb24gc2luZ2xl
IHBhdGggcmVxdWlyZSB0aGVtIHRvIG5lZ290aWF0ZSB0aGlzIHRyYW5zZm9ybS4gRXZlbiBiZXR0
ZXIgaWYgd2UgZmluZCBhbm90aGVyIGxvdyBjb3N0IHNjaGVtZSB3aXRoIGJldHRlciBwcm9wZXJ0
aWVzIGJlZm9yZSB3ZSBzaGlwIFYxLg0KDQogICAgICogICBOby1vcCAoY3VycmVudCBkcmFmdCkN
Cg0KRm9yIGludHJhLWRhdGFjZW50ZXIgb3Igc2luZ2xlIGRvbWFpbiBwcml2YXRlIG5ldHdvcmsg
c2NlbmFyaW9zIGFsbG93IHVzYWdlIG9mIHRoZSBuby1vcCB0cmFuc2Zvcm0uDQoNCklmIHNlcnZl
ciBmYWlscyB0byBuZWdvdGlhdGUgUE5FIGFuZCBzdXBwbGllcyBtdWx0aXBsZSBjb25uZWN0aW9u
IElEcyBmb3IgbWlncmF0aW9uLCBjbGllbnQgZmFpbCB0aGUgY29ubmVjdGlvbi4NCklmIHRoZSBz
ZXJ2ZXIgZmFpbHMgdG8gbmVnb3RpYXRlIGEgbG93IGNvc3QgdHJhbnNmb3JtIG9uIHRoZSBJbnRl
cm5ldCwgY2xpZW50IGZhaWxzIHRoZSBjb25uZWN0aW9uLg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHNl
cnZlcnMgYXJlIGZyZWUgdG8gcGljayBQTkUgYWxsIHRoZSB0aW1lLiBUaGlzIGFsbG93cyBzZXJ2
ZXIgZGVwbG95bWVudHMgd2hpY2ggaGF2ZSBubyBwZXJmb3JtYW5jZSBjb25jZXJuIHRvIGFsd2F5
cyB1c2UgUE5FLiBJIGRvIGhhdmUgc29tZSBiYXR0ZXJ5IGxpZmUgY29uY2VybnMgb24gY2xpZW50
IHNpZGUsIGJ1dCBJIGRvIHRoaW5rIHRoZSBtYWpvciBwZXJmIGNvbmNlcm4gaXMgb24gc2VydmVy
IHNpZGUuDQoNCklmIHRoZSBkZXBsb3ltZW50cyB1c2luZyBsb3cgY29zdCB0cmFuc2Zvcm0gaGl0
IG1pZGRsZWJveCBpc3N1ZXMgdGhleSB3aWxsIHN1ZmZlciBhbmQgcGF5IHRoZSBjb3N0IHRvIGRv
IFBORS4NCg0KRnJvbTogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZq
QGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxMiwgMjAxOCAzOjUyIEFNDQpUbzog
TWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRo
b21zb25AZ21haWwuY29tPj4NCkNjOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRv
OnF1aWNAaWV0Zi5vcmc+PjsgQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxpZXRmQHRyYW1tZWxsLmNo
PG1haWx0bzppZXRmQHRyYW1tZWxsLmNoPj47IFJ5YW4gSGFtaWx0b24gPHJjaEBnb29nbGUuY29t
PG1haWx0bzpyY2hAZ29vZ2xlLmNvbT4+OyBWaWN0b3IgVmFzaWxpZXYgPHZhc2lsdnZAZ29vZ2xl
LmNvbTxtYWlsdG86dmFzaWx2dkBnb29nbGUuY29tPj47IEZvc3NhdGksIFRob21hcyAoTm9raWEg
LSBHQi9DYW1icmlkZ2UpIDx0aG9tYXMuZm9zc2F0aUBub2tpYS5jb208bWFpbHRvOnRob21hcy5m
b3NzYXRpQG5va2lhLmNvbT4+OyBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPG1haWx0
bzprYXp1aG9va3VAZ21haWwuY29tPj47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBt
aWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tPj4NClN1YmplY3Q6IFJlOiBT
aW1wbGUgdHJhbnNmb3JtIGZvciBpbXByb3ZpbmcgUE4gb3NzaWZpY2F0aW9uIHByZXZlbnRpb24N
Cg0KDQoNCk9uIDEyIEFwcmlsIDIwMTggYXQgMTEuMDUuMTcsIE1hcnRpbiBUaG9tc29uIChtYXJ0
aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4pIHdy
b3RlOg0KVGhlIGNsZWFuIHBlci1wYXRoIHBhY2tldCBudW1iZXIgZG9lc24ndCBkZWZlbmQgYWdh
aW5zdCAiaGVscGZ1bG5lc3MiDQpvZiB0aGUgbmF0dXJlIEkgZGVzY3JpYmVkLiBUaG9zZSBwcm9i
bGVtcyBleGlzdCBpZiB0aGUgc2lnbmFsIGV4aXN0cw0KYXQgYWxsLg0KDQoNCg0KVHJ1ZS4gQnV0
IHRoZXNlIGFyZSBzdGlsbCB0aGUgb3B0aW9ucyBhcyBJIHNlZSBpdC4gSGFsZi1iYWtlZCBvYmZ1
c2NhdGlvbiB3aWxsIG9ubHkgbWFrZSBpdCB3b3JzZS4NCg0KVGhlcmUgaXMgdGhlIGhvbHkgZ3Jh
aWwgb2YgZmFzdCAzMi1iaXQgcGVybXV0YXRpb25zIHRoYXQgY2FuIGJlIHVzZWQgZGlyZWN0bHkg
YXMgSVYsIHdoaWNoIGFyZSBzdWZmaWNpZW50bHkgc2FmZSB3cnQuIHByaXZhY3ksIGFuZCB3aGVy
ZSB0aGUgcGVybXV0YXRpb24gZG9lcyBub3QgZGVwZW5kIG9uIHRoZSBwYWNrZXQgY29udGVudC4N
Cg0KVGhlIGZvbGxvd2luZyBmdW5jdGlvbiBpcyB1c2VmdWwgdG8gZGlzcGVyc2UgYSBsb3ctcXVh
bGl0eSBoYXNoIC0gaXQgaXMgYSBwZXJmZWN0IHBlcm11dGF0aW9uLiBVbmZvcnR1bmF0ZWx5LCBv
ciBmb3J0dW5hdGVseSwgaXQgY2FuIGJlIHRyaXZpYWxseSByZXZlcnNlZCAtIHNlZSBzdGFjayBv
dmVyZmxvdyBhcnRpY2xlLiBUaGVyZSBhcmUgYWxzbyA2NC1iaXQgdmFyaWFudHMsIGFuZCBpdCBj
b3VsZCBhbHNvIGJlIGp1c3QgYSBzaW5nbGUgbXVsdGlwbGljYXRpb24uIE1hcnRpbiBULiBhbHJl
YWR5IGhpbnRlZCBhdCBzb21ldGhpbmcgc2ltaWxhciBpbiBhbiBlYXJsaWVyIG1haWwuDQoNClRo
ZSBiZW5lZml0IG9mIHRoaXMgb3ZlciBsb3dlciBvY3RldCBwZXJtdXRhdGlvbiBpcyB0aGF0IHN0
dXBpZCBtaWRkbGUtYm94ZXMgZG9u4oCZdCBoYXZlIGEgY2hhbmNlLCB3aGlsZSBzbGlnaHRseSBp
bnRlbGxpZ2VudCBtaWRkbGUtYm94ZXMgY2FuIHVzZSBpdCBpcyBsb3NzIC8gcmVvcmRlcmluZyBz
aWduYWwsIGFuZCBRVUlDIGhhcmR3YXJlIG9mZmxvYWQgZGVjcnlwdG9ycyBjYW4gdXNlIHRoZSB2
YWx1ZSB1bm1vZGlmaWVkIGFzIElWIHJhdGhlciB0aGFuIGNvbXB1dGluZyB0aGUgaW52ZXJzZSBm
aXJzdC4gRnJvbSBhIHByaXZhY3kgcGVyc3BlY3RpdmUgdGhpcyBpcyBubyBiZXR0ZXIgdGhhbiBw
bGFpbiBzZXF1ZW50aWFsIG51bWJlcnMuDQoNCkJ1dCBpdCBzdGlsbCBzZXJ2ZXMgYXMgZmluZ2Vy
cHJpbnRpbmcgYSBnaXZlbiBRVUlDIHZlcnNpb24uIEnigJlkIHNheSBmdWxsIGVuY3J5cHRpb24g
b3IgY2xlYXIgdGV4dCBzZXF1ZW50aWFsIGFyZSB0aGUgb25seSB2aWFibGUgY2hvaWNlcy4NCg0K
DQoNCg0KDQogICAgLyogaHR0cDovL3N0YWNrb3ZlcmZsb3cuY29tL2EvMTI5OTYwMjg8aHR0cHM6
Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUy
RnN0YWNrb3ZlcmZsb3cuY29tJTJGYSUyRjEyOTk2MDI4JmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQw
bWljcm9zb2Z0LmNvbSU3Q2EyYzg4ZGNiYjE1MTQ2NDY0ODllMDhkNWEwNjM3NjIzJTdDNzJmOTg4
YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjU5MTI3MTQwNDUzODEyMSZz
ZGF0YT1WQThEcFZjeWhWS3lXT01LU2NuaG9tVVF5U0diOXEzeDFyZFlLc2N0d2YwJTNEJnJlc2Vy
dmVkPTA+ICovDQoNCiAgICB1aW50MzJfdCB4ID0gdHlwZV9oYXNoOw0KDQoNCg0KICAgIHggPSAo
KHggPj4gMTYpIF4geCkgKiAweDQ1ZDlmM2JVTDsNCg0KICAgIHggPSAoKHggPj4gMTYpIF4geCkg
KiAweDQ1ZDlmM2JVTDsNCg0KICAgIHggPSAoKHggPj4gMTYpIF4geCk7DQoNCiAgICByZXR1cm4g
eDsNCg0KDQo=

--_000_CY4PR21MB0630B7EE570FA57347E66D8EB6B70CY4PR21MB0630namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSW5jb25zb2xh
dGEgZm9yIFBvd2VybGluZSI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBT
dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v
cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh
bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ
dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r
Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQs
IGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t
c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu
LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow
aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
Zjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hh
ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0
IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmFpcm1haWxvbiwgbGku
YWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1lOmFpcm1haWxfb247DQoJ
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRl
ZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUy
Mw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp
biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp
c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4MTk0MTk0OTsNCglt
c28tbGlzdC10ZW1wbGF0ZS1pZHM6MTcxMDIyODM3Njt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv
LWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps
ZXZlbDINCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNv
LWxpc3QtaWQ6MTgzNzkzMzgzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQyNDMxNDc1NDt9
DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7DQoJ
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w
OjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MzgyMTAxNTU4Ow0KCW1zby1saXN0LXR5
cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzM4NjY2NjIwIDgxNDM4MjQ3OCA2
NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5
ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v
bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp
bjt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93
ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7
fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6
bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl
bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyOmxl
dmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
O30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl
cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDox
NjA3MjI2MDMzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo2MTc3OTU2NzI7fQ0KQGxpc3QgbDM6
bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl
bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdp
bi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k
aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp
dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48
L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl
IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5JIG9wZW5lZCBpc3N1ZSA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVp
Y3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8xMjk2Ij4NCiMxMjk2PC9hPiBmb3IgdHJhY2tpbmcgUE4g
dHJhbnNmb3JtIG5lZ290aWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJv
dW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPlByYXZlZW4gQmFsYXN1YnJhbWFu
aWFuPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAxMiwgMjAxOCA5OjI5IEFNPGJy
Pg0KPGI+VG86PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFp
bC5jb20mZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0
Ozxicj4NCjxiPkNjOjwvYj4gUnlhbiBIYW1pbHRvbiAmbHQ7cmNoQGdvb2dsZS5jb20mZ3Q7OyBG
b3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlKSAmbHQ7dGhvbWFzLmZvc3NhdGlA
bm9raWEuY29tJmd0OzsgQnJpYW4gVHJhbW1lbGwgKElFVEYpICZsdDtpZXRmQHRyYW1tZWxsLmNo
Jmd0OzsgVmljdG9yIFZhc2lsaWV2ICZsdDt2YXNpbHZ2QGdvb2dsZS5jb20mZ3Q7OyBJRVRGIFFV
SUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBLYXp1aG8gT2t1ICZsdDtrYXp1aG9va3VAZ21h
aWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogU2ltcGxlIHRyYW5zZm9ybSBmb3Ig
aW1wcm92aW5nIFBOIG9zc2lmaWNhdGlvbiBwcmV2ZW50aW9uPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZS4gIzEwNzksIGZvbGxvd2luZyBzZWVtcyBsaWtlIGEg
d2F5IGZvcndhcmQgc28gd2UgZ2V0IHRvIGRvIHNvbWUgaW1wbGVtZW50YXRpb25zIGFuZCBnZXQg
ZGF0YTo8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIx
IiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2
ZWwxIGxmbzMiPlBOIHRyYW5zZm9ybSBpcyBuZWdvdGlhdGVkIHVzaW5nIHRyYW5zcG9ydCBwYXJh
bXMuDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlz
dDpsMiBsZXZlbDEgbGZvMyI+Rm9sbG93aW5nIFBOIHRyYW5zZm9ybXMgYXJlIHN1cHBvcnRlZDoN
CjxvOnA+PC9vOnA+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0i
YSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVsMiBsZm8z
Ij5QTkUgPG86cD48L286cD48L2xpPjwvb2w+DQo8L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkNvbm5lY3Rpb25zIGV4cGVjdGluZyB0
byB1c2UgbXVsdGlwbGUgcGF0aHMgZHVlIHRvIGdyYXR1aXRvdXMvdm9sdW50YXJ5IG1pZ3JhdGlv
biBNVVNUIG5lZ290aWF0ZSBhbmQgdXNlIFBORSB0cmFuc2Zvcm0uIFNlZSBpc3N1ZSAxMjcxIHdo
ZXJlIG9wdGlvbnMgYXJlIGJlaW5nIGRpc2N1c3NlZCBvbiBob3cgbWlncmF0aW9uIGNvdWxkIGJl
IG5lZ290aWF0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls
ZT0ibWFyZ2luLWxlZnQ6MS4waW4iPlJldmlzaXQgdGhpcyBzb2x1dGlvbiBmb3IgcHJvcGVyIG11
bHRpLXBhdGggYWZ0ZXIgZGVzaWduaW5nIG11bHRpcGxlIFBOIHNwYWNlcy4gSSBhbSBmaW5lIGlm
IHRoaXMgaXMgZG9uZSBmb3IgVjIuPG86cD48L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10
b3A6MGluIiBzdGFydD0iMiIgdHlwZT0iMSI+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBz
dGFydD0iMiIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0
OmwyIGxldmVsMiBsZm8zIj5Mb3cgY29zdCBvc3NpZmljYXRpb24gcHJldmVudGlvbiB0cmFuc2Zv
cm0gKGxpa2Ugc2h1ZmZsZSkuDQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvb2w+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkZvciBjb25uZWN0aW9u
cyBvbiB0aGUgSW50ZXJuZXQgb24gc2luZ2xlIHBhdGggcmVxdWlyZSB0aGVtIHRvIG5lZ290aWF0
ZSB0aGlzIHRyYW5zZm9ybS4gRXZlbiBiZXR0ZXIgaWYgd2UgZmluZCBhbm90aGVyIGxvdyBjb3N0
IHNjaGVtZSB3aXRoIGJldHRlciBwcm9wZXJ0aWVzIGJlZm9yZSB3ZSBzaGlwIFYxLjxvOnA+PC9v
OnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIiIHR5cGU9IjEiPg0K
PG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjMiIHR5cGU9ImEiPg0KPGxpIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMiBsZXZlbDIgbGZvMyI+Tm8tb3AgKGN1cnJl
bnQgZHJhZnQpIDxvOnA+DQo8L286cD48L2xpPjwvb2w+DQo8L29sPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5Gb3IgaW50cmEtZGF0YWNlbnRlciBv
ciBzaW5nbGUgZG9tYWluIHByaXZhdGUgbmV0d29yayBzY2VuYXJpb3MgYWxsb3cgdXNhZ2Ugb2Yg
dGhlIG5vLW9wIHRyYW5zZm9ybS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgc2VydmVyIGZh
aWxzIHRvIG5lZ290aWF0ZSBQTkUgYW5kIHN1cHBsaWVzIG11bHRpcGxlIGNvbm5lY3Rpb24gSURz
IGZvciBtaWdyYXRpb24sIGNsaWVudCBmYWlsIHRoZSBjb25uZWN0aW9uLjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIHNlcnZlciBmYWlscyB0byBuZWdvdGlhdGUg
YSBsb3cgY29zdCB0cmFuc2Zvcm0gb24gdGhlIEludGVybmV0LCBjbGllbnQgZmFpbHMgdGhlIGNv
bm5lY3Rpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIG5vdGUgdGhhdCBzZXJ2
ZXJzIGFyZSBmcmVlIHRvIHBpY2sgUE5FIGFsbCB0aGUgdGltZS4gVGhpcyBhbGxvd3Mgc2VydmVy
IGRlcGxveW1lbnRzIHdoaWNoIGhhdmUgbm8gcGVyZm9ybWFuY2UgY29uY2VybiB0byBhbHdheXMg
dXNlIFBORS4gSSBkbyBoYXZlIHNvbWUgYmF0dGVyeSBsaWZlIGNvbmNlcm5zIG9uIGNsaWVudCBz
aWRlLCBidXQgSSBkbyB0aGluayB0aGUgbWFqb3IgcGVyZiBjb25jZXJuIGlzDQogb24gc2VydmVy
IHNpZGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBkZXBsb3ltZW50cyB1c2luZyBs
b3cgY29zdCB0cmFuc2Zvcm0gaGl0IG1pZGRsZWJveCBpc3N1ZXMgdGhleSB3aWxsIHN1ZmZlciBh
bmQgcGF5IHRoZSBjb3N0IHRvIGRvIFBORS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNaWtrZWwgRmFobsO4ZSBK
w7hyZ2Vuc2VuIFs8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIj5tYWlsdG86bWlr
a2VsZmpAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwg
MTIsIDIwMTggMzo1MiBBTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIFRob21zb24gJmx0OzxhIGhy
ZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iPm1hcnRpbi50aG9tc29uQGdtYWls
LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1h
aWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZndDs7IEJyaWFuIFRyYW1tZWxs
IChJRVRGKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAdHJhbW1lbGwuY2giPmlldGZAdHJhbW1l
bGwuY2g8L2E+Jmd0OzsgUnlhbiBIYW1pbHRvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJjaEBnb29n
bGUuY29tIj5yY2hAZ29vZ2xlLmNvbTwvYT4mZ3Q7OyBWaWN0b3IgVmFzaWxpZXYgJmx0OzxhIGhy
ZWY9Im1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20iPnZhc2lsdnZAZ29vZ2xlLmNvbTwvYT4mZ3Q7
Ow0KIEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UpICZsdDs8YSBocmVmPSJt
YWlsdG86dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tIj50aG9tYXMuZm9zc2F0aUBub2tpYS5jb208
L2E+Jmd0OzsgS2F6dWhvIE9rdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5j
b20iPmthenVob29rdUBnbWFpbC5jb208L2E+Jmd0OzsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4g
Jmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIj5wcmF2YkBtaWNyb3NvZnQu
Y29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFNpbXBsZSB0cmFuc2Zvcm0gZm9y
IGltcHJvdmluZyBQTiBvc3NpZmljYXRpb24gcHJldmVudGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz
cz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMTIgQXByaWwgMjAxOCBhdCAxMS4w
NS4xNywgTWFydGluIFRob21zb24gKDwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWFydGluLnRob21z
b25AZ21haWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWFydGluLnRob21zb25AZ21haWwuY29t
PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+KQ0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv
cmQtc3BhY2luZzowcHgiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPlRoZSBjbGVhbiBwZXItcGF0aCBw
YWNrZXQgbnVtYmVyIGRvZXNuJ3QgZGVmZW5kIGFnYWluc3QgJnF1b3Q7aGVscGZ1bG5lc3MmcXVv
dDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+b2YgdGhlIG5hdHVyZSBJIGRlc2NyaWJlZC4gVGhvc2UgcHJvYmxlbXMgZXhp
c3QgaWYgdGhlIHNpZ25hbCBleGlzdHM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij5hdCBhbGwuPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
VHJ1ZS4gQnV0IHRoZXNlIGFyZSBzdGlsbCB0aGUgb3B0aW9ucyBhcyBJIHNlZSBpdC4gSGFsZi1i
YWtlZCBvYmZ1c2NhdGlvbiB3aWxsIG9ubHkgbWFrZSBpdCB3b3JzZS48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmUgaXMgdGhlIGhvbHkgZ3JhaWwgb2Yg
ZmFzdCAzMi1iaXQgcGVybXV0YXRpb25zIHRoYXQgY2FuIGJlIHVzZWQgZGlyZWN0bHkgYXMgSVYs
IHdoaWNoIGFyZSBzdWZmaWNpZW50bHkgc2FmZSB3cnQuIHByaXZhY3ksIGFuZCB3aGVyZSB0aGUg
cGVybXV0YXRpb24gZG9lcyBub3QgZGVwZW5kIG9uIHRoZSBwYWNrZXQgY29udGVudC48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGZvbGxvd2luZyBmdW5j
dGlvbiBpcyB1c2VmdWwgdG8gZGlzcGVyc2UgYSBsb3ctcXVhbGl0eSBoYXNoIC0gaXQgaXMgYSBw
ZXJmZWN0IHBlcm11dGF0aW9uLiBVbmZvcnR1bmF0ZWx5LCBvciBmb3J0dW5hdGVseSwgaXQgY2Fu
IGJlIHRyaXZpYWxseSByZXZlcnNlZCAtIHNlZSBzdGFjayBvdmVyZmxvdyBhcnRpY2xlLiBUaGVy
ZQ0KIGFyZSBhbHNvIDY0LWJpdCB2YXJpYW50cywgYW5kIGl0IGNvdWxkIGFsc28gYmUganVzdCBh
IHNpbmdsZSBtdWx0aXBsaWNhdGlvbi4gTWFydGluIFQuIGFscmVhZHkgaGludGVkIGF0IHNvbWV0
aGluZyBzaW1pbGFyIGluIGFuIGVhcmxpZXIgbWFpbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGJlbmVmaXQgb2YgdGhpcyBvdmVyIGxvd2VyIG9jdGV0
IHBlcm11dGF0aW9uIGlzIHRoYXQgc3R1cGlkIG1pZGRsZS1ib3hlcyBkb27igJl0IGhhdmUgYSBj
aGFuY2UsIHdoaWxlIHNsaWdodGx5IGludGVsbGlnZW50IG1pZGRsZS1ib3hlcyBjYW4gdXNlIGl0
IGlzIGxvc3MgLyByZW9yZGVyaW5nIHNpZ25hbCwgYW5kIFFVSUMgaGFyZHdhcmUNCiBvZmZsb2Fk
IGRlY3J5cHRvcnMgY2FuIHVzZSB0aGUgdmFsdWUgdW5tb2RpZmllZCBhcyBJViByYXRoZXIgdGhh
biBjb21wdXRpbmcgdGhlIGludmVyc2UgZmlyc3QuIEZyb20gYSBwcml2YWN5IHBlcnNwZWN0aXZl
IHRoaXMgaXMgbm8gYmV0dGVyIHRoYW4gcGxhaW4gc2VxdWVudGlhbCBudW1iZXJzLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5CdXQgaXQgc3RpbGwgc2VydmVz
IGFzIGZpbmdlcnByaW50aW5nIGEgZ2l2ZW4gUVVJQyB2ZXJzaW9uLiBJ4oCZZCBzYXkgZnVsbCBl
bmNyeXB0aW9uIG9yIGNsZWFyIHRleHQgc2VxdWVudGlhbCBhcmUgdGhlIG9ubHkgdmlhYmxlIGNo
b2ljZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtJbmNvbnNvbGF0YSBmb3IgUG93ZXJsaW5lJnF1b3Q7LHNlcmlmIj4mbmJz
cDsgJm5ic3A7IC8qDQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90
ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnN0YWNrb3ZlcmZsb3cuY29tJTJG
YSUyRjEyOTk2MDI4JmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0Nh
MmM4OGRjYmIxNTE0NjQ2NDg5ZTA4ZDVhMDYzNzYyMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3
Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY1OTEyNzE0MDQ1MzgxMjEmYW1wO3NkYXRhPVZBOERwVmN5
aFZLeVdPTUtTY25ob21VUXlTR2I5cTN4MXJkWUtzY3R3ZjAlM0QmYW1wO3Jlc2VydmVkPTAiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0luY29uc29sYXRh
IGZvciBQb3dlcmxpbmUmcXVvdDssc2VyaWYiPmh0dHA6Ly9zdGFja292ZXJmbG93LmNvbS9hLzEy
OTk2MDI4PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtJbmNvbnNvbGF0YSBmb3IgUG93ZXJsaW5lJnF1b3Q7LHNlcmlmIj4NCiAqLzwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SW5jb25zb2xhdGEgZm9yIFBv
d2VybGluZSZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyB1aW50MzJfdCB4ID0gdHlwZV9oYXNo
Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0luY29uc29sYXRhIGZvciBQ
b3dlcmxpbmUmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgeCA9ICgoeCAmZ3Q7Jmd0OyAxNikg
XiB4KSAqIDB4NDVkOWYzYlVMOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SW5jb25zb2xhdGEgZm9yIFBvd2VybGluZSZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNw
OyB4ID0gKCh4ICZndDsmZ3Q7IDE2KSBeIHgpICogMHg0NWQ5ZjNiVUw7PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtJbmNvbnNvbGF0YSBmb3IgUG93ZXJsaW5lJnF1
b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7IHggPSAoKHggJmd0OyZndDsgMTYpIF4geCk7PC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtJbmNvbnNvbGF0YSBmb3IgUG93
ZXJsaW5lJnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7IHJldHVybiB4Ozwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt
YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxl
PSJib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7Ym94LXNpemluZzpib3JkZXItYm94O2JvcmRlci1z
cGFjaW5nOjBweCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1
cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_CY4PR21MB0630B7EE570FA57347E66D8EB6B70CY4PR21MB0630namp_--


From nobody Tue Apr 17 15:53:00 2018
Return-Path: 
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 283AB124BFA; Tue, 17 Apr 2018 15:52:53 -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-11.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152400557311.31819.13556505314784918814@ietfa.amsl.com>
Date: Tue, 17 Apr 2018 15:52:53 -0700
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 22:52:53 -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-11.txt
	Pages           : 30
	Date            : 2018-04-17

Abstract:
   This document describes loss detection and congestion control
   mechanisms for QUIC.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/search/?email_list=quic [1].

   Working Group information can be found at https://github.com/quicwg
   [2]; source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-recovery [3].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-quic-recovery-11
https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-11


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 Apr 17 16:10:15 2018
Return-Path: 
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39302126C83; Tue, 17 Apr 2018 16:10:14 -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-11.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152400661420.31897.6333036075225461641@ietfa.amsl.com>
Date: Tue, 17 Apr 2018 16:10:14 -0700
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 23:10:14 -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-11.txt
	Pages           : 105
	Date            : 2018-04-17

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-11
https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-11


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 Apr 17 16:10:35 2018
Return-Path: 
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 466EE12704A; Tue, 17 Apr 2018 16:10:14 -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-11.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152400661423.31753.18105362093271688909@ietfa.amsl.com>
Date: Tue, 17 Apr 2018 16:10:14 -0700
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 23:10:14 -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-11.txt
	Pages           : 39
	Date            : 2018-04-17

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-11
https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-11


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 Apr 17 16:38:24 2018
Return-Path: 
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3481270AB; Tue, 17 Apr 2018 16:38:16 -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-11.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152400829682.31889.16179949242028014767@ietfa.amsl.com>
Date: Tue, 17 Apr 2018 16:38:16 -0700
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2018 23:38:17 -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-11.txt
	Pages           : 40
	Date            : 2018-04-17

Abstract:
   This document describes how Transport Layer Security (TLS) is used to
   secure QUIC.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/search/?email_list=quic [1].

   Working Group information can be found at https://github.com/quicwg
   [2]; source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-tls [3].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-tls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-quic-tls-11
https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-11


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 Apr 17 21:48:24 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211D012421A for ; Tue, 17 Apr 2018 21:48:23 -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 yH8qYS02yoLy for ; Tue, 17 Apr 2018 21:48:21 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6F11201F8 for ; Tue, 17 Apr 2018 21:48:21 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id g14so291110pfh.3 for ; Tue, 17 Apr 2018 21:48: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=l9uPp+I/oY+SmzJZrRy6weTJh6S9QVFPB7zWyn9EBvU=; b=u4nxeykdWEmyHWGGGpsYwwlV5Kebl1Kh9LQgrG2DGEpTjo1mvVI8qTpaQFZFbeYFRG SVc0/Pmiu/GVSrkCWRnRedmHls8t/hmAOHcWN9iHEl5BKEioJht/Xe3Qqemq2PpaIROK pcSJ2Rw4vuquDNIDsF7nQ5hPAAunB8y6+P23bmT2TGvwDxak8VOYE4rEg9Xm0YztO2R/ SPZNheAMf01blR/EzSrt8piHowXdXGwizQBu6GxTcXtgWewV3qJTnP5/PiIBI6D55Aky PknZsDGnx+1SnppLcplyKRBLilkMb4C65wBRR5Lmq7Mc+y45QoW24FWLT/xt7l41fMpv aFUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=l9uPp+I/oY+SmzJZrRy6weTJh6S9QVFPB7zWyn9EBvU=; b=nZuJ8pRsryt35/wNOwgzAzQxw3WZsFS1UzqLVD1+oFZJGpPZ3J52Suf01sIfUJLMz2 1CZwIP7HcGIonkpoHWJiagVvXMjWolBU4L1rwsyM1QYuUCfbC4OEL0ZOs2L2yBmbj1tw uQsGN1OMftuwImFE/zPAg6XnknH9tcqLNazaZeBAJXqZ7Rjb5RSokxBw6BYAmievVilm IWQZ/9jmstE747B6tcvanNdVqyErWmgECQ28r2p6sKCbN/YMi8Ffif4vzg9pSLj391er cID5z08DXXLv7WYzfP1itIcyyaWnxVAtaKh3rMRdhXUYA54JfGb7rzm5WJnW2vlsP506 aRAg==
X-Gm-Message-State: ALQs6tA2qK6XVF1Jdc0vDpCU4Z8DgviGXByePJ6R+Kt+/IrwA1J+8+Oq yj1VMgHPOJniod1WEMKizgEOmJelVAc6B/IDXuFpYg==
X-Google-Smtp-Source: AIpwx4/n+MXcf95Jc8n1/N9djIUcUSytOSnd9HGX/2xBwmyhFgK099GazL43yiZ4duBgemCOdPZwnU+lHtm1oyhyTpg=
X-Received: by 10.167.128.207 with SMTP id a15mr602463pfn.116.1524026900568; Tue, 17 Apr 2018 21:48:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Tue, 17 Apr 2018 21:48:19 -0700 (PDT)
In-Reply-To: <1412f856-5eaf-1c7a-266f-2b4d77355647@huitema.net>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>    <1412f856-5eaf-1c7a-266f-2b4d77355647@huitema.net>
From: Kazuho Oku 
Date: Wed, 18 Apr 2018 13:48:19 +0900
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Christian Huitema 
Cc: "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: Wed, 18 Apr 2018 04:48:23 -0000

Hi Christian,

Thank you for updating the wiki page. And the comparison table is awesome.

Looking at that, (it might be unsurprising but) my two cents go to
merging #1079 and continue to consider a hardware-friendly variant as
an extension (until it turns out to be unnecessary).

The reasons I prefer #1079 are:
 * it is easy to implement in software
 * efficient on wire
 * computational overhead is negligible
 * crypto is secure and agile to changes
 * majority of the implementors seem to be happy with the approach

On the PR I see a proposal of a hardware friendly variant (that
modifies AES-GCM). All of us might end up happy with a single scheme.

If some of us (especially those interested in hardware crypto offload)
are unhappy with the solution, we can consider having a negotiated
extension of QUIC that uses a different scheme.

For that variant, my preference goes to the one using nonce due to the
following reasons:
 * it requires the least change from #1079 in terms of key scheduling
 * it would have the broadest range of hardware support

The latter point is from my assumption that most if not all of devices
that have AES-GCM support are capable of accepting an explicit nonce,
while some if not many of them might be incapable of doing some 32-bit
or 64-bit crypto for decrypting PN.

2018-04-18 3:58 GMT+09:00 Christian Huitema :
>
>
> On 4/16/2018 11:15 PM, Kazuho Oku wrote:
>> Hi Christian,
>>
>> Thank you for writing the wonderful summary.
>>
>> Reading it, I think that I now see two issues with the alternative
>> approaches that use a weaker cipher (i..e. alternative PN encryption,
>> 64bit encrypted PN).
>>
>> > We can argue that the algorithm does not have to be as robust as
>> AES.. The main requirement is to prevent real time analysis of
>> sequence numbers by middle-boxes. This is achieved as long as the
>> encryption key cannot be retrieved in a short time by the
>> middle-boxes. If they could do that, we would be once again on the
>> path to ossification. XOR and simple obfuscation probably don't meet
>> that goal, but IPCrypt probably does, and a more robust algorithm
>> certainly would.
>>
>> As you state, it is true that preventing real time analysis is
>> important. But are we sure that we do not need to consider offline
>> attacks? I would be interested in arguing about the other requirement
>> than ossification: privacy.
>>
>> A pervasive monitor might collect CIDs and encrypted PNs that were
>> being used, and then use the encrypted PNs as a source to correlate
>> CIDs to reconstruct a QUIC connection. Are we sure that a weak cipher
>> does not leak such trace?
>
> Yes, you are right. The argument about tolerating weak algorithms only
> applies if we have another solution to prevent linkability, such as
> different sequence numbers and encryption keys for each Connection ID.
> So it comes with a high cost in term of software complexity.
>
>
>>
>> Considering that, I think that the alternative approaches should have
>> per-CID PN encryption keys, even though I am not sure if there are no
>> other privacy-related issues.
> Yes.
>>
>> The other issue is about crypto agility. #1179 has agility in sense
>> that the corresponding CTR mode is used for encrypting the PN. OTOH,
>> the two alternatives using a simple cipher are not agile. So we might
>> need to define two types of simpler ciphers for PN encryption, if
>> consider that privacy issues (like the one above) might arise in the
>> future.
> Yes.  I updated the Wiki page to reflect your comments.
>
> -- Christian Huitema



-- 
Kazuho Oku


From nobody Wed Apr 18 01:09:33 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F50512D810 for ; Wed, 18 Apr 2018 01:09:31 -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=TLGTa8Wa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IkQosu4h
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHmI8u9XiA6i for ; Wed, 18 Apr 2018 01:09:28 -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 81593126CBF for ; Wed, 18 Apr 2018 01:09:28 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C13CD21539; Wed, 18 Apr 2018 04:09:27 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 18 Apr 2018 04:09:27 -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; s=fm2; bh=9LZOcm1kQNVbnkI5Ww6tnCPIJtDzN fWb/4g4zvb2HZI=; b=TLGTa8WaOSLB0QEDqef9H9oTCNsWfA9l0vm5OLcU33ASR LjC0E1xoh8qGAGV8DpUVvpg4ahNSuu6NjNPDJsd02aOPs99aHd/NhMN+8ByXD/pz 9gjnb1WvzhTgNuwtuzCcGd2PoxcaBHBEqSaP6EXzW/2gNt/WN/ThjTgcb11b6iZp 4QaHKT4yg06YPTW6UhyuCKRrdWRepsSil/D09mbuFKSNwPT5jaQ9JBlrN1Usn1wB psZLTnIH+3XSfWpMrFgNX9PCRtn4UjF7/xtnZjsdlCiAkxJYH+77kgmMVa54Kn5z rLa9NCtpQ/H4tpE4DJsyr0JCY223q55VKcSSsOV2w==
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; s=fm2; bh=9LZOcm 1kQNVbnkI5Ww6tnCPIJtDzNfWb/4g4zvb2HZI=; b=IkQosu4hohMxeCCRqLiTei 0IgxAMQHmSbBA9umsQReItB2nuW1Zq2kYsg+kPswM8qtacL4Ayj1GI28tx7kWmtn iKiE/VcFVTRfg0wnU92qhvl31xUP/wjDWVOoOw2810CjSynGmo8ckfHwQ3PadwqV E0Rz67REmo/BBW7YSamgSrFfpTV5RAYrNaPOjoIt8vfwYKMExPLxpJXgJYDrPQsl 0GyNkiyjpjI2tGm5NngHQvY9/s9BIb81/z2XQ/a4u99V9kDQezt/IJNQ2qjaF2Z5 LUTSNI6Uipl4sJbhRpCVy5Kr3EHU0eo4dUYzq0p+Yy8ShV7Qz3b+X04lfQ81x58A ==
X-ME-Sender: 
Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 60EF2E5088; Wed, 18 Apr 2018 04:09:26 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Getting to consensus on packet number encryption
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 18 Apr 2018 18:09:23 +1000
Cc: "quic@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>    <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>  
To: Christian Huitema 
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 18 Apr 2018 08:09:31 -0000

Thanks Christian; that's extremely helpful (and considering that I was =
about to embark on the same task, but do a much worse job, I'm =
especially appreciative).

Everyone please have a read and direct your comments back here.

One aspect that still hasn't been made clear AFAICT -- you say:

"""The process requires two passes, fetching some output of the =
encryption to seed the PN encryption. This is problematic for hardware =
implementations that typically don't buffer the output for further =
access."""

... and then later:

"""Single pass, thus mostly implementable in hardware if we assume that =
the PN encryption/decryption can be done in software."""

Having a bit more context about the hardware implementation limitations =
here would be extremely helpful. Specifically, is "problematic" one of:

* "More difficult for existing hardware (e.g., without firmware updates, =
etc.)"
* "Impossible for existing hardware, but possible for bespoke hardware"
* "Impossible in any hardware"
* Prohibitively expensive for current/future hardware
* Something else?

Cheers,



> On 17 Apr 2018, at 3:05 pm, Christian Huitema  =
wrote:
>=20
> Since you all want to read more text, I wrote a summary of the various =
proposals in the QUIC Wiki: =
https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-is=
sues-and-alternatives.
>=20
> Of course, that summary reflects my own modest understanding. But then =
it's a wiki, so you can easily correct me.
>=20
> -- Christian Huitema

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


From nobody Wed Apr 18 09:38:30 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD54127137 for ; Wed, 18 Apr 2018 09:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BEUsciBD9R7 for ; Wed, 18 Apr 2018 09:38:27 -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 DEFC31242F7 for ; Wed, 18 Apr 2018 09:38:26 -0700 (PDT)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1f8q65-0005Or-Qd for quic@ietf.org; Wed, 18 Apr 2018 18:38:24 +0200
Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1f8q61-0007ie-F3 for quic@ietf.org; Wed, 18 Apr 2018 12:38:13 -0400
Received: (qmail 28637 invoked from network); 18 Apr 2018 16:38:10 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.78]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 18 Apr 2018 16:38:10 -0000
To: Mark Nottingham 
Cc: "quic@ietf.org" 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>
From: Christian Huitema 
Openpgp: preference=signencrypt
Message-ID: 
Date: Wed, 18 Apr 2018 09:38:01 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Subject: Re: Getting to consensus on packet number encryption
X-Originating-IP: 168.144.250.230
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.14)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5trspCnCa6WdvBq2x1FdByx602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViDHqq+sPv/jzg/PMc0qjDtc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBpxvnk7PJGygctl3LC86inx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpWYO2/mqpOb7Q80SeXyngcEQspW6PWtFljIeoG6OsM9IVVYl+3b9Oek V1VW2ytiqcZgiNplmw3yp4FFFCuS+k6jh5d4Swn5E67RV+LaU4GmVjH8gYlRWMzXMtJksqe+xLeX oHkzkRzbKyRDRP8j7fY6rka7glK07Vs7rsUOKUDQF2h+wlfAS2SbL4bvnSO/22VRQT6qIypAqgrt WJG7IDNSD72gXzdJ2+JJROR2tMmoDZRins15oKFWvUk5C9olBXDhjX6bHzu+acs8UcTQf4enw6nI oDr0sXUZ7YZoZ/GZ+jr47k1ZYM+XPLUTB3aEhddz5NQBt6vrTjaii/MA7FoCAhy1/eljfSN5aXns qLZLef9qwM7RXpJS8RjTdyh2j5AWyDZ7BRCxIW6XiPgk5wgNeRXbC69qDBnTAPdQSCnD1TRj9D8H LKHAKpPGP8EPnuDHTXhIrVzYteKGVryF5qVZ
X-Report-Abuse-To: spam@quarantine6.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, 18 Apr 2018 16:38:29 -0000

On 4/18/2018 1:09 AM, Mark Nottingham wrote:
> Thanks Christian; that's extremely helpful (and considering that I was about to embark on the same task, but do a much worse job, I'm especially appreciative).
>
> Everyone please have a read and direct your comments back here.
>
> One aspect that still hasn't been made clear AFAICT -- you say:
>
> """The process requires two passes, fetching some output of the encryption to seed the PN encryption. This is problematic for hardware implementations that typically don't buffer the output for further access."""
>
> .... and then later:
>
> """Single pass, thus mostly implementable in hardware if we assume that the PN encryption/decryption can be done in software."""
>
> Having a bit more context about the hardware implementation limitations here would be extremely helpful. Specifically, is "problematic" one of:
>
> * "More difficult for existing hardware (e.g., without firmware updates, etc.)"
> * "Impossible for existing hardware, but possible for bespoke hardware"
> * "Impossible in any hardware"
> * Prohibitively expensive for current/future hardware
> * Something else?

I tried to express the issue in my own words, based on discussions in
this list. But as I said, this is a Wiki. People with more hands-on
experience on hardware acceleration would be welcome to add a small
section describing the issue with hardware implementations.

-- Christian Huitema


From nobody Sat Apr 21 17:45:23 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E49F127201 for ; Sat, 21 Apr 2018 17:45:21 -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=mnot.net header.b=2mxSNKsh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Oh4G1xem
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuYG_d_fBSHe for ; Sat, 21 Apr 2018 17:45:18 -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 54B71127863 for ; Sat, 21 Apr 2018 17:45:18 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C54F621BC0 for ; Sat, 21 Apr 2018 20:45:17 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 21 Apr 2018 20:45:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Cl1tmATXzpffgpQ/d EZ4N+Uc5EGw5yYa8r9wx8xjOIk=; b=2mxSNKshXTR+autZguE6vUP08CQEuZj/g W9pLe+S8+PnZryMT9ynWH2P3+A+krFjzBEDad1Ry6Ps/jRMvXzFJJxCJxW5ll9dQ Q7Ci/yE6jI3RJiszMM2jz6AVk57uhaJYVGfVOcuCqPIk3W5t7M45ROhH3/NgXPDz iUC6jev3iHzW4ylUxVRadyR0FjhWQNFU4m8z1cAO2HBg0YMxNcx+1HlXuKFIaSE2 9ct7ZYUnwfkeq+DjkjbkL37yALRqV7Ju6+P8/oy7widEVCN4mOnfdoSnhVENKfU0 4Mkt8dFqdFis8eksSsiEDYRr84WhLXv176hYCADPxjiib2sPVNibw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=Cl1tmATXzpffgpQ/dEZ4N+Uc5EGw5yYa8r9wx8xjOIk=; b=Oh4G1xem BJlT9gGa3Ycmw9JpCYt7skgYuqDIAxbWXVYwKT7FrBEpsh5KY15LNM8nQO/RRFmz XaRAk47Y/VhKJhnYh+s8OGxk0vfvtRX1ofUDH1mUi1nomXMbpJO6Td9mLB4SbTsT aimyy57ZxcyYWT6CjQmfJOXq0ZYzD+lOp8CjwPcDobtGPV7dwdRE9/RONQ7Id/R0 PYayimck8BziBr3j8xhp3d4JISOqYasgnLNHRG5SODBEPYOgsvX+esKdYHI05bfb UWF7qfhIevxcpodDs+ZuJtL7uj46ALd5IJosEfrLaZLeh3G6SA96TMdQEiN2ko2N mq/B40Q4d+3dUA==
X-ME-Sender: 
Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id DBB07E4921 for ; Sat, 21 Apr 2018 20:45:16 -0400 (EDT)
Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 341AEC8DBC for ; Sun, 22 Apr 2018 00:45:14 +0000 (UTC)
Content-Type: multipart/alternative; boundary="===============8905050248672553457=="
MIME-Version: 1.0
From: =?utf-8?q?Github_Notifications?= 
To: quic@ietf.org
Subject: Weekly github digest (QUIC Working Group Specifications)
Message-Id: <20180422004514.341AEC8DBC@cloud.mnot.net>
Date: Sun, 22 Apr 2018 00:45:14 +0000 (UTC)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Apr 2018 00:45:21 -0000

--===============8905050248672553457==
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; format="flowed"




Events without label "editorial"

Issues
------
* quicwg/base-drafts (+5/-2/=F0=9F=92=AC8)
  5 issues created:
  - Awkward phrase in ACK Frame section of the Transport Draft (by dtikhono=
v)
    https://github.com/quicwg/base-drafts/issues/1311 =

  - Need to prevent amplification attack for any case where the server's re=
sponse is big (by ekr)
    https://github.com/quicwg/base-drafts/issues/1309 =

  - Packet type of Stateless reset (by tatsuhiro-t)
    https://github.com/quicwg/base-drafts/issues/1305 =

  - Meaning of "application-owned streams" is unclear (by dtikhonov)
    https://github.com/quicwg/base-drafts/issues/1297 =

  - Packet number transform should be negotiated (by pravb)
    https://github.com/quicwg/base-drafts/issues/1296 =


  5 issues received 8 new comments:
  - #1293 Payload length in header encrypted with sequence number (4 by hui=
tema, MikeBishop)
    https://github.com/quicwg/base-drafts/issues/1293 [-transport] [design] =

  - #1296 Packet number transform should be negotiated (1 by pravb)
    https://github.com/quicwg/base-drafts/issues/1296 =

  - #1297 Meaning of "application-owned streams" is unclear (1 by LPardue)
    https://github.com/quicwg/base-drafts/issues/1297 =

  - #1309 Need to prevent amplification attack for any case where the serve=
r's response is big (1 by mcmanus)
    https://github.com/quicwg/base-drafts/issues/1309 =

  - #1271 Connection migration optional? (1 by nibanks)
    https://github.com/quicwg/base-drafts/issues/1271 [-transport] [design] =


  2 issues closed:
  - Awkward phrase in ACK Frame section of the Transport Draft https://gith=
ub.com/quicwg/base-drafts/issues/1311 =

  - Payload length in header encrypted with sequence number https://github.=
com/quicwg/base-drafts/issues/1293 [-transport] [design] =




Pull requests
-------------
* quicwg/base-drafts (+12/-3/=F0=9F=92=AC66)
  12 pull requests submitted:
  - Remove awkward sentence (by ianswett)
    https://github.com/quicwg/base-drafts/pull/1313 =

  - Deemphasize TCP SACKs reference in ACK frame description (by dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1312 =

  - s/initial_max_stream_id_(uni|bidi)/initial_max_streams_$1/g (by dtikhon=
ov)
    https://github.com/quicwg/base-drafts/pull/1310 =

  - Change Packet Number Gap to Packet Number Offset (by nibanks)
    https://github.com/quicwg/base-drafts/pull/1307 =

  - Move Retry to QUIC Layer (by nibanks)
    https://github.com/quicwg/base-drafts/pull/1304 =

  - Remove term "application-owned streams" (by LPardue)
    https://github.com/quicwg/base-drafts/pull/1303 =

  - Generate tags file for explicit and implicit anchors in the drafts (by =
dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1302 =

  - make payload length 0 special (by marten-seemann)
    https://github.com/quicwg/base-drafts/pull/1301 =

  - QUIC-TRANSPORT: Add missing anchor to Packet Number Gap section (by dti=
khonov)
    https://github.com/quicwg/base-drafts/pull/1300 =

  - Makefile: add target to generate tags for I-D sections (by dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1299 =

  - Fix build: remove "numbered" attribute from Acknowledgements section (b=
y dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1298 =

  - Fix wrong spin bit in spin-exp text (by britram)
    https://github.com/quicwg/base-drafts/pull/1295 =


  14 pull requests received 66 new comments:
  - #1310 s/initial_max_stream_id_(uni|bidi)/initial_max_streams_$1/g (16 b=
y vasilvv, mikkelfj, MikeBishop, RyanAtGoogle, dtikhonov, LPardue)
    https://github.com/quicwg/base-drafts/pull/1310 =

  - #1079 Packet number encryption (12 by ad-l, kazuho, mikkelfj, huitema, =
nibanks, ekr)
    https://github.com/quicwg/base-drafts/pull/1079 [-tls] [-transport] =

  - #1307 Change Packet Number Gap to Packet Number Offset (10 by MikeBisho=
p, nibanks, huitema, mikkelfj)
    https://github.com/quicwg/base-drafts/pull/1307 =

  - #1298 Fix build: remove "numbered" attribute from Acknowledgements sect=
ion (5 by dtikhonov, afrind, MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1298 =

  - #1299 Makefile: add target to generate tags for I-D sections (5 by dtik=
honov, MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1299 =

  - #1263 Avoid failure from spoofed/delayed PATH_RESPONSE (3 by bemasc, ma=
rtinduke, ianswett)
    https://github.com/quicwg/base-drafts/pull/1263 [-transport] [design] =

  - #1301 make payload length 0 special (3 by kazuho, mikkelfj, MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1301 =

  - #1303 Remove term "application-owned streams" (3 by LPardue, MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1303 =

  - #1291 Changelog for -11 (3 by LPardue, MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1291 =

  - #1300 QUIC-TRANSPORT: Add missing anchor to Packet Number Gap section (=
2 by dtikhonov, MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1300 =

  - #1251 Server's preferred address (1 by MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1251 [-transport] =

  - #1294 Swap payload length (1 by martinthomson)
    https://github.com/quicwg/base-drafts/pull/1294 =

  - #1302 Generate tags file for explicit and implicit anchors in the draft=
s (1 by dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1302 =

  - #1304 Move Retry to QUIC Layer (1 by nibanks)
    https://github.com/quicwg/base-drafts/pull/1304 =


  3 pull requests merged:
  - Remove awkward sentence
    https://github.com/quicwg/base-drafts/pull/1313 =

  - Changelog for -11
    https://github.com/quicwg/base-drafts/pull/1291 =

  - Swap payload length
    https://github.com/quicwg/base-drafts/pull/1294 =



Repositories tracked by this digest:
-----------------------------------
* https://github.com/quicwg/base-drafts

--===============8905050248672553457==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable





Weekly github digest (QUIC Working Group Specifications)





Sunday April 22, 2018



Events without label "editorial"



Issues



quicwg/base-drafts (+5/-2/=F0=9F=92=AC8)

  
5 issues created:

  

  
5 issues received 8 new comments:

  

  
2 issues closed:

  




Pull requests


quicwg/base-drafts (+12/-3/=F0=9F=92=AC66)

  
12 pull requests submitted:

  

  
14 pull requests received 66 new comments:

  

  
3 pull requests merged:

  



Repositories tracked by this digest:





--===============8905050248672553457==--


From nobody Mon Apr 23 10:55:13 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0E312D889 for ; Mon, 23 Apr 2018 10:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvfzrHMG5ip8 for ; Mon, 23 Apr 2018 10:55:10 -0700 (PDT)
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (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 EFE64126BFD for ; Mon, 23 Apr 2018 10:55:09 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Apr 2018 10:55:09 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.49,319,1520924400"; d="scan'208";a="45429363"
Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by orsmga003.jf.intel.com with ESMTP; 23 Apr 2018 10:55:09 -0700
Received: from orsmsx116.amr.corp.intel.com (10.22.240.14) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 23 Apr 2018 10:55:08 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.154]) by ORSMSX116.amr.corp.intel.com ([169.254.7.150]) with mapi id 14.03.0319.002; Mon, 23 Apr 2018 10:55:08 -0700
From: "Deval, Manasi" 
To: Christian Huitema , Mark Nottingham 
CC: "quic@ietf.org" 
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GXj7dI5SDELEadnY2hsvgWB6Pw3KMAgAC4uwCAAARbAIAAG5CAgAAFCQCAAACJgIAAEVkAgACR+ICAB09lAIAFXyMAgAVK+oCAAJlSAIABxdSAgACOHID//40xQA==
Date: Mon, 23 Apr 2018 17:55:06 +0000
Message-ID: <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.0.0.116
dlp-reaction: no-action
x-originating-ip: [10.22.254.140]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Apr 2018 17:55:12 -0000

SGkgQWxsLA0KDQpJIGhhZCBicm91Z2h0IHVwIHRoZSBpc3N1ZSB3aXRoIFBORSBzZXZlcmFsIHdl
ZWtzIGFnbyBhcyBhIGJhcnJpZXIgdG8gaGFyZHdhcmUgb2ZmbG9hZC4gQWZ0ZXIgZnVydGhlciBy
ZXZpZXcsIGl0IGxvb2tzIGxpa2UgYSBoYXJkd2FyZSBvZmZsb2FkIGNhbiBpbXBsZW1lbnQgdGhl
IFBORSBhdCBhIHNtYWxsIGNvc3QuIA0KDQpUaGUgaW1wbGVtZW50YXRpb24gY2FuIG1vZGlmeSBj
dXJyZW50IEhXIGNyeXB0byBhY2NlbGVyYXRvcnMgdG8gc3VwcG9ydCBlbmNyeXB0aW5nIGEgYnVm
ZmVyIGluIHRoZSBmaXJzdCBwYXNzIGFuZCB0aGVuIGVuY3J5cHRpbmcgcGFja2V0IG51bWJlciBp
biB0aGUgMm5kIHBhc3MgYXMgYWxyZWFkeSBkaXNjdXNzZWQgb24gdGhpcyB0aHJlYWQuIFRoZSBl
eGFjdCByZXF1aXJlbWVudCAoaGVhZGVyIGNoZWNrc3VtLCBwYWNrZXQgbGVuZ3RoIGVuY29kaW5n
KSBpcyBzdGlsbCBpbiBmbHV4IHNvIHRoZXJlIG1heSBiZSBzb21lIHNtYWxsIHZhcmlhdGlvbnMg
ZGVwZW5kaW5nIG9uIHRoZSBhY2NlbGVyYXRvciBhbmQgZmluYWwgYWxnb3JpdGhtIGNob3NlbiBm
b3IgUE5FLiBGdXR1cmUgb2ZmbG9hZCBkZXNpZ25zIGNhbiBkbyBtb3JlIHRvIGZ1cnRoZXIgcmVk
dWNlIHRoZSBvdmVyaGVhZC4NCg0KVGhpcyByZS1vcGVucyB0aGUgaXNzdWUgb2YgY3J5cHRvIG9m
ZmxvYWQgaW4gdGhlIGNvbnRleHQgb2Ygb3RoZXIgb2ZmbG9hZHMuIFRoZXJlIGlzIGFub3RoZXIg
dGhyZWFkIHRhbGtpbmcgYWJvdXQgdGhlIG9mZmxvYWQgaW4gY29udGV4dCBvZiBzZWdtZW50YXRp
b24uIEknbGwgcmVzcG9uZCB0byB0aGF0IHRocmVhZCBzZXBhcmF0ZWx5Lg0KDQpUaGFua3MsDQpN
YW5hc2kNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRv
OnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGlhbiBIdWl0ZW1hDQpT
ZW50OiBXZWRuZXNkYXksIEFwcmlsIDE4LCAyMDE4IDk6MzggQU0NClRvOiBNYXJrIE5vdHRpbmdo
YW0gPG1ub3RAbW5vdC5uZXQ+DQpDYzogcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IEdldHRp
bmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQoNCg0KT24gNC8x
OC8yMDE4IDE6MDkgQU0sIE1hcmsgTm90dGluZ2hhbSB3cm90ZToNCj4gVGhhbmtzIENocmlzdGlh
bjsgdGhhdCdzIGV4dHJlbWVseSBoZWxwZnVsIChhbmQgY29uc2lkZXJpbmcgdGhhdCBJIHdhcyBh
Ym91dCB0byBlbWJhcmsgb24gdGhlIHNhbWUgdGFzaywgYnV0IGRvIGEgbXVjaCB3b3JzZSBqb2Is
IEknbSBlc3BlY2lhbGx5IGFwcHJlY2lhdGl2ZSkuDQo+DQo+IEV2ZXJ5b25lIHBsZWFzZSBoYXZl
IGEgcmVhZCBhbmQgZGlyZWN0IHlvdXIgY29tbWVudHMgYmFjayBoZXJlLg0KPg0KPiBPbmUgYXNw
ZWN0IHRoYXQgc3RpbGwgaGFzbid0IGJlZW4gbWFkZSBjbGVhciBBRkFJQ1QgLS0geW91IHNheToN
Cj4NCj4gIiIiVGhlIHByb2Nlc3MgcmVxdWlyZXMgdHdvIHBhc3NlcywgZmV0Y2hpbmcgc29tZSBv
dXRwdXQgb2YgdGhlIGVuY3J5cHRpb24gdG8gc2VlZCB0aGUgUE4gZW5jcnlwdGlvbi4gVGhpcyBp
cyBwcm9ibGVtYXRpYyBmb3IgaGFyZHdhcmUgaW1wbGVtZW50YXRpb25zIHRoYXQgdHlwaWNhbGx5
IGRvbid0IGJ1ZmZlciB0aGUgb3V0cHV0IGZvciBmdXJ0aGVyIGFjY2Vzcy4iIiINCj4NCj4gLi4u
LiBhbmQgdGhlbiBsYXRlcjoNCj4NCj4gIiIiU2luZ2xlIHBhc3MsIHRodXMgbW9zdGx5IGltcGxl
bWVudGFibGUgaW4gaGFyZHdhcmUgaWYgd2UgYXNzdW1lIHRoYXQgdGhlIFBOIGVuY3J5cHRpb24v
ZGVjcnlwdGlvbiBjYW4gYmUgZG9uZSBpbiBzb2Z0d2FyZS4iIiINCj4NCj4gSGF2aW5nIGEgYml0
IG1vcmUgY29udGV4dCBhYm91dCB0aGUgaGFyZHdhcmUgaW1wbGVtZW50YXRpb24gbGltaXRhdGlv
bnMgaGVyZSB3b3VsZCBiZSBleHRyZW1lbHkgaGVscGZ1bC4gU3BlY2lmaWNhbGx5LCBpcyAicHJv
YmxlbWF0aWMiIG9uZSBvZjoNCj4NCj4gKiAiTW9yZSBkaWZmaWN1bHQgZm9yIGV4aXN0aW5nIGhh
cmR3YXJlIChlLmcuLCB3aXRob3V0IGZpcm13YXJlIHVwZGF0ZXMsIGV0Yy4pIg0KPiAqICJJbXBv
c3NpYmxlIGZvciBleGlzdGluZyBoYXJkd2FyZSwgYnV0IHBvc3NpYmxlIGZvciBiZXNwb2tlIGhh
cmR3YXJlIg0KPiAqICJJbXBvc3NpYmxlIGluIGFueSBoYXJkd2FyZSINCj4gKiBQcm9oaWJpdGl2
ZWx5IGV4cGVuc2l2ZSBmb3IgY3VycmVudC9mdXR1cmUgaGFyZHdhcmUNCj4gKiBTb21ldGhpbmcg
ZWxzZT8NCg0KSSB0cmllZCB0byBleHByZXNzIHRoZSBpc3N1ZSBpbiBteSBvd24gd29yZHMsIGJh
c2VkIG9uIGRpc2N1c3Npb25zIGluIHRoaXMgbGlzdC4gQnV0IGFzIEkgc2FpZCwgdGhpcyBpcyBh
IFdpa2kuIFBlb3BsZSB3aXRoIG1vcmUgaGFuZHMtb24gZXhwZXJpZW5jZSBvbiBoYXJkd2FyZSBh
Y2NlbGVyYXRpb24gd291bGQgYmUgd2VsY29tZSB0byBhZGQgYSBzbWFsbCBzZWN0aW9uIGRlc2Ny
aWJpbmcgdGhlIGlzc3VlIHdpdGggaGFyZHdhcmUgaW1wbGVtZW50YXRpb25zLg0KDQotLSBDaHJp
c3RpYW4gSHVpdGVtYQ0KDQo=


From nobody Mon Apr 23 11:19:05 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6D612DA05 for ; Mon, 23 Apr 2018 11:18:57 -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 RCmgNPmszGZv for ; Mon, 23 Apr 2018 11:18:54 -0700 (PDT)
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (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 DBFA5126C0F for ; Mon, 23 Apr 2018 11:18:53 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Apr 2018 11:18:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.49,319,1520924400"; d="scan'208,217"; a="48451181"
Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by fmsmga004.fm.intel.com with ESMTP; 23 Apr 2018 11:18:52 -0700
Received: from orsmsx114.amr.corp.intel.com (10.22.240.10) by ORSMSX110.amr.corp.intel.com (10.22.240.8) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 23 Apr 2018 11:18:52 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.154]) by ORSMSX114.amr.corp.intel.com ([169.254.8.92]) with mapi id 14.03.0319.002; Mon, 23 Apr 2018 11:18:50 -0700
From: "Deval, Manasi" 
To: Ian Swett , Mike Bishop 
CC: Praveen Balasubramanian , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "IETF QUIC WG" 
Subject: RE: Impact of hardware offloads on network stack performance
Thread-Topic: Impact of hardware offloads on network stack performance
Thread-Index: AdPMUbL7T8nZAW2ySiO289IPTC0ttgAPUYUAADUrUQAACLVdgAAFkLMAACFByIAAAJ6MgANCFysg
Date: Mon, 23 Apr 2018 18:18:49 +0000
Message-ID: <1F436ED13A22A246A59CA374CBC543998B60C7AD@ORSMSX111.amr.corp.intel.com>
References:       
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.0.0.116
dlp-reaction: no-action
x-originating-ip: [10.22.254.140]
Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B60C7ADORSMSX111amrcor_"
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Apr 2018 18:19:00 -0000

--_000_1F436ED13A22A246A59CA374CBC543998B60C7ADORSMSX111amrcor_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SWYgd2UgZG8gVFNPIC8gTFNPIHdpdGggUVVJQywgdGhlIGluaXRpYWwgc2VnbWVudCBwcm92aWRl
ZCBjYW4gbG9vayBsaWtlIOKAkw0KTUFDIOKAkyBJUCDigJMgVURQIOKAkyBRVUlDIENsZWFyIOKA
kyBRVUlDIGVuY3J5cHRlZCBoZWFkZXIgKFBOPXgpIOKAkyBRVUlDIEVuY3J5cHRlZCBwYXlsb2Fk
Lg0KDQoNCklmIHdlIGp1c3QgdXNlIHRoZSBzdGFja+KAmXMgdWRwIHNlZ21lbnRhdGlvbiAodXNp
bmcgdGhlIHBhdGNoIC0gaHR0cHM6Ly9tYXJjLmluZm8vP2w9bGludXgtbmV0ZGV2Jm09MTUyMzk5
NTMwNjAzOTkyJnc9MiksIHRoZSBvdXRjb21lIG9mIFFVSUMgcGFja2V0cyBvbiB0aGUgd2lyZSB3
b3VsZCBiZToNCk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJQyBlbmNy
eXB0ZWQgcGFydCAoUE49eCwgcGFydGlhbCBzZWdtZW50IDEpDQpNQUMg4oCTIElQIOKAkyBVRFAg
4oCTIFFVSUMgZW5jcnlwdGVkIHBhcnQgKHBhcnRpYWwgc2VnbWVudCAyKQ0KTUFDIOKAkyBJUCDi
gJMgVURQIOKAkyBRVUlDIGVuY3J5cHRlZCBwYXJ0IChwYXJ0aWFsIHNlZ21lbnQgMykNCuKApg0K
DQpQdXR0aW5nIHRoZXNlIGJhY2sgdG9nZXRoZXIgaW4gYSBzdGFjayAvIGhhcmR3YXJlIGxvb2tz
IGxpa2UgYSBwYWluZnVsIGFuZCBwb3RlbnRpYWxseSBub24tZGV0ZXJtaW5pc3RpYyBhY3Rpdml0
eS4NCg0KDQpJdCB3b3VsZCBiZSBlYXNpZXIgdG8gZG8gYSBuYXRpdmUgUVVJQyBvZmZsb2FkLCB3
aGVyZSB0aGUgcGFja2V0IG9uIHdpcmUgY2FuIGJlIGlkZW50aWZpZWQgYnkgUVVJQyBDaUQgYW5k
IGFwcHJvcHJpYXRlIHBhY2tldCBudW1iZXIuIFRoZXJlZm9yZSwgb3JpZ2luYWwgcGFja2V0IGxv
b2tzIGxpa2UgLSBNQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMgQ2xlYXIg4oCTIFFVSUMgZW5j
cnlwdGVkIGhlYWRlciAoUE49eCkg4oCTIFFVSUMgRW5jcnlwdGVkIHBheWxvYWQuDQpJZiB3ZSBq
dXN0IGNyZWF0ZSBhbm90aGVyIHZlcnNpb24gb2Ygc2VnbWVudGF0aW9uIGNhbGxlZCBRVUlDIHNl
Z21lbnRhdGlvbiwgdGhlIG91dGNvbWUgb2YgcGFja2V0cyBvbiB0aGUgd2lyZSB3b3VsZCBiZToN
Ck1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJQyBlbmNyeXB0ZWQgcGFy
dCAoUE49eCwgcGFydGlhbCBzZWdtZW50IDEpDQpNQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMg
Q2xlYXIg4oCTIFFVSUMgZW5jcnlwdGVkIHBhcnQgKFBOPXgrMSwgcGFydGlhbCBzZWdtZW50IDIp
DQpNQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMgQ2xlYXIg4oCTIFFVSUMgZW5jcnlwdGVkIHBh
cnQgKFBOPXgrMiwgcGFydGlhbCBzZWdtZW50IDMpDQrigKYNCklmIHRoaXMgc2V0IG9mIHNlZ21l
bnRzIHdlcmUgdG8gYmUgcmUtYXNzZW1ibGVkLCB0aGUgYWJpbGl0eSB0byBpZGVudGlmeSBDaUQg
YW5kIFBOIHdvdWxkIHNpbXBsaWZ5IHRoaXMgdGFzay4gSSB0aGluayB0aGlzIGlzIGEgc2ltcGxl
ciBpbXBsZW1lbnRhdGlvbi4gRG8gb3RoZXJzIHNlZSBhbiBpc3N1ZSB3aXRoIHRoaXM/DQoNClRo
YW5rcywNCk1hbmFzaQ0KDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBJYW4gU3dldHQNClNlbnQ6IEZyaWRheSwgQXByaWwgMDYsIDIwMTgg
MTo1NSBQTQ0KVG86IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZT4NCkNjOiBQcmF2
ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT47IE1pa2tlbCBGYWhuw7hl
IErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRm
Lm9yZz4NClN1YmplY3Q6IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29y
ayBzdGFjayBwZXJmb3JtYW5jZQ0KDQpQTkUgZG9lc24ndCBwcmVjbHVkZSBVRFAgTFJPIG9yIHBh
Y2luZyBvZmZsb2FkLg0KDQpIb3dldmVyLCBpbiBhIGhpZ2hseSBvcHRpbWl6ZWQgc3RhY2soaWU6
IFRoZSBEaXNrfENyeXB0fE5ldCBwYXBlciBmcm9tIFNJR0NPTU0gMjAxNykgbm90IHRvdWNoaW5n
KGllOiBicmluZ2luZyBpbnRvIG1lbW9yeSBvciBjYWNoZSkgdGhlIGNvbnRlbnQgdG8gYmUgc2Vu
dCB1bnRpbCB0aGUgbGFzdCBwb3NzaWJsZSBtb21lbnQgaXMgY3JpdGljYWwuICBQTkUgbGlrZWx5
IG1lYW5zIHRvdWNoaW5nIHRoYXQgY29udGVudCBtdWNoIGVhcmxpZXIuDQoNCkJ1dCBwZXJzb25h
bGx5IEkgY29uc2lkZXIgdGhlIGFjdHVhbCBjcnlwdG8gd2UncmUgdGFsa2luZyBhYm91dCgyIEFF
UyBpbnN0cnVjdGlvbnM/KSBhZGRpbmcgYmFzaWNhbGx5IGZyZWUuDQoNCk9uIEZyaSwgQXByIDYs
IDIwMTggYXQgNDozNyBQTSBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRv
Om1iaXNob3BAZXZlcXVlZm91LmJlPj4gd3JvdGU6DQpUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0
aW9uLiAgSSBndWVzcyB3aGF0IEnigJltIHJlYWxseSBnZXR0aW5nIGRvd24gdG8gaXMgaG93IGRv
IHdlIHF1YW50aWZ5IHRoZSBhY3R1YWwgY29zdCBvZiBQTkU/ICBBcmUgd2Ugc3Vic3RhbnRpYWxs
eSBpbmNyZWFzaW5nIHRoZSBjcnlwdG8gY29zdHM/ICBJZiBJYW4gaXMgc2F5aW5nIHRoYXQgY3J5
cHRvIGlzIGNvbXBhcmF0aXZlbHkgY2hlYXAgYW5kIHRoZSBjb3N0IGlzIHRoYXQgaXTigJlzIGhh
cmRlciB0byBvZmZsb2FkIHNvbWV0aGluZyB0aGF04oCZcyBjb21wYXJhdGl2ZWx5IGNoZWFwLCB3
aGF0IGhhdmUgd2UgbG9zdD8gIEnigJlkIHRoaW5rIHdlIHdhbnQgdG8gb2ZmbG9hZCB0aGUgbW9z
dCBpbnRlbnNpdmUgcGllY2Ugd2UgY2FuLCBhbmQgaXQgc2VlbXMgbGlrZSB3ZeKAmXJlIHRhbGtp
bmcgYWJvdXQgY3J5cHRvIG9mZmxvYWRzLi4uLiAgT3IgYXJlIHdlIHNheWluZyBpbnN0ZWFkIHRo
YXQgdGhlIGNyeXB0byBtYWtlcyBpdCBoYXJkZXIgdG8gb2ZmbG9hZCBvdGhlciB0aGluZ3MgaW4g
dGhlIGZ1dHVyZSwgbGlrZSBhIFFVSUMgZXF1aXZhbGVudCB0byBMUk8vTFNPPw0KDQpGcm9tOiBN
aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86bWlra2VsZmpAZ21haWwuY29tPG1haWx0
bzptaWtrZWxmakBnbWFpbC5jb20+XQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDUsIDIwMTggOTo0
NSBQTQ0KVG86IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRA
Z29vZ2xlLmNvbT4+OyBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1i
aXNob3BAZXZlcXVlZm91LmJlPj4NCkNjOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJA
bWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbT4+OyBJRVRGIFFVSUMgV0cg
PHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IEltcGFj
dCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlDQoNClRv
IGJlIGNsZWFyIC0gSSBkb27igJl0IHRoaW5rIGNyeXB0byBpcyBvdmVyc2hhZG93aW5nIG90aGVy
IGlzc3VlcyBhcyBNaWtlIHJlYWQgbXkgcG9zdC4gSXQgY2VydGFpbmx5IGNvbWVzIGF0IGEgY29z
dCwgYnV0IGVpdGhlciBtdWx0aXBsZSBjb3JlcyBvciBjby1wcm9jZXNzb3JzIHdpbGwgZGVhbCB3
aXRoIHRoaXMuIDEwMDBucyBpcyAxMEdicHMgY3J5cHRvIHNwZWVkIG9uIG9uZSBjb3JlIGFuZCBp
dCBpcyBoaWdseSBwYXJhbGxlbGlzYWJsZSBhbmQgY2FjaGUgZnJpZW5kbHkuDQoNCkJ1dCBpZiB5
b3UgaGF2ZSB0byBkcmlwIHlvdXIgcGFja2V0cyB0aHJvdWdoIGEgdHJhZGl0aW9uYWwgc2VuZCBp
bnRlcmZhY2UgdGhhdCBpcyBjb3B5aW5nLCBidWZmZXJpbmcgb3IgYmxvY2tpbmcsIGFuZCBjZXJ0
YWlubHkgc3luY+KAmWluZyB3aXRoIHRoZSBrZXJuZWwgLSBpdCBpcyBnb2luZyB0byBiZSB0b3Vn
aC4NCg0KRm9yIHJlY2VpdmUgeW91IHJpc2sgaGlnaCBsYXRlbmN5IG9yIHRvcCBtdWNoIHNjaGVk
dWxpbmcgaW4gcmVjZWl2ZSBidWZmZXJzLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KRnJvbTogSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzppYW5zd2V0
dEBnb29nbGUuY29tPj4NClNlbnQ6IEZyaWRheSwgQXByaWwgNiwgMjAxOCA0OjA2OjAxIEFNDQpU
bzogTWlrZSBCaXNob3ANCkNjOiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuOyBQcmF2ZWVuIEJh
bGFzdWJyYW1hbmlhbjsgSUVURiBRVUlDIFdHDQpTdWJqZWN0OiBSZTogSW1wYWN0IG9mIGhhcmR3
YXJlIG9mZmxvYWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVyZm9ybWFuY2UNCg0KDQpPbiBUaHUsIEFw
ciA1LCAyMDE4IGF0IDU6NTcgUE0gTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1h
aWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+IHdyb3RlOg0KVGhhdOKAmXMgaW50ZXJlc3Rpbmcg
ZGF0YSwgUHJhdmVlbiDigJMgdGhhbmtzLiAgVGhlcmUgaXMgb25lIGNhdmVhdCB0aGVyZSwgd2hp
Y2ggaXMgdGhhdCAoSUlVQywgb24gY3VycmVudCBoYXJkd2FyZSkgeW91IGNhbuKAmXQgZG8gcGFj
a2V0IHBhY2luZyB3aXRoIExTTywgYW5kIHNvIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBldmVu
IGZvciBUQ1AgbWFueSBwcm92aWRlcnMgZGlzYWJsZSB0aGlzIGluIHB1cnN1aXQgb2YgYmV0dGVy
IGVncmVzcyBtYW5hZ2VtZW50LiAgU28gd2hhdCB3ZeKAmXJlIHJlYWxseSBzYXlpbmcgaXMgdGhh
dDoNCg0KICAqICAgT24gY3VycmVudCBoYXJkd2FyZSBhbmQgT1Mgc2V0dXBzLCBVRFAgcnVucyBs
ZXNzIHRoYW4gaGFsZiBhcyBtdWNoIHRocm91Z2hwdXQgYXMgVENQOyB0aGF0IG5lZWRzIHNvbWUg
b3B0aW1pemF0aW9uLCBhcyB3ZeKAmXZlIGFscmVhZHkgZGlzY3Vzc2VkDQogICogICBUQ1Agd2ls
bCBkcmFtYXRpY2FsbHkgZ2FpbiBwZXJmb3JtYW5jZSBvbmNlIGhhcmR3YXJlIG9mZmxvYWQgY2F0
Y2hlcyB1cCBhbmQgYWxsb3dzIHBhY2VkIExTTyDwn5iKDQoNCkhvd2V2ZXIsIGFzIE1pa2tlbCBw
b2ludHMgb3V0LCB0aGUgY3J5cHRvIGNvc3RzIGFyZSBsaWtlbHkgdG8gb3ZlcndoZWxtIHRoZSBP
UyB0aHJvdWdocHV0IC8gc2NoZWR1bGluZyBpc3N1ZXMgaW4gcmVhbCBkZXBsb3ltZW50cy4gIFNv
IEkgdGhpbmsgdGhlIG90aGVyIHJlbGV2YW50IHBpZWNlIHRvIHVuZGVyc3RhbmRpbmcgdGhlIGNv
c3QgaGVyZSBpcyB0aGlzOg0KDQpJIGhhdmUgYSBmZXcgY2FzZXMoYm90aCBjbGllbnQgYW5kIHNl
cnZlcikgd2hlcmUgbXkgVURQIHNlbmQgY29zdHMgYXJlIG1vcmUgdGhhbiAzMCUoaW4gc29tZSBj
YXNlcyA1MCUpIG9mIENQVSBjb25zdW1wdGlvbiwgYW5kIGNyeXB0byBpcyBsZXNzIHRoYW4gMTAl
LiAgU28gY3VycmVudGx5LCBJIGFzc3VtZSBjcnlwdG8gaXMgY2hlYXAoZXNwZWNpYWxseSBBRVMt
R0NNIHdoZW4gaGFyZHdhcmUgYWNjZWxlcmF0aW9uIGlzIGF2YWlsYWJsZSkgYW5kIGVncmVzcyBp
cyBleHBlbnNpdmUuICBVRFAgaW5ncmVzIGlzIG5vdCB0aGF0IGV4cGVuc2l2ZSwgYnV0IGNvdWxk
IHVzZSBhIGJpdCBvZiBvcHRpbWl6YXRpb24gYXMgd2VsbC4NCg0KVGhlIG9ubHkgJ2ZhbmN5JyB0
aGluZyBvdXIgY3VycmVudCBjb2RlIGlzIGRvaW5nIGZvciBjcnlwdG8gaXMgZW5jcnlwdGluZyBp
biBwbGFjZSwgd2hpY2ggd2FzIGEgfjIlIHdpbi4gIE5pY2UsIGJ1dCBub3QgdHJhbnNmb3JtYXRp
dmUuICBTZWUgRW5jcnlwdEluUGxhY2U8aHR0cHM6Ly9jcy5jaHJvbWl1bS5vcmcvY2hyb21pdW0v
c3JjL25ldC9xdWljL2NvcmUvcXVpY19mcmFtZXIuY2M/c3E9cGFja2FnZTpjaHJvbWl1bSZsPTE4
OTM+DQoNCkkgaGF2ZW4ndCBkb25lIG11Y2ggd29yayBiZW5jaG1hcmtpbmcgV2luZG93cywgc28g
cG9zc2libHkgdGhlIFdpbmRvd3MgVURQIHN0YWNrIGlzIHJlYWxseSBmYXN0LCBhbmQgc28gY3J5
cHRvIHNlZW1zIHJlYWxseSBzbG93IGluIGNvbXBhcmlzb24/DQoNCg0KICAqICAgV2hhdCBpcyB0
aGUgdGhyb3VnaHB1dCBhbmQgcmVsYXRpdmUgY29zdCBvZiBUTFMvVENQIHZlcnN1cyBRVUlDIChp
LmUuIGhvdyBtdWNoIGFyZSB0aGUgc21hbGxlciB1bml0cyBvZiBlbmNyeXB0aW9uIGh1cnRpbmcg
dXMgdmVyc3VzLCBzYXksIDE2S0IgVExTIHJlY29yZHMpPw0KDQogICAgICogICBUTFMgaW1wbGVt
ZW50YXRpb25zIGFscmVhZHkgdmFyeSBoZXJlOiAgU29tZSBpbXBsZW1lbnRhdGlvbnMgY2hvb3Nl
IGxhcmdlIHJlY29yZCBzaXplcywgc29tZSB2YXJ5IHJlY29yZCBzaXplcyB0byByZWR1Y2UgZGVs
YXkgLyBIb0xCLCBzbyB0aGlzIHByb2JhYmx5IGlzbuKAmXQgYSBzaW5nbGUgbnVtYmVyLg0KDQog
ICogICBIb3cgbXVjaCBhZGRpdGlvbmFsIGxvYWQgZG9lcyBQTkUgYWRkIHRvIHRoaXMgZGlmZmVy
ZW5jZT8NCiAgKiAgIFRvIHdoYXQgZXh0ZW50IHdvdWxkIFBORSBtYWtlIGZ1dHVyZSBjcnlwdG8g
b2ZmbG9hZHMgaW1wb3NzaWJsZSB2ZXJzdXMgcmVxdWlyZXMgbW9yZSBSJkQgdG8gZGV2ZWxvcD8N
Cg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1i
b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4N
ClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxOCAxOjM0IFBNDQpUbzogUHJhdmVlbiBCYWxh
c3VicmFtYW5pYW4gPHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86
NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRm
Lm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogSW1wYWN0IG9mIGhhcmR3
YXJlIG9mZmxvYWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVyZm9ybWFuY2UNCg0KVGhhbmtzIGZvciBz
aGFyaW5nIHRoZXNlIG51bWJlcnMuDQoNCk15IGd1ZXNzIGlzIHRoYXQgdGhlc2Ugb2ZmbG9hZHMg
ZGVhbCB3aXRoIGtlcm5lbCBzY2hlZHVsaW5nLCBtZW1vcnkgY2FjaGUgaXNzdWVzLCBhbmQgaW50
ZXJydXB0IHNjaGVkdWxpbmcuDQoNCkl0IHByb2JhYmx5IGhhcyB2ZXJ5IGxpdHRsZSB0byBkbyB3
aXRoIGNyeXB0bywgVENQIGhlYWRlcnMsIGFuZCBhbnkgb3RoZXIgY3B1IHNlbnNpdGl2ZSBwcm9j
ZXNzaW5nLg0KDQpUaGlzIGlzIHdoZXJlIG5ldG1hcCBlbnRlcnM6IHlvdSBjYW4gdHJhbnNwYXJl
bnRseSBmZWVkIHRoZSBkYXRhIGFzIGl0IGJlY29tZXMgYXZhaWxhYmxlIHdpdGggdmVyeSBsaXR0
bGUgc3luYyB3b3JrIGFuZCB5b3UgY2FuIGFsc28gZWZmaWNpZW50bHkgcGlwZWxpbmUgc28geW91
IHBhc3MgZGF0YSB0byBkZWNyeXB0b3IsIHRoZW4gdG8gYXBwLCB3aXRoIGFzIGxpdHRsZSBidXMg
dHJhZmZpYyBhcyBwb3NzaWJsZS4gTm8gbmVlZCB0byBjb3B5IGRhdGEgb3Igc3luY2hyb25pemUg
a2VybmVsIHNwYWNlLg0KDQpGb3IgMUsgcGFja2V0cyB5b3Ugd291bGQgdXNlIGFib3V0IDEwMDBu
cyAoMyBjeWNsZXMvYnl0ZSkgb24gY3J5cHRvIGFuZCB0aGlzIHdvdWxkIGhhcHBlbiBpbiBMMSBj
YWNoZS4gSXQgd291bGQgb2YgY291cnNlIGNvbnN1bWUgYSBjb3JlIHdoaWNoIGEgY3J5cHRvIG9m
ZmxvYWQgd291bGQgbm90LCBidXQgdGhhdCBjYW4gYmUgZGViYXRlZCBiZWNhdXNlIHdpdGggMTgg
Y29yZSBzeXN0ZW1zLCB5b3VyIHByb2JsZW0gaXMgbWVtb3J5IGFuZCBuZXR3b3JrIG1vcmUgdGhh
biBDUFUuDQoNCk15IGNvbmNlcm4gd2l0aCBQTkUgaXMgZm9yIHNtYWxsIHBhY2tldHMgYW5kIGxv
dyBsYXRlbmN5IHdoZXJlDQoxKSBhbiBlc3RpbWF0ZWQgMjRucyBmb3IgUE4gZW5jcnlwdGlvbiBh
bmQgZGVjcnlwdGlvbiBiZWNvbWVzIG1lYXN1cmFibGUgaWYgeW91ciBuZXR3b3JrIGlzIGZhc3Qg
ZW5vdWdoLg0KMikgYW55IGRhbWFnZSB0byB0aGUgcGFja2V0IGJ1ZmZlciBjYXVzZSBhbGwgc29y
dHMgb2YgbWVtb3J5IGFuZCBjcHUgYnVzIHRyYWZmaWMgaXNzdWVzLg0KDQoxKSBpcyBhbm5veWlu
Zy4gMikgaXMgYmFkLCBjb21wbGV0ZWx5IGF2b2lkYWJsZSBidXQgbm90IGFzIFBSIDEwNzkgaXMg
Zm9ybXVsYXRlZCBjdXJyZW50bHkuDQoNCjIpIGlzIGFsc28gbGlrZWx5IGJhZCBmb3IgaGFyZHdh
cmUgb2ZmbG9hZCB1bml0cyBhcyB3ZWxsLg0KDQpBcyB0byBTUlYtSU8gLSBJ4oCZbSBub3QgZmFt
aWxpYXIgd2l0aCBpdCwgYnV0IG9idmlvdXNseSB0aGVyZSBpcyBzb21lIElPIGFic3RyYWN0aW9u
IGxheWVyIC0gdGhlIHF1ZXN0aW9uIGlzIGhvdyB5b3UgbWFrZSBpdCBhY2Nlc3NpYmxlIHRvIGFw
cHMgYXMgb3Bwb3NlZCB0byBkZXZpY2UgZHJpdmVycyB0aGF0IGRvZXMgbm9yIHdvcmsgd2l0aCB5
b3UgUVVJQyBjdXN0b20gc3RhY2ssIGFuZCBuZXRtYXAgaXMgb25lIG9wdGlvbiBoZXJlLg0KDQpL
aW5kIFJlZ2FyZHMsDQpNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuDQoNCg0KT24gNCBBcHJpbCAy
MDE4IGF0IDIyLjE1LjUyLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAocHJhdmI9NDBtaWNyb3Nv
ZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMu
aWV0Zi5vcmc+KSB3cm90ZToNClNvbWUgY29tcGFyYXRpdmUgbnVtYmVycyBmcm9tIGFuIG91dCBv
ZiBib3ggZGVmYXVsdCBzZXR0aW5ncyBXaW5kb3dzIFNlcnZlciAyMDE2IChyZWxlYXNlZCB2ZXJz
aW9uKSBmb3IgYSBzaW5nbGUgY29ubmVjdGlvbiB3aXRoIGEgbWljcm9iZW5jaG1hcmsgdG9vbDoN
Cg0KT2ZmbG9hZHMgZW5hYmxlZA0KDQpUQ1AgZ2Jwcw0KDQpVRFAgZ2Jwcw0KDQpMU08gKyBMUk8g
KyBjaGVja3N1bQ0KDQoyNA0KDQozLjYNCg0KQ2hlY2tzdW0gb25seQ0KDQo3LjYNCg0KMy42DQoN
Ck5vbmUNCg0KNS42DQoNCjIuMw0KDQoNClRoaXMgaXMgZm9yIGEgZnVsbHkgYm90dGxlbmVja2Vk
IENQVSBjb3JlIC0tIGlmIHlvdSBydW4gbG93ZXIgZGF0YSByYXRlcyB0aGVyZSBpcyBzdGlsbCBh
IHNpZ25pZmljYW50IGRpZmZlcmVuY2UgaW4gQ3ljbGVzL2J5dGUgY29zdC4gU2FtZSBpbmNyZWFz
ZWQgQ1BVIGNvc3QgYXBwbGllcyBmb3IgY2xpZW50IHN5c3RlbXMgZ29pbmcgb3ZlciBoaWdoIGRh
dGEgcmF0ZSBXaWZpIGFuZCBjZWxsdWxhci4NCg0KVGhpcyBpcyB3aXRob3V0IGFueSBjcnlwdG8u
IE9uY2UgeW91IGFkZCBjcnlwdG8gdGhlIG51bWJlcnMgYmVjb21lIG11Y2ggd29yc2Ugd2l0aCBj
cnlwdG8gY29zdCBiZWNvbWluZyBkb21pbmFudC4gQWRkaW5nIGFub3RoZXIgY3J5cHRvIHN0ZXAg
ZnVydGhlciBleGFjZXJiYXRlcyB0aGUgcHJvYmxlbS4gSGVuY2UgY3J5cHRvIG9mZmxvYWQgZ2Fp
bnMgaW4gaW1wb3J0YW5jZSBmb2xsb3dlZCBieSB0aGVzZSBiYXRjaCBvZmZsb2Fkcy4NCg0KSWYg
Zm9sa3MgbmVlZCBhbnkgbW9yZSBudW1iZXJzIEnigJlkIGJlIGhhcHB5IHRvIHByb3ZpZGUgdGhl
bS4NCg0KVGhhbmtzDQoNCg==

--_000_1F436ED13A22A246A59CA374CBC543998B60C7ADORSMSX111amrcor_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6IlNlZ29lIFVJIEVtb2ppIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9
DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6
bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv
SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs
ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29Q
bGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7fQ0KcC5tLTIwMTc3MTQwNDAxMzcxMTYzNDltLTkwMDQ5MTcxNDk0MDU1OTQx
NDNhaXJtYWlsb24sIGxpLm0tMjAxNzcxNDA0MDEzNzExNjM0OW0tOTAwNDkxNzE0OTQwNTU5NDE0
M2Fpcm1haWxvbiwgZGl2Lm0tMjAxNzcxNDA0MDEzNzExNjM0OW0tOTAwNDkxNzE0OTQwNTU5NDE0
M2Fpcm1haWxvbg0KCXttc28tc3R5bGUtbmFtZTptXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bS05MDA0
OTE3MTQ5NDA1NTk0MTQzYWlybWFpbG9uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h
cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl
ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h
biIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt
cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3
RDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hh
ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0
IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy
Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX
b3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxp
c3QtaWQ6NTIxMjg0NjQ5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTU5ODU0MDQ4NDt9DQpA
bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s
ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z
by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u
dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox
LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N
CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K
CW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv
cDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s
O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs
OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3
Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt
c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt
Ym9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEyMDI3NDI0MjQ7DQoJbXNvLWxpc3QtdGVt
cGxhdGUtaWRzOi0xMDc0MTAyNzMyO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt
c3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i
b2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlk
aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt
ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w
aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp
bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA
bGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s
ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250
LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv
bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u
MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9
DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m
b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K
CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxMjQ0Mjk5MTE4
Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjUxODk3NTIyO30NCkBsaXN0IGwyOmxldmVsMQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K
CW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm
b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w
OjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7
fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw0
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i
b2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu
c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2
ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT
eW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDMN
Cgl7bXNvLWxpc3QtaWQ6MTk5MjMyMjQ3MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTMwOTk3
OTU4Njt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxl
dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6
U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz
OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl
bC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0
IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i
b3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd
LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+
DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht
bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2
bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgd2UgZG8gVFNPIC8gTFNP
IHdpdGggUVVJQywgdGhlIGluaXRpYWwgc2VnbWVudCBwcm92aWRlZCBjYW4gbG9vayBsaWtlIOKA
kzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj5NQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMgQ2xlYXIg4oCT
IFFVSUMgZW5jcnlwdGVkIGhlYWRlciAoUE49eCkg4oCTIFFVSUMgRW5jcnlwdGVkIHBheWxvYWQu
DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklmIHdlIGp1c3Qg
dXNlIHRoZSBzdGFja+KAmXMgdWRwIHNlZ21lbnRhdGlvbiAodXNpbmcgdGhlIHBhdGNoIC0NCjwv
c3Bhbj48YSBocmVmPSJodHRwczovL21hcmMuaW5mby8/bD1saW51eC1uZXRkZXYmYW1wO209MTUy
Mzk5NTMwNjAzOTkyJmFtcDt3PTIiPmh0dHBzOi8vbWFyYy5pbmZvLz9sPWxpbnV4LW5ldGRldiZh
bXA7bT0xNTIzOTk1MzA2MDM5OTImYW1wO3c9MjwvYT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3
RCI+KSwgdGhlIG91dGNvbWUgb2YgUVVJQyBwYWNrZXRzIG9uIHRoZSB3aXJlIHdvdWxkIGJlOjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj5NQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMgQ2xlYXIg4oCTIFFV
SUMgZW5jcnlwdGVkIHBhcnQgKFBOPXgsIHBhcnRpYWwgc2VnbWVudCAxKTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj5NQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMgZW5jcnlwdGVkIHBhcnQgKHBhcnRpYWwg
c2VnbWVudCAyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMg
ZW5jcnlwdGVkIHBhcnQgKHBhcnRpYWwgc2VnbWVudCAzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igKY8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlB1dHRpbmcgdGhlc2Ug
YmFjayB0b2dldGhlciBpbiBhIHN0YWNrIC8gaGFyZHdhcmUgbG9va3MgbGlrZSBhIHBhaW5mdWwg
YW5kIHBvdGVudGlhbGx5IG5vbi1kZXRlcm1pbmlzdGljIGFjdGl2aXR5Lg0KPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
SXQgd291bGQgYmUgZWFzaWVyIHRvIGRvIGEgbmF0aXZlIFFVSUMgb2ZmbG9hZCwgd2hlcmUgdGhl
IHBhY2tldCBvbiB3aXJlIGNhbiBiZSBpZGVudGlmaWVkIGJ5IFFVSUMgQ2lEIGFuZCBhcHByb3By
aWF0ZSBwYWNrZXQgbnVtYmVyLjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+DQogVGhlcmVmb3Jl
LCBvcmlnaW5hbCBwYWNrZXQgbG9va3MgbGlrZSAtIE1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJ
QyBDbGVhciDigJMgUVVJQyBlbmNyeXB0ZWQgaGVhZGVyIChQTj14KSDigJMgUVVJQyBFbmNyeXB0
ZWQgcGF5bG9hZC4NCjxvOnA+PC9vOnA+PC9hPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgd2UganVzdCBjcmVhdGUgYW5v
dGhlciB2ZXJzaW9uIG9mIHNlZ21lbnRhdGlvbiBjYWxsZWQgUVVJQyBzZWdtZW50YXRpb24sIHRo
ZSBvdXRjb21lIG9mIHBhY2tldHMgb24gdGhlIHdpcmUgd291bGQgYmU6PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJQyBlbmNyeXB0ZWQg
cGFydCAoUE49eCwgcGFydGlhbCBzZWdtZW50IDEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1BQyDigJMg
SVAg4oCTIFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAoUE49eCYj
NDM7MSwgcGFydGlhbCBzZWdtZW50IDIpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1BQyDigJMgSVAg4oCT
IFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAoUE49eCYjNDM7Miwg
cGFydGlhbCBzZWdtZW50IDMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKApjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij5JZiB0aGlzIHNldCBvZiBzZWdtZW50cyB3ZXJlIHRvIGJlIHJlLWFzc2VtYmxlZCwgdGhlIGFi
aWxpdHkgdG8gaWRlbnRpZnkgQ2lEIGFuZCBQTiB3b3VsZCBzaW1wbGlmeSB0aGlzIHRhc2suIEkg
dGhpbmsgdGhpcyBpcyBhIHNpbXBsZXIgaW1wbGVtZW50YXRpb24uIERvIG90aGVycw0KIHNlZSBh
biBpc3N1ZSB3aXRoIHRoaXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1hbmFzaTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u
IEJlaGFsZiBPZiA8L2I+SWFuIFN3ZXR0PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwg
MDYsIDIwMTggMTo1NSBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0O21iaXNob3BA
ZXZlcXVlZm91LmJlJmd0Ozxicj4NCjxiPkNjOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4g
Jmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7OyBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZs
dDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcm
Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMg
b24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlBORSBkb2Vzbid0IHByZWNsdWRlIFVEUCBMUk8gb3IgcGFjaW5nIG9mZmxvYWQu
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyLCBp
biBhIGhpZ2hseSBvcHRpbWl6ZWQgc3RhY2soaWU6IFRoZSBEaXNrfENyeXB0fE5ldCBwYXBlciBm
cm9tIFNJR0NPTU0gMjAxNykgbm90IHRvdWNoaW5nKGllOiBicmluZ2luZyBpbnRvIG1lbW9yeSBv
ciBjYWNoZSkgdGhlIGNvbnRlbnQgdG8gYmUgc2VudCB1bnRpbCB0aGUgbGFzdCBwb3NzaWJsZSBt
b21lbnQgaXMgY3JpdGljYWwuJm5ic3A7IFBORSBsaWtlbHkgbWVhbnMgdG91Y2hpbmcgdGhhdCBj
b250ZW50DQogbXVjaCBlYXJsaWVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgcGVyc29uYWxseSBJIGNvbnNpZGVyIHRoZSBhY3R1YWwg
Y3J5cHRvIHdlJ3JlIHRhbGtpbmcgYWJvdXQoMiBBRVMgaW5zdHJ1Y3Rpb25zPykgYWRkaW5nIGJh
c2ljYWxseSBmcmVlLiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEFwciA2LCAyMDE4IGF0IDQ6MzcgUE0gTWlr
ZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSI+bWJpc2hv
cEBldmVxdWVmb3UuYmU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs
b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w
cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln
aHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgZm9y
IHRoZSBjbGFyaWZpY2F0aW9uLiZuYnNwOyBJIGd1ZXNzIHdoYXQgSeKAmW0gcmVhbGx5IGdldHRp
bmcgZG93biB0byBpcyBob3cgZG8gd2UgcXVhbnRpZnkgdGhlIGFjdHVhbA0KPGk+Y29zdDwvaT4g
b2YgUE5FPyZuYnNwOyBBcmUgd2Ugc3Vic3RhbnRpYWxseSBpbmNyZWFzaW5nIHRoZSBjcnlwdG8g
Y29zdHM/Jm5ic3A7IElmIElhbiBpcyBzYXlpbmcgdGhhdCBjcnlwdG8gaXMgY29tcGFyYXRpdmVs
eSBjaGVhcCBhbmQgdGhlIGNvc3QgaXMgdGhhdCBpdOKAmXMgaGFyZGVyIHRvIG9mZmxvYWQgc29t
ZXRoaW5nIHRoYXTigJlzIGNvbXBhcmF0aXZlbHkgY2hlYXAsIHdoYXQgaGF2ZSB3ZSBsb3N0PyZu
YnNwOyBJ4oCZZCB0aGluayB3ZSB3YW50IHRvIG9mZmxvYWQgdGhlDQogbW9zdCBpbnRlbnNpdmUg
cGllY2Ugd2UgY2FuLCBhbmQgaXQgc2VlbXMgbGlrZSB3ZeKAmXJlIHRhbGtpbmcgYWJvdXQgY3J5
cHRvIG9mZmxvYWRzLi4uLiZuYnNwOyBPciBhcmUgd2Ugc2F5aW5nIGluc3RlYWQgdGhhdCB0aGUg
Y3J5cHRvIG1ha2VzIGl0IGhhcmRlciB0byBvZmZsb2FkIG90aGVyIHRoaW5ncyBpbiB0aGUgZnV0
dXJlLCBsaWtlIGEgUVVJQyBlcXVpdmFsZW50IHRvIExSTy9MU08/PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n
OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+
IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86bWlra2Vs
ZmpAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9hPl0NCjxi
cj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgNSwgMjAxOCA5OjQ1IFBNPGJyPg0KPGI+
VG86PC9iPiBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29t
IiB0YXJnZXQ9Il9ibGFuayI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT4mZ3Q7OyBNaWtlIEJpc2hv
cCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFu
ayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUHJhdmVlbiBC
YWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIiB0
YXJnZXQ9Il9ibGFuayI+cHJhdmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBJRVRGIFFVSUMgV0cg
Jmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0Bp
ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJbXBhY3Qgb2YgaGFyZHdh
cmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZTxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5Y29tcG9zZS1jb250YWluZXIiPg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UbyBiZSBjbGVhciAt
IEkgZG9u4oCZdCB0aGluayBjcnlwdG8gaXMgb3ZlcnNoYWRvd2luZyBvdGhlciBpc3N1ZXMgYXMg
TWlrZSByZWFkIG15IHBvc3QuIEl0IGNlcnRhaW5seSBjb21lcyBhdCBhIGNvc3QsIGJ1dCBlaXRo
ZXIgbXVsdGlwbGUgY29yZXMgb3IgY28tcHJvY2Vzc29ycyB3aWxsIGRlYWwgd2l0aCB0aGlzLg0K
IDEwMDBucyBpcyAxMEdicHMgY3J5cHRvIHNwZWVkIG9uIG9uZSBjb3JlIGFuZCBpdCBpcyBoaWds
eSBwYXJhbGxlbGlzYWJsZSBhbmQgY2FjaGUgZnJpZW5kbHkuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CdXQgaWYgeW91IGhhdmUgdG8g
ZHJpcCB5b3VyIHBhY2tldHMgdGhyb3VnaCBhIHRyYWRpdGlvbmFsIHNlbmQgaW50ZXJmYWNlIHRo
YXQgaXMgY29weWluZywgYnVmZmVyaW5nIG9yIGJsb2NraW5nLCBhbmQgY2VydGFpbmx5IHN5bmPi
gJlpbmcgd2l0aCB0aGUga2VybmVsIC0gaXQgaXMgZ29pbmcgdG8gYmUgdG91Z2guPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3IgcmVj
ZWl2ZSB5b3UgcmlzayBoaWdoIGxhdGVuY3kgb3IgdG9wIG11Y2ggc2NoZWR1bGluZyBpbiByZWNl
aXZlIGJ1ZmZlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0
LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+
DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTIwMTc3MTQwNDAxMzcxMTYzNDlkaXZScGx5RndkTXNnIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9t
Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gSWFuIFN3ZXR0ICZsdDs8YSBo
cmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0
QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDYsIDIw
MTggNDowNjowMSBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3A8YnI+DQo8Yj5DYzo8L2I+
IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuOyBJRVRG
IFFVSUMgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEltcGFjdCBvZiBoYXJkd2FyZSBvZmZs
b2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlPC9zcGFuPg0KPG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBB
cHIgNSwgMjAxOCBhdCA1OjU3IFBNIE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86bWJp
c2hvcEBldmVxdWVmb3UuYmUiIHRhcmdldD0iX2JsYW5rIj5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwv
YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp
Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5UaGF04oCZcyBpbnRlcmVzdGluZyBkYXRhLCBQcmF2ZWVuIOKAkyB0aGFua3Mu
Jm5ic3A7IFRoZXJlIGlzIG9uZSBjYXZlYXQgdGhlcmUsIHdoaWNoIGlzIHRoYXQgKElJVUMsIG9u
IGN1cnJlbnQgaGFyZHdhcmUpIHlvdSBjYW7igJl0IGRvIHBhY2tldCBwYWNpbmcgd2l0aCBMU08s
IGFuZCBzbyBteSB1bmRlcnN0YW5kaW5nIGlzDQogdGhhdCBldmVuIGZvciBUQ1AgbWFueSBwcm92
aWRlcnMgZGlzYWJsZSB0aGlzIGluIHB1cnN1aXQgb2YgYmV0dGVyIGVncmVzcyBtYW5hZ2VtZW50
LiZuYnNwOyBTbyB3aGF0IHdl4oCZcmUgcmVhbGx5IHNheWluZyBpcyB0aGF0OjxvOnA+PC9vOnA+
PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps
MiBsZXZlbDEgbGZvMSI+DQpPbiBjdXJyZW50IGhhcmR3YXJlIGFuZCBPUyBzZXR1cHMsIFVEUCBy
dW5zIGxlc3MgdGhhbiBoYWxmIGFzIG11Y2ggdGhyb3VnaHB1dCBhcyBUQ1A7IHRoYXQgbmVlZHMg
c29tZSBvcHRpbWl6YXRpb24sIGFzIHdl4oCZdmUgYWxyZWFkeSBkaXNjdXNzZWQ8bzpwPjwvbzpw
PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+DQpU
Q1Agd2lsbCBkcmFtYXRpY2FsbHkgZ2FpbiBwZXJmb3JtYW5jZSBvbmNlIGhhcmR3YXJlIG9mZmxv
YWQgY2F0Y2hlcyB1cCBhbmQgYWxsb3dzDQo8dT5wYWNlZDwvdT4gTFNPIDxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj7wn5iKPC9z
cGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SG93ZXZlciwgYXMgTWlra2Vs
IHBvaW50cyBvdXQsIHRoZSBjcnlwdG8gY29zdHMgYXJlIGxpa2VseSB0byBvdmVyd2hlbG0gdGhl
IE9TIHRocm91Z2hwdXQgLyBzY2hlZHVsaW5nIGlzc3VlcyBpbiByZWFsIGRlcGxveW1lbnRzLiZu
YnNwOyBTbyBJIHRoaW5rIHRoZSBvdGhlciByZWxldmFudCBwaWVjZSB0byB1bmRlcnN0YW5kaW5n
DQogdGhlIGNvc3QgaGVyZSBpcyB0aGlzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhhdmUg
YSBmZXcgY2FzZXMoYm90aCBjbGllbnQgYW5kIHNlcnZlcikgd2hlcmUgbXkgVURQIHNlbmQgY29z
dHMgYXJlIG1vcmUgdGhhbiAzMCUoaW4gc29tZSBjYXNlcyA1MCUpIG9mIENQVSBjb25zdW1wdGlv
biwgYW5kIGNyeXB0byBpcyBsZXNzIHRoYW4gMTAlLiZuYnNwOyBTbyBjdXJyZW50bHksIEkgYXNz
dW1lDQogY3J5cHRvIGlzIGNoZWFwKGVzcGVjaWFsbHkgQUVTLUdDTSB3aGVuIGhhcmR3YXJlIGFj
Y2VsZXJhdGlvbiBpcyBhdmFpbGFibGUpIGFuZCBlZ3Jlc3MgaXMgZXhwZW5zaXZlLiZuYnNwOyBV
RFAgaW5ncmVzIGlzIG5vdCB0aGF0IGV4cGVuc2l2ZSwgYnV0IGNvdWxkIHVzZSBhIGJpdCBvZiBv
cHRpbWl6YXRpb24gYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBvbmx5ICdmYW5jeScgdGhpbmcgb3VyIGN1cnJlbnQg
Y29kZSBpcyBkb2luZyBmb3IgY3J5cHRvIGlzIGVuY3J5cHRpbmcgaW4gcGxhY2UsIHdoaWNoIHdh
cyBhIH4yJSB3aW4uJm5ic3A7IE5pY2UsIGJ1dCBub3QgdHJhbnNmb3JtYXRpdmUuJm5ic3A7IFNl
ZQ0KPGEgaHJlZj0iaHR0cHM6Ly9jcy5jaHJvbWl1bS5vcmcvY2hyb21pdW0vc3JjL25ldC9xdWlj
L2NvcmUvcXVpY19mcmFtZXIuY2M/c3E9cGFja2FnZTpjaHJvbWl1bSZhbXA7bD0xODkzIiB0YXJn
ZXQ9Il9ibGFuayI+DQpFbmNyeXB0SW5QbGFjZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZW4ndCBkb25lIG11Y2ggd29y
ayBiZW5jaG1hcmtpbmcgV2luZG93cywgc28gcG9zc2libHkgdGhlIFdpbmRvd3MgVURQIHN0YWNr
IGlzIHJlYWxseSBmYXN0LCBhbmQgc28gY3J5cHRvIHNlZW1zIHJlYWxseSBzbG93IGluIGNvbXBh
cmlzb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g
MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0
OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2Mi
Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpXaGF0
IGlzIHRoZSB0aHJvdWdocHV0IGFuZCByZWxhdGl2ZSBjb3N0IG9mIFRMUy9UQ1AgdmVyc3VzIFFV
SUMgKGkuZS4gaG93IG11Y2ggYXJlIHRoZSBzbWFsbGVyIHVuaXRzIG9mIGVuY3J5cHRpb24gaHVy
dGluZyB1cyB2ZXJzdXMsIHNheSwgMTZLQiBUTFMgcmVjb3Jkcyk/DQo8bzpwPjwvbzpwPjwvbGk+
PC91bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDIgbGZvMyI+DQpUTFMgaW1wbGVtZW50YXRpb25z
IGFscmVhZHkgdmFyeSBoZXJlOiZuYnNwOyBTb21lIGltcGxlbWVudGF0aW9ucyBjaG9vc2UgbGFy
Z2UgcmVjb3JkIHNpemVzLCBzb21lIHZhcnkgcmVjb3JkIHNpemVzIHRvIHJlZHVjZSBkZWxheSAv
IEhvTEIsIHNvIHRoaXMgcHJvYmFibHkgaXNu4oCZdCBhIHNpbmdsZSBudW1iZXIuPG86cD48L286
cD48L2xpPjwvdWw+DQo8L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+DQpIb3cgbXVjaCBhZGRpdGlvbmFsIGxvYWQg
ZG9lcyBQTkUgYWRkIHRvIHRoaXMgZGlmZmVyZW5jZT88bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+DQpUbyB3aGF0IGV4dGVudCB3
b3VsZCBQTkUgbWFrZSBmdXR1cmUgY3J5cHRvIG9mZmxvYWRzIDxpPmltcG9zc2libGU8L2k+IHZl
cnN1cyA8aT4NCnJlcXVpcmVzIG1vcmUgUiZhbXA7RCB0byBkZXZlbG9wPC9pPj88bzpwPjwvbzpw
PjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNA
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+
T24gQmVoYWxmIE9mIDwvYj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPGJyPg0KPGI+U2VudDo8
L2I+IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxOCAxOjM0IFBNPGJyPg0KPGI+VG86PC9iPiBQcmF2
ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmI9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0
LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbWljcm9zb2Z0LmNvbUBkbWFy
Yy5pZXRmLm9yZzwvYT4mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWlj
QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBz
dGFjayBwZXJmb3JtYW5jZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0
MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGZvciBzaGFyaW5n
IHRoZXNlIG51bWJlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJt
Xy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZv
bnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2
MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TXkgZ3Vlc3MgaXMgdGhhdCB0aGVzZSBvZmZs
b2FkcyBkZWFsIHdpdGgga2VybmVsIHNjaGVkdWxpbmcsIG1lbW9yeSBjYWNoZSBpc3N1ZXMsIGFu
ZCBpbnRlcnJ1cHQgc2NoZWR1bGluZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXYgaWQ9Im1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3Bf
Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTIwMTc3MTQw
NDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JdCBwcm9iYWJseSBoYXMgdmVy
eSBsaXR0bGUgdG8gZG8gd2l0aCBjcnlwdG8sIFRDUCBoZWFkZXJzLCBhbmQgYW55IG90aGVyIGNw
dSBzZW5zaXRpdmUgcHJvY2Vzc2luZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXYgaWQ9Im1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3Bf
Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTIwMTc3MTQw
NDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIHdoZXJlIG5ldG1h
cCBlbnRlcnM6IHlvdSBjYW4gdHJhbnNwYXJlbnRseSBmZWVkIHRoZSBkYXRhIGFzIGl0IGJlY29t
ZXMgYXZhaWxhYmxlIHdpdGggdmVyeSBsaXR0bGUgc3luYw0KIHdvcmsgYW5kIHlvdSBjYW4gYWxz
byBlZmZpY2llbnRseSBwaXBlbGluZSBzbyB5b3UgcGFzcyBkYXRhIHRvIGRlY3J5cHRvciwgdGhl
biB0byBhcHAsIHdpdGggYXMgbGl0dGxlIGJ1cyB0cmFmZmljIGFzIHBvc3NpYmxlLiBObyBuZWVk
IHRvIGNvcHkgZGF0YSBvciBzeW5jaHJvbml6ZSBrZXJuZWwgc3BhY2UuPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkx
NzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29w
X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
Rm9yIDFLIHBhY2tldHMgeW91IHdvdWxkIHVzZSBhYm91dCAxMDAwbnMgKDMgY3ljbGVzL2J5dGUp
IG9uIGNyeXB0byBhbmQgdGhpcyB3b3VsZCBoYXBwZW4gaW4gTDEgY2FjaGUuIEl0IHdvdWxkDQog
b2YgY291cnNlIGNvbnN1bWUgYSBjb3JlIHdoaWNoIGEgY3J5cHRvIG9mZmxvYWQgd291bGQgbm90
LCBidXQgdGhhdCBjYW4gYmUgZGViYXRlZCBiZWNhdXNlIHdpdGggMTggY29yZSBzeXN0ZW1zLCB5
b3VyIHByb2JsZW0gaXMgbWVtb3J5IGFuZCBuZXR3b3JrIG1vcmUgdGhhbiBDUFUuPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8t
OTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0
M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+TXkgY29uY2VybiB3aXRoIFBORSBpcyBmb3Igc21hbGwgcGFja2V0cyBhbmQgbG93IGxh
dGVuY3kgd2hlcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTIw
MTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4xKSBhbiBlc3RpbWF0
ZWQgMjRucyBmb3IgUE4gZW5jcnlwdGlvbiBhbmQgZGVjcnlwdGlvbiBiZWNvbWVzIG1lYXN1cmFi
bGUgaWYgeW91ciBuZXR3b3JrIGlzIGZhc3QgZW5vdWdoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0ibV8tMjAxNzcxNDA0MDEzNzExNjM0OW1fLTkwMDQ5MTcxNDk0MDU1
OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPjIpIGFueSBkYW1hZ2UgdG8gdGhlIHBhY2tldCBidWZmZXIgY2F1c2UgYWxsIHNv
cnRzIG9mIG1lbW9yeSBhbmQgY3B1IGJ1cyB0cmFmZmljIGlzc3Vlcy48L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3
MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXYgaWQ9Im1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3Bf
Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4x
KSBpcyBhbm5veWluZy4gMikgaXMgYmFkLCBjb21wbGV0ZWx5IGF2b2lkYWJsZSBidXQgbm90IGFz
IFBSIDEwNzkgaXMgZm9ybXVsYXRlZCBjdXJyZW50bHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5
NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJt
Xy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZv
bnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+MikgaXMgYWxz
byBsaWtlbHkgYmFkIGZvciBoYXJkd2FyZSBvZmZsb2FkIHVuaXRzIGFzIHdlbGwuPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8t
OTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BcyB0byBTUlYt
SU8gLSBJ4oCZbSBub3QgZmFtaWxpYXIgd2l0aCBpdCwgYnV0IG9idmlvdXNseSB0aGVyZSBpcyBz
b21lIElPIGFic3RyYWN0aW9uIGxheWVyIC0gdGhlIHF1ZXN0aW9uIGlzIGhvdw0KIHlvdSBtYWtl
IGl0IGFjY2Vzc2libGUgdG8gYXBwcyBhcyBvcHBvc2VkIHRvIGRldmljZSBkcml2ZXJzIHRoYXQg
ZG9lcyBub3Igd29yayB3aXRoIHlvdSBRVUlDIGN1c3RvbSBzdGFjaywgYW5kIG5ldG1hcCBpcyBv
bmUgb3B0aW9uIGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxkaXYgaWQ9Im1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQz
Ymxvb3Bfc2lnbl8xNTIyODczMzUwNDE1MTIwMTI4Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5LaW5kIFJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS0yMDE3NzE0MDQwMTM3MTE2MzQ5bS05
MDA0OTE3MTQ5NDA1NTk0MTQzYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gNCBBcHJp
bCAyMDE4IGF0IDIyLjE1LjUyLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAoPGEgaHJlZj0ibWFp
bHRvOnByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi
PnByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4pDQogd3JvdGU6PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Tb21lIGNvbXBhcmF0aXZlIG51bWJlcnMgZnJvbSBh
biBvdXQgb2YgYm94IGRlZmF1bHQgc2V0dGluZ3MgV2luZG93cyBTZXJ2ZXIgMjAxNiAocmVsZWFz
ZWQgdmVyc2lvbikgZm9yIGEgc2luZ2xlDQogY29ubmVjdGlvbiB3aXRoIGEgbWljcm9iZW5jaG1h
cmsgdG9vbDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xh
c3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGlu
Zz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHI+DQo8
dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuODVwdDtib3JkZXI6
c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItYm90dG9tOnNvbGlkICM2NjY2NjYgMS41cHQ7cGFk
ZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPk9mZmxvYWRzIGVuYWJsZWQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9w
Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi45
cHQ7Ym9yZGVyLXRvcDpzb2xpZCAjOTk5OTk5IDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVy
LWJvdHRvbTpzb2xpZCAjNjY2NjY2IDEuNXB0O2JvcmRlci1yaWdodDpzb2xpZCAjOTk5OTk5IDEu
MHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj5UQ1AgZ2Jwczwvc3Bhbj48L2I+PG86cD48L286cD48L3A+
DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2Ljlw
dDtib3JkZXItdG9wOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXIt
Ym90dG9tOnNvbGlkICM2NjY2NjYgMS41cHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4w
cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlVEUCBnYnBzPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4N
CjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0i
d2lkdGg6MTE2Ljg1cHQ7Ym9yZGVyOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXRvcDpub25l
O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5MU08gJiM0MzsgTFJPICYjNDM7IGNoZWNrc3VtPC9zcGFuPjwv
Yj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0
eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRl
ci1ib3R0b206c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAx
LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+MjQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk
IHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2LjlwdDtib3JkZXItdG9w
Om5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICM5OTk5OTkgMS4wcHQ7
Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUu
NHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjMuNjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHdpZHRoPSIxNTYiIHZh
bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2Ljg1cHQ7Ym9yZGVyOnNvbGlkICM5OTk5OTkgMS4w
cHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5DaGVja3N1bSBvbmx5PC9zcGFu
PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3Ai
IHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2Jv
cmRlci1ib3R0b206c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5
OSAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Ny42PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N
Cjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7Ym9yZGVy
LXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjOTk5OTk5IDEu
MHB0O2JvcmRlci1yaWdodDpzb2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBp
biA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4zLjY8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB3aWR0aD0iMTU2
IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi44NXB0O2JvcmRlcjpzb2xpZCAjOTk5OTk5
IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Tm9uZTwvc3Bhbj48L2I+
PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHls
ZT0id2lkdGg6MTE2LjlwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXIt
Ym90dG9tOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4w
cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPjUuNjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg
d2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6
bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgIzk5OTk5OSAxLjBwdDti
b3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40
cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Mi4zPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMg
aXMgZm9yIGEgZnVsbHkgYm90dGxlbmVja2VkIENQVSBjb3JlIC0tDQo8aT5pZiB5b3UgcnVuIGxv
d2VyIGRhdGEgcmF0ZXMgdGhlcmUgaXMgc3RpbGwgYSBzaWduaWZpY2FudCBkaWZmZXJlbmNlIGlu
IEN5Y2xlcy9ieXRlIGNvc3Q8L2k+LiBTYW1lIGluY3JlYXNlZCBDUFUgY29zdCBhcHBsaWVzIGZv
ciBjbGllbnQgc3lzdGVtcyBnb2luZyBvdmVyIGhpZ2ggZGF0YSByYXRlIFdpZmkgYW5kIGNlbGx1
bGFyLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBpcyB3aXRob3V0IGFueSBjcnlwdG8u
IE9uY2UgeW91IGFkZCBjcnlwdG8gdGhlIG51bWJlcnMgYmVjb21lIG11Y2ggd29yc2UNCjxpPndp
dGggY3J5cHRvIGNvc3QgYmVjb21pbmcgZG9taW5hbnQ8L2k+LiBBZGRpbmcgYW5vdGhlciBjcnlw
dG8gc3RlcCBmdXJ0aGVyIGV4YWNlcmJhdGVzIHRoZSBwcm9ibGVtLiBIZW5jZSBjcnlwdG8gb2Zm
bG9hZCBnYWlucyBpbiBpbXBvcnRhbmNlIGZvbGxvd2VkIGJ5IHRoZXNlIGJhdGNoIG9mZmxvYWRz
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklmIGZvbGtzIG5lZWQgYW55IG1vcmUgbnVtYmVycyBJ
4oCZZCBiZSBoYXBweSB0byBwcm92aWRlIHRoZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhh
bmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_1F436ED13A22A246A59CA374CBC543998B60C7ADORSMSX111amrcor_--


From nobody Mon Apr 23 11:25:07 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A1412D88E for ; Mon, 23 Apr 2018 11:25:05 -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 p_Z67doTzgYR for ; Mon, 23 Apr 2018 11:25:02 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48652126C0F for ; Mon, 23 Apr 2018 11:25:02 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id 186-v6so11902310itu.0 for ; Mon, 23 Apr 2018 11:25:02 -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=kHFyE/myrK6aD0+9OHxRtMxv5A5eZ5D+v2iAakZlrjM=; b=NZpwKGYxa39es9yKZzTiH7kRlb4+/n8oqEAJOq34eSQmPaqZNyYNiMZ0D6FMmIUBn/ QcG+pZpm0fAnUNL15f9UT607QnLJe4A5su6TydlkSVZpQFvb35OdXo3YC3j7lZQQ6Hnw 6gO5nT1+TQ2qD2QYcTsDmukWtEdY4XxTghOUQFO/Naa2iUnvVlgijwH5JZIun2i9ulT7 E/3BwDORi+/KE5RqUhLLyxtyrZh55l7jQPxzazH7LgZiA0jirFbvgdjLduf8OA5+qEIG QiNxMa0rV5naHj0DtZS/AMmubggf/e7aKl2fhuxl0wWk4fyKW12NxVimx3zvLj3OrHWb lz1A==
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=kHFyE/myrK6aD0+9OHxRtMxv5A5eZ5D+v2iAakZlrjM=; b=KwukE3oeO9JD/epIZd74pgGm37fusEDLW9YCTxb0A+d5b0EGJpdg8VufYb1xblkcCr ikGMtK6dlra0SH8r/pFRAaemkvTIMDTRpA5HHFM5JgN/8RmQQ6ZqFuZW3t21a2dXSlF7 X+EoE7AW/G4bETbYYXuDjJZyKv/DYCefWvLHsC8tp8zpbcRbp524Htj5L3HetL07RrWB 8rhjuExBMWlb2BfXRlLfbTx5jttRqTZfBpHHfZj+ukUSCO7o4tsm2UeeKn24AigkDWsu ffwCuPRzcCa/09tNIiSD4qaAAYGE7Wm/y+MsjP0IS+3F1ebY4lcA4SowGwBric2vtGKq +fqw==
X-Gm-Message-State: ALQs6tBKQrjsZDdnaIVaSq5YmuOT6zk6SgjG2qtEw5uHZPJPuKKUq3cV WBYLY1J9rxzgEaoBe7jv6XL1CFvwlETglQtLgaA=
X-Google-Smtp-Source: AB8JxZrtBVUoQM4Uhqx5CmIZHJpFJcr5DecnKuEt6zO6AIn/n8huj2gJa19t3GtDEbSjQ78SNkrvcu2b8hyVNwFrfhc=
X-Received: by 2002:a24:7088:: with SMTP id f130-v6mr15392766itc.39.1524507901531;  Mon, 23 Apr 2018 11:25:01 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 23 Apr 2018 11:25:00 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B60C7AD@ORSMSX111.amr.corp.intel.com>
References:        <1F436ED13A22A246A59CA374CBC543998B60C7AD@ORSMSX111.amr.corp.intel.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 23 Apr 2018 11:25:00 -0700
Message-ID: 
Subject: RE: Impact of hardware offloads on network stack performance
To: Ian Swett ,  "Deval, Manasi" , Mike Bishop 
Cc: IETF QUIC WG , Praveen Balasubramanian 
Content-Type: multipart/alternative; boundary="000000000000ed9c77056a8827a9"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 23 Apr 2018 18:25:06 -0000

--000000000000ed9c77056a8827a9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I=E2=80=99m not really familiar with this dump but what does partial segmen=
tation
mean here?

Are you splitting a single UDP datagram into multiple fragments, or are you
processing multiple separate QUIC packets, one PN each?

If you fragment UDP datagrams, that can be a big issue because different
fragments may race along different routes, causing unexpected delays and
blocking at the other end.



On 23 April 2018 at 20.18.54, Deval, Manasi (manasi.deval@intel.com) wrote:

If we do TSO / LSO with QUIC, the initial segment provided can look like =
=E2=80=93

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encrypte=
d header (PN=3Dx) =E2=80=93 QUIC Encrypted
payload.



If we just use the stack=E2=80=99s udp segmentation (using the patch -
https://marc.info/?l=3Dlinux-netdev&m=3D152399530603992&w=3D2), the outcome=
 of
QUIC packets on the wire would be:

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encrypte=
d part (PN=3Dx, partial segment 1)

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC encrypted part (partial segme=
nt 2)

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC encrypted part (partial segme=
nt 3)

=E2=80=A6



Putting these back together in a stack / hardware looks like a painful and
potentially non-deterministic activity.





It would be easier to do a native QUIC offload, where the packet on wire
can be identified by QUIC CiD and appropriate packet number. Therefore,
original packet looks like - MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC =
Clear =E2=80=93 QUIC encrypted
header (PN=3Dx) =E2=80=93 QUIC Encrypted payload.

If we just create another version of segmentation called QUIC segmentation,
the outcome of packets on the wire would be:

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encrypte=
d part (PN=3Dx, partial segment 1)

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encrypte=
d part (PN=3Dx+1, partial segment
2)

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encrypte=
d part (PN=3Dx+2, partial segment
3)

=E2=80=A6

If this set of segments were to be re-assembled, the ability to identify
CiD and PN would simplify this task. I think this is a simpler
implementation. Do others see an issue with this?



Thanks,

Manasi





*From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett
*Sent:* Friday, April 06, 2018 1:55 PM
*To:* Mike Bishop 
*Cc:* Praveen Balasubramanian ; Mikkel Fahn=C3=B8e
J=C3=B8rgensen ; IETF QUIC WG 
*Subject:* Re: Impact of hardware offloads on network stack performance



PNE doesn't preclude UDP LRO or pacing offload.



However, in a highly optimized stack(ie: The Disk|Crypt|Net paper from
SIGCOMM 2017) not touching(ie: bringing into memory or cache) the content
to be sent until the last possible moment is critical.  PNE likely means
touching that content much earlier.



But personally I consider the actual crypto we're talking about(2 AES
instructions?) adding basically free.



On Fri, Apr 6, 2018 at 4:37 PM Mike Bishop  wrote:

Thanks for the clarification.  I guess what I=E2=80=99m really getting down=
 to is
how do we quantify the actual *cost* of PNE?  Are we substantially
increasing the crypto costs?  If Ian is saying that crypto is comparatively
cheap and the cost is that it=E2=80=99s harder to offload something that=E2=
=80=99s
comparatively cheap, what have we lost?  I=E2=80=99d think we want to offlo=
ad the
most intensive piece we can, and it seems like we=E2=80=99re talking about =
crypto
offloads....  Or are we saying instead that the crypto makes it harder to
offload other things in the future, like a QUIC equivalent to LRO/LSO?



*From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]
*Sent:* Thursday, April 5, 2018 9:45 PM
*To:* Ian Swett ; Mike Bishop 
*Cc:* Praveen Balasubramanian ; IETF QUIC WG <
quic@ietf.org>
*Subject:* Re: Impact of hardware offloads on network stack performance



To be clear - I don=E2=80=99t think crypto is overshadowing other issues as=
 Mike
read my post. It certainly comes at a cost, but either multiple cores or
co-processors will deal with this. 1000ns is 10Gbps crypto speed on one
core and it is higly parallelisable and cache friendly.



But if you have to drip your packets through a traditional send interface
that is copying, buffering or blocking, and certainly sync=E2=80=99ing with=
 the
kernel - it is going to be tough.



For receive you risk high latency or top much scheduling in receive buffers=
.


------------------------------

*From:* Ian Swett 
*Sent:* Friday, April 6, 2018 4:06:01 AM
*To:* Mike Bishop
*Cc:* Mikkel Fahn=C3=B8e J=C3=B8rgensen; Praveen Balasubramanian; IETF QUIC=
 WG
*Subject:* Re: Impact of hardware offloads on network stack performance





On Thu, Apr 5, 2018 at 5:57 PM Mike Bishop  wrote:

That=E2=80=99s interesting data, Praveen =E2=80=93 thanks.  There is one ca=
veat there,
which is that (IIUC, on current hardware) you can=E2=80=99t do packet pacin=
g with
LSO, and so my understanding is that even for TCP many providers disable
this in pursuit of better egress management.  So what we=E2=80=99re really =
saying
is that:

   - On current hardware and OS setups, UDP runs less than half as much
   throughput as TCP; that needs some optimization, as we=E2=80=99ve alread=
y discussed
   - TCP will dramatically gain performance once hardware offload catches
   up and allows *paced* LSO =F0=9F=98=8A



However, as Mikkel points out, the crypto costs are likely to overwhelm the
OS throughput / scheduling issues in real deployments.  So I think the
other relevant piece to understanding the cost here is this:



I have a few cases(both client and server) where my UDP send costs are more
than 30%(in some cases 50%) of CPU consumption, and crypto is less than
10%.  So currently, I assume crypto is cheap(especially AES-GCM when
hardware acceleration is available) and egress is expensive.  UDP ingres is
not that expensive, but could use a bit of optimization as well.



The only 'fancy' thing our current code is doing for crypto is encrypting
in place, which was a ~2% win.  Nice, but not transformative.  See
EncryptInPlace




I haven't done much work benchmarking Windows, so possibly the Windows UDP
stack is really fast, and so crypto seems really slow in comparison?




   - What is the throughput and relative cost of TLS/TCP versus QUIC (i.e.
   how much are the smaller units of encryption hurting us versus, say, 16K=
B
   TLS records)?


   - TLS implementations already vary here:  Some implementations choose
      large record sizes, some vary record sizes to reduce delay /
HoLB, so this
      probably isn=E2=80=99t a single number.


   - How much additional load does PNE add to this difference?
   - To what extent would PNE make future crypto offloads *impossible*
   versus * requires more R&D to develop*?



*From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahn=C3=
=B8e
J=C3=B8rgensen
*Sent:* Wednesday, April 4, 2018 1:34 PM
*To:* Praveen Balasubramanian ; IET=
F
QUIC WG 
*Subject:* Re: Impact of hardware offloads on network stack performance



Thanks for sharing these numbers.



My guess is that these offloads deal with kernel scheduling, memory cache
issues, and interrupt scheduling.



It probably has very little to do with crypto, TCP headers, and any other
cpu sensitive processing.



This is where netmap enters: you can transparently feed the data as it
becomes available with very little sync work and you can also efficiently
pipeline so you pass data to decryptor, then to app, with as little bus
traffic as possible. No need to copy data or synchronize kernel space.



For 1K packets you would use about 1000ns (3 cycles/byte) on crypto and
this would happen in L1 cache. It would of course consume a core which a
crypto offload would not, but that can be debated because with 18 core
systems, your problem is memory and network more than CPU.



My concern with PNE is for small packets and low latency where

1) an estimated 24ns for PN encryption and decryption becomes measurable if
your network is fast enough.

2) any damage to the packet buffer cause all sorts of memory and cpu bus
traffic issues.



1) is annoying. 2) is bad, completely avoidable but not as PR 1079 is
formulated currently.



2) is also likely bad for hardware offload units as well.



As to SRV-IO - I=E2=80=99m not familiar with it, but obviously there is som=
e IO
abstraction layer - the question is how you make it accessible to apps as
opposed to device drivers that does nor work with you QUIC custom stack,
and netmap is one option here.



Kind Regards,

Mikkel Fahn=C3=B8e J=C3=B8rgensen



On 4 April 2018 at 22.15.52, Praveen Balasubramanian (
pravb=3D40microsoft.com@dmarc.ietf.org) wrote:

Some comparative numbers from an out of box default settings Windows Server
2016 (released version) for a single connection with a microbenchmark tool:



*Offloads enabled*

*TCP gbps*

*UDP gbps*

*LSO + LRO + checksum*

24

3.6

*Checksum only*

7.6

3.6

*None*

5.6

2.3



This is for a fully bottlenecked CPU core -- *if you run lower data rates
there is still a significant difference in Cycles/byte cost*. Same
increased CPU cost applies for client systems going over high data rate
Wifi and cellular.



This is without any crypto. Once you add crypto the numbers become much
worse *with crypto cost becoming dominant*. Adding another crypto step
further exacerbates the problem. Hence crypto offload gains in importance
followed by these batch offloads.



If folks need any more numbers I=E2=80=99d be happy to provide them.



Thanks

--000000000000ed9c77056a8827a9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
I=E2=80=99m not real=
ly familiar with this dump but what does partial segmentation mean here?

Are you splitting a sin=
gle UDP datagram into multiple fragments, or are you processing multiple se=
parate QUIC packets, one PN each?

If you fragment UDP datagrams, that can be a big issue becau=
se different fragments may race along different routes, causing unexpected =
delays and blocking at the other end.
 


 
On 23 Apri=
l 2018 at 20.18.54, Deval, Manasi (manasi.deval@intel.com) wrote:
 










If we do TSO / LSO with QUIC, the ini=
tial segment provided can look like =E2=80=93


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC Clear =E2=80=93 QUIC encrypted header (PN=3Dx) =E2=80=93 QUIC Encr=
ypted payload.



=C2=A0


If we just use the =
stack=E2=80=99s udp segmentation (using the patch -
https://marc.info/?l=3Dlinux-netdev&m=3D152399530603992&a=
mp;w=3D2), the outcome of QUIC packets on=
 the wire would be:


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC Clear =E2=80=93 QUIC encrypted part (PN=3Dx, partial segment 1)


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC encrypted part (partial segment 2)


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC encrypted part (partial segment 3)


=E2=80=A6


=C2=A0


Putting these back together in a stac=
k / hardware looks like a painful and potentially non-deterministic activit=
y.



=C2=A0


=C2=A0


It would be easier to do a native QUI=
C offload, where the packet on wire can be identified by QUIC CiD and appro=
priate packet number.
 Therefore, original packet looks like - MAC =E2=80=93 IP =E2=80=93 UDP =E2=
=80=93 QUIC Clear =E2=80=93 QUIC encrypted header (PN=3Dx) =E2=80=93 QUIC E=
ncrypted payload.



If we just create another version of =
segmentation called QUIC segmentation, the outcome of packets on the wire w=
ould be:


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC Clear =E2=80=93 QUIC encrypted part (PN=3Dx, partial segment 1)


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC Clear =E2=80=93 QUIC encrypted part (PN=3Dx+1, partial segment 2)<=
/span>


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC Clear =E2=80=93 QUIC encrypted part (PN=3Dx+2, partial segment 3)<=
/span>


=E2=80=A6


If this set of segments were to be re=
-assembled, the ability to identify CiD and PN would simplify this task. I =
think this is a simpler implementation. Do others
 see an issue with this?


=C2=A0


Thanks,


Manasi


=C2=A0


=C2=A0


From: QUIC [mailto:quic-bounces@ietf.org]
On Behalf Of Ian Swett

Sent: Friday, April 06, 2018 1:55 PM

To: Mike Bishop <mbishop@=
evequefou.be>

Cc: Praveen Balasubramanian <pravb@microsoft.com>; Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; IETF QUIC WG &=
lt;quic@ietf.org>

Subject: Re: Impact of hardware offloads on network stack performanc=
e


=C2=A0




PNE doesn't preclude UDP LRO or pacing offload.<=
/p>



=C2=A0






However, in a highly optimized stack(ie: The Disk|Cr=
ypt|Net paper from SIGCOMM 2017) not touching(ie: bringing into memory or c=
ache) the content to be sent until the last possible moment is critical.=C2=
=A0 PNE likely means touching that content
 much earlier.






=C2=A0






But personally I consider the actual crypto we'r=
e talking about(2 AES instructions?) adding basically free.=C2=A0=C2=A0






=C2=A0






On Fri, Apr 6, 2018 at 4:37 PM Mike Bishop <mbishop@evequefou.be> wrote:










Thanks for the clarification.=C2=A0 I guess what I=E2=80=99m reall=
y getting down to is how do we quantify the actual
cost of PNE?=C2=A0 Are we substantially increasing the crypto costs?=
=C2=A0 If Ian is saying that crypto is comparatively cheap and the cost is =
that it=E2=80=99s harder to offload something that=E2=80=99s comparatively =
cheap, what have we lost?=C2=A0 I=E2=80=99d think we want to offload the
 most intensive piece we can, and it seems like we=E2=80=99re talking about=
 crypto offloads....=C2=A0 Or are we saying instead that the crypto makes i=
t harder to offload other things in the future, like a QUIC equivalent to L=
RO/LSO?


=C2=A0






From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]


Sent: Thursday, April 5, 2018 9:45 PM

To: Ian Swett <ianswett@google.com>; Mike Bishop <mbishop@evequefou.be>

Cc: Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>

Subject: Re: Impact of hardware offloads on network stack performanc=
e






=C2=A0










To be clear - I don=E2=80=99t think crypto is overshadowing other =
issues as Mike read my post. It certainly comes at a cost, but either multi=
ple cores or co-processors will deal with this.
 1000ns is 10Gbps crypto speed on one core and it is higly parallelisable a=
nd cache friendly.






=C2=A0






But if you have to drip your packets through a traditional send in=
terface that is copying, buffering or blocking, and certainly sync=E2=80=99=
ing with the kernel - it is going to be tough.






=C2=A0






For receive you risk high latency or top much scheduling in receiv=
e buffers.








=C2=A0
















From: Ian Swett <ianswett@google.com>

Sent: Friday, April 6, 2018 4:06:01 AM

To: Mike Bishop

Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen; Praveen Balasubramanian; IETF=
 QUIC WG

Subject: Re: Impact of hardware offloads on network stack performanc=
e





=C2=A0










=C2=A0






On Thu, Apr 5, 2018 at 5:57 PM Mike Bishop <mbishop@evequefou.be> wrote:<=
/p>









That=E2=80=99s interesting data, Praveen =E2=80=93 thanks.=C2=A0 T=
here is one caveat there, which is that (IIUC, on current hardware) you can=
=E2=80=99t do packet pacing with LSO, and so my understanding is
 that even for TCP many providers disable this in pursuit of better egress =
management.=C2=A0 So what we=E2=80=99re really saying is that:


    

  • 
On current hardware and OS setups, UDP runs less than half as much throughp=
ut as TCP; that needs some optimization, as we=E2=80=99ve already discussed=

  • 
TCP will dramatically gain performance once hardware offload catches up and=
 allows
paced LSO =F0=9F=98=8A


=C2=A0


However, as Mikkel points out, the crypto costs are likely to over=
whelm the OS throughput / scheduling issues in real deployments.=C2=A0 So I=
 think the other relevant piece to understanding
 the cost here is this:










=C2=A0






I have a few cases(both client and server) where my UDP send costs=
 are more than 30%(in some cases 50%) of CPU consumption, and crypto is les=
s than 10%.=C2=A0 So currently, I assume
 crypto is cheap(especially AES-GCM when hardware acceleration is available=
) and egress is expensive.=C2=A0 UDP ingres is not that expensive, but coul=
d use a bit of optimization as well.






=C2=A0






The only 'fancy' thing our current code is doing for crypt=
o is encrypting in place, which was a ~2% win.=C2=A0 Nice, but not transfor=
mative.=C2=A0 See

EncryptInPlace






=C2=A0






I haven't done much work benchmarking Windows, so possibly the=
 Windows UDP stack is really fast, and so crypto seems really slow in compa=
rison?






=C2=A0










    

  • 
What is the throughput and relative cost of TLS/TCP versus QUIC (i.e. how m=
uch are the smaller units of encryption hurting us versus, say, 16KB TLS re=
cords)?



    

      

    • 
TLS implementations already vary here:=C2=A0 Some implementations choose la=
rge record sizes, some vary record sizes to reduce delay / HoLB, so this pr=
obably isn=E2=80=99t a single number.
    



    

  • 
How much additional load does PNE add to this difference?
  • 
To what extent would PNE make future crypto offloads impossible vers=
us 
requires more R&D to develop?


=C2=A0






From: QUIC [mailto:quic-bounces@ietf.org]
On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen

Sent: Wednesday, April 4, 2018 1:34 PM

To: Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org&=
gt;; IETF QUIC WG <qu=
ic@ietf.org>

Subject: Re: Impact of hardware offloads on network stack performanc=
e






=C2=A0




Thanks for sharing these numbers.






=C2=A0






My guess is that these offloads deal with kernel scheduling, me=
mory cache issues, and interrupt scheduling.






=C2=A0






It probably has very little to do with crypto, TCP headers, and=
 any other cpu sensitive processing.






=C2=A0






This is where netmap enters: you can transparently feed the dat=
a as it becomes available with very little sync
 work and you can also efficiently pipeline so you pass data to decryptor, =
then to app, with as little bus traffic as possible. No need to copy data o=
r synchronize kernel space.






=C2=A0






For 1K packets you would use about 1000ns (3 cycles/byte) on cr=
ypto and this would happen in L1 cache. It would
 of course consume a core which a crypto offload would not, but that can be=
 debated because with 18 core systems, your problem is memory and network m=
ore than CPU.






=C2=A0






My concern with PNE is for small packets and low latency where<=
/span>






1) an estimated 24ns for PN encryption and decryption becomes m=
easurable if your network is fast enough.






2) any damage to the packet buffer cause all sorts of memory an=
d cpu bus traffic issues.






=C2=A0






1) is annoying. 2) is bad, completely avoidable but not as PR 1=
079 is formulated currently.






=C2=A0






2) is also likely bad for hardware offload units as well.






=C2=A0




As to SRV-IO - I=E2=80=99m not familiar with it, but obviously =
there is some IO abstraction layer - the question is how
 you make it accessible to apps as opposed to device drivers that does nor =
work with you QUIC custom stack, and netmap is one option here.




=C2=A0






Kind Regards,






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






=C2=A0


On 4 Ap=
ril 2018 at 22.15.52, Praveen Balasubramanian (pravb=3D40microsoft.com@dma=
rc.ietf.org)
 wrote:










Some comparative numbers from an out of box default settings Wi=
ndows Server 2016 (released version) for a single
 connection with a microbenchmark tool:


=C2=A0








Offloads enabled




TCP gbps




UDP gbps








LSO + LRO + checksum




24




3.6








Checksum only




7.6




3.6








None




5.6




2.3








=C2=A0


This is for a fully bottlenecked CPU core --
if you run lower data rates there is still a significant difference in C=
ycles/byte cost. Same increased CPU cost applies for client systems goi=
ng over high data rate Wifi and cellular.



=C2=A0


This is without any crypto. Once you add crypto the numbers bec=
ome much worse
with crypto cost becoming dominant. Adding another crypto step furth=
er exacerbates the problem. Hence crypto offload gains in importance follow=
ed by these batch offloads.


=C2=A0


If folks need any more numbers I=E2=80=99d be happy to provide =
them.


=C2=A0


Thanks


=C2=A0






































--000000000000ed9c77056a8827a9--


From nobody Mon Apr 23 11:38:14 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A865412D810 for ; Mon, 23 Apr 2018 11:38:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k9i0SlozGUU for ; Mon, 23 Apr 2018 11:38:08 -0700 (PDT)
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 40C4C120727 for ; Mon, 23 Apr 2018 11:38:08 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Apr 2018 11:38:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.49,319,1520924400"; d="scan'208,217"; a="44029451"
Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by FMSMGA003.fm.intel.com with ESMTP; 23 Apr 2018 11:38:04 -0700
Received: from orsmsx115.amr.corp.intel.com (10.22.240.11) by ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 23 Apr 2018 11:38:03 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.154]) by ORSMSX115.amr.corp.intel.com ([169.254.4.182]) with mapi id 14.03.0319.002; Mon, 23 Apr 2018 11:37:54 -0700
From: "Deval, Manasi" 
To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Ian Swett , Mike Bishop 
CC: IETF QUIC WG , Praveen Balasubramanian 
Subject: RE: Impact of hardware offloads on network stack performance
Thread-Topic: Impact of hardware offloads on network stack performance
Thread-Index: AdPMUbL7T8nZAW2ySiO289IPTC0ttgAPUYUAADUrUQAACLVdgAAFkLMAACFByIAAAJ6MgANCFysgAA+c2wAADpmtUA==
Date: Mon, 23 Apr 2018 18:37:53 +0000
Message-ID: <1F436ED13A22A246A59CA374CBC543998B60C851@ORSMSX111.amr.corp.intel.com>
References:        <1F436ED13A22A246A59CA374CBC543998B60C7AD@ORSMSX111.amr.corp.intel.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.0.0.116
dlp-reaction: no-action
x-originating-ip: [10.22.254.140]
Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B60C851ORSMSX111amrcor_"
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Apr 2018 18:38:13 -0000

--_000_1F436ED13A22A246A59CA374CBC543998B60C851ORSMSX111amrcor_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SeKAmW0gdHJ5aW5nIHRvIGxheSBvdXQgdGhlIG9wdGlvbnMgZm9yIFRTTy9MU08gd2l0aCBRVUlD
LiBJbiBteSBwcmV2aW91cyBlLW1haWwgSSBjb21wYXJlZCB0aGUgb3V0Y29tZSBvZiB2YW5pbGxh
IFVEUCBzZWdtZW50YXRpb24gYXMgZGVmaW5lZCBieSB0aGUgbGF0ZXN0IHBhdGNoIChodHRwczov
L21hcmMuaW5mby8/bD1saW51eC1uZXRkZXYmbT0xNTIzOTk1MzA2MDM5OTImdz0yKSwgdG8gYW4g
YWx0ZXJuYXRpdmUgbmF0aXZlIFFVSUMgc2VnbWVudGF0aW9uLg0KDQpBIHNlZ21lbnQgaXMgYSBs
YXJnZSBidWZmZXIgcHJvZHVjZWQgaW4gYW4gYXBwbGljYXRpb24uIFRoZSBzZWdtZW50IGlzIG9m
dGVuIG11Y2ggdG9vIGxhcmdlIHRvIGdvIG91dCBvbiB0aGUgd2lyZSB3aXRoIGp1c3QgcHJlLXBl
bmRlZCBoZWFkZXJzLiBUaGVyZWZvcmUgc2VnbWVudCBuZWVkcyB0byBiZSBjaG9wcGVkIHVwIGlu
dG8gYXBwcm9wcmlhdGUgc2l6ZSBhbmQgdGhlIHByZS1wZW5kZWQgaGVhZGVycyBuZWVkIHRvIGJl
IHJlcGxpY2F0ZWQgdG8gbWFrZSBNVFUgc2l6ZSBwYWNrZXRzIGZvciB0aGUgd2lyZS4NCg0KSeKA
mW0gc3VnZ2VzdGluZyB0aGF0IHdlIHNob3VsZCBjb25zaWRlciBwcm9jZXNzaW5nIGEgbGFyZ2Ug
ZGF0YSBidWZmZXIgYXMgbXVsdGlwbGUgUVVJQyBwYWNrZXRzIGVhY2ggd2l0aCBhIHVuaXF1ZSBQ
Ti4NCg0KVGhhbmtzLA0KTWFuYXNpDQoNCg0KRnJvbTogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNl
biBbbWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgQXByaWwgMjMsIDIw
MTggMTE6MjUgQU0NClRvOiBJYW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5p
ZXRmLm9yZz47IERldmFsLCBNYW5hc2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5jb20+OyBNaWtlIEJp
c2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU+DQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYu
b3JnPjsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+DQpTdWJq
ZWN0OiBSRTogSW1wYWN0IG9mIGhhcmR3YXJlIG9mZmxvYWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVy
Zm9ybWFuY2UNCg0KSeKAmW0gbm90IHJlYWxseSBmYW1pbGlhciB3aXRoIHRoaXMgZHVtcCBidXQg
d2hhdCBkb2VzIHBhcnRpYWwgc2VnbWVudGF0aW9uIG1lYW4gaGVyZT8NCg0KQXJlIHlvdSBzcGxp
dHRpbmcgYSBzaW5nbGUgVURQIGRhdGFncmFtIGludG8gbXVsdGlwbGUgZnJhZ21lbnRzLCBvciBh
cmUgeW91IHByb2Nlc3NpbmcgbXVsdGlwbGUgc2VwYXJhdGUgUVVJQyBwYWNrZXRzLCBvbmUgUE4g
ZWFjaD8NCg0KSWYgeW91IGZyYWdtZW50IFVEUCBkYXRhZ3JhbXMsIHRoYXQgY2FuIGJlIGEgYmln
IGlzc3VlIGJlY2F1c2UgZGlmZmVyZW50IGZyYWdtZW50cyBtYXkgcmFjZSBhbG9uZyBkaWZmZXJl
bnQgcm91dGVzLCBjYXVzaW5nIHVuZXhwZWN0ZWQgZGVsYXlzIGFuZCBibG9ja2luZyBhdCB0aGUg
b3RoZXIgZW5kLg0KDQoNCg0KT24gMjMgQXByaWwgMjAxOCBhdCAyMC4xOC41NCwgRGV2YWwsIE1h
bmFzaSAobWFuYXNpLmRldmFsQGludGVsLmNvbTxtYWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNv
bT4pIHdyb3RlOg0KSWYgd2UgZG8gVFNPIC8gTFNPIHdpdGggUVVJQywgdGhlIGluaXRpYWwgc2Vn
bWVudCBwcm92aWRlZCBjYW4gbG9vayBsaWtlIOKAkw0KTUFDIOKAkyBJUCDigJMgVURQIOKAkyBR
VUlDIENsZWFyIOKAkyBRVUlDIGVuY3J5cHRlZCBoZWFkZXIgKFBOPXgpIOKAkyBRVUlDIEVuY3J5
cHRlZCBwYXlsb2FkLg0KDQoNCklmIHdlIGp1c3QgdXNlIHRoZSBzdGFja+KAmXMgdWRwIHNlZ21l
bnRhdGlvbiAodXNpbmcgdGhlIHBhdGNoIC0gaHR0cHM6Ly9tYXJjLmluZm8vP2w9bGludXgtbmV0
ZGV2Jm09MTUyMzk5NTMwNjAzOTkyJnc9MiksIHRoZSBvdXRjb21lIG9mIFFVSUMgcGFja2V0cyBv
biB0aGUgd2lyZSB3b3VsZCBiZToNCk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBDbGVhciDi
gJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAoUE49eCwgcGFydGlhbCBzZWdtZW50IDEvMykNCk1BQyDi
gJMgSVAg4oCTIFVEUCDigJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAocGFydGlhbCBzZWdtZW50IDIv
MykNCk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAocGFydGlhbCBz
ZWdtZW50IDMvMykNCuKApg0KDQpQdXR0aW5nIHRoZXNlIGJhY2sgdG9nZXRoZXIgaW4gYSBzdGFj
ayAvIGhhcmR3YXJlIGxvb2tzIGxpa2UgYSBwYWluZnVsIGFuZCBwb3RlbnRpYWxseSBub24tZGV0
ZXJtaW5pc3RpYyBhY3Rpdml0eS4NCg0KDQpJdCB3b3VsZCBiZSBlYXNpZXIgdG8gZG8gYSBuYXRp
dmUgUVVJQyBvZmZsb2FkLCB3aGVyZSB0aGUgcGFja2V0IG9uIHdpcmUgY2FuIGJlIGlkZW50aWZp
ZWQgYnkgUVVJQyBDaUQgYW5kIGFwcHJvcHJpYXRlIHBhY2tldCBudW1iZXIuIFRoZXJlZm9yZSwg
b3JpZ2luYWwgcGFja2V0IGxvb2tzIGxpa2UgLSBNQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMg
Q2xlYXIg4oCTIFFVSUMgZW5jcnlwdGVkIGhlYWRlciAoUE49eCkg4oCTIFFVSUMgRW5jcnlwdGVk
IHBheWxvYWQuDQpJZiB3ZSBqdXN0IGNyZWF0ZSBhbm90aGVyIHZlcnNpb24gb2Ygc2VnbWVudGF0
aW9uIGNhbGxlZCBRVUlDIHNlZ21lbnRhdGlvbiwgdGhlIG91dGNvbWUgb2YgcGFja2V0cyBvbiB0
aGUgd2lyZSB3b3VsZCBiZToNCk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBDbGVhciDigJMg
UVVJQyBlbmNyeXB0ZWQgcGFydCAoUE49eCwgcGFydGlhbCBzZWdtZW50IDEvMykNCk1BQyDigJMg
SVAg4oCTIFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAoUE49eCsx
LCBwYXJ0aWFsIHNlZ21lbnQgMi8zKQ0KTUFDIOKAkyBJUCDigJMgVURQIOKAkyBRVUlDIENsZWFy
IOKAkyBRVUlDIGVuY3J5cHRlZCBwYXJ0IChQTj14KzIsIHBhcnRpYWwgc2VnbWVudCAzLzMpDQri
gKYNCklmIHRoaXMgc2V0IG9mIHNlZ21lbnRzIHdlcmUgdG8gYmUgcmUtYXNzZW1ibGVkLCB0aGUg
YWJpbGl0eSB0byBpZGVudGlmeSBDaUQgYW5kIFBOIHdvdWxkIHNpbXBsaWZ5IHRoaXMgdGFzay4g
SSB0aGluayB0aGlzIGlzIGEgc2ltcGxlciBpbXBsZW1lbnRhdGlvbi4gRG8gb3RoZXJzIHNlZSBh
biBpc3N1ZSB3aXRoIHRoaXM/DQoNClRoYW5rcywNCk1hbmFzaQ0KDQoNCkZyb206IFFVSUMgW21h
aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz5d
IE9uIEJlaGFsZiBPZiBJYW4gU3dldHQNClNlbnQ6IEZyaWRheSwgQXByaWwgMDYsIDIwMTggMTo1
NSBQTQ0KVG86IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hv
cEBldmVxdWVmb3UuYmU+Pg0KQ2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNy
b3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tPj47IE1pa2tlbCBGYWhuw7hlIErD
uHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPj47
IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQpTdWJq
ZWN0OiBSZTogSW1wYWN0IG9mIGhhcmR3YXJlIG9mZmxvYWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVy
Zm9ybWFuY2UNCg0KUE5FIGRvZXNuJ3QgcHJlY2x1ZGUgVURQIExSTyBvciBwYWNpbmcgb2ZmbG9h
ZC4NCg0KSG93ZXZlciwgaW4gYSBoaWdobHkgb3B0aW1pemVkIHN0YWNrKGllOiBUaGUgRGlza3xD
cnlwdHxOZXQgcGFwZXIgZnJvbSBTSUdDT01NIDIwMTcpIG5vdCB0b3VjaGluZyhpZTogYnJpbmdp
bmcgaW50byBtZW1vcnkgb3IgY2FjaGUpIHRoZSBjb250ZW50IHRvIGJlIHNlbnQgdW50aWwgdGhl
IGxhc3QgcG9zc2libGUgbW9tZW50IGlzIGNyaXRpY2FsLiAgUE5FIGxpa2VseSBtZWFucyB0b3Vj
aGluZyB0aGF0IGNvbnRlbnQgbXVjaCBlYXJsaWVyLg0KDQpCdXQgcGVyc29uYWxseSBJIGNvbnNp
ZGVyIHRoZSBhY3R1YWwgY3J5cHRvIHdlJ3JlIHRhbGtpbmcgYWJvdXQoMiBBRVMgaW5zdHJ1Y3Rp
b25zPykgYWRkaW5nIGJhc2ljYWxseSBmcmVlLg0KDQpPbiBGcmksIEFwciA2LCAyMDE4IGF0IDQ6
MzcgUE0gTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzptYmlzaG9wQGV2
ZXF1ZWZvdS5iZT4+IHdyb3RlOg0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gIEkgZ3Vl
c3Mgd2hhdCBJ4oCZbSByZWFsbHkgZ2V0dGluZyBkb3duIHRvIGlzIGhvdyBkbyB3ZSBxdWFudGlm
eSB0aGUgYWN0dWFsIGNvc3Qgb2YgUE5FPyAgQXJlIHdlIHN1YnN0YW50aWFsbHkgaW5jcmVhc2lu
ZyB0aGUgY3J5cHRvIGNvc3RzPyAgSWYgSWFuIGlzIHNheWluZyB0aGF0IGNyeXB0byBpcyBjb21w
YXJhdGl2ZWx5IGNoZWFwIGFuZCB0aGUgY29zdCBpcyB0aGF0IGl04oCZcyBoYXJkZXIgdG8gb2Zm
bG9hZCBzb21ldGhpbmcgdGhhdOKAmXMgY29tcGFyYXRpdmVseSBjaGVhcCwgd2hhdCBoYXZlIHdl
IGxvc3Q/ICBJ4oCZZCB0aGluayB3ZSB3YW50IHRvIG9mZmxvYWQgdGhlIG1vc3QgaW50ZW5zaXZl
IHBpZWNlIHdlIGNhbiwgYW5kIGl0IHNlZW1zIGxpa2Ugd2XigJlyZSB0YWxraW5nIGFib3V0IGNy
eXB0byBvZmZsb2Fkcy4uLi4gIE9yIGFyZSB3ZSBzYXlpbmcgaW5zdGVhZCB0aGF0IHRoZSBjcnlw
dG8gbWFrZXMgaXQgaGFyZGVyIHRvIG9mZmxvYWQgb3RoZXIgdGhpbmdzIGluIHRoZSBmdXR1cmUs
IGxpa2UgYSBRVUlDIGVxdWl2YWxlbnQgdG8gTFJPL0xTTz8NCg0KRnJvbTogTWlra2VsIEZhaG7D
uGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpA
Z21haWwuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCA1LCAyMDE4IDk6NDUgUE0NClRvOiBJ
YW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+
PjsgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1
ZWZvdS5iZT4+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5j
b208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYu
b3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBJbXBhY3Qgb2YgaGFyZHdh
cmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZQ0KDQpUbyBiZSBjbGVhciAt
IEkgZG9u4oCZdCB0aGluayBjcnlwdG8gaXMgb3ZlcnNoYWRvd2luZyBvdGhlciBpc3N1ZXMgYXMg
TWlrZSByZWFkIG15IHBvc3QuIEl0IGNlcnRhaW5seSBjb21lcyBhdCBhIGNvc3QsIGJ1dCBlaXRo
ZXIgbXVsdGlwbGUgY29yZXMgb3IgY28tcHJvY2Vzc29ycyB3aWxsIGRlYWwgd2l0aCB0aGlzLiAx
MDAwbnMgaXMgMTBHYnBzIGNyeXB0byBzcGVlZCBvbiBvbmUgY29yZSBhbmQgaXQgaXMgaGlnbHkg
cGFyYWxsZWxpc2FibGUgYW5kIGNhY2hlIGZyaWVuZGx5Lg0KDQpCdXQgaWYgeW91IGhhdmUgdG8g
ZHJpcCB5b3VyIHBhY2tldHMgdGhyb3VnaCBhIHRyYWRpdGlvbmFsIHNlbmQgaW50ZXJmYWNlIHRo
YXQgaXMgY29weWluZywgYnVmZmVyaW5nIG9yIGJsb2NraW5nLCBhbmQgY2VydGFpbmx5IHN5bmPi
gJlpbmcgd2l0aCB0aGUga2VybmVsIC0gaXQgaXMgZ29pbmcgdG8gYmUgdG91Z2guDQoNCkZvciBy
ZWNlaXZlIHlvdSByaXNrIGhpZ2ggbGF0ZW5jeSBvciB0b3AgbXVjaCBzY2hlZHVsaW5nIGluIHJl
Y2VpdmUgYnVmZmVycy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206
IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNv
bT4+DQpTZW50OiBGcmlkYXksIEFwcmlsIDYsIDIwMTggNDowNjowMSBBTQ0KVG86IE1pa2UgQmlz
aG9wDQpDYzogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjsgUHJhdmVlbiBCYWxhc3VicmFtYW5p
YW47IElFVEYgUVVJQyBXRw0KU3ViamVjdDogUmU6IEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2Fk
cyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlDQoNCg0KT24gVGh1LCBBcHIgNSwgMjAxOCBh
dCA1OjU3IFBNIE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hv
cEBldmVxdWVmb3UuYmU+PiB3cm90ZToNClRoYXTigJlzIGludGVyZXN0aW5nIGRhdGEsIFByYXZl
ZW4g4oCTIHRoYW5rcy4gIFRoZXJlIGlzIG9uZSBjYXZlYXQgdGhlcmUsIHdoaWNoIGlzIHRoYXQg
KElJVUMsIG9uIGN1cnJlbnQgaGFyZHdhcmUpIHlvdSBjYW7igJl0IGRvIHBhY2tldCBwYWNpbmcg
d2l0aCBMU08sIGFuZCBzbyBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgZXZlbiBmb3IgVENQIG1h
bnkgcHJvdmlkZXJzIGRpc2FibGUgdGhpcyBpbiBwdXJzdWl0IG9mIGJldHRlciBlZ3Jlc3MgbWFu
YWdlbWVudC4gIFNvIHdoYXQgd2XigJlyZSByZWFsbHkgc2F5aW5nIGlzIHRoYXQ6DQoNCiAgKiAg
IE9uIGN1cnJlbnQgaGFyZHdhcmUgYW5kIE9TIHNldHVwcywgVURQIHJ1bnMgbGVzcyB0aGFuIGhh
bGYgYXMgbXVjaCB0aHJvdWdocHV0IGFzIFRDUDsgdGhhdCBuZWVkcyBzb21lIG9wdGltaXphdGlv
biwgYXMgd2XigJl2ZSBhbHJlYWR5IGRpc2N1c3NlZA0KICAqICAgVENQIHdpbGwgZHJhbWF0aWNh
bGx5IGdhaW4gcGVyZm9ybWFuY2Ugb25jZSBoYXJkd2FyZSBvZmZsb2FkIGNhdGNoZXMgdXAgYW5k
IGFsbG93cyBwYWNlZCBMU08g8J+Yig0KDQpIb3dldmVyLCBhcyBNaWtrZWwgcG9pbnRzIG91dCwg
dGhlIGNyeXB0byBjb3N0cyBhcmUgbGlrZWx5IHRvIG92ZXJ3aGVsbSB0aGUgT1MgdGhyb3VnaHB1
dCAvIHNjaGVkdWxpbmcgaXNzdWVzIGluIHJlYWwgZGVwbG95bWVudHMuICBTbyBJIHRoaW5rIHRo
ZSBvdGhlciByZWxldmFudCBwaWVjZSB0byB1bmRlcnN0YW5kaW5nIHRoZSBjb3N0IGhlcmUgaXMg
dGhpczoNCg0KSSBoYXZlIGEgZmV3IGNhc2VzKGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIpIHdoZXJl
IG15IFVEUCBzZW5kIGNvc3RzIGFyZSBtb3JlIHRoYW4gMzAlKGluIHNvbWUgY2FzZXMgNTAlKSBv
ZiBDUFUgY29uc3VtcHRpb24sIGFuZCBjcnlwdG8gaXMgbGVzcyB0aGFuIDEwJS4gIFNvIGN1cnJl
bnRseSwgSSBhc3N1bWUgY3J5cHRvIGlzIGNoZWFwKGVzcGVjaWFsbHkgQUVTLUdDTSB3aGVuIGhh
cmR3YXJlIGFjY2VsZXJhdGlvbiBpcyBhdmFpbGFibGUpIGFuZCBlZ3Jlc3MgaXMgZXhwZW5zaXZl
LiAgVURQIGluZ3JlcyBpcyBub3QgdGhhdCBleHBlbnNpdmUsIGJ1dCBjb3VsZCB1c2UgYSBiaXQg
b2Ygb3B0aW1pemF0aW9uIGFzIHdlbGwuDQoNClRoZSBvbmx5ICdmYW5jeScgdGhpbmcgb3VyIGN1
cnJlbnQgY29kZSBpcyBkb2luZyBmb3IgY3J5cHRvIGlzIGVuY3J5cHRpbmcgaW4gcGxhY2UsIHdo
aWNoIHdhcyBhIH4yJSB3aW4uICBOaWNlLCBidXQgbm90IHRyYW5zZm9ybWF0aXZlLiAgU2VlIEVu
Y3J5cHRJblBsYWNlPGh0dHBzOi8vY3MuY2hyb21pdW0ub3JnL2Nocm9taXVtL3NyYy9uZXQvcXVp
Yy9jb3JlL3F1aWNfZnJhbWVyLmNjP3NxPXBhY2thZ2U6Y2hyb21pdW0mbD0xODkzPg0KDQpJIGhh
dmVuJ3QgZG9uZSBtdWNoIHdvcmsgYmVuY2htYXJraW5nIFdpbmRvd3MsIHNvIHBvc3NpYmx5IHRo
ZSBXaW5kb3dzIFVEUCBzdGFjayBpcyByZWFsbHkgZmFzdCwgYW5kIHNvIGNyeXB0byBzZWVtcyBy
ZWFsbHkgc2xvdyBpbiBjb21wYXJpc29uPw0KDQoNCiAgKiAgIFdoYXQgaXMgdGhlIHRocm91Z2hw
dXQgYW5kIHJlbGF0aXZlIGNvc3Qgb2YgVExTL1RDUCB2ZXJzdXMgUVVJQyAoaS5lLiBob3cgbXVj
aCBhcmUgdGhlIHNtYWxsZXIgdW5pdHMgb2YgZW5jcnlwdGlvbiBodXJ0aW5nIHVzIHZlcnN1cywg
c2F5LCAxNktCIFRMUyByZWNvcmRzKT8NCg0KICAgICAqICAgVExTIGltcGxlbWVudGF0aW9ucyBh
bHJlYWR5IHZhcnkgaGVyZTogIFNvbWUgaW1wbGVtZW50YXRpb25zIGNob29zZSBsYXJnZSByZWNv
cmQgc2l6ZXMsIHNvbWUgdmFyeSByZWNvcmQgc2l6ZXMgdG8gcmVkdWNlIGRlbGF5IC8gSG9MQiwg
c28gdGhpcyBwcm9iYWJseSBpc27igJl0IGEgc2luZ2xlIG51bWJlci4NCg0KICAqICAgSG93IG11
Y2ggYWRkaXRpb25hbCBsb2FkIGRvZXMgUE5FIGFkZCB0byB0aGlzIGRpZmZlcmVuY2U/DQogICog
ICBUbyB3aGF0IGV4dGVudCB3b3VsZCBQTkUgbWFrZSBmdXR1cmUgY3J5cHRvIG9mZmxvYWRzIGlt
cG9zc2libGUgdmVyc3VzIHJlcXVpcmVzIG1vcmUgUiZEIHRvIGRldmVsb3A/DQoNCkZyb206IFFV
SUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm
Lm9yZz5dIE9uIEJlaGFsZiBPZiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuDQpTZW50OiBXZWRu
ZXNkYXksIEFwcmlsIDQsIDIwMTggMTozNCBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFu
IDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbWljcm9zb2Z0
LmNvbUBkbWFyYy5pZXRmLm9yZz4+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRv
OnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2Fk
cyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlDQoNClRoYW5rcyBmb3Igc2hhcmluZyB0aGVz
ZSBudW1iZXJzLg0KDQpNeSBndWVzcyBpcyB0aGF0IHRoZXNlIG9mZmxvYWRzIGRlYWwgd2l0aCBr
ZXJuZWwgc2NoZWR1bGluZywgbWVtb3J5IGNhY2hlIGlzc3VlcywgYW5kIGludGVycnVwdCBzY2hl
ZHVsaW5nLg0KDQpJdCBwcm9iYWJseSBoYXMgdmVyeSBsaXR0bGUgdG8gZG8gd2l0aCBjcnlwdG8s
IFRDUCBoZWFkZXJzLCBhbmQgYW55IG90aGVyIGNwdSBzZW5zaXRpdmUgcHJvY2Vzc2luZy4NCg0K
VGhpcyBpcyB3aGVyZSBuZXRtYXAgZW50ZXJzOiB5b3UgY2FuIHRyYW5zcGFyZW50bHkgZmVlZCB0
aGUgZGF0YSBhcyBpdCBiZWNvbWVzIGF2YWlsYWJsZSB3aXRoIHZlcnkgbGl0dGxlIHN5bmMgd29y
ayBhbmQgeW91IGNhbiBhbHNvIGVmZmljaWVudGx5IHBpcGVsaW5lIHNvIHlvdSBwYXNzIGRhdGEg
dG8gZGVjcnlwdG9yLCB0aGVuIHRvIGFwcCwgd2l0aCBhcyBsaXR0bGUgYnVzIHRyYWZmaWMgYXMg
cG9zc2libGUuIE5vIG5lZWQgdG8gY29weSBkYXRhIG9yIHN5bmNocm9uaXplIGtlcm5lbCBzcGFj
ZS4NCg0KRm9yIDFLIHBhY2tldHMgeW91IHdvdWxkIHVzZSBhYm91dCAxMDAwbnMgKDMgY3ljbGVz
L2J5dGUpIG9uIGNyeXB0byBhbmQgdGhpcyB3b3VsZCBoYXBwZW4gaW4gTDEgY2FjaGUuIEl0IHdv
dWxkIG9mIGNvdXJzZSBjb25zdW1lIGEgY29yZSB3aGljaCBhIGNyeXB0byBvZmZsb2FkIHdvdWxk
IG5vdCwgYnV0IHRoYXQgY2FuIGJlIGRlYmF0ZWQgYmVjYXVzZSB3aXRoIDE4IGNvcmUgc3lzdGVt
cywgeW91ciBwcm9ibGVtIGlzIG1lbW9yeSBhbmQgbmV0d29yayBtb3JlIHRoYW4gQ1BVLg0KDQpN
eSBjb25jZXJuIHdpdGggUE5FIGlzIGZvciBzbWFsbCBwYWNrZXRzIGFuZCBsb3cgbGF0ZW5jeSB3
aGVyZQ0KMSkgYW4gZXN0aW1hdGVkIDI0bnMgZm9yIFBOIGVuY3J5cHRpb24gYW5kIGRlY3J5cHRp
b24gYmVjb21lcyBtZWFzdXJhYmxlIGlmIHlvdXIgbmV0d29yayBpcyBmYXN0IGVub3VnaC4NCjIp
IGFueSBkYW1hZ2UgdG8gdGhlIHBhY2tldCBidWZmZXIgY2F1c2UgYWxsIHNvcnRzIG9mIG1lbW9y
eSBhbmQgY3B1IGJ1cyB0cmFmZmljIGlzc3Vlcy4NCg0KMSkgaXMgYW5ub3lpbmcuIDIpIGlzIGJh
ZCwgY29tcGxldGVseSBhdm9pZGFibGUgYnV0IG5vdCBhcyBQUiAxMDc5IGlzIGZvcm11bGF0ZWQg
Y3VycmVudGx5Lg0KDQoyKSBpcyBhbHNvIGxpa2VseSBiYWQgZm9yIGhhcmR3YXJlIG9mZmxvYWQg
dW5pdHMgYXMgd2VsbC4NCg0KQXMgdG8gU1JWLUlPIC0gSeKAmW0gbm90IGZhbWlsaWFyIHdpdGgg
aXQsIGJ1dCBvYnZpb3VzbHkgdGhlcmUgaXMgc29tZSBJTyBhYnN0cmFjdGlvbiBsYXllciAtIHRo
ZSBxdWVzdGlvbiBpcyBob3cgeW91IG1ha2UgaXQgYWNjZXNzaWJsZSB0byBhcHBzIGFzIG9wcG9z
ZWQgdG8gZGV2aWNlIGRyaXZlcnMgdGhhdCBkb2VzIG5vciB3b3JrIHdpdGggeW91IFFVSUMgY3Vz
dG9tIHN0YWNrLCBhbmQgbmV0bWFwIGlzIG9uZSBvcHRpb24gaGVyZS4NCg0KS2luZCBSZWdhcmRz
LA0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KDQoNCk9uIDQgQXByaWwgMjAxOCBhdCAyMi4x
NS41MiwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gKHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFy
Yy5pZXRmLm9yZzxtYWlsdG86cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPikg
d3JvdGU6DQpTb21lIGNvbXBhcmF0aXZlIG51bWJlcnMgZnJvbSBhbiBvdXQgb2YgYm94IGRlZmF1
bHQgc2V0dGluZ3MgV2luZG93cyBTZXJ2ZXIgMjAxNiAocmVsZWFzZWQgdmVyc2lvbikgZm9yIGEg
c2luZ2xlIGNvbm5lY3Rpb24gd2l0aCBhIG1pY3JvYmVuY2htYXJrIHRvb2w6DQoNCk9mZmxvYWRz
IGVuYWJsZWQNCg0KVENQIGdicHMNCg0KVURQIGdicHMNCg0KTFNPICsgTFJPICsgY2hlY2tzdW0N
Cg0KMjQNCg0KMy42DQoNCkNoZWNrc3VtIG9ubHkNCg0KNy42DQoNCjMuNg0KDQpOb25lDQoNCjUu
Ng0KDQoyLjMNCg0KDQpUaGlzIGlzIGZvciBhIGZ1bGx5IGJvdHRsZW5lY2tlZCBDUFUgY29yZSAt
LSBpZiB5b3UgcnVuIGxvd2VyIGRhdGEgcmF0ZXMgdGhlcmUgaXMgc3RpbGwgYSBzaWduaWZpY2Fu
dCBkaWZmZXJlbmNlIGluIEN5Y2xlcy9ieXRlIGNvc3QuIFNhbWUgaW5jcmVhc2VkIENQVSBjb3N0
IGFwcGxpZXMgZm9yIGNsaWVudCBzeXN0ZW1zIGdvaW5nIG92ZXIgaGlnaCBkYXRhIHJhdGUgV2lm
aSBhbmQgY2VsbHVsYXIuDQoNClRoaXMgaXMgd2l0aG91dCBhbnkgY3J5cHRvLiBPbmNlIHlvdSBh
ZGQgY3J5cHRvIHRoZSBudW1iZXJzIGJlY29tZSBtdWNoIHdvcnNlIHdpdGggY3J5cHRvIGNvc3Qg
YmVjb21pbmcgZG9taW5hbnQuIEFkZGluZyBhbm90aGVyIGNyeXB0byBzdGVwIGZ1cnRoZXIgZXhh
Y2VyYmF0ZXMgdGhlIHByb2JsZW0uIEhlbmNlIGNyeXB0byBvZmZsb2FkIGdhaW5zIGluIGltcG9y
dGFuY2UgZm9sbG93ZWQgYnkgdGhlc2UgYmF0Y2ggb2ZmbG9hZHMuDQoNCklmIGZvbGtzIG5lZWQg
YW55IG1vcmUgbnVtYmVycyBJ4oCZZCBiZSBoYXBweSB0byBwcm92aWRlIHRoZW0uDQoNClRoYW5r
cw0KDQo=

--_000_1F436ED13A22A246A59CA374CBC543998B60C851ORSMSX111amrcor_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC
My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv
ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S
RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj
b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFt
c29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhh
dmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1M
KTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5k
aWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSBFbW9qaSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAy
IDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O
b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz
ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk
LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4
dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuYWlybWFpbG9uLCBsaS5haXJtYWlsb24sIGRp
di5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5
bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAubS0y
MDE3NzE0MDQwMTM3MTE2MzQ5bS05MDA0OTE3MTQ5NDA1NTk0MTQzYWlybWFpbG9uLCBsaS5tLTIw
MTc3MTQwNDAxMzcxMTYzNDltLTkwMDQ5MTcxNDk0MDU1OTQxNDNhaXJtYWlsb24sIGRpdi5tLTIw
MTc3MTQwNDAxMzcxMTYzNDltLTkwMDQ5MTcxNDk0MDU1OTQxNDNhaXJtYWlsb24NCgl7bXNvLXN0
eWxlLW5hbWU6bS0yMDE3NzE0MDQwMTM3MTE2MzQ5bS05MDA0OTE3MTQ5NDA1NTk0MTQzYWlybWFp
bG9uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox
Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl
IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g
MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov
KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0OTYyNjQ0Njk7
DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjExNzUyMzMyODI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv
bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u
MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9
DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m
b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K
CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv
bDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z
aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl
bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C
tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0
Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5
bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t
YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0K
CXttc28tbGlzdC1pZDo3MjQ1MzA0MzA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zMzE3Mzk1
Nzg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z
aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl
bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C
tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0
Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5
bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t
YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps
ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu
MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt
c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs
MTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxNTMyMzAzMDg3Ow0KCW1zby1s
aXN0LXRlbXBsYXRlLWlkczotNDE5MjQ1NzIwO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl
bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg
bDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp
c3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z
aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu
MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K
QGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u
dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxp
c3QtaWQ6MjAxMTEwNTE0MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEzMTQ0Nzc0ODY7fQ0K
QGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250
LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv
LWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz
OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl
bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0
IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp
bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9s
DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv
c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl
ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i
ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv
aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk
aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+SeKAmW0gdHJ5aW5nIHRvIGxheSBvdXQgdGhlIG9wdGlvbnMg
Zm9yIFRTTy9MU08gd2l0aCBRVUlDLiBJbiBteSBwcmV2aW91cyBlLW1haWwgSSBjb21wYXJlZCB0
aGUgb3V0Y29tZSBvZiB2YW5pbGxhIFVEUCBzZWdtZW50YXRpb24gYXMgZGVmaW5lZCBieSB0aGUg
bGF0ZXN0IHBhdGNoDQogKDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6
Ly9tYXJjLmluZm8vP2w9bGludXgtbmV0ZGV2JmFtcDttPTE1MjM5OTUzMDYwMzk5MiZhbXA7dz0y
Ij5odHRwczovL21hcmMuaW5mby8/bD1saW51eC1uZXRkZXYmYW1wO209MTUyMzk5NTMwNjAzOTky
JmFtcDt3PTI8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiksDQo8L3NwYW4+PC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50byBhbiBhbHRlcm5hdGl2ZSBuYXRpdmUg
UVVJQyBzZWdtZW50YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj5BIHNlZ21lbnQgaXMgYSBsYXJnZSBidWZmZXIgcHJvZHVjZWQgaW4gYW4gYXBwbGljYXRp
b24uIFRoZSBzZWdtZW50IGlzIG9mdGVuIG11Y2ggdG9vIGxhcmdlIHRvIGdvIG91dCBvbiB0aGUg
d2lyZSB3aXRoIGp1c3QgcHJlLXBlbmRlZCBoZWFkZXJzLiBUaGVyZWZvcmUgc2VnbWVudA0KIG5l
ZWRzIHRvIGJlIGNob3BwZWQgdXAgaW50byBhcHByb3ByaWF0ZSBzaXplIGFuZCB0aGUgcHJlLXBl
bmRlZCBoZWFkZXJzIG5lZWQgdG8gYmUgcmVwbGljYXRlZCB0byBtYWtlIE1UVSBzaXplIHBhY2tl
dHMgZm9yIHRoZSB3aXJlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj5J4oCZbSBzdWdnZXN0aW5nIHRoYXQgd2Ugc2hvdWxkIGNvbnNpZGVyIHByb2Nlc3Npbmcg
YSBsYXJnZSBkYXRhIGJ1ZmZlciBhcyBtdWx0aXBsZSBRVUlDIHBhY2tldHMgZWFjaCB3aXRoIGEg
dW5pcXVlIFBOLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5U
aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1hbmFzaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp
bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtrZWxm
akBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAyMywgMjAxOCAx
MToyNSBBTTxicj4NCjxiPlRvOjwvYj4gSWFuIFN3ZXR0ICZsdDtpYW5zd2V0dD00MGdvb2dsZS5j
b21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OyBEZXZhbCwgTWFuYXNpICZsdDttYW5hc2kuZGV2YWxAaW50
ZWwuY29tJmd0OzsgTWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJlJmd0Ozxicj4N
CjxiPkNjOjwvYj4gSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgUHJhdmVlbiBC
YWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJFOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBw
ZXJmb3JtYW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgaWQ9ImJsb29wX2N1c3Rv
bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPknigJltIG5v
dCByZWFsbHkgZmFtaWxpYXIgd2l0aCB0aGlzIGR1bXAgYnV0IHdoYXQgZG9lcyBwYXJ0aWFsIHNl
Z21lbnRhdGlvbiBtZWFuIGhlcmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJs
b29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PkFyZSB5b3Ugc3BsaXR0aW5nIGEgc2luZ2xlIFVEUCBkYXRhZ3JhbSBpbnRvIG11bHRpcGxlIGZy
YWdtZW50cywgb3IgYXJlIHlvdSBwcm9jZXNzaW5nIG11bHRpcGxlIHNlcGFyYXRlIFFVSUMgcGFj
a2V0cywgb25lIFBOIGVhY2g/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk
PSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29w
X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklm
IHlvdSBmcmFnbWVudCBVRFAgZGF0YWdyYW1zLCB0aGF0IGNhbiBiZSBhIGJpZyBpc3N1ZSBiZWNh
dXNlIGRpZmZlcmVudCBmcmFnbWVudHMgbWF5IHJhY2UgYWxvbmcgZGlmZmVyZW50IHJvdXRlcywg
Y2F1c2luZyB1bmV4cGVjdGVkIGRlbGF5cyBhbmQgYmxvY2tpbmcgYXQgdGhlIG90aGVyIGVuZC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX3NpZ25fMTUyNDUw
NzczMDAzMDU2Mzg0MCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9u
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMjMgQXByaWwgMjAxOCBhdCAyMC4xOC41NCwgRGV2YWws
IE1hbmFzaSAoPGEgaHJlZj0ibWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5jb20iPm1hbmFzaS5k
ZXZhbEBpbnRlbC5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPklmIHdlIGRvIFRTTyAvIExTTyB3aXRoIFFVSUMsIHRoZSBpbml0aWFsIHNl
Z21lbnQgcHJvdmlkZWQgY2FuIGxvb2sgbGlrZSDigJM8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NQUMg
4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMgQ2xlYXIg4oCTIFFVSUMgZW5jcnlwdGVkIGhlYWRlciAo
UE49eCkg4oCTIFFVSUMgRW5jcnlwdGVkIHBheWxvYWQuDQo8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB3ZSBqdXN0IHVzZSB0aGUgc3RhY2vigJlz
IHVkcCBzZWdtZW50YXRpb24gKHVzaW5nIHRoZSBwYXRjaCAtDQo8L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8vbWFyYy5pbmZvLz9sPWxpbnV4LW5ldGRldiZhbXA7bT0x
NTIzOTk1MzA2MDM5OTImYW1wO3c9MiI+aHR0cHM6Ly9tYXJjLmluZm8vP2w9bGludXgtbmV0ZGV2
JmFtcDttPTE1MjM5OTUzMDYwMzk5MiZhbXA7dz0yPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj4pLCB0aGUgb3V0Y29tZSBvZiBRVUlDIHBhY2tldHMNCiBvbiB0aGUgd2lyZSB3b3VsZCBi
ZTo8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TUFDIOKAkyBJUCDigJMgVURQIOKAkyBRVUlD
IENsZWFyIOKAkyBRVUlDIGVuY3J5cHRlZCBwYXJ0IChQTj14LCBwYXJ0aWFsIHNlZ21lbnQgMS8z
KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBlbmNyeXB0
ZWQgcGFydCAocGFydGlhbCBzZWdtZW50IDIvMyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NQUMg4oCT
IElQIOKAkyBVRFAg4oCTIFFVSUMgZW5jcnlwdGVkIHBhcnQgKHBhcnRpYWwgc2VnbWVudCAzLzMp
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+UHV0dGluZyB0aGVzZSBiYWNrIHRvZ2V0aGVyIGluIGEgc3RhY2sgLyBo
YXJkd2FyZSBsb29rcyBsaWtlIGEgcGFpbmZ1bCBhbmQgcG90ZW50aWFsbHkgbm9uLWRldGVybWlu
aXN0aWMNCiBhY3Rpdml0eS4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SXQgd291bGQgYmUgZWFzaWVyIHRv
IGRvIGEgbmF0aXZlIFFVSUMgb2ZmbG9hZCwgd2hlcmUgdGhlIHBhY2tldCBvbiB3aXJlIGNhbiBi
ZSBpZGVudGlmaWVkIGJ5IFFVSUMNCiBDaUQgYW5kIGFwcHJvcHJpYXRlIHBhY2tldCBudW1iZXIu
IFRoZXJlZm9yZSwgb3JpZ2luYWwgcGFja2V0IGxvb2tzIGxpa2UgLSBNQUMg4oCTIElQIOKAkyBV
RFAg4oCTIFFVSUMgQ2xlYXIg4oCTIFFVSUMgZW5jcnlwdGVkIGhlYWRlciAoUE49eCkg4oCTIFFV
SUMgRW5jcnlwdGVkIHBheWxvYWQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB3ZSBqdXN0IGNy
ZWF0ZSBhbm90aGVyIHZlcnNpb24gb2Ygc2VnbWVudGF0aW9uIGNhbGxlZCBRVUlDIHNlZ21lbnRh
dGlvbiwgdGhlIG91dGNvbWUgb2YgcGFja2V0cw0KIG9uIHRoZSB3aXJlIHdvdWxkIGJlOjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJ
QyBlbmNyeXB0ZWQgcGFydCAoUE49eCwgcGFydGlhbCBzZWdtZW50IDEvMyk8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj5NQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMgQ2xlYXIg4oCTIFFVSUMgZW5jcnlw
dGVkIHBhcnQgKFBOPXgmIzQzOzEsIHBhcnRpYWwgc2VnbWVudCAyLzMpPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+TUFDIOKAkyBJUCDigJMgVURQIOKAkyBRVUlDIENsZWFyIOKAkyBRVUlDIGVuY3J5cHRl
ZCBwYXJ0IChQTj14JiM0MzsyLCBwYXJ0aWFsIHNlZ21lbnQgMy8zKTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPuKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHRoaXMgc2V0IG9mIHNlZ21lbnRzIHdlcmUg
dG8gYmUgcmUtYXNzZW1ibGVkLCB0aGUgYWJpbGl0eSB0byBpZGVudGlmeSBDaUQgYW5kIFBOIHdv
dWxkIHNpbXBsaWZ5DQogdGhpcyB0YXNrLiBJIHRoaW5rIHRoaXMgaXMgYSBzaW1wbGVyIGltcGxl
bWVudGF0aW9uLiBEbyBvdGhlcnMgc2VlIGFuIGlzc3VlIHdpdGggdGhpcz88L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+TWFuYXNpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBRVUlD
IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3Vu
Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SWFuIFN3ZXR0PGJyPg0KPGI+
U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMDYsIDIwMTggMTo1NSBQTTxicj4NCjxiPlRvOjwvYj4g
TWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSI+bWJp
c2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUHJhdmVlbiBCYWxhc3Vi
cmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIj5wcmF2YkBt
aWNyb3NvZnQuY29tPC9hPiZndDs7IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0OzxhIGhy
ZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT4mZ3Q7
OyBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGll
dGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEltcGFjdCBvZiBoYXJkd2Fy
ZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBORSBkb2Vzbid0IHByZWNsdWRlIFVEUCBMUk8gb3Ig
cGFjaW5nIG9mZmxvYWQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+SG93ZXZlciwgaW4gYSBoaWdobHkgb3B0aW1pemVkIHN0YWNrKGllOiBUaGUgRGlz
a3xDcnlwdHxOZXQgcGFwZXIgZnJvbSBTSUdDT01NIDIwMTcpIG5vdCB0b3VjaGluZyhpZTogYnJp
bmdpbmcgaW50byBtZW1vcnkgb3IgY2FjaGUpIHRoZSBjb250ZW50IHRvIGJlIHNlbnQgdW50aWwg
dGhlIGxhc3QgcG9zc2libGUNCiBtb21lbnQgaXMgY3JpdGljYWwuJm5ic3A7IFBORSBsaWtlbHkg
bWVhbnMgdG91Y2hpbmcgdGhhdCBjb250ZW50IG11Y2ggZWFybGllci48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJ1dCBwZXJzb25hbGx5
IEkgY29uc2lkZXIgdGhlIGFjdHVhbCBjcnlwdG8gd2UncmUgdGFsa2luZyBhYm91dCgyIEFFUyBp
bnN0cnVjdGlvbnM/KSBhZGRpbmcgYmFzaWNhbGx5IGZyZWUuJm5ic3A7Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmks
IEFwciA2LCAyMDE4IGF0IDQ6MzcgUE0gTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzpt
YmlzaG9wQGV2ZXF1ZWZvdS5iZSI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0OyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt
YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhh
bmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4mbmJzcDsgSSBndWVzcyB3aGF0IEnigJltIHJlYWxs
eSBnZXR0aW5nIGRvd24gdG8gaXMgaG93IGRvIHdlIHF1YW50aWZ5IHRoZSBhY3R1YWwNCjxpPmNv
c3Q8L2k+IG9mIFBORT8mbmJzcDsgQXJlIHdlIHN1YnN0YW50aWFsbHkgaW5jcmVhc2luZyB0aGUg
Y3J5cHRvIGNvc3RzPyZuYnNwOyBJZiBJYW4gaXMgc2F5aW5nIHRoYXQgY3J5cHRvIGlzIGNvbXBh
cmF0aXZlbHkgY2hlYXAgYW5kIHRoZSBjb3N0IGlzIHRoYXQgaXTigJlzIGhhcmRlciB0byBvZmZs
b2FkIHNvbWV0aGluZyB0aGF04oCZcyBjb21wYXJhdGl2ZWx5IGNoZWFwLCB3aGF0IGhhdmUgd2Ug
bG9zdD8mbmJzcDsgSeKAmWQgdGhpbmsgd2Ugd2FudCB0byBvZmZsb2FkIHRoZQ0KIG1vc3QgaW50
ZW5zaXZlIHBpZWNlIHdlIGNhbiwgYW5kIGl0IHNlZW1zIGxpa2Ugd2XigJlyZSB0YWxraW5nIGFi
b3V0IGNyeXB0byBvZmZsb2Fkcy4uLi4mbmJzcDsgT3IgYXJlIHdlIHNheWluZyBpbnN0ZWFkIHRo
YXQgdGhlIGNyeXB0byBtYWtlcyBpdCBoYXJkZXIgdG8gb2ZmbG9hZCBvdGhlciB0aGluZ3MgaW4g
dGhlIGZ1dHVyZSwgbGlrZSBhIFFVSUMgZXF1aXZhbGVudCB0byBMUk8vTFNPPzxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZy
b206PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv
Om1pa2tlbGZqQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1pa2tlbGZqQGdtYWlsLmNvbTwv
YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDUsIDIwMTggOTo0NSBQTTxi
cj4NCjxiPlRvOjwvYj4gSWFuIFN3ZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29v
Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0OzsgTWlr
ZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0
PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFBy
YXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsgSUVURiBR
VUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi
PnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSW1wYWN0IG9m
IGhhcmR3YXJlIG9mZmxvYWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVyZm9ybWFuY2U8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPGRpdiBpZD0ibV8tMjAxNzcxNDA0MDEzNzExNjM0OWNvbXBvc2UtY29udGFp
bmVyIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VG8gYmUg
Y2xlYXIgLSBJIGRvbuKAmXQgdGhpbmsgY3J5cHRvIGlzIG92ZXJzaGFkb3dpbmcgb3RoZXIgaXNz
dWVzIGFzIE1pa2UgcmVhZCBteSBwb3N0LiBJdCBjZXJ0YWlubHkgY29tZXMgYXQgYSBjb3N0LCBi
dXQgZWl0aGVyIG11bHRpcGxlIGNvcmVzIG9yIGNvLXByb2Nlc3NvcnMgd2lsbCBkZWFsIHdpdGgg
dGhpcy4NCiAxMDAwbnMgaXMgMTBHYnBzIGNyeXB0byBzcGVlZCBvbiBvbmUgY29yZSBhbmQgaXQg
aXMgaGlnbHkgcGFyYWxsZWxpc2FibGUgYW5kIGNhY2hlIGZyaWVuZGx5LjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QnV0IGlmIHlvdSBo
YXZlIHRvIGRyaXAgeW91ciBwYWNrZXRzIHRocm91Z2ggYSB0cmFkaXRpb25hbCBzZW5kIGludGVy
ZmFjZSB0aGF0IGlzIGNvcHlpbmcsIGJ1ZmZlcmluZyBvciBibG9ja2luZywgYW5kIGNlcnRhaW5s
eSBzeW5j4oCZaW5nIHdpdGggdGhlIGtlcm5lbCAtIGl0IGlzIGdvaW5nIHRvIGJlIHRvdWdoLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Rm9yIHJlY2VpdmUgeW91IHJpc2sgaGlnaCBsYXRlbmN5IG9yIHRvcCBtdWNoIHNjaGVkdWxpbmcg
aW4gcmVjZWl2ZSBidWZmZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls
ZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4NCjxociBzaXplPSIyIiB3
aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9Im1fLTIw
MTc3MTQwNDAxMzcxMTYzNDlkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImNvbG9yOmJsYWNrIj4gSWFuIFN3ZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29v
Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4N
CjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDYsIDIwMTggNDowNjowMSBBTTxicj4NCjxiPlRv
OjwvYj4gTWlrZSBCaXNob3A8YnI+DQo8Yj5DYzo8L2I+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5z
ZW47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuOyBJRVRGIFFVSUMgV0c8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUmU6IEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBl
cmZvcm1hbmNlPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
YXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBBcHIgNSwgMjAxOCBhdCA1OjU3IFBNIE1p
a2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiIHRhcmdl
dD0iX2JsYW5rIj5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGF04oCZcyBpbnRl
cmVzdGluZyBkYXRhLCBQcmF2ZWVuIOKAkyB0aGFua3MuJm5ic3A7IFRoZXJlIGlzIG9uZSBjYXZl
YXQgdGhlcmUsIHdoaWNoIGlzIHRoYXQgKElJVUMsIG9uIGN1cnJlbnQgaGFyZHdhcmUpIHlvdSBj
YW7igJl0IGRvIHBhY2tldCBwYWNpbmcgd2l0aCBMU08sIGFuZCBzbyBteSB1bmRlcnN0YW5kaW5n
IGlzDQogdGhhdCBldmVuIGZvciBUQ1AgbWFueSBwcm92aWRlcnMgZGlzYWJsZSB0aGlzIGluIHB1
cnN1aXQgb2YgYmV0dGVyIGVncmVzcyBtYW5hZ2VtZW50LiZuYnNwOyBTbyB3aGF0IHdl4oCZcmUg
cmVhbGx5IHNheWluZyBpcyB0aGF0OjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0K
PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQo8c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+T24gY3VycmVudCBoYXJkd2FyZSBhbmQgT1Mgc2V0dXBzLCBVRFAgcnVucyBs
ZXNzIHRoYW4gaGFsZiBhcyBtdWNoIHRocm91Z2hwdXQgYXMgVENQOyB0aGF0IG5lZWRzIHNvbWUg
b3B0aW1pemF0aW9uLCBhcyB3ZeKAmXZlIGFscmVhZHkgZGlzY3Vzc2VkPG86cD48L286cD48L3Nw
YW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4N
CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5UQ1Agd2lsbCBkcmFtYXRpY2FsbHkgZ2FpbiBwZXJmb3JtYW5j
ZSBvbmNlIGhhcmR3YXJlIG9mZmxvYWQgY2F0Y2hlcyB1cCBhbmQgYWxsb3dzDQo8dT5wYWNlZDwv
dT4gTFNPIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj7wn5iKPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3dl
dmVyLCBhcyBNaWtrZWwgcG9pbnRzIG91dCwgdGhlIGNyeXB0byBjb3N0cyBhcmUgbGlrZWx5IHRv
IG92ZXJ3aGVsbSB0aGUgT1MgdGhyb3VnaHB1dCAvIHNjaGVkdWxpbmcgaXNzdWVzIGluIHJlYWwg
ZGVwbG95bWVudHMuJm5ic3A7IFNvIEkgdGhpbmsgdGhlIG90aGVyIHJlbGV2YW50IHBpZWNlIHRv
IHVuZGVyc3RhbmRpbmcNCiB0aGUgY29zdCBoZXJlIGlzIHRoaXM6PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPkkgaGF2ZSBhIGZldyBjYXNlcyhib3RoIGNsaWVudCBhbmQgc2VydmVyKSB3aGVyZSBt
eSBVRFAgc2VuZCBjb3N0cyBhcmUgbW9yZSB0aGFuIDMwJShpbiBzb21lIGNhc2VzIDUwJSkgb2Yg
Q1BVIGNvbnN1bXB0aW9uLCBhbmQgY3J5cHRvIGlzIGxlc3MgdGhhbiAxMCUuJm5ic3A7IFNvIGN1
cnJlbnRseSwgSSBhc3N1bWUNCiBjcnlwdG8gaXMgY2hlYXAoZXNwZWNpYWxseSBBRVMtR0NNIHdo
ZW4gaGFyZHdhcmUgYWNjZWxlcmF0aW9uIGlzIGF2YWlsYWJsZSkgYW5kIGVncmVzcyBpcyBleHBl
bnNpdmUuJm5ic3A7IFVEUCBpbmdyZXMgaXMgbm90IHRoYXQgZXhwZW5zaXZlLCBidXQgY291bGQg
dXNlIGEgYml0IG9mIG9wdGltaXphdGlvbiBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIG9ubHkgJ2ZhbmN5JyB0aGlu
ZyBvdXIgY3VycmVudCBjb2RlIGlzIGRvaW5nIGZvciBjcnlwdG8gaXMgZW5jcnlwdGluZyBpbiBw
bGFjZSwgd2hpY2ggd2FzIGEgfjIlIHdpbi4mbmJzcDsgTmljZSwgYnV0IG5vdCB0cmFuc2Zvcm1h
dGl2ZS4mbmJzcDsgU2VlDQo8YSBocmVmPSJodHRwczovL2NzLmNocm9taXVtLm9yZy9jaHJvbWl1
bS9zcmMvbmV0L3F1aWMvY29yZS9xdWljX2ZyYW1lci5jYz9zcT1wYWNrYWdlOmNocm9taXVtJmFt
cDtsPTE4OTMiIHRhcmdldD0iX2JsYW5rIj4NCkVuY3J5cHRJblBsYWNlPC9hPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBoYXZlbid0
IGRvbmUgbXVjaCB3b3JrIGJlbmNobWFya2luZyBXaW5kb3dzLCBzbyBwb3NzaWJseSB0aGUgV2lu
ZG93cyBVRFAgc3RhY2sgaXMgcmVhbGx5IGZhc3QsIGFuZCBzbyBjcnlwdG8gc2VlbXMgcmVhbGx5
IHNsb3cgaW4gY29tcGFyaXNvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8
dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVs
MSBsZm8yIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5XaGF0IGlzIHRoZSB0aHJvdWdocHV0IGFuZCBy
ZWxhdGl2ZSBjb3N0IG9mIFRMUy9UQ1AgdmVyc3VzIFFVSUMgKGkuZS4gaG93IG11Y2ggYXJlIHRo
ZSBzbWFsbGVyIHVuaXRzIG9mIGVuY3J5cHRpb24gaHVydGluZyB1cyB2ZXJzdXMsIHNheSwgMTZL
QiBUTFMgcmVjb3Jkcyk/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8dWwgdHlwZT0i
ZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp
c3Q6bDMgbGV2ZWwyIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRMUyBpbXBsZW1lbnRhdGlv
bnMgYWxyZWFkeSB2YXJ5IGhlcmU6Jm5ic3A7IFNvbWUgaW1wbGVtZW50YXRpb25zIGNob29zZSBs
YXJnZSByZWNvcmQgc2l6ZXMsIHNvbWUgdmFyeSByZWNvcmQgc2l6ZXMgdG8gcmVkdWNlIGRlbGF5
IC8gSG9MQiwgc28gdGhpcyBwcm9iYWJseSBpc27igJl0IGEgc2luZ2xlIG51bWJlci48bzpwPjwv
bzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvNCI+DQo8c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+SG93IG11Y2ggYWRkaXRpb25hbCBsb2FkIGRvZXMgUE5FIGFkZCB0byB0aGlzIGRpZmZlcmVu
Y2U/PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0
OmwyIGxldmVsMSBsZm80Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UbyB3aGF0IGV4dGVudCB3b3Vs
ZCBQTkUgbWFrZSBmdXR1cmUgY3J5cHRvIG9mZmxvYWRzDQo8aT5pbXBvc3NpYmxlPC9pPiB2ZXJz
dXMgPGk+cmVxdWlyZXMgbW9yZSBSJmFtcDtEIHRvIGRldmVsb3A8L2k+PzxvOnA+PC9vOnA+PC9z
cGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF
MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5j
ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K
PGI+T24gQmVoYWxmIE9mIDwvYj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPGJyPg0KPGI+U2Vu
dDo8L2I+IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxOCAxOjM0IFBNPGJyPg0KPGI+VG86PC9iPiBQ
cmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmI9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9z
b2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbWljcm9zb2Z0LmNvbUBk
bWFyYy5pZXRmLm9yZzwvYT4mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpx
dWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K
PGI+U3ViamVjdDo8L2I+IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29y
ayBzdGFjayBwZXJmb3JtYW5jZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJtXy0yMDE3
NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGZvciBzaGFy
aW5nIHRoZXNlIG51bWJlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk
PSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3Rv
bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3
MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TXkgZ3Vlc3MgaXMgdGhhdCB0aGVzZSBv
ZmZsb2FkcyBkZWFsIHdpdGgga2VybmVsIHNjaGVkdWxpbmcsIG1lbW9yeSBjYWNoZSBpc3N1ZXMs
IGFuZCBpbnRlcnJ1cHQgc2NoZWR1bGluZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXYgaWQ9Im1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxv
b3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTIwMTc3
MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JdCBwcm9iYWJseSBoYXMg
dmVyeSBsaXR0bGUgdG8gZG8gd2l0aCBjcnlwdG8sIFRDUCBoZWFkZXJzLCBhbmQgYW55IG90aGVy
IGNwdSBzZW5zaXRpdmUgcHJvY2Vzc2luZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXYgaWQ9Im1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxv
b3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTIwMTc3
MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIHdoZXJlIG5l
dG1hcCBlbnRlcnM6IHlvdSBjYW4gdHJhbnNwYXJlbnRseSBmZWVkIHRoZSBkYXRhIGFzIGl0IGJl
Y29tZXMgYXZhaWxhYmxlIHdpdGggdmVyeSBsaXR0bGUgc3luYw0KIHdvcmsgYW5kIHlvdSBjYW4g
YWxzbyBlZmZpY2llbnRseSBwaXBlbGluZSBzbyB5b3UgcGFzcyBkYXRhIHRvIGRlY3J5cHRvciwg
dGhlbiB0byBhcHAsIHdpdGggYXMgbGl0dGxlIGJ1cyB0cmFmZmljIGFzIHBvc3NpYmxlLiBObyBu
ZWVkIHRvIGNvcHkgZGF0YSBvciBzeW5jaHJvbml6ZSBrZXJuZWwgc3BhY2UuPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAw
NDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Js
b29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+Rm9yIDFLIHBhY2tldHMgeW91IHdvdWxkIHVzZSBhYm91dCAxMDAwbnMgKDMgY3ljbGVzL2J5
dGUpIG9uIGNyeXB0byBhbmQgdGhpcyB3b3VsZCBoYXBwZW4gaW4gTDEgY2FjaGUuIEl0IHdvdWxk
DQogb2YgY291cnNlIGNvbnN1bWUgYSBjb3JlIHdoaWNoIGEgY3J5cHRvIG9mZmxvYWQgd291bGQg
bm90LCBidXQgdGhhdCBjYW4gYmUgZGViYXRlZCBiZWNhdXNlIHdpdGggMTggY29yZSBzeXN0ZW1z
LCB5b3VyIHByb2JsZW0gaXMgbWVtb3J5IGFuZCBuZXR3b3JrIG1vcmUgdGhhbiBDUFUuPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5
bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5
NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+TXkgY29uY2VybiB3aXRoIFBORSBpcyBmb3Igc21hbGwgcGFja2V0cyBhbmQgbG93
IGxhdGVuY3kgd2hlcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1f
LTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9u
dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4xKSBhbiBlc3Rp
bWF0ZWQgMjRucyBmb3IgUE4gZW5jcnlwdGlvbiBhbmQgZGVjcnlwdGlvbiBiZWNvbWVzIG1lYXN1
cmFibGUgaWYgeW91ciBuZXR3b3JrIGlzIGZhc3QgZW5vdWdoLjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tMjAxNzcxNDA0MDEzNzExNjM0OW1fLTkwMDQ5MTcxNDk0
MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPjIpIGFueSBkYW1hZ2UgdG8gdGhlIHBhY2tldCBidWZmZXIgY2F1c2UgYWxs
IHNvcnRzIG9mIG1lbW9yeSBhbmQgY3B1IGJ1cyB0cmFmZmljIGlzc3Vlcy48L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0
OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXYgaWQ9Im1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxv
b3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij4xKSBpcyBhbm5veWluZy4gMikgaXMgYmFkLCBjb21wbGV0ZWx5IGF2b2lkYWJsZSBidXQgbm90
IGFzIFBSIDEwNzkgaXMgZm9ybXVsYXRlZCBjdXJyZW50bHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQw
NTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk
PSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3Rv
bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+MikgaXMg
YWxzbyBsaWtlbHkgYmFkIGZvciBoYXJkd2FyZSBvZmZsb2FkIHVuaXRzIGFzIHdlbGwuPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5
bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BcyB0byBT
UlYtSU8gLSBJ4oCZbSBub3QgZmFtaWxpYXIgd2l0aCBpdCwgYnV0IG9idmlvdXNseSB0aGVyZSBp
cyBzb21lIElPIGFic3RyYWN0aW9uIGxheWVyIC0gdGhlIHF1ZXN0aW9uIGlzIGhvdw0KIHlvdSBt
YWtlIGl0IGFjY2Vzc2libGUgdG8gYXBwcyBhcyBvcHBvc2VkIHRvIGRldmljZSBkcml2ZXJzIHRo
YXQgZG9lcyBub3Igd29yayB3aXRoIHlvdSBRVUlDIGN1c3RvbSBzdGFjaywgYW5kIG5ldG1hcCBp
cyBvbmUgb3B0aW9uIGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxkaXYgaWQ9Im1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0
MTQzYmxvb3Bfc2lnbl8xNTIyODczMzUwNDE1MTIwMTI4Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5LaW5kIFJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS0yMDE3NzE0MDQwMTM3MTE2MzQ5
bS05MDA0OTE3MTQ5NDA1NTk0MTQzYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gNCBB
cHJpbCAyMDE4IGF0IDIyLjE1LjUyLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAoPGEgaHJlZj0i
bWFpbHRvOnByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiPnByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4pDQogd3JvdGU6PG86
cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Tb21lIGNvbXBhcmF0aXZlIG51bWJlcnMgZnJv
bSBhbiBvdXQgb2YgYm94IGRlZmF1bHQgc2V0dGluZ3MgV2luZG93cyBTZXJ2ZXIgMjAxNiAocmVs
ZWFzZWQgdmVyc2lvbikgZm9yIGEgc2luZ2xlDQogY29ubmVjdGlvbiB3aXRoIGEgbWljcm9iZW5j
aG1hcmsgdG9vbDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUg
Y2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFk
ZGluZz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHI+
DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuODVwdDtib3Jk
ZXI6c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItYm90dG9tOnNvbGlkICM2NjY2NjYgMS41cHQ7
cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPk9mZmxvYWRzIGVuYWJsZWQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+
PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjEx
Ni45cHQ7Ym9yZGVyLXRvcDpzb2xpZCAjOTk5OTk5IDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7Ym9y
ZGVyLWJvdHRvbTpzb2xpZCAjNjY2NjY2IDEuNXB0O2JvcmRlci1yaWdodDpzb2xpZCAjOTk5OTk5
IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UQ1AgZ2Jwczwvc3Bhbj48L2I+PG86cD48L286cD48
L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2
LjlwdDtib3JkZXItdG9wOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtib3Jk
ZXItYm90dG9tOnNvbGlkICM2NjY2NjYgMS41cHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkg
MS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlVEUCBnYnBzPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwv
cD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHls
ZT0id2lkdGg6MTE2Ljg1cHQ7Ym9yZGVyOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXRvcDpu
b25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj5MU08gJiM0MzsgTFJPICYjNDM7IGNoZWNrc3VtPC9zcGFu
PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3Ai
IHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2Jv
cmRlci1ib3R0b206c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5
OSAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+MjQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K
PHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2LjlwdDtib3JkZXIt
dG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICM5OTk5OTkgMS4w
cHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGlu
IDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjMuNjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHdpZHRoPSIxNTYi
IHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2Ljg1cHQ7Ym9yZGVyOnNvbGlkICM5OTk5OTkg
MS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5DaGVja3N1bSBvbmx5PC9z
cGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0
b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25l
O2JvcmRlci1ib3R0b206c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5
OTk5OSAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Ny42PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90
ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7Ym9y
ZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjOTk5OTk5
IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0
IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4z
LjY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB3aWR0aD0i
MTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi44NXB0O2JvcmRlcjpzb2xpZCAjOTk5
OTk5IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Tm9uZTwvc3Bhbj48
L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBz
dHlsZT0id2lkdGg6MTE2LjlwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3Jk
ZXItYm90dG9tOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkg
MS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjUuNjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8
dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10
b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgIzk5OTk5OSAxLjBw
dDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4g
NS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Mi4zPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRo
aXMgaXMgZm9yIGEgZnVsbHkgYm90dGxlbmVja2VkIENQVSBjb3JlIC0tDQo8aT5pZiB5b3UgcnVu
IGxvd2VyIGRhdGEgcmF0ZXMgdGhlcmUgaXMgc3RpbGwgYSBzaWduaWZpY2FudCBkaWZmZXJlbmNl
IGluIEN5Y2xlcy9ieXRlIGNvc3Q8L2k+LiBTYW1lIGluY3JlYXNlZCBDUFUgY29zdCBhcHBsaWVz
IGZvciBjbGllbnQgc3lzdGVtcyBnb2luZyBvdmVyIGhpZ2ggZGF0YSByYXRlIFdpZmkgYW5kIGNl
bGx1bGFyLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBpcyB3aXRob3V0IGFueSBjcnlw
dG8uIE9uY2UgeW91IGFkZCBjcnlwdG8gdGhlIG51bWJlcnMgYmVjb21lIG11Y2ggd29yc2UNCjxp
PndpdGggY3J5cHRvIGNvc3QgYmVjb21pbmcgZG9taW5hbnQ8L2k+LiBBZGRpbmcgYW5vdGhlciBj
cnlwdG8gc3RlcCBmdXJ0aGVyIGV4YWNlcmJhdGVzIHRoZSBwcm9ibGVtLiBIZW5jZSBjcnlwdG8g
b2ZmbG9hZCBnYWlucyBpbiBpbXBvcnRhbmNlIGZvbGxvd2VkIGJ5IHRoZXNlIGJhdGNoIG9mZmxv
YWRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklmIGZvbGtzIG5lZWQgYW55IG1vcmUgbnVtYmVy
cyBJ4oCZZCBiZSBoYXBweSB0byBwcm92aWRlIHRoZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_1F436ED13A22A246A59CA374CBC543998B60C851ORSMSX111amrcor_--


From nobody Mon Apr 23 11:46:04 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BA4120727 for ; Mon, 23 Apr 2018 11:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 t32eveNwlCsn for ; Mon, 23 Apr 2018 11:45:58 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA91126C0F for ; Mon, 23 Apr 2018 11:45:58 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id o20-v6so12300968itc.1 for ; Mon, 23 Apr 2018 11:45:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=6T0dverTOkA55N4B+f1Zdsd/pCOB03Z4kg/HcqFhJVE=; b=g+wytADU9xJB02bLng1SXvIQ4f2DpMO2P0I2RypYcKbI9wg31noSdYlEkiSCMU/ZTy toq/S//G3NE0ZgXsi+IzA0gStX4i9Z4itr/itWMwVb6R7o1DisUdRV7dfAjlrMrfNbUK vWCccOie5sqtmNCVvnHYaJnfgz1Hb7gqVC76ya8Kbh9ruqsUUrz9IlHZd1PculvSuSMC 5BHbTDF6jll63/BwyPSnVfyrWtvSxASLMR98+i2DPenDsGbjtm8uY6dj9Ed0Al1PL2BL bftW5+K9OXC7sVy4p3eJL7sMb5RPmu1fkZgt43Gm/jDuqUQEsWe7eVmuVc1zzMkhNVDU yXQQ==
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=6T0dverTOkA55N4B+f1Zdsd/pCOB03Z4kg/HcqFhJVE=; b=FlqdTyVDypXOOTh9aZ2rVK2xXi6j/t5hxKUaoZod+KlSrf0nZN4+ORxixgdIAGh0j9 SeAYnaVq4ONEE/nxF/yz7O8v27coZZxCB5ULiAcpqhnz4BsA3f92wzjl3wP8nke5jxKK LUIvpnaEEZfxIgyvP+QDOlsaNykcnSGTDMrzAlRZH8xwB3asJ9kKsSvH09mj4tpXKawF nrORFz7ANTroBkNl+KC6Y1DEBa0uFA0xSaj6uyUkMwd9FL5jE7x3nrUQ3oeWpY0cqIg7 zaUDaXtwZCVvrkatsaTY7DuH8nTeie6S9YzpMn+z21xxVoLuV5ix3lMvZtLyl1wEibQ4 rH3A==
X-Gm-Message-State: ALQs6tDZiN/mXiyEwy6UoF3TIQOiBFtCy+Q4YpjXyeiDjSFPcXZKG81M VNhuZzUaMsLIpGGhkgL2/OKSXnr3I9zJ/839iew=
X-Google-Smtp-Source: AB8JxZrc4oIdAI8LHRRDRWEtNyg8YllMKdv8PwutvXqmAL10mcmU7epEFJAWCHn8oAFxxoNcdrcb2BzvLZf0XyuLS6E=
X-Received: by 2002:a24:e4f:: with SMTP id 76-v6mr15247880ite.80.1524509157692;  Mon, 23 Apr 2018 11:45:57 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 23 Apr 2018 11:45:56 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B60C851@ORSMSX111.amr.corp.intel.com>
References:        <1F436ED13A22A246A59CA374CBC543998B60C7AD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B60C851@ORSMSX111.amr.corp.intel.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 23 Apr 2018 11:45:56 -0700
Message-ID: 
Subject: RE: Impact of hardware offloads on network stack performance
To: Ian Swett ,  "Deval, Manasi" , Mike Bishop 
Cc: Praveen Balasubramanian , IETF QUIC WG 
Content-Type: multipart/alternative; boundary="000000000000cd2044056a8872bd"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 23 Apr 2018 18:46:02 -0000

--000000000000cd2044056a8872bd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ah, I see. Thanks for explaining.

QUIC has a much reacher interface, so there could be, say 100 active
streams waiting for transmission. The QUIC implementation would use some
sort of scheduler to move the most important parts first without loosing
progress on other parts, for example using

https://en.wikipedia.org/wiki/Deficit_round_robin

A simple huge buffer segmentation would probably not work directly, but a
means to forward data pre-wrapped in QUIC frames, in reasonable package
units, but without AEAD envelope would make sense. These could be queued in
volumes, leaving it an offloader to proceed.

I=E2=80=99ve been looking into the netmap interface where you can feed cont=
ent in
units directly to hardware, and I=E2=80=99m sure you have detailed knowledg=
e of
DPDK that does something similar.


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


On 23 April 2018 at 20.38.06, Deval, Manasi (manasi.deval@intel.com) wrote:

I=E2=80=99m trying to lay out the options for TSO/LSO with QUIC. In my prev=
ious
e-mail I compared the outcome of vanilla UDP segmentation as defined by the
latest patch (https://marc.info/?l=3Dlinux-netdev&m=3D152399530603992&w=3D2=
), to
an alternative native QUIC segmentation.



A segment is a large buffer produced in an application. The segment is
often much too large to go out on the wire with just pre-pended headers.
Therefore segment needs to be chopped up into appropriate size and the
pre-pended headers need to be replicated to make MTU size packets for the
wire.



I=E2=80=99m suggesting that we should consider processing a large data buff=
er as
multiple QUIC packets each with a unique PN.



Thanks,

Manasi





*From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]
*Sent:* Monday, April 23, 2018 11:25 AM
*To:* Ian Swett ; Deval, Manasi <
manasi.deval@intel.com>; Mike Bishop 
*Cc:* IETF QUIC WG ; Praveen Balasubramanian <
pravb@microsoft.com>
*Subject:* RE: Impact of hardware offloads on network stack performance



I=E2=80=99m not really familiar with this dump but what does partial segmen=
tation
mean here?



Are you splitting a single UDP datagram into multiple fragments, or are you
processing multiple separate QUIC packets, one PN each?



If you fragment UDP datagrams, that can be a big issue because different
fragments may race along different routes, causing unexpected delays and
blocking at the other end.





On 23 April 2018 at 20.18.54, Deval, Manasi (manasi.deval@intel.com) wrote:

If we do TSO / LSO with QUIC, the initial segment provided can look like =
=E2=80=93

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encrypte=
d header (PN=3Dx) =E2=80=93 QUIC Encrypted
payload.



If we just use the stack=E2=80=99s udp segmentation (using the patch -
https://marc.info/?l=3Dlinux-netdev&m=3D152399530603992&w=3D2), the outcome=
 of
QUIC packets on the wire would be:

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encrypte=
d part (PN=3Dx, partial segment
1/3)

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC encrypted part (partial segme=
nt 2/3)

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC encrypted part (partial segme=
nt 3/3)

=E2=80=A6



Putting these back together in a stack / hardware looks like a painful and
potentially non-deterministic activity.





It would be easier to do a native QUIC offload, where the packet on wire
can be identified by QUIC CiD and appropriate packet number. Therefore,
original packet looks like - MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC =
Clear =E2=80=93 QUIC encrypted
header (PN=3Dx) =E2=80=93 QUIC Encrypted payload.

If we just create another version of segmentation called QUIC segmentation,
the outcome of packets on the wire would be:

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encrypte=
d part (PN=3Dx, partial segment
1/3)

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encrypte=
d part (PN=3Dx+1, partial segment
2/3)

MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encrypte=
d part (PN=3Dx+2, partial segment
3/3)

=E2=80=A6

If this set of segments were to be re-assembled, the ability to identify
CiD and PN would simplify this task. I think this is a simpler
implementation. Do others see an issue with this?



Thanks,

Manasi





*From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett
*Sent:* Friday, April 06, 2018 1:55 PM
*To:* Mike Bishop 
*Cc:* Praveen Balasubramanian ; Mikkel Fahn=C3=B8e
J=C3=B8rgensen ; IETF QUIC WG 
*Subject:* Re: Impact of hardware offloads on network stack performance



PNE doesn't preclude UDP LRO or pacing offload.



However, in a highly optimized stack(ie: The Disk|Crypt|Net paper from
SIGCOMM 2017) not touching(ie: bringing into memory or cache) the content
to be sent until the last possible moment is critical.  PNE likely means
touching that content much earlier.



But personally I consider the actual crypto we're talking about(2 AES
instructions?) adding basically free.



On Fri, Apr 6, 2018 at 4:37 PM Mike Bishop  wrote:

Thanks for the clarification.  I guess what I=E2=80=99m really getting down=
 to is
how do we quantify the actual *cost* of PNE?  Are we substantially
increasing the crypto costs?  If Ian is saying that crypto is comparatively
cheap and the cost is that it=E2=80=99s harder to offload something that=E2=
=80=99s
comparatively cheap, what have we lost?  I=E2=80=99d think we want to offlo=
ad the
most intensive piece we can, and it seems like we=E2=80=99re talking about =
crypto
offloads....  Or are we saying instead that the crypto makes it harder to
offload other things in the future, like a QUIC equivalent to LRO/LSO?



*From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]
*Sent:* Thursday, April 5, 2018 9:45 PM
*To:* Ian Swett ; Mike Bishop 
*Cc:* Praveen Balasubramanian ; IETF QUIC WG <
quic@ietf.org>
*Subject:* Re: Impact of hardware offloads on network stack performance



To be clear - I don=E2=80=99t think crypto is overshadowing other issues as=
 Mike
read my post. It certainly comes at a cost, but either multiple cores or
co-processors will deal with this. 1000ns is 10Gbps crypto speed on one
core and it is higly parallelisable and cache friendly.



But if you have to drip your packets through a traditional send interface
that is copying, buffering or blocking, and certainly sync=E2=80=99ing with=
 the
kernel - it is going to be tough.



For receive you risk high latency or top much scheduling in receive buffers=
.


------------------------------

*From:* Ian Swett 
*Sent:* Friday, April 6, 2018 4:06:01 AM
*To:* Mike Bishop
*Cc:* Mikkel Fahn=C3=B8e J=C3=B8rgensen; Praveen Balasubramanian; IETF QUIC=
 WG
*Subject:* Re: Impact of hardware offloads on network stack performance





On Thu, Apr 5, 2018 at 5:57 PM Mike Bishop  wrote:

That=E2=80=99s interesting data, Praveen =E2=80=93 thanks.  There is one ca=
veat there,
which is that (IIUC, on current hardware) you can=E2=80=99t do packet pacin=
g with
LSO, and so my understanding is that even for TCP many providers disable
this in pursuit of better egress management.  So what we=E2=80=99re really =
saying
is that:

   - On current hardware and OS setups, UDP runs less than half as much
   throughput as TCP; that needs some optimization, as we=E2=80=99ve alread=
y discussed
   - TCP will dramatically gain performance once hardware offload catches
   up and allows *paced* LSO =F0=9F=98=8A



However, as Mikkel points out, the crypto costs are likely to overwhelm the
OS throughput / scheduling issues in real deployments.  So I think the
other relevant piece to understanding the cost here is this:



I have a few cases(both client and server) where my UDP send costs are more
than 30%(in some cases 50%) of CPU consumption, and crypto is less than
10%.  So currently, I assume crypto is cheap(especially AES-GCM when
hardware acceleration is available) and egress is expensive.  UDP ingres is
not that expensive, but could use a bit of optimization as well.



The only 'fancy' thing our current code is doing for crypto is encrypting
in place, which was a ~2% win.  Nice, but not transformative.  See
EncryptInPlace




I haven't done much work benchmarking Windows, so possibly the Windows UDP
stack is really fast, and so crypto seems really slow in comparison?




   - What is the throughput and relative cost of TLS/TCP versus QUIC (i.e.
   how much are the smaller units of encryption hurting us versus, say, 16K=
B
   TLS records)?


   - TLS implementations already vary here:  Some implementations choose
      large record sizes, some vary record sizes to reduce delay /
HoLB, so this
      probably isn=E2=80=99t a single number.


   - How much additional load does PNE add to this difference?
   - To what extent would PNE make future crypto offloads *impossible*
   versus *requires more R&D to develop*?



*From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahn=C3=
=B8e
J=C3=B8rgensen
*Sent:* Wednesday, April 4, 2018 1:34 PM
*To:* Praveen Balasubramanian ; IET=
F
QUIC WG 
*Subject:* Re: Impact of hardware offloads on network stack performance



Thanks for sharing these numbers.



My guess is that these offloads deal with kernel scheduling, memory cache
issues, and interrupt scheduling.



It probably has very little to do with crypto, TCP headers, and any other
cpu sensitive processing.



This is where netmap enters: you can transparently feed the data as it
becomes available with very little sync work and you can also efficiently
pipeline so you pass data to decryptor, then to app, with as little bus
traffic as possible. No need to copy data or synchronize kernel space.



For 1K packets you would use about 1000ns (3 cycles/byte) on crypto and
this would happen in L1 cache. It would of course consume a core which a
crypto offload would not, but that can be debated because with 18 core
systems, your problem is memory and network more than CPU.



My concern with PNE is for small packets and low latency where

1) an estimated 24ns for PN encryption and decryption becomes measurable if
your network is fast enough.

2) any damage to the packet buffer cause all sorts of memory and cpu bus
traffic issues.



1) is annoying. 2) is bad, completely avoidable but not as PR 1079 is
formulated currently.



2) is also likely bad for hardware offload units as well.



As to SRV-IO - I=E2=80=99m not familiar with it, but obviously there is som=
e IO
abstraction layer - the question is how you make it accessible to apps as
opposed to device drivers that does nor work with you QUIC custom stack,
and netmap is one option here.



Kind Regards,

Mikkel Fahn=C3=B8e J=C3=B8rgensen



On 4 April 2018 at 22.15.52, Praveen Balasubramanian (
pravb=3D40microsoft.com@dmarc.ietf.org) wrote:

Some comparative numbers from an out of box default settings Windows Server
2016 (released version) for a single connection with a microbenchmark tool:



*Offloads enabled*

*TCP gbps*

*UDP gbps*

*LSO + LRO + checksum*

24

3.6

*Checksum only*

7.6

3.6

*None*

5.6

2.3



This is for a fully bottlenecked CPU core -- *if you run lower data rates
there is still a significant difference in Cycles/byte cost*. Same
increased CPU cost applies for client systems going over high data rate
Wifi and cellular.



This is without any crypto. Once you add crypto the numbers become much
worse *with crypto cost becoming dominant*. Adding another crypto step
further exacerbates the problem. Hence crypto offload gains in importance
followed by these batch offloads.



If folks need any more numbers I=E2=80=99d be happy to provide them.



Thanks

--000000000000cd2044056a8872bd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
Ah, I see. Thanks fo=
r explaining.

QUIC ha=
s a much reacher interface, so there could be, say 100 active streams waiti=
ng for transmission. The QUIC implementation would use some sort of schedul=
er to move the most important parts first without loosing progress on other=
 parts, for example using


A simple huge buffer segmentation would probably n=
ot work directly, but a means to forward data pre-wrapped in QUIC frames, i=
n reasonable package units, but without AEAD envelope would make sense. The=
se could be queued in volumes, leaving it an offloader to proceed.

I=E2=80=99ve been looking int=
o the netmap interface where you can feed content in units directly to hard=
ware, and I=E2=80=99m sure you have detailed knowledge of DPDK that does so=
mething similar.

 
 
Kind Reg=
ards,
Mikkel=
 Fahn=C3=B8e J=C3=B8rgensen

 
On 23 April 2018 at 20.38.06, Deval, Manasi (manasi.deval@intel.com) wrote:
 










I=E2=80=99m trying to lay out the opt=
ions for TSO/LSO with QUIC. In my previous e-mail I compared the outcome of=
 vanilla UDP segmentation as defined by the latest patch
 (https://marc.info/?l=3Dlinux-netdev&m=3D152399530603=
992&w=3D2),
to an alternative native QUIC segmentation.


=C2=A0


A segment is a large buffer produced =
in an application. The segment is often much too large to go out on the wir=
e with just pre-pended headers. Therefore segment
 needs to be chopped up into appropriate size and the pre-pended headers ne=
ed to be replicated to make MTU size packets for the wire.



=C2=A0


I=E2=80=99m suggesting that we should=
 consider processing a large data buffer as multiple QUIC packets each with=
 a unique PN.



=C2=A0


Thanks,


Manasi


=C2=A0


=C2=A0






From: Mikkel Fahn=C3=B8e J=C3=B8rgen=
sen [mailto:mikkelfj@gmail.com]


Sent: Monday, April 23, 2018 11:25 AM

To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Deval, Manasi <manasi.deval@intel.com>; Mike Bishop &=
lt;mbishop@evequefou.be>

Cc: IETF QUIC WG <quic@ietf.org<=
/a>>; Praveen Balasubramanian <pravb@microsoft.com>

Subject: RE: Impact of hardware offloads on network stack performanc=
e






=C2=A0




I=E2=80=99m not really familiar with this dump bu=
t what does partial segmentation mean here?






=C2=A0






Are you splitting a single UDP datagram into mult=
iple fragments, or are you processing multiple separate QUIC packets, one P=
N each?






=C2=A0






If you fragment UDP datagrams, that can be a big =
issue because different fragments may race along different routes, causing =
unexpected delays and blocking at the other end.








=C2=A0






=C2=A0


On 23 April 2018 at 20.18.54, Deval, Manasi (manasi.deval@intel.com) wrote:










If we do TSO / LSO with QUIC, the initial segment p=
rovided can look like =E2=80=93


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear=
 =E2=80=93 QUIC encrypted header (PN=3Dx) =E2=80=93 QUIC Encrypted payload.



=C2=A0


If we just use the stack=E2=80=
=99s udp segmentation (using the patch -
https://marc.info/?l=3Dlinux-netdev&m=3D15239953060399=
2&w=3D2), the outcome of QUIC packets
 on the wire would be:


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear=
 =E2=80=93 QUIC encrypted part (PN=3Dx, partial segment 1/3)


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC encry=
pted part (partial segment 2/3)


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC encry=
pted part (partial segment 3/3)


=E2=80=A6


=C2=A0


Putting these back together in a stack / hardware l=
ooks like a painful and potentially non-deterministic
 activity. 


=C2=A0


=C2=A0


It would be easier to do a native QUIC offload, whe=
re the packet on wire can be identified by QUIC
 CiD and appropriate packet number. Therefore, original packet looks like -=
 MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encrypt=
ed header (PN=3Dx) =E2=80=93 QUIC Encrypted payload.



If we just create another version of segmentation c=
alled QUIC segmentation, the outcome of packets
 on the wire would be:


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear=
 =E2=80=93 QUIC encrypted part (PN=3Dx, partial segment 1/3)


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear=
 =E2=80=93 QUIC encrypted part (PN=3Dx+1, partial segment 2/3)


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear=
 =E2=80=93 QUIC encrypted part (PN=3Dx+2, partial segment 3/3)


=E2=80=A6


If this set of segments were to be re-assembled, th=
e ability to identify CiD and PN would simplify
 this task. I think this is a simpler implementation. Do others see an issu=
e with this?


=C2=A0


Thanks,


Manasi


=C2=A0


=C2=A0


From: QUIC [mailto:quic-bounces@ietf.org]
On Behalf Of Ian Swett

Sent: Friday, April 06, 2018 1:55 PM

To: Mike Bishop <mbishop@=
evequefou.be>

Cc: Praveen Balasubramanian <pravb@microsoft.com>; Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; IETF QUIC WG &=
lt;quic@ietf.org>

Subject: Re: Impact of hardware offloads on network stack performanc=
e


=C2=A0




PNE doesn't preclude UDP LRO or pacing offload.




=C2=A0






However, in a highly optimized stack(ie: The Disk|Crypt|Net paper =
from SIGCOMM 2017) not touching(ie: bringing into memory or cache) the cont=
ent to be sent until the last possible
 moment is critical.=C2=A0 PNE likely means touching that content much earl=
ier.






=C2=A0






But personally I consider the actual crypto we're talking abou=
t(2 AES instructions?) adding basically free.=C2=A0=C2=A0






=C2=A0






On Fri, Apr 6, 2018 at 4:37 PM Mike Bishop <mbishop@evequefou.be> wrote:










Thanks for the clarification.=C2=A0 I guess what I=E2=80=99m reall=
y getting down to is how do we quantify the actual
cost of PNE?=C2=A0 Are we substantially increasing the crypto costs?=
=C2=A0 If Ian is saying that crypto is comparatively cheap and the cost is =
that it=E2=80=99s harder to offload something that=E2=80=99s comparatively =
cheap, what have we lost?=C2=A0 I=E2=80=99d think we want to offload the
 most intensive piece we can, and it seems like we=E2=80=99re talking about=
 crypto offloads....=C2=A0 Or are we saying instead that the crypto makes i=
t harder to offload other things in the future, like a QUIC equivalent to L=
RO/LSO?


=C2=A0






From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]


Sent: Thursday, April 5, 2018 9:45 PM

To: Ian Swett <ianswett@google.com>; Mike Bishop <mbishop@evequefou.be>

Cc: Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>

Subject: Re: Impact of hardware offloads on network stack performanc=
e






=C2=A0










To be clear - I don=E2=80=99t think crypto is overshadowing other =
issues as Mike read my post. It certainly comes at a cost, but either multi=
ple cores or co-processors will deal with this.
 1000ns is 10Gbps crypto speed on one core and it is higly parallelisable a=
nd cache friendly.






=C2=A0






But if you have to drip your packets through a traditional send in=
terface that is copying, buffering or blocking, and certainly sync=E2=80=99=
ing with the kernel - it is going to be tough.






=C2=A0






For receive you risk high latency or top much scheduling in receiv=
e buffers.








=C2=A0
















From: Ian Swett <ianswett@google.com>

Sent: Friday, April 6, 2018 4:06:01 AM

To: Mike Bishop

Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen; Praveen Balasubramanian; IETF=
 QUIC WG

Subject: Re: Impact of hardware offloads on network stack performanc=
e





=C2=A0










=C2=A0






On Thu, Apr 5, 2018 at 5:57 PM Mike Bishop <mbishop@evequefou.be> wrote:<=
/p>









That=E2=80=99s interesting data, Praveen =E2=80=93 thanks.=C2=A0 T=
here is one caveat there, which is that (IIUC, on current hardware) you can=
=E2=80=99t do packet pacing with LSO, and so my understanding is
 that even for TCP many providers disable this in pursuit of better egress =
management.=C2=A0 So what we=E2=80=99re really saying is that:


    

  • 
On current hardware and OS setups, UDP runs less than half as much throu=
ghput as TCP; that needs some optimization, as we=E2=80=99ve already discus=
sed
  • 
TCP will dramatically gain performance once hardware offload catches up =
and allows
paced LSO =F0=9F=98=8A


=C2=A0


However, as Mikkel points out, the crypto costs are likely to over=
whelm the OS throughput / scheduling issues in real deployments.=C2=A0 So I=
 think the other relevant piece to understanding
 the cost here is this:










=C2=A0






I have a few cases(both client and server) where my UDP send costs=
 are more than 30%(in some cases 50%) of CPU consumption, and crypto is les=
s than 10%.=C2=A0 So currently, I assume
 crypto is cheap(especially AES-GCM when hardware acceleration is available=
) and egress is expensive.=C2=A0 UDP ingres is not that expensive, but coul=
d use a bit of optimization as well.






=C2=A0






The only 'fancy' thing our current code is doing for crypt=
o is encrypting in place, which was a ~2% win.=C2=A0 Nice, but not transfor=
mative.=C2=A0 See

EncryptInPlace






=C2=A0






I haven't done much work benchmarking Windows, so possibly the=
 Windows UDP stack is really fast, and so crypto seems really slow in compa=
rison?






=C2=A0










    

  • 
What is the throughput and relative cost of TLS/TCP versus QUIC (i.e. ho=
w much are the smaller units of encryption hurting us versus, say, 16KB TLS=
 records)?



    

      

    • 
TLS implementations already vary here:=C2=A0 Some implementations choose=
 large record sizes, some vary record sizes to reduce delay / HoLB, so this=
 probably isn=E2=80=99t a single number.
    



    

  • 
How much additional load does PNE add to this difference?
    • 
To what extent would PNE make future crypto offloads
impossible versus requires more R&D to develop?


=C2=A0






From: QUIC [mailto:quic-bounces@ietf.org]
On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen

Sent: Wednesday, April 4, 2018 1:34 PM

To: Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org&=
gt;; IETF QUIC WG <qu=
ic@ietf.org>

Subject: Re: Impact of hardware offloads on network stack performanc=
e






=C2=A0




Thanks for sharing these numbers.






=C2=A0






My guess is that these offloads deal with kernel scheduling, me=
mory cache issues, and interrupt scheduling.






=C2=A0






It probably has very little to do with crypto, TCP headers, and=
 any other cpu sensitive processing.






=C2=A0






This is where netmap enters: you can transparently feed the dat=
a as it becomes available with very little sync
 work and you can also efficiently pipeline so you pass data to decryptor, =
then to app, with as little bus traffic as possible. No need to copy data o=
r synchronize kernel space.






=C2=A0






For 1K packets you would use about 1000ns (3 cycles/byte) on cr=
ypto and this would happen in L1 cache. It would
 of course consume a core which a crypto offload would not, but that can be=
 debated because with 18 core systems, your problem is memory and network m=
ore than CPU.






=C2=A0






My concern with PNE is for small packets and low latency where<=
/span>






1) an estimated 24ns for PN encryption and decryption becomes m=
easurable if your network is fast enough.






2) any damage to the packet buffer cause all sorts of memory an=
d cpu bus traffic issues.






=C2=A0






1) is annoying. 2) is bad, completely avoidable but not as PR 1=
079 is formulated currently.






=C2=A0






2) is also likely bad for hardware offload units as well.






=C2=A0




As to SRV-IO - I=E2=80=99m not familiar with it, but obviously =
there is some IO abstraction layer - the question is how
 you make it accessible to apps as opposed to device drivers that does nor =
work with you QUIC custom stack, and netmap is one option here.




=C2=A0






Kind Regards,






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






=C2=A0


On 4 Ap=
ril 2018 at 22.15.52, Praveen Balasubramanian (pravb=3D40microsoft.com@dma=
rc.ietf.org)
 wrote:










Some comparative numbers from an out of box default settings Wi=
ndows Server 2016 (released version) for a single
 connection with a microbenchmark tool:


=C2=A0








Offloads enabled




TCP gbps




UDP gbps








LSO + LRO + checksum




24




3.6








Checksum only




7.6




3.6








None




5.6




2.3








=C2=A0


This is for a fully bottlenecked CPU core --
if you run lower data rates there is still a significant difference in C=
ycles/byte cost. Same increased CPU cost applies for client systems goi=
ng over high data rate Wifi and cellular.



=C2=A0


This is without any crypto. Once you add crypto the numbers bec=
ome much worse
with crypto cost becoming dominant. Adding another crypto step furth=
er exacerbates the problem. Hence crypto offload gains in importance follow=
ed by these batch offloads.


=C2=A0


If folks need any more numbers I=E2=80=99d be happy to provide =
them.


=C2=A0


Thanks


=C2=A0














































--000000000000cd2044056a8872bd--


From nobody Mon Apr 23 12:20:30 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE1912D946 for ; Mon, 23 Apr 2018 12:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable 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 WiNwhUBv9_Zz for ; Mon, 23 Apr 2018 12:20:19 -0700 (PDT)
Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26BAF12D945 for ; Mon, 23 Apr 2018 12:20:00 -0700 (PDT)
Received: by mail-yb0-x22e.google.com with SMTP id w14-v6so4346809ybm.5 for ; Mon, 23 Apr 2018 12:20:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZTAmP8SEgqa0jSfvBMqQZpZvYJyfDX6NsWoTfX72dAE=; b=nyfhJDYq6mNvRZIxu4qPPZ/Ky9taW4DHP4CP2fyvUHIX54AWt2CuuJaXm+1CdJsBnc Pt961AxKDktWGp7FsS73O81z28xE1jD2cTF0wXixo/rscgQy6dpipdkdnQ+ZaB2M/7Kd AW1/dMLoMEMZuszr8zFJb0557eeAaw4rm/+NN869ht2okbWjCPYObB/yXs01ZcZmdl7m TYozVyFYuVB52XVNevbCj9Ln/3dcUOgHKoLfboo4xd+oCZGjCckvJ8j+3Pgp3lsRom8i JCI1GHJc/A0s+K9NfNOrdOk8OGrqz427ObKwwHiMpSzM0yw6ClAgAKNoMwDlUpda/aAz uTJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZTAmP8SEgqa0jSfvBMqQZpZvYJyfDX6NsWoTfX72dAE=; b=OfApKTfw8nfxQQ1XEyCoT0d3BMWIw7qNfyQMWgfGUjhlYu+Bk7oTl3pfZz1JtDO7ma ANyQ2ot5H8NzvrlTnEpR2F/s+Ko0+eICuXAXZYszWUNTFzF0pFwtmG1dj83WLBlOas3X crX1cqzZwf3BqlmCTDzYP1Ci27ke91xrDCu3Vz1cHydgnneTp+3HhvSIIjn157F9lKUl 5F72O+BI3YeE8Z7/KDnxuIbpE37t6VKebkGB8cuium3Auc7ymvoeCeJwgT5os/1UlkvD Efh2blOEo5RJQVqPMJYqXIleib7XH0j4B32GZC8PyeZCTzM7mnel524oiX+1y7nHFn7v eRjg==
X-Gm-Message-State: ALQs6tCxklJJKQ3kCXhKNPVrDleP/HLbqKMmvInCfRmxB9qK9GVktese 4fcTcRmdb9dCsUBdgEr11AWyxU1OOt6VvGebh7jYwQ==
X-Google-Smtp-Source: AIpwx48+cF9ruZcj/WVQVDGPgaDy0CNOYy1cCS69ocmEyC/bUzZMgteVR9H+XwTU0wbEU0qISTfUD9PeggvabWzXgxI=
X-Received: by 2002:a25:ab47:: with SMTP id u65-v6mr12317333ybi.178.1524511199031;  Mon, 23 Apr 2018 12:19:59 -0700 (PDT)
MIME-Version: 1.0
References:        <1F436ED13A22A246A59CA374CBC543998B60C7AD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B60C851@ORSMSX111.amr.corp.intel.com> 
In-Reply-To: 
From: Ian Swett 
Date: Mon, 23 Apr 2018 19:19:48 +0000
Message-ID: 
Subject: Re: Impact of hardware offloads on network stack performance
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Cc: ianswett=40google.com@dmarc.ietf.org,  "Deval, Manasi" , Mike Bishop ,  Praveen Balasubramanian , IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000007a1637056a88ecbd"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 23 Apr 2018 19:20:23 -0000

--0000000000007a1637056a88ecbd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

To clarify my understanding, you'd have to receive all 3 segments to
decrypt the payload?  If that's what you're proposing, then I think it's
not a good design for QUIC, because it amplifies the effective loss rate
and it doesn't save that much CPU.

It's not that hard for userspace to provide 3 fully formed encrypted
packets and use an API like Willem's UDP GSO patch, and I believe that
approach is more agile as well.

If you wanted to do crypto offload, then you could provide the ability to
offload payload and PN encryption instead of doing it in userspace.  As a
bonus, support iovec style scatter-gather, so bulk payloads never need to
be brought into CPU cache before they're encrypted and copied to the NIC.

On Mon, Apr 23, 2018 at 2:46 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen 
wrote:

> Ah, I see. Thanks for explaining.
>
> QUIC has a much reacher interface, so there could be, say 100 active
> streams waiting for transmission. The QUIC implementation would use some
> sort of scheduler to move the most important parts first without loosing
> progress on other parts, for example using
>
> https://en.wikipedia.org/wiki/Deficit_round_robin
>
> A simple huge buffer segmentation would probably not work directly, but a
> means to forward data pre-wrapped in QUIC frames, in reasonable package
> units, but without AEAD envelope would make sense. These could be queued =
in
> volumes, leaving it an offloader to proceed.
>
> I=E2=80=99ve been looking into the netmap interface where you can feed co=
ntent in
> units directly to hardware, and I=E2=80=99m sure you have detailed knowle=
dge of
> DPDK that does something similar.
>
>
> Kind Regards,
> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>
>
> On 23 April 2018 at 20.38.06, Deval, Manasi (manasi.deval@intel.com)
> wrote:
>
> I=E2=80=99m trying to lay out the options for TSO/LSO with QUIC. In my pr=
evious
> e-mail I compared the outcome of vanilla UDP segmentation as defined by t=
he
> latest patch (https://marc.info/?l=3Dlinux-netdev&m=3D152399530603992&w=
=3D2), to
> an alternative native QUIC segmentation.
>
>
>
> A segment is a large buffer produced in an application. The segment is
> often much too large to go out on the wire with just pre-pended headers.
> Therefore segment needs to be chopped up into appropriate size and the
> pre-pended headers need to be replicated to make MTU size packets for the
> wire.
>
>
>
> I=E2=80=99m suggesting that we should consider processing a large data bu=
ffer as
> multiple QUIC packets each with a unique PN.
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
> *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]
> *Sent:* Monday, April 23, 2018 11:25 AM
> *To:* Ian Swett ; Deval, Manasi <
> manasi.deval@intel.com>; Mike Bishop 
> *Cc:* IETF QUIC WG ; Praveen Balasubramanian <
> pravb@microsoft.com>
> *Subject:* RE: Impact of hardware offloads on network stack performance
>
>
>
> I=E2=80=99m not really familiar with this dump but what does partial segm=
entation
> mean here?
>
>
>
> Are you splitting a single UDP datagram into multiple fragments, or are
> you processing multiple separate QUIC packets, one PN each?
>
>
>
> If you fragment UDP datagrams, that can be a big issue because different
> fragments may race along different routes, causing unexpected delays and
> blocking at the other end.
>
>
>
>
>
> On 23 April 2018 at 20.18.54, Deval, Manasi (manasi.deval@intel.com)
> wrote:
>
> If we do TSO / LSO with QUIC, the initial segment provided can look like =
=E2=80=93
>
> MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encryp=
ted header (PN=3Dx) =E2=80=93 QUIC
> Encrypted payload.
>
>
>
> If we just use the stack=E2=80=99s udp segmentation (using the patch -
> https://marc.info/?l=3Dlinux-netdev&m=3D152399530603992&w=3D2), the outco=
me of
> QUIC packets on the wire would be:
>
> MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encryp=
ted part (PN=3Dx, partial segment
> 1/3)
>
> MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC encrypted part (partial seg=
ment 2/3)
>
> MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC encrypted part (partial seg=
ment 3/3)
>
> =E2=80=A6
>
>
>
> Putting these back together in a stack / hardware looks like a painful an=
d
> potentially non-deterministic activity.
>
>
>
>
>
> It would be easier to do a native QUIC offload, where the packet on wire
> can be identified by QUIC CiD and appropriate packet number. Therefore,
> original packet looks like - MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUI=
C Clear =E2=80=93 QUIC encrypted
> header (PN=3Dx) =E2=80=93 QUIC Encrypted payload.
>
> If we just create another version of segmentation called QUIC
> segmentation, the outcome of packets on the wire would be:
>
> MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encryp=
ted part (PN=3Dx, partial segment
> 1/3)
>
> MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encryp=
ted part (PN=3Dx+1, partial segment
> 2/3)
>
> MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encryp=
ted part (PN=3Dx+2, partial segment
> 3/3)
>
> =E2=80=A6
>
> If this set of segments were to be re-assembled, the ability to identify
> CiD and PN would simplify this task. I think this is a simpler
> implementation. Do others see an issue with this?
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett
> *Sent:* Friday, April 06, 2018 1:55 PM
> *To:* Mike Bishop 
> *Cc:* Praveen Balasubramanian ; Mikkel Fahn=C3=B8e
> J=C3=B8rgensen ; IETF QUIC WG 
> *Subject:* Re: Impact of hardware offloads on network stack performance
>
>
>
> PNE doesn't preclude UDP LRO or pacing offload.
>
>
>
> However, in a highly optimized stack(ie: The Disk|Crypt|Net paper from
> SIGCOMM 2017) not touching(ie: bringing into memory or cache) the content
> to be sent until the last possible moment is critical.  PNE likely means
> touching that content much earlier.
>
>
>
> But personally I consider the actual crypto we're talking about(2 AES
> instructions?) adding basically free.
>
>
>
> On Fri, Apr 6, 2018 at 4:37 PM Mike Bishop  wrote:
>
> Thanks for the clarification.  I guess what I=E2=80=99m really getting do=
wn to is
> how do we quantify the actual *cost* of PNE?  Are we substantially
> increasing the crypto costs?  If Ian is saying that crypto is comparative=
ly
> cheap and the cost is that it=E2=80=99s harder to offload something that=
=E2=80=99s
> comparatively cheap, what have we lost?  I=E2=80=99d think we want to off=
load the
> most intensive piece we can, and it seems like we=E2=80=99re talking abou=
t crypto
> offloads....  Or are we saying instead that the crypto makes it harder to
> offload other things in the future, like a QUIC equivalent to LRO/LSO?
>
>
>
> *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]
> *Sent:* Thursday, April 5, 2018 9:45 PM
> *To:* Ian Swett ; Mike Bishop 
> *Cc:* Praveen Balasubramanian ; IETF QUIC WG <
> quic@ietf.org>
> *Subject:* Re: Impact of hardware offloads on network stack performance
>
>
>
> To be clear - I don=E2=80=99t think crypto is overshadowing other issues =
as Mike
> read my post. It certainly comes at a cost, but either multiple cores or
> co-processors will deal with this. 1000ns is 10Gbps crypto speed on one
> core and it is higly parallelisable and cache friendly.
>
>
>
> But if you have to drip your packets through a traditional send interface
> that is copying, buffering or blocking, and certainly sync=E2=80=99ing wi=
th the
> kernel - it is going to be tough.
>
>
>
> For receive you risk high latency or top much scheduling in receive
> buffers.
>
>
> ------------------------------
>
> *From:* Ian Swett 
> *Sent:* Friday, April 6, 2018 4:06:01 AM
> *To:* Mike Bishop
> *Cc:* Mikkel Fahn=C3=B8e J=C3=B8rgensen; Praveen Balasubramanian; IETF QU=
IC WG
> *Subject:* Re: Impact of hardware offloads on network stack performance
>
>
>
>
>
> On Thu, Apr 5, 2018 at 5:57 PM Mike Bishop  wrote:
>
> That=E2=80=99s interesting data, Praveen =E2=80=93 thanks.  There is one =
caveat there,
> which is that (IIUC, on current hardware) you can=E2=80=99t do packet pac=
ing with
> LSO, and so my understanding is that even for TCP many providers disable
> this in pursuit of better egress management.  So what we=E2=80=99re reall=
y saying
> is that:
>
>    - On current hardware and OS setups, UDP runs less than half as much
>    throughput as TCP; that needs some optimization, as we=E2=80=99ve alre=
ady discussed
>    - TCP will dramatically gain performance once hardware offload catches
>    up and allows *paced* LSO =F0=9F=98=8A
>
>
>
> However, as Mikkel points out, the crypto costs are likely to overwhelm
> the OS throughput / scheduling issues in real deployments.  So I think th=
e
> other relevant piece to understanding the cost here is this:
>
>
>
> I have a few cases(both client and server) where my UDP send costs are
> more than 30%(in some cases 50%) of CPU consumption, and crypto is less
> than 10%.  So currently, I assume crypto is cheap(especially AES-GCM when
> hardware acceleration is available) and egress is expensive.  UDP ingres =
is
> not that expensive, but could use a bit of optimization as well.
>
>
>
> The only 'fancy' thing our current code is doing for crypto is encrypting
> in place, which was a ~2% win.  Nice, but not transformative.  See
> EncryptInPlace
> 
>
>
>
> I haven't done much work benchmarking Windows, so possibly the Windows UD=
P
> stack is really fast, and so crypto seems really slow in comparison?
>
>
>
>
>    - What is the throughput and relative cost of TLS/TCP versus QUIC
>    (i.e. how much are the smaller units of encryption hurting us versus, =
say,
>    16KB TLS records)?
>
>
>    - TLS implementations already vary here:  Some implementations choose
>       large record sizes, some vary record sizes to reduce delay / HoLB, =
so this
>       probably isn=E2=80=99t a single number.
>
>
>    - How much additional load does PNE add to this difference?
>    - To what extent would PNE make future crypto offloads *impossible*
>    versus *requires more R&D to develop*?
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahn=C3=
=B8e
> J=C3=B8rgensen
> *Sent:* Wednesday, April 4, 2018 1:34 PM
> *To:* Praveen Balasubramanian ;
> IETF QUIC WG 
> *Subject:* Re: Impact of hardware offloads on network stack performance
>
>
>
> Thanks for sharing these numbers.
>
>
>
> My guess is that these offloads deal with kernel scheduling, memory cache
> issues, and interrupt scheduling.
>
>
>
> It probably has very little to do with crypto, TCP headers, and any other
> cpu sensitive processing.
>
>
>
> This is where netmap enters: you can transparently feed the data as it
> becomes available with very little sync work and you can also efficiently
> pipeline so you pass data to decryptor, then to app, with as little bus
> traffic as possible. No need to copy data or synchronize kernel space.
>
>
>
> For 1K packets you would use about 1000ns (3 cycles/byte) on crypto and
> this would happen in L1 cache. It would of course consume a core which a
> crypto offload would not, but that can be debated because with 18 core
> systems, your problem is memory and network more than CPU.
>
>
>
> My concern with PNE is for small packets and low latency where
>
> 1) an estimated 24ns for PN encryption and decryption becomes measurable
> if your network is fast enough.
>
> 2) any damage to the packet buffer cause all sorts of memory and cpu bus
> traffic issues.
>
>
>
> 1) is annoying. 2) is bad, completely avoidable but not as PR 1079 is
> formulated currently.
>
>
>
> 2) is also likely bad for hardware offload units as well.
>
>
>
> As to SRV-IO - I=E2=80=99m not familiar with it, but obviously there is s=
ome IO
> abstraction layer - the question is how you make it accessible to apps as
> opposed to device drivers that does nor work with you QUIC custom stack,
> and netmap is one option here.
>
>
>
> Kind Regards,
>
> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>
>
>
> On 4 April 2018 at 22.15.52, Praveen Balasubramanian (
> pravb=3D40microsoft.com@dmarc.ietf.org) wrote:
>
> Some comparative numbers from an out of box default settings Windows
> Server 2016 (released version) for a single connection with a
> microbenchmark tool:
>
>
>
> *Offloads enabled*
>
> *TCP gbps*
>
> *UDP gbps*
>
> *LSO + LRO + checksum*
>
> 24
>
> 3.6
>
> *Checksum only*
>
> 7.6
>
> 3.6
>
> *None*
>
> 5.6
>
> 2.3
>
>
>
> This is for a fully bottlenecked CPU core -- *if you run lower data rates
> there is still a significant difference in Cycles/byte cost*. Same
> increased CPU cost applies for client systems going over high data rate
> Wifi and cellular.
>
>
>
> This is without any crypto. Once you add crypto the numbers become much
> worse *with crypto cost becoming dominant*. Adding another crypto step
> further exacerbates the problem. Hence crypto offload gains in importance
> followed by these batch offloads.
>
>
>
> If folks need any more numbers I=E2=80=99d be happy to provide them.
>
>
>
> Thanks
>
>
>
>

--0000000000007a1637056a88ecbd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


To clarify my understanding, you'd have to receiv=
e all 3 segments to decrypt the payload?=C2=A0 If that's what you'r=
e proposing, then I think it's not a good design for QUIC, because it a=
mplifies the effective loss rate and it doesn't save that much CPU.
=


It's not that hard for userspace to provide 3=
 fully formed encrypted packets and use an API like Willem's UDP GSO pa=
tch, and I believe that approach is more agile as well.

If you wanted to do crypto offload, then you could provide the abilit=
y to offload payload and PN encryption instead of doing it in userspace.=C2=
=A0 As a bonus, support iovec style scatter-gather, so bulk payloads never =
need to be brought into CPU cache before they're encrypted and copied t=
o the NIC.

On Mon, Apr=
 23, 2018 at 2:46 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
Ah, I see. Thanks for explaining.

QUIC=
 has a much reacher interface, so there could be, say 100 active streams wa=
iting for transmission. The QUIC implementation would use some sort of sche=
duler to move the most important parts first without loosing progress on ot=
her parts, for example using


A simple huge buffer segmentation would probably=
 not work directly, but a means to forward data pre-wrapped in QUIC frames,=
 in reasonable package units, but without AEAD envelope would make sense. T=
hese could be queued in volumes, leaving it an offloader to proceed.
<=
div id=3D"m_1880571161640275674bloop_customfont" style=3D"font-family:Helve=
tica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto=
">
I=E2=80=99ve been looking into the netmap interface where yo=
u can feed content in units directly to hardware, and I=E2=80=99m sure you =
have detailed knowledge of DPDK that does something similar.

=

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

=

 
On 23 April 2018 at=
 20.38.06, Deval, Manasi (manasi.deval@intel.com) wrote:
 










I=E2=80=99m trying to lay out the opt=
ions for TSO/LSO with QUIC. In my previous e-mail I compared the outcome of=
 vanilla UDP segmentation as defined by the latest patch
 (https://marc.info/?l=3Dlinux-netdev&am=
p;m=3D152399530603992&w=3D2),
to an alternative native QUIC segmentation.


=C2=A0


A segment is a large buffer produced =
in an application. The segment is often much too large to go out on the wir=
e with just pre-pended headers. Therefore segment
 needs to be chopped up into appropriate size and the pre-pended headers ne=
ed to be replicated to make MTU size packets for the wire.



=C2=A0


I=E2=80=99m suggesting that we should=
 consider processing a large data buffer as multiple QUIC packets each with=
 a unique PN.



=C2=A0


Thanks,


Manasi


=C2=A0


=C2=A0






From: Mikkel Fahn=C3=B8e J=C3=B8rgen=
sen [mailto:mikkelf=
j@gmail.com]


Sent: Monday, April 23, 2018 11:25 AM

To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Deval, Manas=
i <manasi.de=
val@intel.com>; Mike Bishop <mbishop@evequefou.be>

Cc: IETF QUIC WG <quic@ietf.org>; Praveen Balasubramanian <pravb@microsoft.com>

Subject: RE: Impact of hardware offloads on network stack performanc=
e






=C2=A0




I=E2=80=99m not really familiar with this dump bu=
t what does partial segmentation mean here?






=C2=A0






Are you splitting a single UDP datagram into mult=
iple fragments, or are you processing multiple separate QUIC packets, one P=
N each?






=C2=A0






If you fragment UDP datagrams, that can be a big =
issue because different fragments may race along different routes, causing =
unexpected delays and blocking at the other end.








=C2=A0






=C2=A0


On 23 April 2018 at 20.18.54=
, Deval, Manasi (manasi.deval@intel.com) wrote:










If we do TSO / LSO with QUIC, the ini=
tial segment provided can look like =E2=80=93


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC Clear =E2=80=93 QUIC encrypted header (PN=3Dx) =E2=80=93 QUIC Encr=
ypted payload.



=C2=A0


If we just =
use the stack=E2=80=99s udp segmentation (using the patch -
https://marc.info/?l=3Dlinux-netdev&=
m=3D152399530603992&w=3D2), the outco=
me of QUIC packets
 on the wire would be:


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC Clear =E2=80=93 QUIC encrypted part (PN=3Dx, partial segment 1/3)<=
/span>


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC encrypted part (partial segment 2/3)


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC encrypted part (partial segment 3/3)


=E2=80=A6


=C2=A0


Putting these back together in a stac=
k / hardware looks like a painful and potentially non-deterministic
 activity. 


=C2=A0


=C2=A0


It would be easier to do a native QUI=
C offload, where the packet on wire can be identified by QUIC
 CiD and appropriate packet number. Therefore, original packet looks like -=
 MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=93 QUIC Clear =E2=80=93 QUIC encrypt=
ed header (PN=3Dx) =E2=80=93 QUIC Encrypted payload.



If we just create another version of =
segmentation called QUIC segmentation, the outcome of packets
 on the wire would be:


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC Clear =E2=80=93 QUIC encrypted part (PN=3Dx, partial segment 1/3)<=
/span>


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC Clear =E2=80=93 QUIC encrypted part (PN=3Dx+1, partial segment 2/3=
)


MAC =E2=80=93 IP =E2=80=93 UDP =E2=80=
=93 QUIC Clear =E2=80=93 QUIC encrypted part (PN=3Dx+2, partial segment 3/3=
)


=E2=80=A6


If this set of segments were to be re=
-assembled, the ability to identify CiD and PN would simplify
 this task. I think this is a simpler implementation. Do others see an issu=
e with this?


=C2=A0


Thanks,


Manasi


=C2=A0


=C2=A0


From: QUIC [mailto:quic-bounces@ietf.org]
On Behalf Of Ian Swett

Sent: Friday, April 06, 2018 1:55 PM

To: Mike Bishop <mbishop@evequefou.be>

Cc: Praveen Balasubramanian <pravb@microsoft.com>; Mikkel Fahn=C3=B8e J=C3=
=B8rgensen <mikk=
elfj@gmail.com>; IETF QUIC WG <quic@ietf.org>

Subject: Re: Impact of hardware offloads on network stack performanc=
e


=C2=A0




PNE doesn't preclude UDP LRO or pacing offload.<=
/p>



=C2=A0






However, in a highly optimized stack(ie: The Disk|Cr=
ypt|Net paper from SIGCOMM 2017) not touching(ie: bringing into memory or c=
ache) the content to be sent until the last possible
 moment is critical.=C2=A0 PNE likely means touching that content much earl=
ier.






=C2=A0






But personally I consider the actual crypto we'r=
e talking about(2 AES instructions?) adding basically free.=C2=A0=C2=A0






=C2=A0






On Fri, Apr 6, 2018 at 4:37 PM Mike Bishop <mbishop@evequefou.be> wrote:










Thanks for the clarification.=C2=A0 I guess what I=
=E2=80=99m really getting down to is how do we quantify the actual
cost of PNE?=C2=A0 Are we substantially increasing the crypto costs?=
=C2=A0 If Ian is saying that crypto is comparatively cheap and the cost is =
that it=E2=80=99s harder to offload something that=E2=80=99s comparatively =
cheap, what have we lost?=C2=A0 I=E2=80=99d think we want to offload the
 most intensive piece we can, and it seems like we=E2=80=99re talking about=
 crypto offloads....=C2=A0 Or are we saying instead that the crypto makes i=
t harder to offload other things in the future, like a QUIC equivalent to L=
RO/LSO?


=C2=A0






From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mail=
to:mikkelfj@gmail.c=
om]


Sent: Thursday, April 5, 2018 9:45 PM

To: Ian Swett <ianswett@google.com>; Mike Bishop <mbishop@evequefou.be>

Cc: Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>

Subject: Re: Impact of hardware offloads on network stack performanc=
e






=C2=A0










To be clear - I don=E2=80=99t think crypto is oversh=
adowing other issues as Mike read my post. It certainly comes at a cost, bu=
t either multiple cores or co-processors will deal with this.
 1000ns is 10Gbps crypto speed on one core and it is higly parallelisable a=
nd cache friendly.






=C2=A0






But if you have to drip your packets through a tradi=
tional send interface that is copying, buffering or blocking, and certainly=
 sync=E2=80=99ing with the kernel - it is going to be tough.






=C2=A0






For receive you risk high latency or top much schedu=
ling in receive buffers.








=C2=A0
















From: Ian Swett <ianswett@google.com>

Sent: Friday, April 6, 2018 4:06:01 AM

To: Mike Bishop

Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen; Praveen Balasubramanian; IETF=
 QUIC WG

Subject: Re: Impact of hardware offloads on network stack performanc=
e





=C2=A0










=C2=A0






On Thu, Apr 5, 2018 at 5:57 PM Mike Bishop <mbishop@evequefou.be> wrote:










That=E2=80=99s interesting data, Praveen =E2=80=93 t=
hanks.=C2=A0 There is one caveat there, which is that (IIUC, on current har=
dware) you can=E2=80=99t do packet pacing with LSO, and so my understanding=
 is
 that even for TCP many providers disable this in pursuit of better egress =
management.=C2=A0 So what we=E2=80=99re really saying is that:


    

  • 
On current hardware and OS setups, UDP runs less than half as much throu=
ghput as TCP; that needs some optimization, as we=E2=80=99ve already discus=
sed
  • 
TCP will dramatically gain performance once hardware offload catches up =
and allows
paced LSO =F0=9F=98=8A


=C2=A0


However, as Mikkel points out, the crypto costs are =
likely to overwhelm the OS throughput / scheduling issues in real deploymen=
ts.=C2=A0 So I think the other relevant piece to understanding
 the cost here is this:










=C2=A0






I have a few cases(both client and server) where my =
UDP send costs are more than 30%(in some cases 50%) of CPU consumption, and=
 crypto is less than 10%.=C2=A0 So currently, I assume
 crypto is cheap(especially AES-GCM when hardware acceleration is available=
) and egress is expensive.=C2=A0 UDP ingres is not that expensive, but coul=
d use a bit of optimization as well.






=C2=A0







=C2=A0






I haven't done much work benchmarking Windows, s=
o possibly the Windows UDP stack is really fast, and so crypto seems really=
 slow in comparison?






=C2=A0










    

  • 
What is the throughput and relative cost of TLS/TCP versus QUIC (i.e. ho=
w much are the smaller units of encryption hurting us versus, say, 16KB TLS=
 records)?



    

      

    • 
TLS implementations already vary here:=C2=A0 Some implementations choose=
 large record sizes, some vary record sizes to reduce delay / HoLB, so this=
 probably isn=E2=80=99t a single number.
    



    

  • 
How much additional load does PNE add to this difference?
    • 
To what extent would PNE make future crypto offloads
impossible versus requires more R&D to develop?


=C2=A0






From: QUIC [mailto:quic-bounces@ietf.org]
On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen

Sent: Wednesday, April 4, 2018 1:34 PM

To: Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org&=
gt;; IETF QUIC WG <qu=
ic@ietf.org>

Subject: Re: Impact of hardware offloads on network stack performanc=
e






=C2=A0




Thanks for sharing these numbers.






=C2=A0






My guess is that these offloads deal with kernel =
scheduling, memory cache issues, and interrupt scheduling.






=C2=A0






It probably has very little to do with crypto, TC=
P headers, and any other cpu sensitive processing.






=C2=A0






This is where netmap enters: you can transparentl=
y feed the data as it becomes available with very little sync
 work and you can also efficiently pipeline so you pass data to decryptor, =
then to app, with as little bus traffic as possible. No need to copy data o=
r synchronize kernel space.






=C2=A0






For 1K packets you would use about 1000ns (3 cycl=
es/byte) on crypto and this would happen in L1 cache. It would
 of course consume a core which a crypto offload would not, but that can be=
 debated because with 18 core systems, your problem is memory and network m=
ore than CPU.






=C2=A0






My concern with PNE is for small packets and low =
latency where






1) an estimated 24ns for PN encryption and decryp=
tion becomes measurable if your network is fast enough.






2) any damage to the packet buffer cause all sort=
s of memory and cpu bus traffic issues.






=C2=A0






1) is annoying. 2) is bad, completely avoidable b=
ut not as PR 1079 is formulated currently.






=C2=A0






2) is also likely bad for hardware offload units =
as well.






=C2=A0




As to SRV-IO - I=E2=80=99m not familiar with it, =
but obviously there is some IO abstraction layer - the question is how
 you make it accessible to apps as opposed to device drivers that does nor =
work with you QUIC custom stack, and netmap is one option here.




=C2=A0






Kind Regards,






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






=C2=A0


On 4 April 2018 at 22.15.52, Praveen Balasubramanian (pravb=
=3D40microsoft.com@dmarc.ietf.org)
 wrote:










Some comparative numbers from an out of box defau=
lt settings Windows Server 2016 (released version) for a single
 connection with a microbenchmark tool:


=C2=A0








Offloads enabled




TCP gbps




UDP gbps








LSO + LRO + checksum




24




3.6








Checksum only




7.6




3.6








None




5.6




2.3








=C2=A0


This is for a fully bottlenecked CPU core --
if you run lower data rates there is still a significant difference in C=
ycles/byte cost. Same increased CPU cost applies for client systems goi=
ng over high data rate Wifi and cellular.



=C2=A0


This is without any crypto. Once you add crypto t=
he numbers become much worse
with crypto cost becoming dominant. Adding another crypto step furth=
er exacerbates the problem. Hence crypto offload gains in importance follow=
ed by these batch offloads.


=C2=A0


If folks need any more numbers I=E2=80=99d be hap=
py to provide them.


=C2=A0


Thanks


=C2=A0
















































--0000000000007a1637056a88ecbd--


From nobody Mon Apr 23 12:36:46 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C039612D810 for ; Mon, 23 Apr 2018 12:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.721
X-Spam-Level: 
X-Spam-Status: No, score=-0.721 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable 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 EveBJpZK0NrJ for ; Mon, 23 Apr 2018 12:36:42 -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 622C4126B6E for ; Mon, 23 Apr 2018 12:36:42 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w3NJNnDO032131; Mon, 23 Apr 2018 20:36: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=RqDYc3JRpoTrMT/l9vBT/67pq5jC6agpVd3cGNsAEhw=; b=c+8DlT92UGPZVf8e6gVQ83Jr/IHAAvjy+g1ixJ8Wm3e/vfH0Ts5nkww/FH49BEPjfgaf 82rVtV3bboj8H+dMS+a3OgfZphK9fbEt1lQRFKSA0bs9W9kiDxTbAHK+tRRqcjE9Ia1C OzCf9xBeSqCoCkGZK+T1K/wMST8twBiegZ3WSCxlsRMomBmffO1DjjrR1zn1iUseM3Wu R7YjbGDJBy1IgClHNSO/l7uvsLox0AkgofuMqkRfPOz028DK/0CalV26MlH21zaTtQv4 WH2jRPdb98YBdNvdWx33T7eF1qppxfhUSeDFkD4KdEGH4fgU6tGdD/Xzg3M2g+qNPHqK 5Q== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2hg0c1wvxt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Apr 2018 20:36:34 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3NJaPaJ028293; Mon, 23 Apr 2018 15:36:33 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2hg0nbs11q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 Apr 2018 15:36:30 -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.1365.1; Mon, 23 Apr 2018 15:36:16 -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.1365.000; Mon, 23 Apr 2018 15:36:16 -0400
From: "Lubashev, Igor" 
To: Ian Swett , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= 
CC: Praveen Balasubramanian , IETF QUIC WG , Mike Bishop , "Deval, Manasi" 
Subject: RE: Impact of hardware offloads on network stack performance
Thread-Topic: Impact of hardware offloads on network stack performance
Thread-Index: AdPMUbL7T8nZAW2ySiO289IPTC0ttgAJCDIAADUrUQAACLVdgAAFkLMAACFBx4AAAJ6NgANRfL2AAAA3SAAAAHMwgAAAR/kAAAEuywAACA7YgA==
Date: Mon, 23 Apr 2018 19:36:15 +0000
Message-ID: 
References:        <1F436ED13A22A246A59CA374CBC543998B60C7AD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B60C851@ORSMSX111.amr.corp.intel.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.33.66]
Content-Type: multipart/alternative; boundary="_000_bf540ec1f6f045aca1cf2379380630b5usma1exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-23_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804230195
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-23_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804230194
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 23 Apr 2018 19:36:46 -0000

--_000_bf540ec1f6f045aca1cf2379380630b5usma1exdag1mb5msgcorpak_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIHBvaW50IG9mIEhXIG9mZmxvYWRzIGlzIHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mIHRpbWVz
IHRoZSBrZXJuZWwgKOKAnHRyYW5zcG9ydOKAnSkgc3RhY2sgaXMgaW52b2tlZCB0byBsb2NhdGUg
dGhlIGZsb3csIHZhbGlkYXRlIGhlYWRlcnMsIGVucXVldWUgZGF0YSBmb3IgZGVsaXZlcnkgdG8g
c29ja2V0cywgZXRjLg0KDQpJZiBIVyBjYW4gYXNzb2NpYXRlIG11bHRpcGxlIFFVSUMgcGFja2V0
cyB3aXRoIGEgc2luZ2xlIGZsb3csIHJlbW92ZSBlbmNyeXB0aW9uIGFuZCBwYXNzIGl0IG9uIHRv
IHRoZSBzdGFjaywgaXQgZG9lcyBub3QgcmVhbGx5IG5lZWQgdG8gc2ltdWxhdGUgdGhlIGRhdGEg
YXJyaXZpbmcgaW4gYSBzaW5nbGUganVtYm8gUVVJQyBwYWNrZXQuDQoNCg0KICAqICAgSWdvcg0K
DQoNCkZyb206IElhbiBTd2V0dCBbbWFpbHRvOmlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5p
ZXRmLm9yZ10NClNlbnQ6IE1vbmRheSwgQXByaWwgMjMsIDIwMTggMzoyMCBQTQ0KVG86IE1pa2tl
bCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT4NCkNjOiBQcmF2ZWVuIEJh
bGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0Bp
ZXRmLm9yZz47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZT47IERldmFsLCBNYW5h
c2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5jb20+OyBpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMu
aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0
d29yayBzdGFjayBwZXJmb3JtYW5jZQ0KDQpUbyBjbGFyaWZ5IG15IHVuZGVyc3RhbmRpbmcsIHlv
dSdkIGhhdmUgdG8gcmVjZWl2ZSBhbGwgMyBzZWdtZW50cyB0byBkZWNyeXB0IHRoZSBwYXlsb2Fk
PyAgSWYgdGhhdCdzIHdoYXQgeW91J3JlIHByb3Bvc2luZywgdGhlbiBJIHRoaW5rIGl0J3Mgbm90
IGEgZ29vZCBkZXNpZ24gZm9yIFFVSUMsIGJlY2F1c2UgaXQgYW1wbGlmaWVzIHRoZSBlZmZlY3Rp
dmUgbG9zcyByYXRlIGFuZCBpdCBkb2Vzbid0IHNhdmUgdGhhdCBtdWNoIENQVS4NCg0KSXQncyBu
b3QgdGhhdCBoYXJkIGZvciB1c2Vyc3BhY2UgdG8gcHJvdmlkZSAzIGZ1bGx5IGZvcm1lZCBlbmNy
eXB0ZWQgcGFja2V0cyBhbmQgdXNlIGFuIEFQSSBsaWtlIFdpbGxlbSdzIFVEUCBHU08gcGF0Y2gs
IGFuZCBJIGJlbGlldmUgdGhhdCBhcHByb2FjaCBpcyBtb3JlIGFnaWxlIGFzIHdlbGwuDQoNCklm
IHlvdSB3YW50ZWQgdG8gZG8gY3J5cHRvIG9mZmxvYWQsIHRoZW4geW91IGNvdWxkIHByb3ZpZGUg
dGhlIGFiaWxpdHkgdG8gb2ZmbG9hZCBwYXlsb2FkIGFuZCBQTiBlbmNyeXB0aW9uIGluc3RlYWQg
b2YgZG9pbmcgaXQgaW4gdXNlcnNwYWNlLiAgQXMgYSBib251cywgc3VwcG9ydCBpb3ZlYyBzdHls
ZSBzY2F0dGVyLWdhdGhlciwgc28gYnVsayBwYXlsb2FkcyBuZXZlciBuZWVkIHRvIGJlIGJyb3Vn
aHQgaW50byBDUFUgY2FjaGUgYmVmb3JlIHRoZXkncmUgZW5jcnlwdGVkIGFuZCBjb3BpZWQgdG8g
dGhlIE5JQy4NCg0KT24gTW9uLCBBcHIgMjMsIDIwMTggYXQgMjo0NiBQTSBNaWtrZWwgRmFobsO4
ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNv
bT4+IHdyb3RlOg0KQWgsIEkgc2VlLiBUaGFua3MgZm9yIGV4cGxhaW5pbmcuDQoNClFVSUMgaGFz
IGEgbXVjaCByZWFjaGVyIGludGVyZmFjZSwgc28gdGhlcmUgY291bGQgYmUsIHNheSAxMDAgYWN0
aXZlIHN0cmVhbXMgd2FpdGluZyBmb3IgdHJhbnNtaXNzaW9uLiBUaGUgUVVJQyBpbXBsZW1lbnRh
dGlvbiB3b3VsZCB1c2Ugc29tZSBzb3J0IG9mIHNjaGVkdWxlciB0byBtb3ZlIHRoZSBtb3N0IGlt
cG9ydGFudCBwYXJ0cyBmaXJzdCB3aXRob3V0IGxvb3NpbmcgcHJvZ3Jlc3Mgb24gb3RoZXIgcGFy
dHMsIGZvciBleGFtcGxlIHVzaW5nDQoNCmh0dHBzOi8vZW4ud2lraXBlZGlhLi5vcmcvd2lraS9E
ZWZpY2l0X3JvdW5kX3JvYmluPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91
cmw/dT1odHRwcy0zQV9fZW4ud2lraXBlZGlhLm9yZ193aWtpX0RlZmljaXQtNUZyb3VuZC01RnJv
YmluJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPURqbjNiUTV1TkpEUE1fMnNr
ZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mbT1rTG4yS2dLTFB0R0p4UnZLWEwtRko1SktiLVJ1
MFAwakVMZGh4cFd3TThZJnM9RWlGeEVsa0g0c2czMG1CQWcxN2hNNkUxdVNuc2sxbV9DY25FcGJm
QVI0USZlPT4NCg0KQSBzaW1wbGUgaHVnZSBidWZmZXIgc2VnbWVudGF0aW9uIHdvdWxkIHByb2Jh
Ymx5IG5vdCB3b3JrIGRpcmVjdGx5LCBidXQgYSBtZWFucyB0byBmb3J3YXJkIGRhdGEgcHJlLXdy
YXBwZWQgaW4gUVVJQyBmcmFtZXMsIGluIHJlYXNvbmFibGUgcGFja2FnZSB1bml0cywgYnV0IHdp
dGhvdXQgQUVBRCBlbnZlbG9wZSB3b3VsZCBtYWtlIHNlbnNlLiBUaGVzZSBjb3VsZCBiZSBxdWV1
ZWQgaW4gdm9sdW1lcywgbGVhdmluZyBpdCBhbiBvZmZsb2FkZXIgdG8gcHJvY2VlZC4NCg0KSeKA
mXZlIGJlZW4gbG9va2luZyBpbnRvIHRoZSBuZXRtYXAgaW50ZXJmYWNlIHdoZXJlIHlvdSBjYW4g
ZmVlZCBjb250ZW50IGluIHVuaXRzIGRpcmVjdGx5IHRvIGhhcmR3YXJlLCBhbmQgSeKAmW0gc3Vy
ZSB5b3UgaGF2ZSBkZXRhaWxlZCBrbm93bGVkZ2Ugb2YgRFBESyB0aGF0IGRvZXMgc29tZXRoaW5n
IHNpbWlsYXIuDQoNCg0KS2luZCBSZWdhcmRzLA0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0K
DQoNCk9uIDIzIEFwcmlsIDIwMTggYXQgMjAuMzguMDYsIERldmFsLCBNYW5hc2kgKG1hbmFzaS5k
ZXZhbEBpbnRlbC5jb208bWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5jb20+KSB3cm90ZToNCkni
gJltIHRyeWluZyB0byBsYXkgb3V0IHRoZSBvcHRpb25zIGZvciBUU08vTFNPIHdpdGggUVVJQy4g
SW4gbXkgcHJldmlvdXMgZS1tYWlsIEkgY29tcGFyZWQgdGhlIG91dGNvbWUgb2YgdmFuaWxsYSBV
RFAgc2VnbWVudGF0aW9uIGFzIGRlZmluZWQgYnkgdGhlIGxhdGVzdCBwYXRjaCAoaHR0cHM6Ly9t
YXJjLmluZm8vP2w9bGludXgtbmV0ZGV2Jm09MTUyMzk5NTMwNjAzOTkyJnc9MjxodHRwczovL3Vy
bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX21hcmMuaW5mb18tM0Zs
LTNEbGludXgtMkRuZXRkZXYtMjZtLTNEMTUyMzk5NTMwNjAzOTkyLTI2dy0zRDImZD1Ed01GYVEm
Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlq
VVpkbl9tNTVLUG1sbyZtPWtMbjJLZ0tMUHRHSnhSdktYTC1GSjVKS2ItUnUwUDBqRUxkaHhwV3dN
OFkmcz1oWUhaZlp5ZnhQN2tJbnBUdk5FOVUwMkJQQWhqZS1admFVZ1Yxck5DU0xJJmU9PiksIHRv
IGFuIGFsdGVybmF0aXZlIG5hdGl2ZSBRVUlDIHNlZ21lbnRhdGlvbi4NCg0KQSBzZWdtZW50IGlz
IGEgbGFyZ2UgYnVmZmVyIHByb2R1Y2VkIGluIGFuIGFwcGxpY2F0aW9uLiBUaGUgc2VnbWVudCBp
cyBvZnRlbiBtdWNoIHRvbyBsYXJnZSB0byBnbyBvdXQgb24gdGhlIHdpcmUgd2l0aCBqdXN0IHBy
ZS1wZW5kZWQgaGVhZGVycy4gVGhlcmVmb3JlIHNlZ21lbnQgbmVlZHMgdG8gYmUgY2hvcHBlZCB1
cCBpbnRvIGFwcHJvcHJpYXRlIHNpemUgYW5kIHRoZSBwcmUtcGVuZGVkIGhlYWRlcnMgbmVlZCB0
byBiZSByZXBsaWNhdGVkIHRvIG1ha2UgTVRVIHNpemUgcGFja2V0cyBmb3IgdGhlIHdpcmUuDQoN
CknigJltIHN1Z2dlc3RpbmcgdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIgcHJvY2Vzc2luZyBhIGxh
cmdlIGRhdGEgYnVmZmVyIGFzIG11bHRpcGxlIFFVSUMgcGFja2V0cyBlYWNoIHdpdGggYSB1bmlx
dWUgUE4uDQoNClRoYW5rcywNCk1hbmFzaQ0KDQoNCkZyb206IE1pa2tlbCBGYWhuw7hlIErDuHJn
ZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNv
bT5dDQpTZW50OiBNb25kYXksIEFwcmlsIDIzLCAyMDE4IDExOjI1IEFNDQpUbzogSWFuIFN3ZXR0
IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwZ29vZ2xlLmNv
bUBkbWFyYy5pZXRmLm9yZz4+OyBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuZGV2YWxAaW50ZWwuY29t
PG1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tPj47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2
ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+Pg0KQ2M6IElFVEYgUVVJQyBX
RyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBQcmF2ZWVuIEJhbGFzdWJy
YW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbT4+
DQpTdWJqZWN0OiBSRTogSW1wYWN0IG9mIGhhcmR3YXJlIG9mZmxvYWRzIG9uIG5ldHdvcmsgc3Rh
Y2sgcGVyZm9ybWFuY2UNCg0KSeKAmW0gbm90IHJlYWxseSBmYW1pbGlhciB3aXRoIHRoaXMgZHVt
cCBidXQgd2hhdCBkb2VzIHBhcnRpYWwgc2VnbWVudGF0aW9uIG1lYW4gaGVyZT8NCg0KQXJlIHlv
dSBzcGxpdHRpbmcgYSBzaW5nbGUgVURQIGRhdGFncmFtIGludG8gbXVsdGlwbGUgZnJhZ21lbnRz
LCBvciBhcmUgeW91IHByb2Nlc3NpbmcgbXVsdGlwbGUgc2VwYXJhdGUgUVVJQyBwYWNrZXRzLCBv
bmUgUE4gZWFjaD8NCg0KSWYgeW91IGZyYWdtZW50IFVEUCBkYXRhZ3JhbXMsIHRoYXQgY2FuIGJl
IGEgYmlnIGlzc3VlIGJlY2F1c2UgZGlmZmVyZW50IGZyYWdtZW50cyBtYXkgcmFjZSBhbG9uZyBk
aWZmZXJlbnQgcm91dGVzLCBjYXVzaW5nIHVuZXhwZWN0ZWQgZGVsYXlzIGFuZCBibG9ja2luZyBh
dCB0aGUgb3RoZXIgZW5kLg0KDQoNCg0KT24gMjMgQXByaWwgMjAxOCBhdCAyMC4xOC41NCwgRGV2
YWwsIE1hbmFzaSAobWFuYXNpLmRldmFsQGludGVsLmNvbTxtYWlsdG86bWFuYXNpLmRldmFsQGlu
dGVsLmNvbT4pIHdyb3RlOg0KSWYgd2UgZG8gVFNPIC8gTFNPIHdpdGggUVVJQywgdGhlIGluaXRp
YWwgc2VnbWVudCBwcm92aWRlZCBjYW4gbG9vayBsaWtlIOKAkw0KTUFDIOKAkyBJUCDigJMgVURQ
IOKAkyBRVUlDIENsZWFyIOKAkyBRVUlDIGVuY3J5cHRlZCBoZWFkZXIgKFBOPXgpIOKAkyBRVUlD
IEVuY3J5cHRlZCBwYXlsb2FkLg0KDQoNCklmIHdlIGp1c3QgdXNlIHRoZSBzdGFja+KAmXMgdWRw
IHNlZ21lbnRhdGlvbiAodXNpbmcgdGhlIHBhdGNoIC0gaHR0cHM6Ly9tYXJjLmluZm8vP2w9bGlu
dXgtbmV0ZGV2Jm09MTUyMzk5NTMwNjAzOTkyJnc9MjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw
b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX21hcmMuaW5mb18tM0ZsLTNEbGludXgtMkRuZXRk
ZXYtMjZtLTNEMTUyMzk5NTMwNjAzOTkyLTI2dy0zRDImZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcw
RjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZt
PWtMbjJLZ0tMUHRHSnhSdktYTC1GSjVKS2ItUnUwUDBqRUxkaHhwV3dNOFkmcz1oWUhaZlp5ZnhQ
N2tJbnBUdk5FOVUwMkJQQWhqZS1admFVZ1Yxck5DU0xJJmU9PiksIHRoZSBvdXRjb21lIG9mIFFV
SUMgcGFja2V0cyBvbiB0aGUgd2lyZSB3b3VsZCBiZToNCk1BQyDigJMgSVAg4oCTIFVEUCDigJMg
UVVJQyBDbGVhciDigJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAoUE49eCwgcGFydGlhbCBzZWdtZW50
IDEvMykNCk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAocGFydGlh
bCBzZWdtZW50IDIvMykNCk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBlbmNyeXB0ZWQgcGFy
dCAocGFydGlhbCBzZWdtZW50IDMvMykNCuKApg0KDQpQdXR0aW5nIHRoZXNlIGJhY2sgdG9nZXRo
ZXIgaW4gYSBzdGFjayAvIGhhcmR3YXJlIGxvb2tzIGxpa2UgYSBwYWluZnVsIGFuZCBwb3RlbnRp
YWxseSBub24tZGV0ZXJtaW5pc3RpYyBhY3Rpdml0eS4NCg0KDQpJdCB3b3VsZCBiZSBlYXNpZXIg
dG8gZG8gYSBuYXRpdmUgUVVJQyBvZmZsb2FkLCB3aGVyZSB0aGUgcGFja2V0IG9uIHdpcmUgY2Fu
IGJlIGlkZW50aWZpZWQgYnkgUVVJQyBDaUQgYW5kIGFwcHJvcHJpYXRlIHBhY2tldCBudW1iZXIu
IFRoZXJlZm9yZSwgb3JpZ2luYWwgcGFja2V0IGxvb2tzIGxpa2UgLSBNQUMg4oCTIElQIOKAkyBV
RFAg4oCTIFFVSUMgQ2xlYXIg4oCTIFFVSUMgZW5jcnlwdGVkIGhlYWRlciAoUE49eCkg4oCTIFFV
SUMgRW5jcnlwdGVkIHBheWxvYWQuDQpJZiB3ZSBqdXN0IGNyZWF0ZSBhbm90aGVyIHZlcnNpb24g
b2Ygc2VnbWVudGF0aW9uIGNhbGxlZCBRVUlDIHNlZ21lbnRhdGlvbiwgdGhlIG91dGNvbWUgb2Yg
cGFja2V0cyBvbiB0aGUgd2lyZSB3b3VsZCBiZToNCk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJ
QyBDbGVhciDigJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAoUE49eCwgcGFydGlhbCBzZWdtZW50IDEv
MykNCk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJQyBlbmNyeXB0ZWQg
cGFydCAoUE49eCsxLCBwYXJ0aWFsIHNlZ21lbnQgMi8zKQ0KTUFDIOKAkyBJUCDigJMgVURQIOKA
kyBRVUlDIENsZWFyIOKAkyBRVUlDIGVuY3J5cHRlZCBwYXJ0IChQTj14KzIsIHBhcnRpYWwgc2Vn
bWVudCAzLzMpDQrigKYNCklmIHRoaXMgc2V0IG9mIHNlZ21lbnRzIHdlcmUgdG8gYmUgcmUtYXNz
ZW1ibGVkLCB0aGUgYWJpbGl0eSB0byBpZGVudGlmeSBDaUQgYW5kIFBOIHdvdWxkIHNpbXBsaWZ5
IHRoaXMgdGFzay4gSSB0aGluayB0aGlzIGlzIGEgc2ltcGxlciBpbXBsZW1lbnRhdGlvbi4gRG8g
b3RoZXJzIHNlZSBhbiBpc3N1ZSB3aXRoIHRoaXM/DQoNClRoYW5rcywNCk1hbmFzaQ0KDQoNCkZy
b206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNl
c0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBJYW4gU3dldHQNClNlbnQ6IEZyaWRheSwgQXByaWwg
MDYsIDIwMTggMTo1NSBQTQ0KVG86IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxt
YWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+Pg0KQ2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFu
IDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tPj47IE1pa2tl
bCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpA
Z21haWwuY29tPj47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRm
Lm9yZz4+DQpTdWJqZWN0OiBSZTogSW1wYWN0IG9mIGhhcmR3YXJlIG9mZmxvYWRzIG9uIG5ldHdv
cmsgc3RhY2sgcGVyZm9ybWFuY2UNCg0KUE5FIGRvZXNuJ3QgcHJlY2x1ZGUgVURQIExSTyBvciBw
YWNpbmcgb2ZmbG9hZC4NCg0KSG93ZXZlciwgaW4gYSBoaWdobHkgb3B0aW1pemVkIHN0YWNrKGll
OiBUaGUgRGlza3xDcnlwdHxOZXQgcGFwZXIgZnJvbSBTSUdDT01NIDIwMTcpIG5vdCB0b3VjaGlu
ZyhpZTogYnJpbmdpbmcgaW50byBtZW1vcnkgb3IgY2FjaGUpIHRoZSBjb250ZW50IHRvIGJlIHNl
bnQgdW50aWwgdGhlIGxhc3QgcG9zc2libGUgbW9tZW50IGlzIGNyaXRpY2FsLiAgUE5FIGxpa2Vs
eSBtZWFucyB0b3VjaGluZyB0aGF0IGNvbnRlbnQgbXVjaCBlYXJsaWVyLg0KDQpCdXQgcGVyc29u
YWxseSBJIGNvbnNpZGVyIHRoZSBhY3R1YWwgY3J5cHRvIHdlJ3JlIHRhbGtpbmcgYWJvdXQoMiBB
RVMgaW5zdHJ1Y3Rpb25zPykgYWRkaW5nIGJhc2ljYWxseSBmcmVlLg0KDQpPbiBGcmksIEFwciA2
LCAyMDE4IGF0IDQ6MzcgUE0gTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0
bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+IHdyb3RlOg0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNh
dGlvbi4gIEkgZ3Vlc3Mgd2hhdCBJ4oCZbSByZWFsbHkgZ2V0dGluZyBkb3duIHRvIGlzIGhvdyBk
byB3ZSBxdWFudGlmeSB0aGUgYWN0dWFsIGNvc3Qgb2YgUE5FPyAgQXJlIHdlIHN1YnN0YW50aWFs
bHkgaW5jcmVhc2luZyB0aGUgY3J5cHRvIGNvc3RzPyAgSWYgSWFuIGlzIHNheWluZyB0aGF0IGNy
eXB0byBpcyBjb21wYXJhdGl2ZWx5IGNoZWFwIGFuZCB0aGUgY29zdCBpcyB0aGF0IGl04oCZcyBo
YXJkZXIgdG8gb2ZmbG9hZCBzb21ldGhpbmcgdGhhdOKAmXMgY29tcGFyYXRpdmVseSBjaGVhcCwg
d2hhdCBoYXZlIHdlIGxvc3Q/ICBJ4oCZZCB0aGluayB3ZSB3YW50IHRvIG9mZmxvYWQgdGhlIG1v
c3QgaW50ZW5zaXZlIHBpZWNlIHdlIGNhbiwgYW5kIGl0IHNlZW1zIGxpa2Ugd2XigJlyZSB0YWxr
aW5nIGFib3V0IGNyeXB0byBvZmZsb2Fkcy4uLi4gIE9yIGFyZSB3ZSBzYXlpbmcgaW5zdGVhZCB0
aGF0IHRoZSBjcnlwdG8gbWFrZXMgaXQgaGFyZGVyIHRvIG9mZmxvYWQgb3RoZXIgdGhpbmdzIGlu
IHRoZSBmdXR1cmUsIGxpa2UgYSBRVUlDIGVxdWl2YWxlbnQgdG8gTFJPL0xTTz8NCg0KRnJvbTog
TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbTxtYWls
dG86bWlra2VsZmpAZ21haWwuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCA1LCAyMDE4IDk6
NDUgUE0NClRvOiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0
QGdvb2dsZS5jb20+PjsgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzpt
YmlzaG9wQGV2ZXF1ZWZvdS5iZT4+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZi
QG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+PjsgSUVURiBRVUlDIFdH
IDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBJbXBh
Y3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZQ0KDQpU
byBiZSBjbGVhciAtIEkgZG9u4oCZdCB0aGluayBjcnlwdG8gaXMgb3ZlcnNoYWRvd2luZyBvdGhl
ciBpc3N1ZXMgYXMgTWlrZSByZWFkIG15IHBvc3QuIEl0IGNlcnRhaW5seSBjb21lcyBhdCBhIGNv
c3QsIGJ1dCBlaXRoZXIgbXVsdGlwbGUgY29yZXMgb3IgY28tcHJvY2Vzc29ycyB3aWxsIGRlYWwg
d2l0aCB0aGlzLiAxMDAwbnMgaXMgMTBHYnBzIGNyeXB0byBzcGVlZCBvbiBvbmUgY29yZSBhbmQg
aXQgaXMgaGlnbHkgcGFyYWxsZWxpc2FibGUgYW5kIGNhY2hlIGZyaWVuZGx5Lg0KDQpCdXQgaWYg
eW91IGhhdmUgdG8gZHJpcCB5b3VyIHBhY2tldHMgdGhyb3VnaCBhIHRyYWRpdGlvbmFsIHNlbmQg
aW50ZXJmYWNlIHRoYXQgaXMgY29weWluZywgYnVmZmVyaW5nIG9yIGJsb2NraW5nLCBhbmQgY2Vy
dGFpbmx5IHN5bmPigJlpbmcgd2l0aCB0aGUga2VybmVsIC0gaXQgaXMgZ29pbmcgdG8gYmUgdG91
Z2guDQoNCkZvciByZWNlaXZlIHlvdSByaXNrIGhpZ2ggbGF0ZW5jeSBvciB0b3AgbXVjaCBzY2hl
ZHVsaW5nIGluIHJlY2VpdmUgYnVmZmVycy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCkZyb206IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dl
dHRAZ29vZ2xlLmNvbT4+DQpTZW50OiBGcmlkYXksIEFwcmlsIDYsIDIwMTggNDowNjowMSBBTQ0K
VG86IE1pa2UgQmlzaG9wDQpDYzogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjsgUHJhdmVlbiBC
YWxhc3VicmFtYW5pYW47IElFVEYgUVVJQyBXRw0KU3ViamVjdDogUmU6IEltcGFjdCBvZiBoYXJk
d2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlDQoNCg0KT24gVGh1LCBB
cHIgNSwgMjAxOCBhdCA1OjU3IFBNIE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxt
YWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+PiB3cm90ZToNClRoYXTigJlzIGludGVyZXN0aW5n
IGRhdGEsIFByYXZlZW4g4oCTIHRoYW5rcy4gIFRoZXJlIGlzIG9uZSBjYXZlYXQgdGhlcmUsIHdo
aWNoIGlzIHRoYXQgKElJVUMsIG9uIGN1cnJlbnQgaGFyZHdhcmUpIHlvdSBjYW7igJl0IGRvIHBh
Y2tldCBwYWNpbmcgd2l0aCBMU08sIGFuZCBzbyBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgZXZl
biBmb3IgVENQIG1hbnkgcHJvdmlkZXJzIGRpc2FibGUgdGhpcyBpbiBwdXJzdWl0IG9mIGJldHRl
ciBlZ3Jlc3MgbWFuYWdlbWVudC4gIFNvIHdoYXQgd2XigJlyZSByZWFsbHkgc2F5aW5nIGlzIHRo
YXQ6DQoNCiAgKiAgIE9uIGN1cnJlbnQgaGFyZHdhcmUgYW5kIE9TIHNldHVwcywgVURQIHJ1bnMg
bGVzcyB0aGFuIGhhbGYgYXMgbXVjaCB0aHJvdWdocHV0IGFzIFRDUDsgdGhhdCBuZWVkcyBzb21l
IG9wdGltaXphdGlvbiwgYXMgd2XigJl2ZSBhbHJlYWR5IGRpc2N1c3NlZA0KICAqICAgVENQIHdp
bGwgZHJhbWF0aWNhbGx5IGdhaW4gcGVyZm9ybWFuY2Ugb25jZSBoYXJkd2FyZSBvZmZsb2FkIGNh
dGNoZXMgdXAgYW5kIGFsbG93cyBwYWNlZCBMU08g8J+Yig0KDQpIb3dldmVyLCBhcyBNaWtrZWwg
cG9pbnRzIG91dCwgdGhlIGNyeXB0byBjb3N0cyBhcmUgbGlrZWx5IHRvIG92ZXJ3aGVsbSB0aGUg
T1MgdGhyb3VnaHB1dCAvIHNjaGVkdWxpbmcgaXNzdWVzIGluIHJlYWwgZGVwbG95bWVudHMuICBT
byBJIHRoaW5rIHRoZSBvdGhlciByZWxldmFudCBwaWVjZSB0byB1bmRlcnN0YW5kaW5nIHRoZSBj
b3N0IGhlcmUgaXMgdGhpczoNCg0KSSBoYXZlIGEgZmV3IGNhc2VzKGJvdGggY2xpZW50IGFuZCBz
ZXJ2ZXIpIHdoZXJlIG15IFVEUCBzZW5kIGNvc3RzIGFyZSBtb3JlIHRoYW4gMzAlKGluIHNvbWUg
Y2FzZXMgNTAlKSBvZiBDUFUgY29uc3VtcHRpb24sIGFuZCBjcnlwdG8gaXMgbGVzcyB0aGFuIDEw
JS4gIFNvIGN1cnJlbnRseSwgSSBhc3N1bWUgY3J5cHRvIGlzIGNoZWFwKGVzcGVjaWFsbHkgQUVT
LUdDTSB3aGVuIGhhcmR3YXJlIGFjY2VsZXJhdGlvbiBpcyBhdmFpbGFibGUpIGFuZCBlZ3Jlc3Mg
aXMgZXhwZW5zaXZlLiAgVURQIGluZ3JlcyBpcyBub3QgdGhhdCBleHBlbnNpdmUsIGJ1dCBjb3Vs
ZCB1c2UgYSBiaXQgb2Ygb3B0aW1pemF0aW9uIGFzIHdlbGwuDQoNClRoZSBvbmx5ICdmYW5jeScg
dGhpbmcgb3VyIGN1cnJlbnQgY29kZSBpcyBkb2luZyBmb3IgY3J5cHRvIGlzIGVuY3J5cHRpbmcg
aW4gcGxhY2UsIHdoaWNoIHdhcyBhIH4yJSB3aW4uICBOaWNlLCBidXQgbm90IHRyYW5zZm9ybWF0
aXZlLiAgU2VlIEVuY3J5cHRJblBsYWNlPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv
bS92Mi91cmw/dT1odHRwcy0zQV9fY3MuY2hyb21pdW0ub3JnX2Nocm9taXVtX3NyY19uZXRfcXVp
Y19jb3JlX3F1aWMtNUZmcmFtZXIuY2MtM0ZzcS0zRHBhY2thZ2UtM0FjaHJvbWl1bS0yNmwtM0Qx
ODkzJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPURqbjNiUTV1TkpEUE1fMnNr
ZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mbT1rTG4yS2dLTFB0R0p4UnZLWEwtRko1SktiLVJ1
MFAwakVMZGh4cFd3TThZJnM9LS1Eb0FMUFpvYTBMNEllOVRaclBLcER5MV9kbmIxa04tM0dhM01y
WG5iMCZlPT4NCg0KSSBoYXZlbid0IGRvbmUgbXVjaCB3b3JrIGJlbmNobWFya2luZyBXaW5kb3dz
LCBzbyBwb3NzaWJseSB0aGUgV2luZG93cyBVRFAgc3RhY2sgaXMgcmVhbGx5IGZhc3QsIGFuZCBz
byBjcnlwdG8gc2VlbXMgcmVhbGx5IHNsb3cgaW4gY29tcGFyaXNvbj8NCg0KDQogICogICBXaGF0
IGlzIHRoZSB0aHJvdWdocHV0IGFuZCByZWxhdGl2ZSBjb3N0IG9mIFRMUy9UQ1AgdmVyc3VzIFFV
SUMgKGkuZS4gaG93IG11Y2ggYXJlIHRoZSBzbWFsbGVyIHVuaXRzIG9mIGVuY3J5cHRpb24gaHVy
dGluZyB1cyB2ZXJzdXMsIHNheSwgMTZLQiBUTFMgcmVjb3Jkcyk/DQoNCiAgICAgKiAgIFRMUyBp
bXBsZW1lbnRhdGlvbnMgYWxyZWFkeSB2YXJ5IGhlcmU6ICBTb21lIGltcGxlbWVudGF0aW9ucyBj
aG9vc2UgbGFyZ2UgcmVjb3JkIHNpemVzLCBzb21lIHZhcnkgcmVjb3JkIHNpemVzIHRvIHJlZHVj
ZSBkZWxheSAvIEhvTEIsIHNvIHRoaXMgcHJvYmFibHkgaXNu4oCZdCBhIHNpbmdsZSBudW1iZXIu
DQoNCiAgKiAgIEhvdyBtdWNoIGFkZGl0aW9uYWwgbG9hZCBkb2VzIFBORSBhZGQgdG8gdGhpcyBk
aWZmZXJlbmNlPw0KICAqICAgVG8gd2hhdCBleHRlbnQgd291bGQgUE5FIG1ha2UgZnV0dXJlIGNy
eXB0byBvZmZsb2FkcyBpbXBvc3NpYmxlIHZlcnN1cyByZXF1aXJlcyBtb3JlIFImRCB0byBkZXZl
bG9wPw0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpx
dWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTWlra2VsIEZhaG7DuGUgSsO4cmdl
bnNlbg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDE4IDE6MzQgUE0NClRvOiBQcmF2ZWVu
IEJhbGFzdWJyYW1hbmlhbiA8cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1h
aWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+PjsgSUVURiBRVUlDIFdHIDxxdWlj
QGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBJbXBhY3Qgb2Yg
aGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZQ0KDQpUaGFua3Mg
Zm9yIHNoYXJpbmcgdGhlc2UgbnVtYmVycy4NCg0KTXkgZ3Vlc3MgaXMgdGhhdCB0aGVzZSBvZmZs
b2FkcyBkZWFsIHdpdGgga2VybmVsIHNjaGVkdWxpbmcsIG1lbW9yeSBjYWNoZSBpc3N1ZXMsIGFu
ZCBpbnRlcnJ1cHQgc2NoZWR1bGluZy4NCg0KSXQgcHJvYmFibHkgaGFzIHZlcnkgbGl0dGxlIHRv
IGRvIHdpdGggY3J5cHRvLCBUQ1AgaGVhZGVycywgYW5kIGFueSBvdGhlciBjcHUgc2Vuc2l0aXZl
IHByb2Nlc3NpbmcuDQoNClRoaXMgaXMgd2hlcmUgbmV0bWFwIGVudGVyczogeW91IGNhbiB0cmFu
c3BhcmVudGx5IGZlZWQgdGhlIGRhdGEgYXMgaXQgYmVjb21lcyBhdmFpbGFibGUgd2l0aCB2ZXJ5
IGxpdHRsZSBzeW5jIHdvcmsgYW5kIHlvdSBjYW4gYWxzbyBlZmZpY2llbnRseSBwaXBlbGluZSBz
byB5b3UgcGFzcyBkYXRhIHRvIGRlY3J5cHRvciwgdGhlbiB0byBhcHAsIHdpdGggYXMgbGl0dGxl
IGJ1cyB0cmFmZmljIGFzIHBvc3NpYmxlLiBObyBuZWVkIHRvIGNvcHkgZGF0YSBvciBzeW5jaHJv
bml6ZSBrZXJuZWwgc3BhY2UuDQoNCkZvciAxSyBwYWNrZXRzIHlvdSB3b3VsZCB1c2UgYWJvdXQg
MTAwMG5zICgzIGN5Y2xlcy9ieXRlKSBvbiBjcnlwdG8gYW5kIHRoaXMgd291bGQgaGFwcGVuIGlu
IEwxIGNhY2hlLiBJdCB3b3VsZCBvZiBjb3Vyc2UgY29uc3VtZSBhIGNvcmUgd2hpY2ggYSBjcnlw
dG8gb2ZmbG9hZCB3b3VsZCBub3QsIGJ1dCB0aGF0IGNhbiBiZSBkZWJhdGVkIGJlY2F1c2Ugd2l0
aCAxOCBjb3JlIHN5c3RlbXMsIHlvdXIgcHJvYmxlbSBpcyBtZW1vcnkgYW5kIG5ldHdvcmsgbW9y
ZSB0aGFuIENQVS4NCg0KTXkgY29uY2VybiB3aXRoIFBORSBpcyBmb3Igc21hbGwgcGFja2V0cyBh
bmQgbG93IGxhdGVuY3kgd2hlcmUNCjEpIGFuIGVzdGltYXRlZCAyNG5zIGZvciBQTiBlbmNyeXB0
aW9uIGFuZCBkZWNyeXB0aW9uIGJlY29tZXMgbWVhc3VyYWJsZSBpZiB5b3VyIG5ldHdvcmsgaXMg
ZmFzdCBlbm91Z2guDQoyKSBhbnkgZGFtYWdlIHRvIHRoZSBwYWNrZXQgYnVmZmVyIGNhdXNlIGFs
bCBzb3J0cyBvZiBtZW1vcnkgYW5kIGNwdSBidXMgdHJhZmZpYyBpc3N1ZXMuDQoNCjEpIGlzIGFu
bm95aW5nLiAyKSBpcyBiYWQsIGNvbXBsZXRlbHkgYXZvaWRhYmxlIGJ1dCBub3QgYXMgUFIgMTA3
OSBpcyBmb3JtdWxhdGVkIGN1cnJlbnRseS4NCg0KMikgaXMgYWxzbyBsaWtlbHkgYmFkIGZvciBo
YXJkd2FyZSBvZmZsb2FkIHVuaXRzIGFzIHdlbGwuDQoNCkFzIHRvIFNSVi1JTyAtIEnigJltIG5v
dCBmYW1pbGlhciB3aXRoIGl0LCBidXQgb2J2aW91c2x5IHRoZXJlIGlzIHNvbWUgSU8gYWJzdHJh
Y3Rpb24gbGF5ZXIgLSB0aGUgcXVlc3Rpb24gaXMgaG93IHlvdSBtYWtlIGl0IGFjY2Vzc2libGUg
dG8gYXBwcyBhcyBvcHBvc2VkIHRvIGRldmljZSBkcml2ZXJzIHRoYXQgZG9lcyBub3Igd29yayB3
aXRoIHlvdSBRVUlDIGN1c3RvbSBzdGFjaywgYW5kIG5ldG1hcCBpcyBvbmUgb3B0aW9uIGhlcmUu
DQoNCktpbmQgUmVnYXJkcywNCk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCg0KDQpPbiA0IEFw
cmlsIDIwMTggYXQgMjIuMTUuNTIsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIChwcmF2Yj00MG1p
Y3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnByYXZiPTQwbWljcm9zb2Z0LmNvbUBk
bWFyYy5pZXRmLm9yZz4pIHdyb3RlOg0KU29tZSBjb21wYXJhdGl2ZSBudW1iZXJzIGZyb20gYW4g
b3V0IG9mIGJveCBkZWZhdWx0IHNldHRpbmdzIFdpbmRvd3MgU2VydmVyIDIwMTYgKHJlbGVhc2Vk
IHZlcnNpb24pIGZvciBhIHNpbmdsZSBjb25uZWN0aW9uIHdpdGggYSBtaWNyb2JlbmNobWFyayB0
b29sOg0KDQpPZmZsb2FkcyBlbmFibGVkDQoNClRDUCBnYnBzDQoNClVEUCBnYnBzDQoNCkxTTyAr
IExSTyArIGNoZWNrc3VtDQoNCjI0DQoNCjMuNg0KDQpDaGVja3N1bSBvbmx5DQoNCjcuNg0KDQoz
LjYNCg0KTm9uZQ0KDQo1LjYNCg0KMi4zDQoNCg0KVGhpcyBpcyBmb3IgYSBmdWxseSBib3R0bGVu
ZWNrZWQgQ1BVIGNvcmUgLS0gaWYgeW91IHJ1biBsb3dlciBkYXRhIHJhdGVzIHRoZXJlIGlzIHN0
aWxsIGEgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZSBpbiBDeWNsZXMvYnl0ZSBjb3N0LiBTYW1lIGlu
Y3JlYXNlZCBDUFUgY29zdCBhcHBsaWVzIGZvciBjbGllbnQgc3lzdGVtcyBnb2luZyBvdmVyIGhp
Z2ggZGF0YSByYXRlIFdpZmkgYW5kIGNlbGx1bGFyLg0KDQpUaGlzIGlzIHdpdGhvdXQgYW55IGNy
eXB0by4gT25jZSB5b3UgYWRkIGNyeXB0byB0aGUgbnVtYmVycyBiZWNvbWUgbXVjaCB3b3JzZSB3
aXRoIGNyeXB0byBjb3N0IGJlY29taW5nIGRvbWluYW50LiBBZGRpbmcgYW5vdGhlciBjcnlwdG8g
c3RlcCBmdXJ0aGVyIGV4YWNlcmJhdGVzIHRoZSBwcm9ibGVtLiBIZW5jZSBjcnlwdG8gb2ZmbG9h
ZCBnYWlucyBpbiBpbXBvcnRhbmNlIGZvbGxvd2VkIGJ5IHRoZXNlIGJhdGNoIG9mZmxvYWRzLg0K
DQpJZiBmb2xrcyBuZWVkIGFueSBtb3JlIG51bWJlcnMgSeKAmWQgYmUgaGFwcHkgdG8gcHJvdmlk
ZSB0aGVtLg0KDQpUaGFua3MNCg0K

--_000_bf540ec1f6f045aca1cf2379380630b5usma1exdag1mb5msgcorpak_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg
MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgRW1vamkiO30NCi8qIFN0eWxlIERlZmluaXRp
b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp
bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu
aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp
b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYu
TXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDow
aW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVm
dDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y
bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t
YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tMTg4MDU3MTE2MTY0MDI3NTY3NGFp
cm1haWxvbiwgbGkubTE4ODA1NzExNjE2NDAyNzU2NzRhaXJtYWlsb24sIGRpdi5tMTg4MDU3MTE2
MTY0MDI3NTY3NGFpcm1haWxvbg0KCXttc28tc3R5bGUtbmFtZTptXzE4ODA1NzExNjE2NDAyNzU2
NzRhaXJtYWlsX29uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow
aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv
bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5t
MTg4MDU3MTE2MTY0MDI3NTY3NGFpcm1haWxvbjAsIGxpLm0xODgwNTcxMTYxNjQwMjc1Njc0YWly
bWFpbG9uMCwgZGl2Lm0xODgwNTcxMTYxNjQwMjc1Njc0YWlybWFpbG9uMA0KCXttc28tc3R5bGUt
bmFtZTptXzE4ODA1NzExNjE2NDAyNzU2NzRhaXJtYWlsb247DQoJbXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN
CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjt9DQpwLm0xODgwNTcxMTYxNjQwMjc1Njc0bXNvcGxhaW50ZXh0LCBs
aS5tMTg4MDU3MTE2MTY0MDI3NTY3NG1zb3BsYWludGV4dCwgZGl2Lm0xODgwNTcxMTYxNjQwMjc1
Njc0bXNvcGxhaW50ZXh0DQoJe21zby1zdHlsZS1uYW1lOm1fMTg4MDU3MTE2MTY0MDI3NTY3NG1z
b3BsYWludGV4dDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu
Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubTE4
ODA1NzExNjE2NDAyNzU2NzRtLTIwMTc3MTQwNDAxMzcxMTYzNDltLTkwMDQ5MTcxNDk0MDU1OTQx
NDNhaXJtYWlsb24sIGxpLm0xODgwNTcxMTYxNjQwMjc1Njc0bS0yMDE3NzE0MDQwMTM3MTE2MzQ5
bS05MDA0OTE3MTQ5NDA1NTk0MTQzYWlybWFpbG9uLCBkaXYubTE4ODA1NzExNjE2NDAyNzU2NzRt
LTIwMTc3MTQwNDAxMzcxMTYzNDltLTkwMDQ5MTcxNDk0MDU1OTQxNDNhaXJtYWlsb24NCgl7bXNv
LXN0eWxlLW5hbWU6bV8xODgwNTcxMTYxNjQwMjc1Njc0bS0yMDE3NzE0MDQwMTM3MTE2MzQ5bS05
MDA0OTE3MTQ5NDA1NTk0MTQzYWlybWFpbG9uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K
CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu
LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt
cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93
dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7
c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp
di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9u
cyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzM4OTMwODE7DQoJbXNvLWxpc3QtdGVtcGxh
dGUtaWRzOjI3MjEzNjk5MDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m
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
cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjMwNTU5
NjM3NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE3NDA3MDc5NjA7fQ0KQGxpc3QgbDE6bGV2
ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0
Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z
dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291
cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs
aXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z
by1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u
dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy
LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N
CkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K
CW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv
cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s
O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21z
by1saXN0LWlkOjk4NzEyNTQ4NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MzM0NzM1NDg7fQ0K
QGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250
LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv
bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u
MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9
DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m
b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K
CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv
bDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z
aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZl
bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C
tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0
Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5
bWJvbDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxMjEyMTEwMjM2Ow0KCW1zby1saXN0LXRl
bXBsYXRlLWlkczo3Nzg3NTg4NDY7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv
bDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z
aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZl
bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C
tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0
Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5
bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t
YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzps
ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu
MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt
c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs
MzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDox
NDU1NTYzNzgxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk
czotNjEzNDE0NzY0IDEyODYzOTcxMDQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2
OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDQ6bGV2ZWwx
DQoJe21zby1sZXZlbC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs
aWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs
NDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO
ZXciO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m
YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu
b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDQ6bGV2ZWw2
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp
c3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i
b2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9
DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5
XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N
CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv
dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286
c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V
UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHBvaW50IG9mIEhXIG9mZmxvYWRzIGlzIHRvIHJl
ZHVjZSB0aGUgbnVtYmVyIG9mIHRpbWVzIHRoZSBrZXJuZWwgKOKAnHRyYW5zcG9ydOKAnSkgc3Rh
Y2sgaXMgaW52b2tlZCB0byBsb2NhdGUgdGhlIGZsb3csIHZhbGlkYXRlIGhlYWRlcnMsIGVucXVl
dWUgZGF0YSBmb3IgZGVsaXZlcnkgdG8gc29ja2V0cywgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5JZiBIVyBjYW4gYXNzb2NpYXRlIG11bHRpcGxlIFFVSUMgcGFja2V0cyB3aXRoIGEgc2lu
Z2xlIGZsb3csIHJlbW92ZSBlbmNyeXB0aW9uIGFuZCBwYXNzIGl0IG9uIHRvIHRoZSBzdGFjaywg
aXQgZG9lcyBub3QgcmVhbGx5IG5lZWQgdG8gc2ltdWxhdGUgdGhlIGRhdGEgYXJyaXZpbmcgaW4g
YSBzaW5nbGUganVtYm8gUVVJQyBwYWNrZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4i
IHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6MGluO21zby1saXN0Omw0IGxldmVsMSBsZm81Ij5JZ29yPG86cD48L286cD48L2xpPjwv
dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+RnJvbTo8L2I+IElhbiBTd2V0dCBbbWFpbHRvOmlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFy
Yy5pZXRmLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDIzLCAyMDE4IDM6
MjAgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0O21pa2tl
bGZqQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFu
ICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYu
b3JnJmd0OzsgTWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJlJmd0OzsgRGV2YWws
IE1hbmFzaSAmbHQ7bWFuYXNpLmRldmFsQGludGVsLmNvbSZndDs7IGlhbnN3ZXR0PTQwZ29vZ2xl
LmNvbUBkbWFyYy5pZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSW1wYWN0IG9mIGhh
cmR3YXJlIG9mZmxvYWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVyZm9ybWFuY2U8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBjbGFyaWZ5IG15IHVuZGVyc3RhbmRpbmcsIHlv
dSdkIGhhdmUgdG8gcmVjZWl2ZSBhbGwgMyBzZWdtZW50cyB0byBkZWNyeXB0IHRoZSBwYXlsb2Fk
PyZuYnNwOyBJZiB0aGF0J3Mgd2hhdCB5b3UncmUgcHJvcG9zaW5nLCB0aGVuIEkgdGhpbmsgaXQn
cyBub3QgYSBnb29kIGRlc2lnbiBmb3IgUVVJQywgYmVjYXVzZSBpdCBhbXBsaWZpZXMgdGhlIGVm
ZmVjdGl2ZSBsb3NzIHJhdGUgYW5kIGl0IGRvZXNuJ3Qgc2F2ZSB0aGF0DQogbXVjaCBDUFUuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0J3Mg
bm90IHRoYXQgaGFyZCBmb3IgdXNlcnNwYWNlIHRvIHByb3ZpZGUgMyBmdWxseSBmb3JtZWQgZW5j
cnlwdGVkIHBhY2tldHMgYW5kIHVzZSBhbiBBUEkgbGlrZSBXaWxsZW0ncyBVRFAgR1NPIHBhdGNo
LCBhbmQgSSBiZWxpZXZlIHRoYXQgYXBwcm9hY2ggaXMgbW9yZSBhZ2lsZSBhcyB3ZWxsLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3Ug
d2FudGVkIHRvIGRvIGNyeXB0byBvZmZsb2FkLCB0aGVuIHlvdSBjb3VsZCBwcm92aWRlIHRoZSBh
YmlsaXR5IHRvIG9mZmxvYWQgcGF5bG9hZCBhbmQgUE4gZW5jcnlwdGlvbiBpbnN0ZWFkIG9mIGRv
aW5nIGl0IGluIHVzZXJzcGFjZS4mbmJzcDsgQXMgYSBib251cywgc3VwcG9ydCBpb3ZlYyBzdHls
ZSBzY2F0dGVyLWdhdGhlciwgc28gYnVsayBwYXlsb2FkcyBuZXZlciBuZWVkIHRvIGJlIGJyb3Vn
aHQgaW50bw0KIENQVSBjYWNoZSBiZWZvcmUgdGhleSdyZSBlbmNyeXB0ZWQgYW5kIGNvcGllZCB0
byB0aGUgTklDLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
T24gTW9uLCBBcHIgMjMsIDIwMTggYXQgMjo0NiBQTSBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2Vu
ICZsdDs8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIj5taWtrZWxmakBnbWFpbC5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk
aXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRibG9vcF9jdXN0b21mb250Ij4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BaCwgSSBzZWUuIFRoYW5rcyBm
b3IgZXhwbGFpbmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1f
MTg4MDU3MTE2MTY0MDI3NTY3NGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+UVVJQyBoYXMgYSBtdWNoIHJlYWNo
ZXIgaW50ZXJmYWNlLCBzbyB0aGVyZSBjb3VsZCBiZSwgc2F5IDEwMCBhY3RpdmUgc3RyZWFtcyB3
YWl0aW5nIGZvciB0cmFuc21pc3Npb24uIFRoZSBRVUlDIGltcGxlbWVudGF0aW9uIHdvdWxkIHVz
ZSBzb21lIHNvcnQgb2Ygc2NoZWR1bGVyIHRvIG1vdmUgdGhlDQogbW9zdCBpbXBvcnRhbnQgcGFy
dHMgZmlyc3Qgd2l0aG91dCBsb29zaW5nIHByb2dyZXNzIG9uIG90aGVyIHBhcnRzLCBmb3IgZXhh
bXBsZSB1c2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgw
NTcxMTYxNjQwMjc1Njc0Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL3VybGRlZmVu
c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2VuLndpa2lwZWRpYS5vcmdfd2lr
aV9EZWZpY2l0LTVGcm91bmQtNUZyb2JpbiZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3
MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQ
bWxvJmFtcDttPWtMbjJLZ0tMUHRHSnhSdktYTC1GSjVKS2ItUnUwUDBqRUxkaHhwV3dNOFkmYW1w
O3M9RWlGeEVsa0g0c2czMG1CQWcxN2hNNkUxdVNuc2sxbV9DY25FcGJmQVI0USZhbXA7ZT0iIHRh
cmdldD0iX2JsYW5rIj5odHRwczovL2VuLndpa2lwZWRpYS4ub3JnL3dpa2kvRGVmaWNpdF9yb3Vu
ZF9yb2JpbjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4
MDU3MTE2MTY0MDI3NTY3NGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3
NTY3NGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPkEgc2ltcGxlIGh1Z2UgYnVmZmVyIHNlZ21lbnRhdGlvbiB3b3VsZCBwcm9iYWJseSBu
b3Qgd29yayBkaXJlY3RseSwgYnV0IGEgbWVhbnMgdG8gZm9yd2FyZCBkYXRhIHByZS13cmFwcGVk
IGluIFFVSUMgZnJhbWVzLCBpbiByZWFzb25hYmxlIHBhY2thZ2UgdW5pdHMsIGJ1dCB3aXRob3V0
IEFFQUQNCiBlbnZlbG9wZSB3b3VsZCBtYWtlIHNlbnNlLiBUaGVzZSBjb3VsZCBiZSBxdWV1ZWQg
aW4gdm9sdW1lcywgbGVhdmluZyBpdCBhbiBvZmZsb2FkZXIgdG8gcHJvY2VlZC48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3NGJsb29w
X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgwNTcxMTYx
NjQwMjc1Njc0Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+SeKAmXZlIGJlZW4gbG9va2luZyBpbnRvIHRoZSBuZXRtYXAgaW50ZXJmYWNl
IHdoZXJlIHlvdSBjYW4gZmVlZCBjb250ZW50IGluIHVuaXRzIGRpcmVjdGx5IHRvIGhhcmR3YXJl
LCBhbmQgSeKAmW0gc3VyZSB5b3UgaGF2ZSBkZXRhaWxlZCBrbm93bGVkZ2Ugb2YgRFBESyB0aGF0
IGRvZXMgc29tZXRoaW5nDQogc2ltaWxhci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3NGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRibG9vcF9zaWduXzE1MjQ1MDg4MDQ2MDA1
NTY4MDAiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5L
aW5kIFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJtMTg4MDU3MTE2MTY0MDI3NTY3NGFpcm1haWxvbiI+T24gMjMgQXByaWwgMjAx
OCBhdCAyMC4zOC4wNiwgRGV2YWwsIE1hbmFzaSAoPGEgaHJlZj0ibWFpbHRvOm1hbmFzaS5kZXZh
bEBpbnRlbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYW5hc2kuZGV2YWxAaW50ZWwuY29tPC9hPikg
d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPknigJltIHRyeWluZyB0byBs
YXkgb3V0IHRoZSBvcHRpb25zIGZvciBUU08vTFNPIHdpdGggUVVJQy4gSW4gbXkgcHJldmlvdXMg
ZS1tYWlsIEkgY29tcGFyZWQgdGhlIG91dGNvbWUgb2YgdmFuaWxsYSBVRFAgc2VnbWVudGF0aW9u
IGFzIGRlZmluZWQgYnkgdGhlIGxhdGVzdA0KIHBhdGNoICg8L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o
dHRwcy0zQV9fbWFyYy5pbmZvXy0zRmwtM0RsaW51eC0yRG5ldGRldi0yNm0tM0QxNTIzOTk1MzA2
MDM5OTItMjZ3LTNEMiZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZh
bXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPWtM
bjJLZ0tMUHRHSnhSdktYTC1GSjVKS2ItUnUwUDBqRUxkaHhwV3dNOFkmYW1wO3M9aFlIWmZaeWZ4
UDdrSW5wVHZORTlVMDJCUEFoamUtWnZhVWdWMXJOQ1NMSSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5r
Ij5odHRwczovL21hcmMuaW5mby8/bD1saW51eC1uZXRkZXYmYW1wO209MTUyMzk5NTMwNjAzOTky
JmFtcDt3PTI8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiksDQo8L3NwYW4+PC9zcGFu
PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj50byBhbiBhbHRlcm5hdGl2ZSBuYXRpdmUgUVVJ
QyBzZWdtZW50YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+
QSBzZWdtZW50IGlzIGEgbGFyZ2UgYnVmZmVyIHByb2R1Y2VkIGluIGFuIGFwcGxpY2F0aW9uLiBU
aGUgc2VnbWVudCBpcyBvZnRlbiBtdWNoIHRvbyBsYXJnZSB0byBnbyBvdXQgb24gdGhlIHdpcmUg
d2l0aCBqdXN0IHByZS1wZW5kZWQgaGVhZGVycy4gVGhlcmVmb3JlDQogc2VnbWVudCBuZWVkcyB0
byBiZSBjaG9wcGVkIHVwIGludG8gYXBwcm9wcmlhdGUgc2l6ZSBhbmQgdGhlIHByZS1wZW5kZWQg
aGVhZGVycyBuZWVkIHRvIGJlIHJlcGxpY2F0ZWQgdG8gbWFrZSBNVFUgc2l6ZSBwYWNrZXRzIGZv
ciB0aGUgd2lyZS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkni
gJltIHN1Z2dlc3RpbmcgdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIgcHJvY2Vzc2luZyBhIGxhcmdl
IGRhdGEgYnVmZmVyIGFzIG11bHRpcGxlIFFVSUMgcGFja2V0cyBlYWNoIHdpdGggYSB1bmlxdWUg
UE4uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCI+TWFuYXNpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJtXzE4ODA1NzExNjE2
NDAyNzU2NzRfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i
c3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu
IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBNaWtrZWwgRmFobsO4
ZSBKw7hyZ2Vuc2VuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50Ojwv
Yj4gTW9uZGF5LCBBcHJpbCAyMywgMjAxOCAxMToyNSBBTTxicj4NCjxiPlRvOjwvYj4gSWFuIFN3
ZXR0ICZsdDtpYW5zd2V0dD08YSBocmVmPSJtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYu
b3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs7
IERldmFsLCBNYW5hc2kgJmx0OzxhIGhyZWY9Im1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29t
IiB0YXJnZXQ9Il9ibGFuayI+bWFuYXNpLmRldmFsQGludGVsLmNvbTwvYT4mZ3Q7OyBNaWtlIEJp
c2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9i
bGFuayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBR
VUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi
PnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OzsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhy
ZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+cHJhdmJAbWlj
cm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBJbXBhY3Qgb2YgaGFy
ZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZTxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRibG9vcF9jdXN0b21mb250Ij4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPknigJltIG5vdCByZWFs
bHkgZmFtaWxpYXIgd2l0aCB0aGlzIGR1bXAgYnV0IHdoYXQgZG9lcyBwYXJ0aWFsIHNlZ21lbnRh
dGlvbiBtZWFuIGhlcmU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJt
XzE4ODA1NzExNjE2NDAyNzU2NzRibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0Ymxvb3BfY3VzdG9tZm9udCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BcmUgeW91IHNwbGl0dGlu
ZyBhIHNpbmdsZSBVRFAgZGF0YWdyYW0gaW50byBtdWx0aXBsZSBmcmFnbWVudHMsIG9yIGFyZSB5
b3UgcHJvY2Vzc2luZyBtdWx0aXBsZSBzZXBhcmF0ZSBRVUlDIHBhY2tldHMsDQogb25lIFBOIGVh
Y2g/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2
NDAyNzU2NzRibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBp
ZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JZiB5b3UgZnJhZ21lbnQgVURQIGRhdGFncmFt
cywgdGhhdCBjYW4gYmUgYSBiaWcgaXNzdWUgYmVjYXVzZSBkaWZmZXJlbnQgZnJhZ21lbnRzIG1h
eSByYWNlIGFsb25nIGRpZmZlcmVudCByb3V0ZXMsDQogY2F1c2luZyB1bmV4cGVjdGVkIGRlbGF5
cyBhbmQgYmxvY2tpbmcgYXQgdGhlIG90aGVyIGVuZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3NGJsb29wX3NpZ25fMTUyNDUwNzcz
MDAzMDU2Mzg0MCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJtMTg4MDU3MTE2MTY0MDI3NTY3NGFpcm1haWxvbjAiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj5PbiAyMyBBcHJpbCAyMDE4IGF0IDIwLjE4LjU0LCBEZXZhbCwgTWFuYXNpICg8YSBo
cmVmPSJtYWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hbmFz
aS5kZXZhbEBpbnRlbC5jb208L2E+KSB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMxRjQ5N0QiPklmIHdlIGRvIFRTTyAvIExTTyB3aXRoIFFVSUMsIHRoZSBpbml0aWFsIHNl
Z21lbnQgcHJvdmlkZWQgY2FuIGxvb2sgbGlrZSDigJM8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5NQUMg4oCT
IElQIOKAkyBVRFAg4oCTIFFVSUMgQ2xlYXIg4oCTIFFVSUMgZW5jcnlwdGVkIGhlYWRlciAoUE49
eCkg4oCTIFFVSUMgRW5jcnlwdGVkIHBheWxvYWQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTE4ODA1NzExNjE2NDAyNzU2NzRtc29w
bGFpbnRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHdlIGp1c3QgdXNl
IHRoZSBzdGFja+KAmXMgdWRwIHNlZ21lbnRhdGlvbiAodXNpbmcgdGhlIHBhdGNoIC0NCjwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p
bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19tYXJjLmluZm9fLTNGbC0zRGxpbnV4LTJEbmV0ZGV2
LTI2bS0zRDE1MjM5OTUzMDYwMzk5Mi0yNnctM0QyJmFtcDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpj
YU1GNHcwRjRqcE42TFpnJmFtcDtyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5f
bTU1S1BtbG8mYW1wO209a0xuMktnS0xQdEdKeFJ2S1hMLUZKNUpLYi1SdTBQMGpFTGRoeHBXd004
WSZhbXA7cz1oWUhaZlp5ZnhQN2tJbnBUdk5FOVUwMkJQQWhqZS1admFVZ1Yxck5DU0xJJmFtcDtl
PSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbWFyYy5pbmZvLz9sPWxpbnV4LW5ldGRldiZhbXA7
bT0xNTIzOTk1MzA2MDM5OTImYW1wO3c9MjwvYT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+
KSwNCiB0aGUgb3V0Y29tZSBvZiBRVUlDIHBhY2tldHMgb24gdGhlIHdpcmUgd291bGQgYmU6PC9z
cGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBDbGVhciDi
gJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAoUE49eCwgcGFydGlhbCBzZWdtZW50IDEvMyk8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv
cjojMUY0OTdEIj5NQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMgZW5jcnlwdGVkIHBhcnQgKHBh
cnRpYWwgc2VnbWVudCAyLzMpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TUFDIOKAkyBJUCDigJMgVURQIOKA
kyBRVUlDIGVuY3J5cHRlZCBwYXJ0IChwYXJ0aWFsIHNlZ21lbnQgMy8zKTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5
N0QiPuKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlB1dHRpbmcg
dGhlc2UgYmFjayB0b2dldGhlciBpbiBhIHN0YWNrIC8gaGFyZHdhcmUgbG9va3MgbGlrZSBhIHBh
aW5mdWwgYW5kIHBvdGVudGlhbGx5IG5vbi1kZXRlcm1pbmlzdGljIGFjdGl2aXR5Lg0KPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s
b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3
RCI+SXQgd291bGQgYmUgZWFzaWVyIHRvIGRvIGEgbmF0aXZlIFFVSUMgb2ZmbG9hZCwgd2hlcmUg
dGhlIHBhY2tldCBvbiB3aXJlIGNhbiBiZSBpZGVudGlmaWVkIGJ5IFFVSUMgQ2lEIGFuZCBhcHBy
b3ByaWF0ZSBwYWNrZXQgbnVtYmVyLiBUaGVyZWZvcmUsIG9yaWdpbmFsDQogcGFja2V0IGxvb2tz
IGxpa2UgLSBNQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMgQ2xlYXIg4oCTIFFVSUMgZW5jcnlw
dGVkIGhlYWRlciAoUE49eCkg4oCTIFFVSUMgRW5jcnlwdGVkIHBheWxvYWQuDQo8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MUY0OTdEIj5JZiB3ZSBqdXN0IGNyZWF0ZSBhbm90aGVyIHZlcnNpb24gb2Ygc2VnbWVudGF0aW9u
IGNhbGxlZCBRVUlDIHNlZ21lbnRhdGlvbiwgdGhlIG91dGNvbWUgb2YgcGFja2V0cyBvbiB0aGUg
d2lyZSB3b3VsZCBiZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5NQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFV
SUMgQ2xlYXIg4oCTIFFVSUMgZW5jcnlwdGVkIHBhcnQgKFBOPXgsIHBhcnRpYWwgc2VnbWVudCAx
LzMpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iY29sb3I6IzFGNDk3RCI+TUFDIOKAkyBJUCDigJMgVURQIOKAkyBRVUlDIENsZWFyIOKA
kyBRVUlDIGVuY3J5cHRlZCBwYXJ0IChQTj14JiM0MzsxLCBwYXJ0aWFsIHNlZ21lbnQgMi8zKTwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMxRjQ5N0QiPk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJ
QyBlbmNyeXB0ZWQgcGFydCAoUE49eCYjNDM7MiwgcGFydGlhbCBzZWdtZW50IDMvMyk8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv
cjojMUY0OTdEIj7igKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZiB0aGlzIHNldCBvZiBzZWdtZW50cyB3
ZXJlIHRvIGJlIHJlLWFzc2VtYmxlZCwgdGhlIGFiaWxpdHkgdG8gaWRlbnRpZnkgQ2lEIGFuZCBQ
TiB3b3VsZCBzaW1wbGlmeSB0aGlzIHRhc2suIEkgdGhpbmsgdGhpcyBpcyBhIHNpbXBsZXIgaW1w
bGVtZW50YXRpb24uDQogRG8gb3RoZXJzIHNlZSBhbiBpc3N1ZSB3aXRoIHRoaXM/PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6
IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi
Pk1hbmFzaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+
IFFVSUMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8
L2I+SWFuIFN3ZXR0PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMDYsIDIwMTggMTo1
NSBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlz
aG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9h
PiZndDs8YnI+DQo8Yj5DYzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVm
PSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiQG1pY3Jv
c29mdC5jb208L2E+Jmd0OzsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7PGEgaHJlZj0i
bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1pa2tlbGZqQGdtYWls
LmNvbTwvYT4mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYu
b3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBw
ZXJmb3JtYW5jZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBORSBkb2Vzbid0
IHByZWNsdWRlIFVEUCBMUk8gb3IgcGFjaW5nIG9mZmxvYWQuPG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SG93ZXZlciwgaW4gYSBoaWdobHkgb3B0aW1p
emVkIHN0YWNrKGllOiBUaGUgRGlza3xDcnlwdHxOZXQgcGFwZXIgZnJvbSBTSUdDT01NIDIwMTcp
IG5vdCB0b3VjaGluZyhpZTogYnJpbmdpbmcgaW50byBtZW1vcnkgb3IgY2FjaGUpIHRoZSBjb250
ZW50IHRvIGJlIHNlbnQgdW50aWwgdGhlIGxhc3QgcG9zc2libGUNCiBtb21lbnQgaXMgY3JpdGlj
YWwuJm5ic3A7IFBORSBsaWtlbHkgbWVhbnMgdG91Y2hpbmcgdGhhdCBjb250ZW50IG11Y2ggZWFy
bGllci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPkJ1dCBwZXJzb25hbGx5IEkgY29uc2lkZXIgdGhlIGFjdHVhbCBjcnlwdG8gd2UncmUg
dGFsa2luZyBhYm91dCgyIEFFUyBpbnN0cnVjdGlvbnM/KSBhZGRpbmcgYmFzaWNhbGx5IGZyZWUu
Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5PbiBGcmksIEFwciA2LCAyMDE4IGF0IDQ6MzcgUE0gTWlrZSBCaXNob3Ag
Jmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsi
Pm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBmb3IgdGhlIGNsYXJpZmlj
YXRpb24uJm5ic3A7IEkgZ3Vlc3Mgd2hhdCBJ4oCZbSByZWFsbHkgZ2V0dGluZyBkb3duIHRvIGlz
IGhvdyBkbyB3ZSBxdWFudGlmeSB0aGUgYWN0dWFsDQo8aT5jb3N0PC9pPiBvZiBQTkU/Jm5ic3A7
IEFyZSB3ZSBzdWJzdGFudGlhbGx5IGluY3JlYXNpbmcgdGhlIGNyeXB0byBjb3N0cz8mbmJzcDsg
SWYgSWFuIGlzIHNheWluZyB0aGF0IGNyeXB0byBpcyBjb21wYXJhdGl2ZWx5IGNoZWFwIGFuZCB0
aGUgY29zdCBpcyB0aGF0IGl04oCZcyBoYXJkZXIgdG8gb2ZmbG9hZCBzb21ldGhpbmcgdGhhdOKA
mXMgY29tcGFyYXRpdmVseSBjaGVhcCwgd2hhdCBoYXZlIHdlIGxvc3Q/Jm5ic3A7IEnigJlkIHRo
aW5rIHdlIHdhbnQgdG8gb2ZmbG9hZCB0aGUNCiBtb3N0IGludGVuc2l2ZSBwaWVjZSB3ZSBjYW4s
IGFuZCBpdCBzZWVtcyBsaWtlIHdl4oCZcmUgdGFsa2luZyBhYm91dCBjcnlwdG8gb2ZmbG9hZHMu
Li4uJm5ic3A7IE9yIGFyZSB3ZSBzYXlpbmcgaW5zdGVhZCB0aGF0IHRoZSBjcnlwdG8gbWFrZXMg
aXQgaGFyZGVyIHRvIG9mZmxvYWQgb3RoZXIgdGhpbmdzIGluIHRoZSBmdXR1cmUsIGxpa2UgYSBR
VUlDIGVxdWl2YWxlbnQgdG8gTFJPL0xTTz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp
biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gTWlra2VsIEZhaG7D
uGUgSsO4cmdlbnNlbiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20i
IHRhcmdldD0iX2JsYW5rIj5taWtrZWxmakBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8
L2I+IFRodXJzZGF5LCBBcHJpbCA1LCAyMDE4IDk6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IElhbiBT
d2V0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20iIHRhcmdldD0iX2Js
YW5rIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPiZndDs7IE1pa2UgQmlzaG9wICZsdDs8YSBocmVm
PSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiIHRhcmdldD0iX2JsYW5rIj5tYmlzaG9wQGV2
ZXF1ZWZvdS5iZTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh
biAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5r
Ij5wcmF2YkBtaWNyb3NvZnQuY29tPC9hPiZndDs7IElFVEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0i
bWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZn
dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBv
biBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9
Im1fMTg4MDU3MTE2MTY0MDI3NTY3NG1fLTIwMTc3MTQwNDAxMzcxMTYzNDljb21wb3NlLWNvbnRh
aW5lciI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvIGJl
IGNsZWFyIC0gSSBkb27igJl0IHRoaW5rIGNyeXB0byBpcyBvdmVyc2hhZG93aW5nIG90aGVyIGlz
c3VlcyBhcyBNaWtlIHJlYWQgbXkgcG9zdC4gSXQgY2VydGFpbmx5IGNvbWVzIGF0IGEgY29zdCwg
YnV0IGVpdGhlciBtdWx0aXBsZSBjb3JlcyBvciBjby1wcm9jZXNzb3JzIHdpbGwgZGVhbCB3aXRo
IHRoaXMuDQogMTAwMG5zIGlzIDEwR2JwcyBjcnlwdG8gc3BlZWQgb24gb25lIGNvcmUgYW5kIGl0
IGlzIGhpZ2x5IHBhcmFsbGVsaXNhYmxlIGFuZCBjYWNoZSBmcmllbmRseS48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJ1dCBpZiB5b3Ug
aGF2ZSB0byBkcmlwIHlvdXIgcGFja2V0cyB0aHJvdWdoIGEgdHJhZGl0aW9uYWwgc2VuZCBpbnRl
cmZhY2UgdGhhdCBpcyBjb3B5aW5nLCBidWZmZXJpbmcgb3IgYmxvY2tpbmcsIGFuZCBjZXJ0YWlu
bHkgc3luY+KAmWluZyB3aXRoIHRoZSBrZXJuZWwgLSBpdCBpcyBnb2luZyB0byBiZSB0b3VnaC48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PkZvciByZWNlaXZlIHlvdSByaXNrIGhpZ2ggbGF0ZW5jeSBvciB0b3AgbXVjaCBzY2hlZHVsaW5n
IGluIHJlY2VpdmUgYnVmZmVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5
bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+DQo8aHIgc2l6ZT0iMiIg
d2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGlkPSJtXzE4
ODA1NzExNjE2NDAyNzU2NzRtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5ZGl2UnBseUZ3ZE1zZyI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTo8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IElhbiBTd2V0dCAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pYW5zd2V0dEBn
b29nbGUuY29tPC9hPiZndDs8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCA2LCAyMDE4
IDQ6MDY6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgQmlzaG9wPGJyPg0KPGI+Q2M6PC9iPiBN
aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuOyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbjsgSUVURiBR
VUlDIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9h
ZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZTwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgQXBy
IDUsIDIwMTggYXQgNTo1NyBQTSBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNo
b3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo
dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+VGhhdOKAmXMgaW50ZXJlc3RpbmcgZGF0YSwgUHJhdmVlbiDigJMgdGhhbmtzLiZu
YnNwOyBUaGVyZSBpcyBvbmUgY2F2ZWF0IHRoZXJlLCB3aGljaCBpcyB0aGF0IChJSVVDLCBvbiBj
dXJyZW50IGhhcmR3YXJlKSB5b3UgY2Fu4oCZdCBkbyBwYWNrZXQgcGFjaW5nIHdpdGggTFNPLCBh
bmQgc28gbXkgdW5kZXJzdGFuZGluZyBpcw0KIHRoYXQgZXZlbiBmb3IgVENQIG1hbnkgcHJvdmlk
ZXJzIGRpc2FibGUgdGhpcyBpbiBwdXJzdWl0IG9mIGJldHRlciBlZ3Jlc3MgbWFuYWdlbWVudC4m
bmJzcDsgU28gd2hhdCB3ZeKAmXJlIHJlYWxseSBzYXlpbmcgaXMgdGhhdDo8bzpwPjwvbzpwPjwv
cD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIg
bGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIGN1cnJlbnQgaGFyZHdhcmUgYW5k
IE9TIHNldHVwcywgVURQIHJ1bnMgbGVzcyB0aGFuIGhhbGYgYXMgbXVjaCB0aHJvdWdocHV0IGFz
IFRDUDsgdGhhdCBuZWVkcyBzb21lIG9wdGltaXphdGlvbiwgYXMgd2XigJl2ZSBhbHJlYWR5IGRp
c2N1c3NlZDwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t
bGlzdDpsMiBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VENQIHdpbGwgZHJhbWF0
aWNhbGx5IGdhaW4gcGVyZm9ybWFuY2Ugb25jZSBoYXJkd2FyZSBvZmZsb2FkIGNhdGNoZXMgdXAg
YW5kIGFsbG93cw0KPHU+cGFjZWQ8L3U+IExTTyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJp
ZiI+JiMxMjg1MjI7PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SG93
ZXZlciwgYXMgTWlra2VsIHBvaW50cyBvdXQsIHRoZSBjcnlwdG8gY29zdHMgYXJlIGxpa2VseSB0
byBvdmVyd2hlbG0gdGhlIE9TIHRocm91Z2hwdXQgLyBzY2hlZHVsaW5nIGlzc3VlcyBpbiByZWFs
IGRlcGxveW1lbnRzLiZuYnNwOyBTbyBJIHRoaW5rIHRoZSBvdGhlciByZWxldmFudCBwaWVjZSB0
byB1bmRlcnN0YW5kaW5nDQogdGhlIGNvc3QgaGVyZSBpcyB0aGlzOjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5JIGhhdmUgYSBmZXcgY2FzZXMoYm90aCBjbGllbnQgYW5kIHNlcnZlcikgd2hlcmUg
bXkgVURQIHNlbmQgY29zdHMgYXJlIG1vcmUgdGhhbiAzMCUoaW4gc29tZSBjYXNlcyA1MCUpIG9m
IENQVSBjb25zdW1wdGlvbiwgYW5kIGNyeXB0byBpcyBsZXNzIHRoYW4gMTAlLiZuYnNwOyBTbyBj
dXJyZW50bHksIEkgYXNzdW1lDQogY3J5cHRvIGlzIGNoZWFwKGVzcGVjaWFsbHkgQUVTLUdDTSB3
aGVuIGhhcmR3YXJlIGFjY2VsZXJhdGlvbiBpcyBhdmFpbGFibGUpIGFuZCBlZ3Jlc3MgaXMgZXhw
ZW5zaXZlLiZuYnNwOyBVRFAgaW5ncmVzIGlzIG5vdCB0aGF0IGV4cGVuc2l2ZSwgYnV0IGNvdWxk
IHVzZSBhIGJpdCBvZiBvcHRpbWl6YXRpb24gYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBvbmx5ICdmYW5jeScgdGhp
bmcgb3VyIGN1cnJlbnQgY29kZSBpcyBkb2luZyBmb3IgY3J5cHRvIGlzIGVuY3J5cHRpbmcgaW4g
cGxhY2UsIHdoaWNoIHdhcyBhIH4yJSB3aW4uJm5ic3A7IE5pY2UsIGJ1dCBub3QgdHJhbnNmb3Jt
YXRpdmUuJm5ic3A7IFNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu
Y29tL3YyL3VybD91PWh0dHBzLTNBX19jcy5jaHJvbWl1bS5vcmdfY2hyb21pdW1fc3JjX25ldF9x
dWljX2NvcmVfcXVpYy01RmZyYW1lci5jYy0zRnNxLTNEcGFja2FnZS0zQWNocm9taXVtLTI2bC0z
RDE4OTMmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9RGpu
M2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZhbXA7bT1rTG4yS2dLTFB0
R0p4UnZLWEwtRko1SktiLVJ1MFAwakVMZGh4cFd3TThZJmFtcDtzPS0tRG9BTFBab2EwTDRJZTlU
WnJQS3BEeTFfZG5iMWtOLTNHYTNNclhuYjAmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpFbmNy
eXB0SW5QbGFjZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPkkgaGF2ZW4ndCBkb25lIG11Y2ggd29yayBiZW5jaG1hcmtpbmcgV2lu
ZG93cywgc28gcG9zc2libHkgdGhlIFdpbmRvd3MgVURQIHN0YWNrIGlzIHJlYWxseSBmYXN0LCBh
bmQgc28gY3J5cHRvIHNlZW1zIHJlYWxseSBzbG93IGluIGNvbXBhcmlzb24/PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s
ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+V2hh
dCBpcyB0aGUgdGhyb3VnaHB1dCBhbmQgcmVsYXRpdmUgY29zdCBvZiBUTFMvVENQIHZlcnN1cyBR
VUlDIChpLmUuIGhvdyBtdWNoIGFyZSB0aGUgc21hbGxlciB1bml0cyBvZiBlbmNyeXB0aW9uIGh1
cnRpbmcgdXMgdmVyc3VzLCBzYXksIDE2S0IgVExTIHJlY29yZHMpPw0KPC9zcGFuPjxvOnA+PC9v
OnA+PC9saT48L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMiBsZm8zIj4NCjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj5UTFMgaW1wbGVtZW50YXRpb25zIGFscmVhZHkgdmFyeSBoZXJlOiZuYnNwOyBTb21l
IGltcGxlbWVudGF0aW9ucyBjaG9vc2UgbGFyZ2UgcmVjb3JkIHNpemVzLCBzb21lIHZhcnkgcmVj
b3JkIHNpemVzIHRvIHJlZHVjZSBkZWxheSAvIEhvTEIsIHNvIHRoaXMgcHJvYmFibHkgaXNu4oCZ
dCBhIHNpbmdsZSBudW1iZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjx1
bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx
IGxmbzQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhvdyBtdWNoIGFkZGl0aW9uYWwgbG9hZCBkb2Vz
IFBORSBhZGQgdG8gdGhpcyBkaWZmZXJlbmNlPzwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvNCI+DQo8c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+VG8gd2hhdCBleHRlbnQgd291bGQgUE5FIG1ha2UgZnV0dXJlIGNyeXB0byBvZmZsb2Fk
cw0KPGk+aW1wb3NzaWJsZTwvaT4gdmVyc3VzIDxpPnJlcXVpcmVzIG1vcmUgUiZhbXA7RCB0byBk
ZXZlbG9wPC9pPj88L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzo8
YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVp
Yy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWlra2VsIEZhaG7D
uGUgSsO4cmdlbnNlbjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTgg
MTozNCBQTTxicj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZi
PTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj40MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzsgSUVURiBRVUlD
IFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1
aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSW1wYWN0IG9mIGhh
cmR3YXJlIG9mZmxvYWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVyZm9ybWFuY2U8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0bV8tMjAxNzcxNDA0MDEzNzEx
NjM0OW1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3Igc2hhcmluZyB0aGVzZSBu
dW1iZXJzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgwNTcx
MTYxNjQwMjc1Njc0bV8tMjAxNzcxNDA0MDEzNzExNjM0OW1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNi
bG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgw
NTcxMTYxNjQwMjc1Njc0bV8tMjAxNzcxNDA0MDEzNzExNjM0OW1fLTkwMDQ5MTcxNDk0MDU1OTQx
NDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPk15IGd1ZXNzIGlzIHRoYXQgdGhlc2Ugb2ZmbG9hZHMgZGVhbCB3aXRoIGtlcm5lbCBz
Y2hlZHVsaW5nLCBtZW1vcnkgY2FjaGUgaXNzdWVzLCBhbmQgaW50ZXJydXB0IHNjaGVkdWxpbmcu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAy
NzU2NzRtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1
c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2
NDAyNzU2NzRtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29w
X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
SXQgcHJvYmFibHkgaGFzIHZlcnkgbGl0dGxlIHRvIGRvIHdpdGggY3J5cHRvLCBUQ1AgaGVhZGVy
cywgYW5kIGFueSBvdGhlciBjcHUgc2Vuc2l0aXZlIHByb2Nlc3NpbmcuPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRtXy0yMDE3NzE0
MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRtXy0yMDE3
NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBpcyB3aGVyZSBu
ZXRtYXAgZW50ZXJzOiB5b3UgY2FuIHRyYW5zcGFyZW50bHkgZmVlZCB0aGUgZGF0YSBhcyBpdCBi
ZWNvbWVzIGF2YWlsYWJsZSB3aXRoIHZlcnkgbGl0dGxlIHN5bmMNCiB3b3JrIGFuZCB5b3UgY2Fu
IGFsc28gZWZmaWNpZW50bHkgcGlwZWxpbmUgc28geW91IHBhc3MgZGF0YSB0byBkZWNyeXB0b3Is
IHRoZW4gdG8gYXBwLCB3aXRoIGFzIGxpdHRsZSBidXMgdHJhZmZpYyBhcyBwb3NzaWJsZS4gTm8g
bmVlZCB0byBjb3B5IGRhdGEgb3Igc3luY2hyb25pemUga2VybmVsIHNwYWNlLjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0bV8tMjAx
NzcxNDA0MDEzNzExNjM0OW1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0bV8t
MjAxNzcxNDA0MDEzNzExNjM0OW1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkZvciAxSyBwYWNr
ZXRzIHlvdSB3b3VsZCB1c2UgYWJvdXQgMTAwMG5zICgzIGN5Y2xlcy9ieXRlKSBvbiBjcnlwdG8g
YW5kIHRoaXMgd291bGQgaGFwcGVuIGluIEwxIGNhY2hlLiBJdCB3b3VsZA0KIG9mIGNvdXJzZSBj
b25zdW1lIGEgY29yZSB3aGljaCBhIGNyeXB0byBvZmZsb2FkIHdvdWxkIG5vdCwgYnV0IHRoYXQg
Y2FuIGJlIGRlYmF0ZWQgYmVjYXVzZSB3aXRoIDE4IGNvcmUgc3lzdGVtcywgeW91ciBwcm9ibGVt
IGlzIG1lbW9yeSBhbmQgbmV0d29yayBtb3JlIHRoYW4gQ1BVLjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0bV8tMjAxNzcxNDA0MDEz
NzExNjM0OW1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0bV8tMjAxNzcxNDA0
MDEzNzExNjM0OW1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk15IGNvbmNlcm4gd2l0aCBQTkUg
aXMgZm9yIHNtYWxsIHBhY2tldHMgYW5kIGxvdyBsYXRlbmN5IHdoZXJlPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRtXy0yMDE3NzE0
MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+MSkgYW4gZXN0aW1hdGVkIDI0
bnMgZm9yIFBOIGVuY3J5cHRpb24gYW5kIGRlY3J5cHRpb24gYmVjb21lcyBtZWFzdXJhYmxlIGlm
IHlvdXIgbmV0d29yayBpcyBmYXN0IGVub3VnaC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3NG1fLTIwMTc3MTQwNDAxMzcxMTYzNDlt
Xy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yKSBhbnkgZGFtYWdlIHRvIHRoZSBwYWNrZXQgYnVm
ZmVyIGNhdXNlIGFsbCBzb3J0cyBvZiBtZW1vcnkgYW5kIGNwdSBidXMgdHJhZmZpYyBpc3N1ZXMu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAy
NzU2NzRtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1
c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2
NDAyNzU2NzRtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29w
X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
MSkgaXMgYW5ub3lpbmcuIDIpIGlzIGJhZCwgY29tcGxldGVseSBhdm9pZGFibGUgYnV0IG5vdCBh
cyBQUiAxMDc5IGlzIGZvcm11bGF0ZWQgY3VycmVudGx5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0bV8tMjAxNzcxNDA0MDEzNzEx
NjM0OW1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0bV8tMjAxNzcxNDA0MDEz
NzExNjM0OW1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjIpIGlzIGFsc28gbGlrZWx5IGJhZCBm
b3IgaGFyZHdhcmUgb2ZmbG9hZCB1bml0cyBhcyB3ZWxsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0bV8tMjAxNzcxNDA0MDEzNzEx
NjM0OW1fLTkwMDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QXMg
dG8gU1JWLUlPIC0gSeKAmW0gbm90IGZhbWlsaWFyIHdpdGggaXQsIGJ1dCBvYnZpb3VzbHkgdGhl
cmUgaXMgc29tZSBJTyBhYnN0cmFjdGlvbiBsYXllciAtIHRoZSBxdWVzdGlvbiBpcyBob3cNCiB5
b3UgbWFrZSBpdCBhY2Nlc3NpYmxlIHRvIGFwcHMgYXMgb3Bwb3NlZCB0byBkZXZpY2UgZHJpdmVy
cyB0aGF0IGRvZXMgbm9yIHdvcmsgd2l0aCB5b3UgUVVJQyBjdXN0b20gc3RhY2ssIGFuZCBuZXRt
YXAgaXMgb25lIG9wdGlvbiBoZXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRtXy0yMDE3NzE0MDQwMTM3
MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX3NpZ25fMTUyMjg3MzM1MDQxNTEyMDEy
OCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+S2lu
ZCBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t
OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Im0xODgwNTcxMTYxNjQwMjc1Njc0bS0yMDE3NzE0MDQwMTM3MTE2MzQ5bS05MDA0OTE3MTQ5
NDA1NTk0MTQzYWlybWFpbG9uIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiA0IEFwcmlsIDIwMTgg
YXQgMjIuMTUuNTIsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICg8YSBocmVmPSJtYWlsdG86cHJh
dmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cHJhdmI9
NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPikgd3JvdGU6PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj5Tb21lIGNvbXBhcmF0aXZlIG51bWJlcnMgZnJvbSBhbiBvdXQgb2Yg
Ym94IGRlZmF1bHQgc2V0dGluZ3MgV2luZG93cyBTZXJ2ZXIgMjAxNiAocmVsZWFzZWQgdmVyc2lv
bikgZm9yIGEgc2luZ2xlDQogY29ubmVjdGlvbiB3aXRoIGEgbWljcm9iZW5jaG1hcmsgdG9vbDo8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05v
cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5
bGU9ImJvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9
IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuODVwdDtib3JkZXI6c29saWQgIzk5
OTk5OSAxLjBwdDtib3JkZXItYm90dG9tOnNvbGlkICM2NjY2NjYgMS41cHQ7cGFkZGluZzowaW4g
NS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPk9mZmxvYWRzIGVuYWJsZWQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N
Cjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7Ym9yZGVy
LXRvcDpzb2xpZCAjOTk5OTk5IDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpz
b2xpZCAjNjY2NjY2IDEuNXB0O2JvcmRlci1yaWdodDpzb2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRp
bmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj5UQ1AgZ2Jwczwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0K
PHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2LjlwdDtib3JkZXIt
dG9wOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNv
bGlkICM2NjY2NjYgMS41cHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7cGFkZGlu
ZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPlVEUCBnYnBzPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8
L3RyPg0KPHRyPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2
Ljg1cHQ7Ym9yZGVyOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6
MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5MU08gJiM0MzsgTFJPICYjNDM7IGNoZWNrc3VtPC9zcGFuPjwvYj48bzpwPjwv
bzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0
aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206
c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRk
aW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+MjQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIx
NTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2LjlwdDtib3JkZXItdG9wOm5vbmU7Ym9y
ZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXJp
Z2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjMuNjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9w
IiBzdHlsZT0id2lkdGg6MTE2Ljg1cHQ7Ym9yZGVyOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVy
LXRvcDpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5DaGVja3N1bSBvbmx5PC9zcGFuPjwvYj48bzpw
PjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3
aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0
b206c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtw
YWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+Ny42PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0
aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7Ym9yZGVyLXRvcDpub25l
O2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjOTk5OTk5IDEuMHB0O2JvcmRl
ci1yaWdodDpzb2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4zLjY8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249
InRvcCIgc3R5bGU9IndpZHRoOjExNi44NXB0O2JvcmRlcjpzb2xpZCAjOTk5OTk5IDEuMHB0O2Jv
cmRlci10b3A6bm9uZTtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Tm9uZTwvc3Bhbj48L2I+PG86cD48L286
cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6
MTE2LjlwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNv
bGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7cGFkZGlu
ZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPjUuNjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1
NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTtib3Jk
ZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItcmln
aHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Mi4zPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgaXMgZm9yIGEg
ZnVsbHkgYm90dGxlbmVja2VkIENQVSBjb3JlIC0tDQo8aT5pZiB5b3UgcnVuIGxvd2VyIGRhdGEg
cmF0ZXMgdGhlcmUgaXMgc3RpbGwgYSBzaWduaWZpY2FudCBkaWZmZXJlbmNlIGluIEN5Y2xlcy9i
eXRlIGNvc3Q8L2k+LiBTYW1lIGluY3JlYXNlZCBDUFUgY29zdCBhcHBsaWVzIGZvciBjbGllbnQg
c3lzdGVtcyBnb2luZyBvdmVyIGhpZ2ggZGF0YSByYXRlIFdpZmkgYW5kIGNlbGx1bGFyLg0KPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBpcyB3aXRob3V0IGFueSBjcnlwdG8uIE9uY2UgeW91
IGFkZCBjcnlwdG8gdGhlIG51bWJlcnMgYmVjb21lIG11Y2ggd29yc2UNCjxpPndpdGggY3J5cHRv
IGNvc3QgYmVjb21pbmcgZG9taW5hbnQ8L2k+LiBBZGRpbmcgYW5vdGhlciBjcnlwdG8gc3RlcCBm
dXJ0aGVyIGV4YWNlcmJhdGVzIHRoZSBwcm9ibGVtLiBIZW5jZSBjcnlwdG8gb2ZmbG9hZCBnYWlu
cyBpbiBpbXBvcnRhbmNlIGZvbGxvd2VkIGJ5IHRoZXNlIGJhdGNoIG9mZmxvYWRzLjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPklmIGZvbGtzIG5lZWQgYW55IG1vcmUgbnVtYmVycyBJ4oCZZCBiZSBo
YXBweSB0byBwcm92aWRlIHRoZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_bf540ec1f6f045aca1cf2379380630b5usma1exdag1mb5msgcorpak_--


From nobody Mon Apr 23 13:06:48 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1743712D946 for ; Mon, 23 Apr 2018 13:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.079
X-Spam-Level: 
X-Spam-Status: No, score=0.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzPEsdXPAKjc for ; Mon, 23 Apr 2018 13:06:38 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0104.outbound.protection.outlook.com [104.47.34.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 3C1F6126B6E for ; Mon, 23 Apr 2018 13:06:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tMNKJPxOj7MvsA1emv6crERDYpec+IJcWP6SjBZswFc=; b=Uf3N4j4+m7JrNXf4tx7EmIee0YPhXO4dxxPcRYxD0iDboy37ETWv1xZfAVOe/r8I+//ZJEuwKmiH7yDZf4YBmWhvGDA/t9O3vz6YLwSOfCDHZuigSjTnTTzIjPo4dUdOsvsFHiX/wl3If7n3AiPRZKmQxWeDIG2rPmoSMZFepN8=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1374.namprd08.prod.outlook.com (10.162.1.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Mon, 23 Apr 2018 20:06:34 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::dd26:af46:4549:f472]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::dd26:af46:4549:f472%13]) with mapi id 15.20.0696.017; Mon, 23 Apr 2018 20:06:34 +0000
From: Mike Bishop 
To: "Lubashev, Igor" , Ian Swett , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= 
CC: Praveen Balasubramanian , IETF QUIC WG , "Deval, Manasi" 
Subject: RE: Impact of hardware offloads on network stack performance
Thread-Topic: Impact of hardware offloads on network stack performance
Thread-Index: AdPMUbL7T8nZAW2ySiO289IPTC0ttgAApm4AADSbFZAACUWYgAAFkLQAACA3b/AAAajkgANRfL2AAAA3SQAAAHMwgAAAR/kAAAEuygAAAJMTgAAAxh6A
Date: Mon, 23 Apr 2018 20:06:33 +0000
Message-ID: 
References:        <1F436ED13A22A246A59CA374CBC543998B60C7AD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B60C851@ORSMSX111.amr.corp.intel.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; 
x-originating-ip: [73.140.154.179]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1374; 7:ovPv3/vevJSKNxKz78S/t8asOyWnuZvki+89kHkUBs9iOZKIsxEwf5QRWZtcIPpGDJ7BUu1irPX2ARliDY05+GfzAgaQf+n4GiQyqVah8o5rDq0/P4TwpNtueYMcGqdkwknjnVF2I01F7vnaclEGBHVHbdnRwhjnFZqZFf33uV4ypBLyQfk3KImj/SLR8OPawLeBJ9Gt3d0zdnrmgJPV5SQYiD5gZf/wa6kPoExtOfs3WnUH8UIbejlUAVoupG0L
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1374; 
x-ms-traffictypediagnostic: SN1PR08MB1374:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(10436049006162)(89211679590171)(85827821059158)(211936372134217)(153496737603132)(21748063052155)(228905959029699);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231232)(944501410)(52105095)(6041310)(20161123562045)(20161123558120)(20161123564045)(2016111802025)(20161123560045)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1374; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1374; 
x-forefront-prvs: 06515DA04B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(39380400002)(376002)(366004)(396003)(346002)(51914003)(81166006)(2906002)(3660700001)(8936002)(229853002)(8676002)(59450400001)(86362001)(54906003)(99286004)(7696005)(9686003)(3280700002)(2900100001)(14454004)(55016002)(6436002)(76176011)(25786009)(186003)(45080400002)(39060400002)(53546011)(26005)(16200700003)(316002)(54896002)(110136005)(6306002)(53936002)(478600001)(6506007)(446003)(236005)(6246003)(93886005)(11346002)(102836004)(33656002)(74316002)(5250100002)(74482002)(53946003)(476003)(4326008)(66066001)(966005)(8666007)(5660300001)(606006)(7736002)(790700001)(19609705001)(3846002)(6116002)(579004)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1374; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:ovrnspm; PTR:InfoNoRecords; 
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: CN/T9WHp+9rP0sVDI2Aie+IBYEd4Q/WYas3g/sNpxXDIOgzcK0u6cxHQOTc+hAhik5VJlCroypVOUnsUPlHr6O9v/byBpmqKPxaYAsARa019lyZKWWYM4P5lAngFU79NdQ12dsQWHvcgSwUOjDaUXE5k9vI0kcgMsmKy4MN0u/z0XWnE9ZclLiEtrN9XxzXS
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR08MB185446750FCDA2B58C9833C8DA890SN1PR08MB1854namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 9fbab68a-af3f-4a63-de1d-08d5a955b686
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 9fbab68a-af3f-4a63-de1d-08d5a955b686
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2018 20:06:34.0211 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1374
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 23 Apr 2018 20:06:46 -0000

--_000_SN1PR08MB185446750FCDA2B58C9833C8DA890SN1PR08MB1854namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBhZ3JlZSDigJMgdGhlIHBvaW50IG9mIG9mZmxvYWRpbmcgdGhlIGNyeXB0byBpcyBub3Qgb25s
eSB0byBzcGFyZSB0aGF0IGNvc3Qgb24gdGhlIENQVSwgdGhvdWdoIHRoYXQgY2FuIGJlIHVzZWZ1
bCwgaXTigJlzIHRvIGVuYWJsZSBmdXJ0aGVyIG9mZmxvYWRzIHRoYXQgY2Fu4oCZdCBiZSBkb25l
IG9uIHRoZSBlbmNyeXB0ZWQgcGFja2V0Lg0KDQpMUk8gdGhhdCBjb3VsZCBzaW1wbHkgZ3JvdXAg
cGFja2V0cyBieSBDSUQgYW5kIGRlbGl2ZXIgYSBzaW5nbGUgYmF0Y2ggb2YgcGFja2V0cyBmcm9t
IGEgc2luZ2xlIENJRCBpbiBhIHNpbmdsZSBpbnZvY2F0aW9uIHNlZW1zIGxpa2UgYSBncmVhdCBm
aXJzdCBzdGVwLCBhbmQgZG9lc27igJl0IGV2ZW4gcmVxdWlyZSBjcnlwdG8gb2ZmbG9hZC4gIE9u
Y2UgeW91IGhhdmUgY3J5cHRvIG9mZmxvYWQsIG9mIGNvdXJzZSB0aG9zZSBwYWNrZXRzIHBlciBD
SUQgY291bGQgYmUgZGVsaXZlcmVkIGFscmVhZHkgZGVjcnlwdGVkLiAgSeKAmWQgd2FudCB0byBz
ZWUgZGF0YSBvbiB3aGV0aGVyIHRoZXJl4oCZcyB2YWx1ZSBpbiBtYWtpbmcgdGhlIHJlY2VpdmVk
IGRhdGEgbG9vayBsaWtlIG9uZSBodWdlIHBhY2tldCB3aGVuIHRoZXJl4oCZcyBub3QgYSBzaW5n
bGUgYnl0ZXN0cmVhbSwgYnV0IHRoYXTigJlzIG5vdCBzb21ldGhpbmcgd2UgbmVlZCB0byBzcGVj
aWZ5IGhlcmUuDQoNCkxTTyBpcyBtb3JlIGludGVyZXN0aW5nLCBhbmQgdGhlIGNoYWxsZW5nZSB0
aGVyZSBpcyB0aGF0IHRoZSB0cmFuc3BvcnQgc3RhY2sgc3RpbGwgbmVlZHMgdG8ga25vdyB3aGF0
IGRhdGEgd2FzIGluIHdoaWNoIHBhY2tldCBzbyB0aGF0IGl0IGNhbiBkbyBsb3NzIHJlY292ZXJ5
IHByb3Blcmx5LiAgUVVJQyBleHBsaWNpdGx5IGRpc2FsbG93cyBmcmFnbWVudGF0aW9uIG9mIHRo
ZSBVRFAgZGF0YWdyYW0sIGZvciB0aGUg4oCccGFpbmZ1bCBhbmQgcG90ZW50aWFsbHkgbm9uLWRl
dGVybWluaXN0aWPigJ0gcmVhc29ucyB5b3UgcmVmZXJlbmNlZC4NCg0KRnJvbTogTHViYXNoZXYs
IElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+DQpTZW50OiBNb25kYXksIEFwcmlsIDIzLCAyMDE4
IDEyOjM2IFBNDQpUbzogSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0
Zi5vcmc+OyBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb20+DQpD
YzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBJRVRGIFFV
SUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU+
OyBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuZGV2YWxAaW50ZWwuY29tPg0KU3ViamVjdDogUkU6IElt
cGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlDQoN
ClRoZSBwb2ludCBvZiBIVyBvZmZsb2FkcyBpcyB0byByZWR1Y2UgdGhlIG51bWJlciBvZiB0aW1l
cyB0aGUga2VybmVsICjigJx0cmFuc3BvcnTigJ0pIHN0YWNrIGlzIGludm9rZWQgdG8gbG9jYXRl
IHRoZSBmbG93LCB2YWxpZGF0ZSBoZWFkZXJzLCBlbnF1ZXVlIGRhdGEgZm9yIGRlbGl2ZXJ5IHRv
IHNvY2tldHMsIGV0Yy4NCg0KSWYgSFcgY2FuIGFzc29jaWF0ZSBtdWx0aXBsZSBRVUlDIHBhY2tl
dHMgd2l0aCBhIHNpbmdsZSBmbG93LCByZW1vdmUgZW5jcnlwdGlvbiBhbmQgcGFzcyBpdCBvbiB0
byB0aGUgc3RhY2ssIGl0IGRvZXMgbm90IHJlYWxseSBuZWVkIHRvIHNpbXVsYXRlIHRoZSBkYXRh
IGFycml2aW5nIGluIGEgc2luZ2xlIGp1bWJvIFFVSUMgcGFja2V0Lg0KDQoNCiAgKiAgIElnb3IN
Cg0KDQpGcm9tOiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMu
aWV0Zi5vcmddDQpTZW50OiBNb25kYXksIEFwcmlsIDIzLCAyMDE4IDM6MjAgUE0NClRvOiBNaWtr
ZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tlbGZq
QGdtYWlsLmNvbT4+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29m
dC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+PjsgSUVURiBRVUlDIFdHIDxxdWljQGll
dGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1
ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+PjsgRGV2YWwsIE1hbmFzaSA8bWFu
YXNpLmRldmFsQGludGVsLmNvbTxtYWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNvbT4+OyBpYW5z
d2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmlhbnN3ZXR0PTQwZ29vZ2xl
LmNvbUBkbWFyYy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2Zm
bG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZQ0KDQpUbyBjbGFyaWZ5IG15IHVuZGVy
c3RhbmRpbmcsIHlvdSdkIGhhdmUgdG8gcmVjZWl2ZSBhbGwgMyBzZWdtZW50cyB0byBkZWNyeXB0
IHRoZSBwYXlsb2FkPyAgSWYgdGhhdCdzIHdoYXQgeW91J3JlIHByb3Bvc2luZywgdGhlbiBJIHRo
aW5rIGl0J3Mgbm90IGEgZ29vZCBkZXNpZ24gZm9yIFFVSUMsIGJlY2F1c2UgaXQgYW1wbGlmaWVz
IHRoZSBlZmZlY3RpdmUgbG9zcyByYXRlIGFuZCBpdCBkb2Vzbid0IHNhdmUgdGhhdCBtdWNoIENQ
VS4NCg0KSXQncyBub3QgdGhhdCBoYXJkIGZvciB1c2Vyc3BhY2UgdG8gcHJvdmlkZSAzIGZ1bGx5
IGZvcm1lZCBlbmNyeXB0ZWQgcGFja2V0cyBhbmQgdXNlIGFuIEFQSSBsaWtlIFdpbGxlbSdzIFVE
UCBHU08gcGF0Y2gsIGFuZCBJIGJlbGlldmUgdGhhdCBhcHByb2FjaCBpcyBtb3JlIGFnaWxlIGFz
IHdlbGwuDQoNCklmIHlvdSB3YW50ZWQgdG8gZG8gY3J5cHRvIG9mZmxvYWQsIHRoZW4geW91IGNv
dWxkIHByb3ZpZGUgdGhlIGFiaWxpdHkgdG8gb2ZmbG9hZCBwYXlsb2FkIGFuZCBQTiBlbmNyeXB0
aW9uIGluc3RlYWQgb2YgZG9pbmcgaXQgaW4gdXNlcnNwYWNlLiAgQXMgYSBib251cywgc3VwcG9y
dCBpb3ZlYyBzdHlsZSBzY2F0dGVyLWdhdGhlciwgc28gYnVsayBwYXlsb2FkcyBuZXZlciBuZWVk
IHRvIGJlIGJyb3VnaHQgaW50byBDUFUgY2FjaGUgYmVmb3JlIHRoZXkncmUgZW5jcnlwdGVkIGFu
ZCBjb3BpZWQgdG8gdGhlIE5JQy4NCg0KT24gTW9uLCBBcHIgMjMsIDIwMTggYXQgMjo0NiBQTSBN
aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tl
bGZqQGdtYWlsLmNvbT4+IHdyb3RlOg0KQWgsIEkgc2VlLiBUaGFua3MgZm9yIGV4cGxhaW5pbmcu
DQoNClFVSUMgaGFzIGEgbXVjaCByZWFjaGVyIGludGVyZmFjZSwgc28gdGhlcmUgY291bGQgYmUs
IHNheSAxMDAgYWN0aXZlIHN0cmVhbXMgd2FpdGluZyBmb3IgdHJhbnNtaXNzaW9uLiBUaGUgUVVJ
QyBpbXBsZW1lbnRhdGlvbiB3b3VsZCB1c2Ugc29tZSBzb3J0IG9mIHNjaGVkdWxlciB0byBtb3Zl
IHRoZSBtb3N0IGltcG9ydGFudCBwYXJ0cyBmaXJzdCB3aXRob3V0IGxvb3NpbmcgcHJvZ3Jlc3Mg
b24gb3RoZXIgcGFydHMsIGZvciBleGFtcGxlIHVzaW5nDQoNCmh0dHBzOi8vZW4ud2lraXBlZGlh
Li5vcmcvd2lraS9EZWZpY2l0X3JvdW5kX3JvYmluPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv
aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZW4ud2lraXBlZGlhLm9yZ193aWtpX0RlZmljaXQt
NUZyb3VuZC01RnJvYmluJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPURqbjNi
UTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mbT1rTG4yS2dLTFB0R0p4UnZL
WEwtRko1SktiLVJ1MFAwakVMZGh4cFd3TThZJnM9RWlGeEVsa0g0c2czMG1CQWcxN2hNNkUxdVNu
c2sxbV9DY25FcGJmQVI0USZlPT4NCg0KQSBzaW1wbGUgaHVnZSBidWZmZXIgc2VnbWVudGF0aW9u
IHdvdWxkIHByb2JhYmx5IG5vdCB3b3JrIGRpcmVjdGx5LCBidXQgYSBtZWFucyB0byBmb3J3YXJk
IGRhdGEgcHJlLXdyYXBwZWQgaW4gUVVJQyBmcmFtZXMsIGluIHJlYXNvbmFibGUgcGFja2FnZSB1
bml0cywgYnV0IHdpdGhvdXQgQUVBRCBlbnZlbG9wZSB3b3VsZCBtYWtlIHNlbnNlLiBUaGVzZSBj
b3VsZCBiZSBxdWV1ZWQgaW4gdm9sdW1lcywgbGVhdmluZyBpdCBhbiBvZmZsb2FkZXIgdG8gcHJv
Y2VlZC4NCg0KSeKAmXZlIGJlZW4gbG9va2luZyBpbnRvIHRoZSBuZXRtYXAgaW50ZXJmYWNlIHdo
ZXJlIHlvdSBjYW4gZmVlZCBjb250ZW50IGluIHVuaXRzIGRpcmVjdGx5IHRvIGhhcmR3YXJlLCBh
bmQgSeKAmW0gc3VyZSB5b3UgaGF2ZSBkZXRhaWxlZCBrbm93bGVkZ2Ugb2YgRFBESyB0aGF0IGRv
ZXMgc29tZXRoaW5nIHNpbWlsYXIuDQoNCg0KS2luZCBSZWdhcmRzLA0KTWlra2VsIEZhaG7DuGUg
SsO4cmdlbnNlbg0KDQoNCk9uIDIzIEFwcmlsIDIwMTggYXQgMjAuMzguMDYsIERldmFsLCBNYW5h
c2kgKG1hbmFzaS5kZXZhbEBpbnRlbC5jb208bWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5jb20+
KSB3cm90ZToNCknigJltIHRyeWluZyB0byBsYXkgb3V0IHRoZSBvcHRpb25zIGZvciBUU08vTFNP
IHdpdGggUVVJQy4gSW4gbXkgcHJldmlvdXMgZS1tYWlsIEkgY29tcGFyZWQgdGhlIG91dGNvbWUg
b2YgdmFuaWxsYSBVRFAgc2VnbWVudGF0aW9uIGFzIGRlZmluZWQgYnkgdGhlIGxhdGVzdCBwYXRj
aCAoaHR0cHM6Ly9tYXJjLmluZm8vP2w9bGludXgtbmV0ZGV2Jm09MTUyMzk5NTMwNjAzOTkyJnc9
MjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX21h
cmMuaW5mb18tM0ZsLTNEbGludXgtMkRuZXRkZXYtMjZtLTNEMTUyMzk5NTMwNjAzOTkyLTI2dy0z
RDImZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tm
TDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZtPWtMbjJLZ0tMUHRHSnhSdktYTC1GSjVKS2ItUnUw
UDBqRUxkaHhwV3dNOFkmcz1oWUhaZlp5ZnhQN2tJbnBUdk5FOVUwMkJQQWhqZS1admFVZ1Yxck5D
U0xJJmU9PiksIHRvIGFuIGFsdGVybmF0aXZlIG5hdGl2ZSBRVUlDIHNlZ21lbnRhdGlvbi4NCg0K
QSBzZWdtZW50IGlzIGEgbGFyZ2UgYnVmZmVyIHByb2R1Y2VkIGluIGFuIGFwcGxpY2F0aW9uLiBU
aGUgc2VnbWVudCBpcyBvZnRlbiBtdWNoIHRvbyBsYXJnZSB0byBnbyBvdXQgb24gdGhlIHdpcmUg
d2l0aCBqdXN0IHByZS1wZW5kZWQgaGVhZGVycy4gVGhlcmVmb3JlIHNlZ21lbnQgbmVlZHMgdG8g
YmUgY2hvcHBlZCB1cCBpbnRvIGFwcHJvcHJpYXRlIHNpemUgYW5kIHRoZSBwcmUtcGVuZGVkIGhl
YWRlcnMgbmVlZCB0byBiZSByZXBsaWNhdGVkIHRvIG1ha2UgTVRVIHNpemUgcGFja2V0cyBmb3Ig
dGhlIHdpcmUuDQoNCknigJltIHN1Z2dlc3RpbmcgdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIgcHJv
Y2Vzc2luZyBhIGxhcmdlIGRhdGEgYnVmZmVyIGFzIG11bHRpcGxlIFFVSUMgcGFja2V0cyBlYWNo
IHdpdGggYSB1bmlxdWUgUE4uDQoNClRoYW5rcywNCk1hbmFzaQ0KDQoNCkZyb206IE1pa2tlbCBG
YWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tl
bGZqQGdtYWlsLmNvbT5dDQpTZW50OiBNb25kYXksIEFwcmlsIDIzLCAyMDE4IDExOjI1IEFNDQpU
bzogSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRv
OjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4+OyBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuZGV2
YWxAaW50ZWwuY29tPG1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tPj47IE1pa2UgQmlzaG9w
IDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+Pg0KQ2M6
IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBQcmF2
ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWlj
cm9zb2Z0LmNvbT4+DQpTdWJqZWN0OiBSRTogSW1wYWN0IG9mIGhhcmR3YXJlIG9mZmxvYWRzIG9u
IG5ldHdvcmsgc3RhY2sgcGVyZm9ybWFuY2UNCg0KSeKAmW0gbm90IHJlYWxseSBmYW1pbGlhciB3
aXRoIHRoaXMgZHVtcCBidXQgd2hhdCBkb2VzIHBhcnRpYWwgc2VnbWVudGF0aW9uIG1lYW4gaGVy
ZT8NCg0KQXJlIHlvdSBzcGxpdHRpbmcgYSBzaW5nbGUgVURQIGRhdGFncmFtIGludG8gbXVsdGlw
bGUgZnJhZ21lbnRzLCBvciBhcmUgeW91IHByb2Nlc3NpbmcgbXVsdGlwbGUgc2VwYXJhdGUgUVVJ
QyBwYWNrZXRzLCBvbmUgUE4gZWFjaD8NCg0KSWYgeW91IGZyYWdtZW50IFVEUCBkYXRhZ3JhbXMs
IHRoYXQgY2FuIGJlIGEgYmlnIGlzc3VlIGJlY2F1c2UgZGlmZmVyZW50IGZyYWdtZW50cyBtYXkg
cmFjZSBhbG9uZyBkaWZmZXJlbnQgcm91dGVzLCBjYXVzaW5nIHVuZXhwZWN0ZWQgZGVsYXlzIGFu
ZCBibG9ja2luZyBhdCB0aGUgb3RoZXIgZW5kLg0KDQoNCg0KT24gMjMgQXByaWwgMjAxOCBhdCAy
MC4xOC41NCwgRGV2YWwsIE1hbmFzaSAobWFuYXNpLmRldmFsQGludGVsLmNvbTxtYWlsdG86bWFu
YXNpLmRldmFsQGludGVsLmNvbT4pIHdyb3RlOg0KSWYgd2UgZG8gVFNPIC8gTFNPIHdpdGggUVVJ
QywgdGhlIGluaXRpYWwgc2VnbWVudCBwcm92aWRlZCBjYW4gbG9vayBsaWtlIOKAkw0KTUFDIOKA
kyBJUCDigJMgVURQIOKAkyBRVUlDIENsZWFyIOKAkyBRVUlDIGVuY3J5cHRlZCBoZWFkZXIgKFBO
PXgpIOKAkyBRVUlDIEVuY3J5cHRlZCBwYXlsb2FkLg0KDQoNCklmIHdlIGp1c3QgdXNlIHRoZSBz
dGFja+KAmXMgdWRwIHNlZ21lbnRhdGlvbiAodXNpbmcgdGhlIHBhdGNoIC0gaHR0cHM6Ly9tYXJj
LmluZm8vP2w9bGludXgtbmV0ZGV2Jm09MTUyMzk5NTMwNjAzOTkyJnc9MjxodHRwczovL3VybGRl
ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX21hcmMuaW5mb18tM0ZsLTNE
bGludXgtMkRuZXRkZXYtMjZtLTNEMTUyMzk5NTMwNjAzOTkyLTI2dy0zRDImZD1Ed01GYVEmYz05
NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpk
bl9tNTVLUG1sbyZtPWtMbjJLZ0tMUHRHSnhSdktYTC1GSjVKS2ItUnUwUDBqRUxkaHhwV3dNOFkm
cz1oWUhaZlp5ZnhQN2tJbnBUdk5FOVUwMkJQQWhqZS1admFVZ1Yxck5DU0xJJmU9PiksIHRoZSBv
dXRjb21lIG9mIFFVSUMgcGFja2V0cyBvbiB0aGUgd2lyZSB3b3VsZCBiZToNCk1BQyDigJMgSVAg
4oCTIFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAoUE49eCwgcGFy
dGlhbCBzZWdtZW50IDEvMykNCk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBlbmNyeXB0ZWQg
cGFydCAocGFydGlhbCBzZWdtZW50IDIvMykNCk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBl
bmNyeXB0ZWQgcGFydCAocGFydGlhbCBzZWdtZW50IDMvMykNCuKApg0KDQpQdXR0aW5nIHRoZXNl
IGJhY2sgdG9nZXRoZXIgaW4gYSBzdGFjayAvIGhhcmR3YXJlIGxvb2tzIGxpa2UgYSBwYWluZnVs
IGFuZCBwb3RlbnRpYWxseSBub24tZGV0ZXJtaW5pc3RpYyBhY3Rpdml0eS4NCg0KDQpJdCB3b3Vs
ZCBiZSBlYXNpZXIgdG8gZG8gYSBuYXRpdmUgUVVJQyBvZmZsb2FkLCB3aGVyZSB0aGUgcGFja2V0
IG9uIHdpcmUgY2FuIGJlIGlkZW50aWZpZWQgYnkgUVVJQyBDaUQgYW5kIGFwcHJvcHJpYXRlIHBh
Y2tldCBudW1iZXIuIFRoZXJlZm9yZSwgb3JpZ2luYWwgcGFja2V0IGxvb2tzIGxpa2UgLSBNQUMg
4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMgQ2xlYXIg4oCTIFFVSUMgZW5jcnlwdGVkIGhlYWRlciAo
UE49eCkg4oCTIFFVSUMgRW5jcnlwdGVkIHBheWxvYWQuDQpJZiB3ZSBqdXN0IGNyZWF0ZSBhbm90
aGVyIHZlcnNpb24gb2Ygc2VnbWVudGF0aW9uIGNhbGxlZCBRVUlDIHNlZ21lbnRhdGlvbiwgdGhl
IG91dGNvbWUgb2YgcGFja2V0cyBvbiB0aGUgd2lyZSB3b3VsZCBiZToNCk1BQyDigJMgSVAg4oCT
IFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAoUE49eCwgcGFydGlh
bCBzZWdtZW50IDEvMykNCk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJ
QyBlbmNyeXB0ZWQgcGFydCAoUE49eCsxLCBwYXJ0aWFsIHNlZ21lbnQgMi8zKQ0KTUFDIOKAkyBJ
UCDigJMgVURQIOKAkyBRVUlDIENsZWFyIOKAkyBRVUlDIGVuY3J5cHRlZCBwYXJ0IChQTj14KzIs
IHBhcnRpYWwgc2VnbWVudCAzLzMpDQrigKYNCklmIHRoaXMgc2V0IG9mIHNlZ21lbnRzIHdlcmUg
dG8gYmUgcmUtYXNzZW1ibGVkLCB0aGUgYWJpbGl0eSB0byBpZGVudGlmeSBDaUQgYW5kIFBOIHdv
dWxkIHNpbXBsaWZ5IHRoaXMgdGFzay4gSSB0aGluayB0aGlzIGlzIGEgc2ltcGxlciBpbXBsZW1l
bnRhdGlvbi4gRG8gb3RoZXJzIHNlZSBhbiBpc3N1ZSB3aXRoIHRoaXM/DQoNClRoYW5rcywNCk1h
bmFzaQ0KDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv
OnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBJYW4gU3dldHQNClNlbnQ6IEZy
aWRheSwgQXByaWwgMDYsIDIwMTggMTo1NSBQTQ0KVG86IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2
ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+Pg0KQ2M6IFByYXZlZW4gQmFs
YXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQu
Y29tPj47IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWls
dG86bWlra2VsZmpAZ21haWwuY29tPj47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWls
dG86cXVpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogSW1wYWN0IG9mIGhhcmR3YXJlIG9mZmxv
YWRzIG9uIG5ldHdvcmsgc3RhY2sgcGVyZm9ybWFuY2UNCg0KUE5FIGRvZXNuJ3QgcHJlY2x1ZGUg
VURQIExSTyBvciBwYWNpbmcgb2ZmbG9hZC4NCg0KSG93ZXZlciwgaW4gYSBoaWdobHkgb3B0aW1p
emVkIHN0YWNrKGllOiBUaGUgRGlza3xDcnlwdHxOZXQgcGFwZXIgZnJvbSBTSUdDT01NIDIwMTcp
IG5vdCB0b3VjaGluZyhpZTogYnJpbmdpbmcgaW50byBtZW1vcnkgb3IgY2FjaGUpIHRoZSBjb250
ZW50IHRvIGJlIHNlbnQgdW50aWwgdGhlIGxhc3QgcG9zc2libGUgbW9tZW50IGlzIGNyaXRpY2Fs
LiAgUE5FIGxpa2VseSBtZWFucyB0b3VjaGluZyB0aGF0IGNvbnRlbnQgbXVjaCBlYXJsaWVyLg0K
DQpCdXQgcGVyc29uYWxseSBJIGNvbnNpZGVyIHRoZSBhY3R1YWwgY3J5cHRvIHdlJ3JlIHRhbGtp
bmcgYWJvdXQoMiBBRVMgaW5zdHJ1Y3Rpb25zPykgYWRkaW5nIGJhc2ljYWxseSBmcmVlLg0KDQpP
biBGcmksIEFwciA2LCAyMDE4IGF0IDQ6MzcgUE0gTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVl
Zm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+IHdyb3RlOg0KVGhhbmtzIGZvciB0
aGUgY2xhcmlmaWNhdGlvbi4gIEkgZ3Vlc3Mgd2hhdCBJ4oCZbSByZWFsbHkgZ2V0dGluZyBkb3du
IHRvIGlzIGhvdyBkbyB3ZSBxdWFudGlmeSB0aGUgYWN0dWFsIGNvc3Qgb2YgUE5FPyAgQXJlIHdl
IHN1YnN0YW50aWFsbHkgaW5jcmVhc2luZyB0aGUgY3J5cHRvIGNvc3RzPyAgSWYgSWFuIGlzIHNh
eWluZyB0aGF0IGNyeXB0byBpcyBjb21wYXJhdGl2ZWx5IGNoZWFwIGFuZCB0aGUgY29zdCBpcyB0
aGF0IGl04oCZcyBoYXJkZXIgdG8gb2ZmbG9hZCBzb21ldGhpbmcgdGhhdOKAmXMgY29tcGFyYXRp
dmVseSBjaGVhcCwgd2hhdCBoYXZlIHdlIGxvc3Q/ICBJ4oCZZCB0aGluayB3ZSB3YW50IHRvIG9m
ZmxvYWQgdGhlIG1vc3QgaW50ZW5zaXZlIHBpZWNlIHdlIGNhbiwgYW5kIGl0IHNlZW1zIGxpa2Ug
d2XigJlyZSB0YWxraW5nIGFib3V0IGNyeXB0byBvZmZsb2Fkcy4uLi4gIE9yIGFyZSB3ZSBzYXlp
bmcgaW5zdGVhZCB0aGF0IHRoZSBjcnlwdG8gbWFrZXMgaXQgaGFyZGVyIHRvIG9mZmxvYWQgb3Ro
ZXIgdGhpbmdzIGluIHRoZSBmdXR1cmUsIGxpa2UgYSBRVUlDIGVxdWl2YWxlbnQgdG8gTFJPL0xT
Tz8NCg0KRnJvbTogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdt
YWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBBcHJp
bCA1LCAyMDE4IDk6NDUgUE0NClRvOiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFp
bHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+PjsgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91
LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFt
YW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+Pjsg
SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1Ympl
Y3Q6IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJm
b3JtYW5jZQ0KDQpUbyBiZSBjbGVhciAtIEkgZG9u4oCZdCB0aGluayBjcnlwdG8gaXMgb3ZlcnNo
YWRvd2luZyBvdGhlciBpc3N1ZXMgYXMgTWlrZSByZWFkIG15IHBvc3QuIEl0IGNlcnRhaW5seSBj
b21lcyBhdCBhIGNvc3QsIGJ1dCBlaXRoZXIgbXVsdGlwbGUgY29yZXMgb3IgY28tcHJvY2Vzc29y
cyB3aWxsIGRlYWwgd2l0aCB0aGlzLiAxMDAwbnMgaXMgMTBHYnBzIGNyeXB0byBzcGVlZCBvbiBv
bmUgY29yZSBhbmQgaXQgaXMgaGlnbHkgcGFyYWxsZWxpc2FibGUgYW5kIGNhY2hlIGZyaWVuZGx5
Lg0KDQpCdXQgaWYgeW91IGhhdmUgdG8gZHJpcCB5b3VyIHBhY2tldHMgdGhyb3VnaCBhIHRyYWRp
dGlvbmFsIHNlbmQgaW50ZXJmYWNlIHRoYXQgaXMgY29weWluZywgYnVmZmVyaW5nIG9yIGJsb2Nr
aW5nLCBhbmQgY2VydGFpbmx5IHN5bmPigJlpbmcgd2l0aCB0aGUga2VybmVsIC0gaXQgaXMgZ29p
bmcgdG8gYmUgdG91Z2guDQoNCkZvciByZWNlaXZlIHlvdSByaXNrIGhpZ2ggbGF0ZW5jeSBvciB0
b3AgbXVjaCBzY2hlZHVsaW5nIGluIHJlY2VpdmUgYnVmZmVycy4NCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCkZyb206IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxt
YWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+DQpTZW50OiBGcmlkYXksIEFwcmlsIDYsIDIwMTgg
NDowNjowMSBBTQ0KVG86IE1pa2UgQmlzaG9wDQpDYzogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNl
bjsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW47IElFVEYgUVVJQyBXRw0KU3ViamVjdDogUmU6IElt
cGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlDQoN
Cg0KT24gVGh1LCBBcHIgNSwgMjAxOCBhdCA1OjU3IFBNIE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2
ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+PiB3cm90ZToNClRoYXTigJlz
IGludGVyZXN0aW5nIGRhdGEsIFByYXZlZW4g4oCTIHRoYW5rcy4gIFRoZXJlIGlzIG9uZSBjYXZl
YXQgdGhlcmUsIHdoaWNoIGlzIHRoYXQgKElJVUMsIG9uIGN1cnJlbnQgaGFyZHdhcmUpIHlvdSBj
YW7igJl0IGRvIHBhY2tldCBwYWNpbmcgd2l0aCBMU08sIGFuZCBzbyBteSB1bmRlcnN0YW5kaW5n
IGlzIHRoYXQgZXZlbiBmb3IgVENQIG1hbnkgcHJvdmlkZXJzIGRpc2FibGUgdGhpcyBpbiBwdXJz
dWl0IG9mIGJldHRlciBlZ3Jlc3MgbWFuYWdlbWVudC4gIFNvIHdoYXQgd2XigJlyZSByZWFsbHkg
c2F5aW5nIGlzIHRoYXQ6DQoNCiAgKiAgIE9uIGN1cnJlbnQgaGFyZHdhcmUgYW5kIE9TIHNldHVw
cywgVURQIHJ1bnMgbGVzcyB0aGFuIGhhbGYgYXMgbXVjaCB0aHJvdWdocHV0IGFzIFRDUDsgdGhh
dCBuZWVkcyBzb21lIG9wdGltaXphdGlvbiwgYXMgd2XigJl2ZSBhbHJlYWR5IGRpc2N1c3NlZA0K
ICAqICAgVENQIHdpbGwgZHJhbWF0aWNhbGx5IGdhaW4gcGVyZm9ybWFuY2Ugb25jZSBoYXJkd2Fy
ZSBvZmZsb2FkIGNhdGNoZXMgdXAgYW5kIGFsbG93cyBwYWNlZCBMU08g8J+Yig0KDQpIb3dldmVy
LCBhcyBNaWtrZWwgcG9pbnRzIG91dCwgdGhlIGNyeXB0byBjb3N0cyBhcmUgbGlrZWx5IHRvIG92
ZXJ3aGVsbSB0aGUgT1MgdGhyb3VnaHB1dCAvIHNjaGVkdWxpbmcgaXNzdWVzIGluIHJlYWwgZGVw
bG95bWVudHMuICBTbyBJIHRoaW5rIHRoZSBvdGhlciByZWxldmFudCBwaWVjZSB0byB1bmRlcnN0
YW5kaW5nIHRoZSBjb3N0IGhlcmUgaXMgdGhpczoNCg0KSSBoYXZlIGEgZmV3IGNhc2VzKGJvdGgg
Y2xpZW50IGFuZCBzZXJ2ZXIpIHdoZXJlIG15IFVEUCBzZW5kIGNvc3RzIGFyZSBtb3JlIHRoYW4g
MzAlKGluIHNvbWUgY2FzZXMgNTAlKSBvZiBDUFUgY29uc3VtcHRpb24sIGFuZCBjcnlwdG8gaXMg
bGVzcyB0aGFuIDEwJS4gIFNvIGN1cnJlbnRseSwgSSBhc3N1bWUgY3J5cHRvIGlzIGNoZWFwKGVz
cGVjaWFsbHkgQUVTLUdDTSB3aGVuIGhhcmR3YXJlIGFjY2VsZXJhdGlvbiBpcyBhdmFpbGFibGUp
IGFuZCBlZ3Jlc3MgaXMgZXhwZW5zaXZlLiAgVURQIGluZ3JlcyBpcyBub3QgdGhhdCBleHBlbnNp
dmUsIGJ1dCBjb3VsZCB1c2UgYSBiaXQgb2Ygb3B0aW1pemF0aW9uIGFzIHdlbGwuDQoNClRoZSBv
bmx5ICdmYW5jeScgdGhpbmcgb3VyIGN1cnJlbnQgY29kZSBpcyBkb2luZyBmb3IgY3J5cHRvIGlz
IGVuY3J5cHRpbmcgaW4gcGxhY2UsIHdoaWNoIHdhcyBhIH4yJSB3aW4uICBOaWNlLCBidXQgbm90
IHRyYW5zZm9ybWF0aXZlLiAgU2VlIEVuY3J5cHRJblBsYWNlPGh0dHBzOi8vdXJsZGVmZW5zZS5w
cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fY3MuY2hyb21pdW0ub3JnX2Nocm9taXVt
X3NyY19uZXRfcXVpY19jb3JlX3F1aWMtNUZmcmFtZXIuY2MtM0ZzcS0zRHBhY2thZ2UtM0FjaHJv
bWl1bS0yNmwtM0QxODkzJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPURqbjNi
UTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mbT1rTG4yS2dLTFB0R0p4UnZL
WEwtRko1SktiLVJ1MFAwakVMZGh4cFd3TThZJnM9LS1Eb0FMUFpvYTBMNEllOVRaclBLcER5MV9k
bmIxa04tM0dhM01yWG5iMCZlPT4NCg0KSSBoYXZlbid0IGRvbmUgbXVjaCB3b3JrIGJlbmNobWFy
a2luZyBXaW5kb3dzLCBzbyBwb3NzaWJseSB0aGUgV2luZG93cyBVRFAgc3RhY2sgaXMgcmVhbGx5
IGZhc3QsIGFuZCBzbyBjcnlwdG8gc2VlbXMgcmVhbGx5IHNsb3cgaW4gY29tcGFyaXNvbj8NCg0K
DQogICogICBXaGF0IGlzIHRoZSB0aHJvdWdocHV0IGFuZCByZWxhdGl2ZSBjb3N0IG9mIFRMUy9U
Q1AgdmVyc3VzIFFVSUMgKGkuZS4gaG93IG11Y2ggYXJlIHRoZSBzbWFsbGVyIHVuaXRzIG9mIGVu
Y3J5cHRpb24gaHVydGluZyB1cyB2ZXJzdXMsIHNheSwgMTZLQiBUTFMgcmVjb3Jkcyk/DQoNCiAg
ICAgKiAgIFRMUyBpbXBsZW1lbnRhdGlvbnMgYWxyZWFkeSB2YXJ5IGhlcmU6ICBTb21lIGltcGxl
bWVudGF0aW9ucyBjaG9vc2UgbGFyZ2UgcmVjb3JkIHNpemVzLCBzb21lIHZhcnkgcmVjb3JkIHNp
emVzIHRvIHJlZHVjZSBkZWxheSAvIEhvTEIsIHNvIHRoaXMgcHJvYmFibHkgaXNu4oCZdCBhIHNp
bmdsZSBudW1iZXIuDQoNCiAgKiAgIEhvdyBtdWNoIGFkZGl0aW9uYWwgbG9hZCBkb2VzIFBORSBh
ZGQgdG8gdGhpcyBkaWZmZXJlbmNlPw0KICAqICAgVG8gd2hhdCBleHRlbnQgd291bGQgUE5FIG1h
a2UgZnV0dXJlIGNyeXB0byBvZmZsb2FkcyBpbXBvc3NpYmxlIHZlcnN1cyByZXF1aXJlcyBtb3Jl
IFImRCB0byBkZXZlbG9wPw0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu
b3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTWlra2VsIEZh
aG7DuGUgSsO4cmdlbnNlbg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDE4IDE6MzQgUE0N
ClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJj
LmlldGYub3JnPG1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+PjsgSUVURiBR
VUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJl
OiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5j
ZQ0KDQpUaGFua3MgZm9yIHNoYXJpbmcgdGhlc2UgbnVtYmVycy4NCg0KTXkgZ3Vlc3MgaXMgdGhh
dCB0aGVzZSBvZmZsb2FkcyBkZWFsIHdpdGgga2VybmVsIHNjaGVkdWxpbmcsIG1lbW9yeSBjYWNo
ZSBpc3N1ZXMsIGFuZCBpbnRlcnJ1cHQgc2NoZWR1bGluZy4NCg0KSXQgcHJvYmFibHkgaGFzIHZl
cnkgbGl0dGxlIHRvIGRvIHdpdGggY3J5cHRvLCBUQ1AgaGVhZGVycywgYW5kIGFueSBvdGhlciBj
cHUgc2Vuc2l0aXZlIHByb2Nlc3NpbmcuDQoNClRoaXMgaXMgd2hlcmUgbmV0bWFwIGVudGVyczog
eW91IGNhbiB0cmFuc3BhcmVudGx5IGZlZWQgdGhlIGRhdGEgYXMgaXQgYmVjb21lcyBhdmFpbGFi
bGUgd2l0aCB2ZXJ5IGxpdHRsZSBzeW5jIHdvcmsgYW5kIHlvdSBjYW4gYWxzbyBlZmZpY2llbnRs
eSBwaXBlbGluZSBzbyB5b3UgcGFzcyBkYXRhIHRvIGRlY3J5cHRvciwgdGhlbiB0byBhcHAsIHdp
dGggYXMgbGl0dGxlIGJ1cyB0cmFmZmljIGFzIHBvc3NpYmxlLiBObyBuZWVkIHRvIGNvcHkgZGF0
YSBvciBzeW5jaHJvbml6ZSBrZXJuZWwgc3BhY2UuDQoNCkZvciAxSyBwYWNrZXRzIHlvdSB3b3Vs
ZCB1c2UgYWJvdXQgMTAwMG5zICgzIGN5Y2xlcy9ieXRlKSBvbiBjcnlwdG8gYW5kIHRoaXMgd291
bGQgaGFwcGVuIGluIEwxIGNhY2hlLiBJdCB3b3VsZCBvZiBjb3Vyc2UgY29uc3VtZSBhIGNvcmUg
d2hpY2ggYSBjcnlwdG8gb2ZmbG9hZCB3b3VsZCBub3QsIGJ1dCB0aGF0IGNhbiBiZSBkZWJhdGVk
IGJlY2F1c2Ugd2l0aCAxOCBjb3JlIHN5c3RlbXMsIHlvdXIgcHJvYmxlbSBpcyBtZW1vcnkgYW5k
IG5ldHdvcmsgbW9yZSB0aGFuIENQVS4NCg0KTXkgY29uY2VybiB3aXRoIFBORSBpcyBmb3Igc21h
bGwgcGFja2V0cyBhbmQgbG93IGxhdGVuY3kgd2hlcmUNCjEpIGFuIGVzdGltYXRlZCAyNG5zIGZv
ciBQTiBlbmNyeXB0aW9uIGFuZCBkZWNyeXB0aW9uIGJlY29tZXMgbWVhc3VyYWJsZSBpZiB5b3Vy
IG5ldHdvcmsgaXMgZmFzdCBlbm91Z2guDQoyKSBhbnkgZGFtYWdlIHRvIHRoZSBwYWNrZXQgYnVm
ZmVyIGNhdXNlIGFsbCBzb3J0cyBvZiBtZW1vcnkgYW5kIGNwdSBidXMgdHJhZmZpYyBpc3N1ZXMu
DQoNCjEpIGlzIGFubm95aW5nLiAyKSBpcyBiYWQsIGNvbXBsZXRlbHkgYXZvaWRhYmxlIGJ1dCBu
b3QgYXMgUFIgMTA3OSBpcyBmb3JtdWxhdGVkIGN1cnJlbnRseS4NCg0KMikgaXMgYWxzbyBsaWtl
bHkgYmFkIGZvciBoYXJkd2FyZSBvZmZsb2FkIHVuaXRzIGFzIHdlbGwuDQoNCkFzIHRvIFNSVi1J
TyAtIEnigJltIG5vdCBmYW1pbGlhciB3aXRoIGl0LCBidXQgb2J2aW91c2x5IHRoZXJlIGlzIHNv
bWUgSU8gYWJzdHJhY3Rpb24gbGF5ZXIgLSB0aGUgcXVlc3Rpb24gaXMgaG93IHlvdSBtYWtlIGl0
IGFjY2Vzc2libGUgdG8gYXBwcyBhcyBvcHBvc2VkIHRvIGRldmljZSBkcml2ZXJzIHRoYXQgZG9l
cyBub3Igd29yayB3aXRoIHlvdSBRVUlDIGN1c3RvbSBzdGFjaywgYW5kIG5ldG1hcCBpcyBvbmUg
b3B0aW9uIGhlcmUuDQoNCktpbmQgUmVnYXJkcywNCk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4N
Cg0KDQpPbiA0IEFwcmlsIDIwMTggYXQgMjIuMTUuNTIsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFu
IChwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnByYXZiPTQwbWlj
cm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4pIHdyb3RlOg0KU29tZSBjb21wYXJhdGl2ZSBudW1i
ZXJzIGZyb20gYW4gb3V0IG9mIGJveCBkZWZhdWx0IHNldHRpbmdzIFdpbmRvd3MgU2VydmVyIDIw
MTYgKHJlbGVhc2VkIHZlcnNpb24pIGZvciBhIHNpbmdsZSBjb25uZWN0aW9uIHdpdGggYSBtaWNy
b2JlbmNobWFyayB0b29sOg0KDQpPZmZsb2FkcyBlbmFibGVkDQoNClRDUCBnYnBzDQoNClVEUCBn
YnBzDQoNCkxTTyArIExSTyArIGNoZWNrc3VtDQoNCjI0DQoNCjMuNg0KDQpDaGVja3N1bSBvbmx5
DQoNCjcuNg0KDQozLjYNCg0KTm9uZQ0KDQo1LjYNCg0KMi4zDQoNCg0KVGhpcyBpcyBmb3IgYSBm
dWxseSBib3R0bGVuZWNrZWQgQ1BVIGNvcmUgLS0gaWYgeW91IHJ1biBsb3dlciBkYXRhIHJhdGVz
IHRoZXJlIGlzIHN0aWxsIGEgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZSBpbiBDeWNsZXMvYnl0ZSBj
b3N0LiBTYW1lIGluY3JlYXNlZCBDUFUgY29zdCBhcHBsaWVzIGZvciBjbGllbnQgc3lzdGVtcyBn
b2luZyBvdmVyIGhpZ2ggZGF0YSByYXRlIFdpZmkgYW5kIGNlbGx1bGFyLg0KDQpUaGlzIGlzIHdp
dGhvdXQgYW55IGNyeXB0by4gT25jZSB5b3UgYWRkIGNyeXB0byB0aGUgbnVtYmVycyBiZWNvbWUg
bXVjaCB3b3JzZSB3aXRoIGNyeXB0byBjb3N0IGJlY29taW5nIGRvbWluYW50LiBBZGRpbmcgYW5v
dGhlciBjcnlwdG8gc3RlcCBmdXJ0aGVyIGV4YWNlcmJhdGVzIHRoZSBwcm9ibGVtLiBIZW5jZSBj
cnlwdG8gb2ZmbG9hZCBnYWlucyBpbiBpbXBvcnRhbmNlIGZvbGxvd2VkIGJ5IHRoZXNlIGJhdGNo
IG9mZmxvYWRzLg0KDQpJZiBmb2xrcyBuZWVkIGFueSBtb3JlIG51bWJlcnMgSeKAmWQgYmUgaGFw
cHkgdG8gcHJvdmlkZSB0aGVtLg0KDQpUaGFua3MNCg0K

--_000_SN1PR08MB185446750FCDA2B58C9833C8DA890SN1PR08MB1854namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg
MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgRW1vamkiOw0KCXBhbm9zZS0xOjIgMTEgNSAy
IDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku
TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl
ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFy
YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsN
CgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7
bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h
cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl
ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7fQ0KcC5tMTg4MDU3MTE2MTY0MDI3NTY3NGFpcm1haWxvbiwgbGkubTE4ODA1NzExNjE2
NDAyNzU2NzRhaXJtYWlsb24sIGRpdi5tMTg4MDU3MTE2MTY0MDI3NTY3NGFpcm1haWxvbg0KCXtt
c28tc3R5bGUtbmFtZTptXzE4ODA1NzExNjE2NDAyNzU2NzRhaXJtYWlsX29uOw0KCW1zby1tYXJn
aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tMTg4MDU3MTE2MTY0MDI3NTY3NGFpcm1h
aWxvbjAsIGxpLm0xODgwNTcxMTYxNjQwMjc1Njc0YWlybWFpbG9uMCwgZGl2Lm0xODgwNTcxMTYx
NjQwMjc1Njc0YWlybWFpbG9uMA0KCXttc28tc3R5bGUtbmFtZTptXzE4ODA1NzExNjE2NDAyNzU2
NzRhaXJtYWlsb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp
bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u
dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm0x
ODgwNTcxMTYxNjQwMjc1Njc0bXNvcGxhaW50ZXh0LCBsaS5tMTg4MDU3MTE2MTY0MDI3NTY3NG1z
b3BsYWludGV4dCwgZGl2Lm0xODgwNTcxMTYxNjQwMjc1Njc0bXNvcGxhaW50ZXh0DQoJe21zby1z
dHlsZS1uYW1lOm1fMTg4MDU3MTE2MTY0MDI3NTY3NG1zb3BsYWludGV4dDsNCgltc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubTE4ODA1NzExNjE2NDAyNzU2NzRtLTIwMTc3
MTQwNDAxMzcxMTYzNDltLTkwMDQ5MTcxNDk0MDU1OTQxNDNhaXJtYWlsb24sIGxpLm0xODgwNTcx
MTYxNjQwMjc1Njc0bS0yMDE3NzE0MDQwMTM3MTE2MzQ5bS05MDA0OTE3MTQ5NDA1NTk0MTQzYWly
bWFpbG9uLCBkaXYubTE4ODA1NzExNjE2NDAyNzU2NzRtLTIwMTc3MTQwNDAxMzcxMTYzNDltLTkw
MDQ5MTcxNDk0MDU1OTQxNDNhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6bV8xODgwNTcxMTYx
NjQwMjc1Njc0bS0yMDE3NzE0MDQwMTM3MTE2MzQ5bS05MDA0OTE3MTQ5NDA1NTk0MTQzYWlybWFp
bG9uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox
MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm
aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjMzODkzMDgxOw0KCW1zby1saXN0
LXRlbXBsYXRlLWlkczoyNzIxMzY5OTA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5
bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t
YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps
ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu
MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt
c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs
MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz
dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl
bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp
emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1p
ZDozMDU1OTYzNzc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzQwNzA3OTYwO30NCkBsaXN0
IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl
bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu
Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z
aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl
bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C
tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0
Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5
bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t
YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps
ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu
MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt
c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs
Mg0KCXttc28tbGlzdC1pZDo5ODcxMjU0ODU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjMzNDcz
NTQ4O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu
c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2
ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT
eW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6
bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg
bDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTIxMjExMDIzNjsNCgltc28t
bGlzdC10ZW1wbGF0ZS1pZHM6Nzc4NzU4ODQ2O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl
bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg
bDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp
c3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z
aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu
MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K
QGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u
dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQNCgl7bXNvLWxp
c3QtaWQ6MTQ1NTU2Mzc4MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w
bGF0ZS1pZHM6LTYxMzQxNDc2NCAxMjg2Mzk3MTA0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5
IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGw0
OmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt
aWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K
QGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3Ijt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDUNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw0
OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz
O30NCkBsaXN0IGw0OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p
bHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv
bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv
bTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw
MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv
Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu
Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl
Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUg4oCTIHRoZSBwb2ludCBvZiBv
ZmZsb2FkaW5nIHRoZSBjcnlwdG8gaXMgbm90IG9ubHkgdG8gc3BhcmUgdGhhdCBjb3N0IG9uIHRo
ZSBDUFUsIHRob3VnaCB0aGF0IGNhbiBiZSB1c2VmdWwsIGl04oCZcyB0byBlbmFibGUgZnVydGhl
ciBvZmZsb2FkcyB0aGF0IGNhbuKAmXQgYmUgZG9uZSBvbiB0aGUgZW5jcnlwdGVkIHBhY2tldC48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TFJPIHRoYXQgY291bGQgc2ltcGx5IGdyb3VwIHBhY2tl
dHMgYnkgQ0lEIGFuZCBkZWxpdmVyIGEgc2luZ2xlIGJhdGNoIG9mIHBhY2tldHMgZnJvbSBhIHNp
bmdsZSBDSUQgaW4gYSBzaW5nbGUgaW52b2NhdGlvbiBzZWVtcyBsaWtlIGEgZ3JlYXQgZmlyc3Qg
c3RlcCwgYW5kIGRvZXNu4oCZdCBldmVuIHJlcXVpcmUgY3J5cHRvIG9mZmxvYWQuJm5ic3A7IE9u
Y2UgeW91IGhhdmUgY3J5cHRvIG9mZmxvYWQsIG9mIGNvdXJzZSB0aG9zZQ0KIHBhY2tldHMgcGVy
IENJRCBjb3VsZCBiZSBkZWxpdmVyZWQgYWxyZWFkeSBkZWNyeXB0ZWQuJm5ic3A7IEnigJlkIHdh
bnQgdG8gc2VlIGRhdGEgb24gd2hldGhlciB0aGVyZeKAmXMgdmFsdWUgaW4gbWFraW5nIHRoZSBy
ZWNlaXZlZCBkYXRhIGxvb2sgbGlrZSBvbmUgaHVnZSBwYWNrZXQgd2hlbiB0aGVyZeKAmXMgbm90
IGEgc2luZ2xlIGJ5dGVzdHJlYW0sIGJ1dCB0aGF04oCZcyBub3Qgc29tZXRoaW5nIHdlIG5lZWQg
dG8gc3BlY2lmeSBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MU08gaXMgbW9yZSBpbnRl
cmVzdGluZywgYW5kIHRoZSBjaGFsbGVuZ2UgdGhlcmUgaXMgdGhhdCB0aGUgdHJhbnNwb3J0IHN0
YWNrIHN0aWxsIG5lZWRzIHRvIGtub3cgd2hhdCBkYXRhIHdhcyBpbiB3aGljaCBwYWNrZXQgc28g
dGhhdCBpdCBjYW4gZG8gbG9zcyByZWNvdmVyeSBwcm9wZXJseS4mbmJzcDsgUVVJQyBleHBsaWNp
dGx5IGRpc2FsbG93cyBmcmFnbWVudGF0aW9uIG9mIHRoZSBVRFAgZGF0YWdyYW0sIGZvciB0aGUN
CiDigJw8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+cGFpbmZ1bCBhbmQgcG90ZW50aWFsbHkg
bm9uLWRldGVybWluaXN0aWM8L3NwYW4+4oCdIHJlYXNvbnMgeW91IHJlZmVyZW5jZWQuPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w
cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G
cm9tOjwvYj4gTHViYXNoZXYsIElnb3IgJmx0O2lsdWJhc2hlQGFrYW1haS5jb20mZ3Q7IDxicj4N
CjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDIzLCAyMDE4IDEyOjM2IFBNPGJyPg0KPGI+VG86
PC9iPiBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyZn
dDs7IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0O21pa2tlbGZqQGdtYWlsLmNvbSZndDs8
YnI+DQo8Yj5DYzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3Nv
ZnQuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgTWlrZSBCaXNo
b3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJlJmd0OzsgRGV2YWwsIE1hbmFzaSAmbHQ7bWFuYXNp
LmRldmFsQGludGVsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEltcGFjdCBvZiBo
YXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcG9pbnQgb2YgSFcgb2ZmbG9hZHMgaXMg
dG8gcmVkdWNlIHRoZSBudW1iZXIgb2YgdGltZXMgdGhlIGtlcm5lbCAo4oCcdHJhbnNwb3J04oCd
KSBzdGFjayBpcyBpbnZva2VkIHRvIGxvY2F0ZSB0aGUgZmxvdywgdmFsaWRhdGUgaGVhZGVycywg
ZW5xdWV1ZSBkYXRhIGZvciBkZWxpdmVyeSB0byBzb2NrZXRzLCBldGMuPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPklmIEhXIGNhbiBhc3NvY2lhdGUgbXVsdGlwbGUgUVVJQyBwYWNrZXRzIHdpdGgg
YSBzaW5nbGUgZmxvdywgcmVtb3ZlIGVuY3J5cHRpb24gYW5kIHBhc3MgaXQgb24gdG8gdGhlIHN0
YWNrLCBpdCBkb2VzIG5vdCByZWFsbHkgbmVlZCB0byBzaW11bGF0ZSB0aGUgZGF0YSBhcnJpdmlu
ZyBpbiBhIHNpbmdsZSBqdW1ibyBRVUlDIHBhY2tldC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9w
OjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0
Omw0IGxldmVsMSBsZm8xIj5JZ29yPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IElhbiBT
d2V0dCBbPGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9y
ZyI+bWFpbHRvOmlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT5dDQo8YnI+
DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAyMywgMjAxOCAzOjIwIFBNPGJyPg0KPGI+VG86
PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVmPSJtYWlsdG86bWlra2Vs
ZmpAZ21haWwuY29tIj5taWtrZWxmakBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4g
UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3Nv
ZnQuY29tIj5wcmF2YkBtaWNyb3NvZnQuY29tPC9hPiZndDs7IElFVEYgUVVJQyBXRyAmbHQ7PGEg
aHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OzsgTWlrZSBC
aXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSI+bWJpc2hvcEBl
dmVxdWVmb3UuYmU8L2E+Jmd0OzsgRGV2YWwsIE1hbmFzaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1h
bmFzaS5kZXZhbEBpbnRlbC5jb20iPm1hbmFzaS5kZXZhbEBpbnRlbC5jb208L2E+Jmd0OzsNCjxh
IGhyZWY9Im1haWx0bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmciPmlhbnN3
ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g
UmU6IEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1h
bmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gY2xhcmlmeSBteSB1
bmRlcnN0YW5kaW5nLCB5b3UnZCBoYXZlIHRvIHJlY2VpdmUgYWxsIDMgc2VnbWVudHMgdG8gZGVj
cnlwdCB0aGUgcGF5bG9hZD8mbmJzcDsgSWYgdGhhdCdzIHdoYXQgeW91J3JlIHByb3Bvc2luZywg
dGhlbiBJIHRoaW5rIGl0J3Mgbm90IGEgZ29vZCBkZXNpZ24gZm9yIFFVSUMsIGJlY2F1c2UgaXQg
YW1wbGlmaWVzIHRoZSBlZmZlY3RpdmUgbG9zcyByYXRlIGFuZCBpdCBkb2Vzbid0IHNhdmUgdGhh
dA0KIG11Y2ggQ1BVLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5JdCdzIG5vdCB0aGF0IGhhcmQgZm9yIHVzZXJzcGFjZSB0byBwcm92aWRlIDMg
ZnVsbHkgZm9ybWVkIGVuY3J5cHRlZCBwYWNrZXRzIGFuZCB1c2UgYW4gQVBJIGxpa2UgV2lsbGVt
J3MgVURQIEdTTyBwYXRjaCwgYW5kIEkgYmVsaWV2ZSB0aGF0IGFwcHJvYWNoIGlzIG1vcmUgYWdp
bGUgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SWYgeW91IHdhbnRlZCB0byBkbyBjcnlwdG8gb2ZmbG9hZCwgdGhlbiB5b3UgY291
bGQgcHJvdmlkZSB0aGUgYWJpbGl0eSB0byBvZmZsb2FkIHBheWxvYWQgYW5kIFBOIGVuY3J5cHRp
b24gaW5zdGVhZCBvZiBkb2luZyBpdCBpbiB1c2Vyc3BhY2UuJm5ic3A7IEFzIGEgYm9udXMsIHN1
cHBvcnQgaW92ZWMgc3R5bGUgc2NhdHRlci1nYXRoZXIsIHNvIGJ1bGsgcGF5bG9hZHMgbmV2ZXIg
bmVlZCB0byBiZSBicm91Z2h0IGludG8NCiBDUFUgY2FjaGUgYmVmb3JlIHRoZXkncmUgZW5jcnlw
dGVkIGFuZCBjb3BpZWQgdG8gdGhlIE5JQy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXByIDIzLCAyMDE4IGF0IDI6NDYgUE0gTWlra2VsIEZh
aG7DuGUgSsO4cmdlbnNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbSI+
bWlra2VsZmpAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N
CjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3NGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFoLCBJIHNlZS4gVGhhbmtzIGZvciBl
eHBsYWluaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgw
NTcxMTYxNjQwMjc1Njc0Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5RVUlDIGhhcyBhIG11Y2ggcmVhY2hlciBp
bnRlcmZhY2UsIHNvIHRoZXJlIGNvdWxkIGJlLCBzYXkgMTAwIGFjdGl2ZSBzdHJlYW1zIHdhaXRp
bmcgZm9yIHRyYW5zbWlzc2lvbi4gVGhlIFFVSUMgaW1wbGVtZW50YXRpb24gd291bGQgdXNlIHNv
bWUgc29ydCBvZiBzY2hlZHVsZXIgdG8gbW92ZSB0aGUNCiBtb3N0IGltcG9ydGFudCBwYXJ0cyBm
aXJzdCB3aXRob3V0IGxvb3NpbmcgcHJvZ3Jlc3Mgb24gb3RoZXIgcGFydHMsIGZvciBleGFtcGxl
IHVzaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzEx
NjE2NDAyNzU2NzRibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg
aWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3NGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w
cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZW4ud2lraXBlZGlhLm9yZ193aWtpX0Rl
ZmljaXQtNUZyb3VuZC01RnJvYmluJmFtcDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRq
cE42TFpnJmFtcDtyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8m
YW1wO209a0xuMktnS0xQdEdKeFJ2S1hMLUZKNUpLYi1SdTBQMGpFTGRoeHBXd004WSZhbXA7cz1F
aUZ4RWxrSDRzZzMwbUJBZzE3aE02RTF1U25zazFtX0NjbkVwYmZBUjRRJmFtcDtlPSIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vZW4ud2lraXBlZGlhLi5vcmcvd2lraS9EZWZpY2l0X3JvdW5kX3Jv
YmluPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgwNTcx
MTYxNjQwMjc1Njc0Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0
Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+QSBzaW1wbGUgaHVnZSBidWZmZXIgc2VnbWVudGF0aW9uIHdvdWxkIHByb2JhYmx5IG5vdCB3
b3JrIGRpcmVjdGx5LCBidXQgYSBtZWFucyB0byBmb3J3YXJkIGRhdGEgcHJlLXdyYXBwZWQgaW4g
UVVJQyBmcmFtZXMsIGluIHJlYXNvbmFibGUgcGFja2FnZSB1bml0cywgYnV0IHdpdGhvdXQgQUVB
RA0KIGVudmVsb3BlIHdvdWxkIG1ha2Ugc2Vuc2UuIFRoZXNlIGNvdWxkIGJlIHF1ZXVlZCBpbiB2
b2x1bWVzLCBsZWF2aW5nIGl0IGFuIG9mZmxvYWRlciB0byBwcm9jZWVkLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0Ymxvb3BfY3Vz
dG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAy
NzU2NzRibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj5J4oCZdmUgYmVlbiBsb29raW5nIGludG8gdGhlIG5ldG1hcCBpbnRlcmZhY2Ugd2hl
cmUgeW91IGNhbiBmZWVkIGNvbnRlbnQgaW4gdW5pdHMgZGlyZWN0bHkgdG8gaGFyZHdhcmUsIGFu
ZCBJ4oCZbSBzdXJlIHlvdSBoYXZlIGRldGFpbGVkIGtub3dsZWRnZSBvZiBEUERLIHRoYXQgZG9l
cyBzb21ldGhpbmcNCiBzaW1pbGFyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
diBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3NGJsb29wX3NpZ25fMTUyNDUwODgwNDYwMDU1Njgw
MCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQg
UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Im0xODgwNTcxMTYxNjQwMjc1Njc0YWlybWFpbG9uIj5PbiAyMyBBcHJpbCAyMDE4IGF0
IDIwLjM4LjA2LCBEZXZhbCwgTWFuYXNpICg8YSBocmVmPSJtYWlsdG86bWFuYXNpLmRldmFsQGlu
dGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hbmFzaS5kZXZhbEBpbnRlbC5jb208L2E+KSB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SeKAmW0gdHJ5aW5nIHRvIGxheSBv
dXQgdGhlIG9wdGlvbnMgZm9yIFRTTy9MU08gd2l0aCBRVUlDLiBJbiBteSBwcmV2aW91cyBlLW1h
aWwgSSBjb21wYXJlZCB0aGUgb3V0Y29tZSBvZiB2YW5pbGxhIFVEUCBzZWdtZW50YXRpb24gYXMg
ZGVmaW5lZCBieSB0aGUgbGF0ZXN0DQogcGF0Y2ggKDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz
LTNBX19tYXJjLmluZm9fLTNGbC0zRGxpbnV4LTJEbmV0ZGV2LTI2bS0zRDE1MjM5OTUzMDYwMzk5
Mi0yNnctM0QyJmFtcDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDty
PURqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mYW1wO209a0xuMktn
S0xQdEdKeFJ2S1hMLUZKNUpLYi1SdTBQMGpFTGRoeHBXd004WSZhbXA7cz1oWUhaZlp5ZnhQN2tJ
bnBUdk5FOVUwMkJQQWhqZS1admFVZ1Yxck5DU0xJJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHBzOi8vbWFyYy5pbmZvLz9sPWxpbnV4LW5ldGRldiZhbXA7bT0xNTIzOTk1MzA2MDM5OTImYW1w
O3c9MjwvYT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+KSwNCjwvc3Bhbj48L3NwYW4+PHNw
YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPnRvIGFuIGFsdGVybmF0aXZlIG5hdGl2ZSBRVUlDIHNl
Z21lbnRhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BIHNl
Z21lbnQgaXMgYSBsYXJnZSBidWZmZXIgcHJvZHVjZWQgaW4gYW4gYXBwbGljYXRpb24uIFRoZSBz
ZWdtZW50IGlzIG9mdGVuIG11Y2ggdG9vIGxhcmdlIHRvIGdvIG91dCBvbiB0aGUgd2lyZSB3aXRo
IGp1c3QgcHJlLXBlbmRlZCBoZWFkZXJzLiBUaGVyZWZvcmUNCiBzZWdtZW50IG5lZWRzIHRvIGJl
IGNob3BwZWQgdXAgaW50byBhcHByb3ByaWF0ZSBzaXplIGFuZCB0aGUgcHJlLXBlbmRlZCBoZWFk
ZXJzIG5lZWQgdG8gYmUgcmVwbGljYXRlZCB0byBtYWtlIE1UVSBzaXplIHBhY2tldHMgZm9yIHRo
ZSB3aXJlLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SeKAmW0g
c3VnZ2VzdGluZyB0aGF0IHdlIHNob3VsZCBjb25zaWRlciBwcm9jZXNzaW5nIGEgbGFyZ2UgZGF0
YSBidWZmZXIgYXMgbXVsdGlwbGUgUVVJQyBwYWNrZXRzIGVhY2ggd2l0aCBhIHVuaXF1ZSBQTi4N
Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv
cjojMUY0OTdEIj5NYW5hc2k8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fMTg4MDU3MTE2MTY0MDI3
NTY3NF9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IE1pa2tlbCBGYWhuw7hlIErD
uHJnZW5zZW4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBN
b25kYXksIEFwcmlsIDIzLCAyMDE4IDExOjI1IEFNPGJyPg0KPGI+VG86PC9iPiBJYW4gU3dldHQg
Jmx0O2lhbnN3ZXR0PTxhIGhyZWY9Im1haWx0bzo0MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj40MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzsgRGV2
YWwsIE1hbmFzaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5jb20iIHRh
cmdldD0iX2JsYW5rIj5tYW5hc2kuZGV2YWxAaW50ZWwuY29tPC9hPiZndDs7IE1pa2UgQmlzaG9w
ICZsdDs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiIHRhcmdldD0iX2JsYW5r
Ij5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMg
V0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVp
Y0BpZXRmLm9yZzwvYT4mZ3Q7OyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7PGEgaHJlZj0i
bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5wcmF2YkBtaWNyb3Nv
ZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEltcGFjdCBvZiBoYXJkd2Fy
ZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3NGJsb29wX2N1c3RvbWZvbnQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SeKAmW0gbm90IHJlYWxseSBm
YW1pbGlhciB3aXRoIHRoaXMgZHVtcCBidXQgd2hhdCBkb2VzIHBhcnRpYWwgc2VnbWVudGF0aW9u
IG1lYW4gaGVyZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4
MDU3MTE2MTY0MDI3NTY3NGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFyZSB5b3Ugc3BsaXR0aW5nIGEg
c2luZ2xlIFVEUCBkYXRhZ3JhbSBpbnRvIG11bHRpcGxlIGZyYWdtZW50cywgb3IgYXJlIHlvdSBw
cm9jZXNzaW5nIG11bHRpcGxlIHNlcGFyYXRlIFFVSUMgcGFja2V0cywNCiBvbmUgUE4gZWFjaD88
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3
NTY3NGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJt
XzE4ODA1NzExNjE2NDAyNzU2NzRibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklmIHlvdSBmcmFnbWVudCBVRFAgZGF0YWdyYW1zLCB0
aGF0IGNhbiBiZSBhIGJpZyBpc3N1ZSBiZWNhdXNlIGRpZmZlcmVudCBmcmFnbWVudHMgbWF5IHJh
Y2UgYWxvbmcgZGlmZmVyZW50IHJvdXRlcywNCiBjYXVzaW5nIHVuZXhwZWN0ZWQgZGVsYXlzIGFu
ZCBibG9ja2luZyBhdCB0aGUgb3RoZXIgZW5kLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0Ymxvb3Bfc2lnbl8xNTI0NTA3NzMwMDMw
NTYzODQwIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Im0xODgwNTcxMTYxNjQwMjc1Njc0YWlybWFpbG9uMCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPk9uIDIzIEFwcmlsIDIwMTggYXQgMjAuMTguNTQsIERldmFsLCBNYW5hc2kgKDxhIGhyZWY9
Im1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFuYXNpLmRl
dmFsQGludGVsLmNvbTwvYT4pIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6
IzFGNDk3RCI+SWYgd2UgZG8gVFNPIC8gTFNPIHdpdGggUVVJQywgdGhlIGluaXRpYWwgc2VnbWVu
dCBwcm92aWRlZCBjYW4gbG9vayBsaWtlIOKAkzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1BQyDigJMgSVAg
4oCTIFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJQyBlbmNyeXB0ZWQgaGVhZGVyIChQTj14KSDi
gJMgUVVJQyBFbmNyeXB0ZWQgcGF5bG9hZC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTg4MDU3MTE2MTY0MDI3NTY3NG1zb3BsYWlu
dGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgd2UganVzdCB1c2UgdGhl
IHN0YWNr4oCZcyB1ZHAgc2VnbWVudGF0aW9uICh1c2luZyB0aGUgcGF0Y2ggLQ0KPC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX21hcmMuaW5mb18tM0ZsLTNEbGludXgtMkRuZXRkZXYtMjZt
LTNEMTUyMzk5NTMwNjAzOTkyLTI2dy0zRDImYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0
dzBGNGpwTjZMWmcmYW1wO3I9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVL
UG1sbyZhbXA7bT1rTG4yS2dLTFB0R0p4UnZLWEwtRko1SktiLVJ1MFAwakVMZGh4cFd3TThZJmFt
cDtzPWhZSFpmWnlmeFA3a0lucFR2TkU5VTAyQlBBaGplLVp2YVVnVjFyTkNTTEkmYW1wO2U9IiB0
YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9tYXJjLmluZm8vP2w9bGludXgtbmV0ZGV2JmFtcDttPTE1
MjM5OTUzMDYwMzk5MiZhbXA7dz0yPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4pLA0K
IHRoZSBvdXRjb21lIG9mIFFVSUMgcGFja2V0cyBvbiB0aGUgd2lyZSB3b3VsZCBiZTo8L3NwYW4+
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iY29sb3I6IzFGNDk3RCI+TUFDIOKAkyBJUCDigJMgVURQIOKAkyBRVUlDIENsZWFyIOKAkyBR
VUlDIGVuY3J5cHRlZCBwYXJ0IChQTj14LCBwYXJ0aWFsIHNlZ21lbnQgMS8zKTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx
RjQ5N0QiPk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAocGFydGlh
bCBzZWdtZW50IDIvMyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5NQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFV
SUMgZW5jcnlwdGVkIHBhcnQgKHBhcnRpYWwgc2VnbWVudCAzLzMpPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+
4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UHV0dGluZyB0aGVz
ZSBiYWNrIHRvZ2V0aGVyIGluIGEgc3RhY2sgLyBoYXJkd2FyZSBsb29rcyBsaWtlIGEgcGFpbmZ1
bCBhbmQgcG90ZW50aWFsbHkgbm9uLWRldGVybWluaXN0aWMgYWN0aXZpdHkuDQo8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5J
dCB3b3VsZCBiZSBlYXNpZXIgdG8gZG8gYSBuYXRpdmUgUVVJQyBvZmZsb2FkLCB3aGVyZSB0aGUg
cGFja2V0IG9uIHdpcmUgY2FuIGJlIGlkZW50aWZpZWQgYnkgUVVJQyBDaUQgYW5kIGFwcHJvcHJp
YXRlIHBhY2tldCBudW1iZXIuIFRoZXJlZm9yZSwgb3JpZ2luYWwNCiBwYWNrZXQgbG9va3MgbGlr
ZSAtIE1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBDbGVhciDigJMgUVVJQyBlbmNyeXB0ZWQg
aGVhZGVyIChQTj14KSDigJMgUVVJQyBFbmNyeXB0ZWQgcGF5bG9hZC4NCjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5
N0QiPklmIHdlIGp1c3QgY3JlYXRlIGFub3RoZXIgdmVyc2lvbiBvZiBzZWdtZW50YXRpb24gY2Fs
bGVkIFFVSUMgc2VnbWVudGF0aW9uLCB0aGUgb3V0Y29tZSBvZiBwYWNrZXRzIG9uIHRoZSB3aXJl
IHdvdWxkIGJlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1BQyDigJMgSVAg4oCTIFVEUCDigJMgUVVJQyBD
bGVhciDigJMgUVVJQyBlbmNyeXB0ZWQgcGFydCAoUE49eCwgcGFydGlhbCBzZWdtZW50IDEvMyk8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJjb2xvcjojMUY0OTdEIj5NQUMg4oCTIElQIOKAkyBVRFAg4oCTIFFVSUMgQ2xlYXIg4oCTIFFV
SUMgZW5jcnlwdGVkIHBhcnQgKFBOPXgmIzQzOzEsIHBhcnRpYWwgc2VnbWVudCAyLzMpPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s
b3I6IzFGNDk3RCI+TUFDIOKAkyBJUCDigJMgVURQIOKAkyBRVUlDIENsZWFyIOKAkyBRVUlDIGVu
Y3J5cHRlZCBwYXJ0IChQTj14JiM0MzsyLCBwYXJ0aWFsIHNlZ21lbnQgMy8zKTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx
RjQ5N0QiPuKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklmIHRoaXMgc2V0IG9mIHNlZ21lbnRzIHdlcmUg
dG8gYmUgcmUtYXNzZW1ibGVkLCB0aGUgYWJpbGl0eSB0byBpZGVudGlmeSBDaUQgYW5kIFBOIHdv
dWxkIHNpbXBsaWZ5IHRoaXMgdGFzay4gSSB0aGluayB0aGlzIGlzIGEgc2ltcGxlciBpbXBsZW1l
bnRhdGlvbi4NCiBEbyBvdGhlcnMgc2VlIGFuIGlzc3VlIHdpdGggdGhpcz88L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TWFu
YXNpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUVVJ
QyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5J
YW4gU3dldHQ8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAwNiwgMjAxOCAxOjU1IFBN
PGJyPg0KPGI+VG86PC9iPiBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BA
ZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0
Ozxicj4NCjxiPkNjOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1h
aWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+cHJhdmJAbWljcm9zb2Z0
LmNvbTwvYT4mZ3Q7OyBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVmPSJtYWls
dG86bWlra2VsZmpAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29t
PC9hPiZndDs7IElFVEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUmU6IEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZv
cm1hbmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UE5FIGRvZXNuJ3QgcHJl
Y2x1ZGUgVURQIExSTyBvciBwYWNpbmcgb2ZmbG9hZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3dldmVyLCBpbiBhIGhpZ2hseSBvcHRpbWl6ZWQg
c3RhY2soaWU6IFRoZSBEaXNrfENyeXB0fE5ldCBwYXBlciBmcm9tIFNJR0NPTU0gMjAxNykgbm90
IHRvdWNoaW5nKGllOiBicmluZ2luZyBpbnRvIG1lbW9yeSBvciBjYWNoZSkgdGhlIGNvbnRlbnQg
dG8gYmUgc2VudCB1bnRpbCB0aGUgbGFzdCBwb3NzaWJsZQ0KIG1vbWVudCBpcyBjcml0aWNhbC4m
bmJzcDsgUE5FIGxpa2VseSBtZWFucyB0b3VjaGluZyB0aGF0IGNvbnRlbnQgbXVjaCBlYXJsaWVy
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+QnV0IHBlcnNvbmFsbHkgSSBjb25zaWRlciB0aGUgYWN0dWFsIGNyeXB0byB3ZSdyZSB0YWxr
aW5nIGFib3V0KDIgQUVTIGluc3RydWN0aW9ucz8pIGFkZGluZyBiYXNpY2FsbHkgZnJlZS4mbmJz
cDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPk9uIEZyaSwgQXByIDYsIDIwMTggYXQgNDozNyBQTSBNaWtlIEJpc2hvcCAmbHQ7
PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWJp
c2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg
MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlv
bi4mbmJzcDsgSSBndWVzcyB3aGF0IEnigJltIHJlYWxseSBnZXR0aW5nIGRvd24gdG8gaXMgaG93
IGRvIHdlIHF1YW50aWZ5IHRoZSBhY3R1YWwNCjxpPmNvc3Q8L2k+IG9mIFBORT8mbmJzcDsgQXJl
IHdlIHN1YnN0YW50aWFsbHkgaW5jcmVhc2luZyB0aGUgY3J5cHRvIGNvc3RzPyZuYnNwOyBJZiBJ
YW4gaXMgc2F5aW5nIHRoYXQgY3J5cHRvIGlzIGNvbXBhcmF0aXZlbHkgY2hlYXAgYW5kIHRoZSBj
b3N0IGlzIHRoYXQgaXTigJlzIGhhcmRlciB0byBvZmZsb2FkIHNvbWV0aGluZyB0aGF04oCZcyBj
b21wYXJhdGl2ZWx5IGNoZWFwLCB3aGF0IGhhdmUgd2UgbG9zdD8mbmJzcDsgSeKAmWQgdGhpbmsg
d2Ugd2FudCB0byBvZmZsb2FkIHRoZQ0KIG1vc3QgaW50ZW5zaXZlIHBpZWNlIHdlIGNhbiwgYW5k
IGl0IHNlZW1zIGxpa2Ugd2XigJlyZSB0YWxraW5nIGFib3V0IGNyeXB0byBvZmZsb2Fkcy4uLi4m
bmJzcDsgT3IgYXJlIHdlIHNheWluZyBpbnN0ZWFkIHRoYXQgdGhlIGNyeXB0byBtYWtlcyBpdCBo
YXJkZXIgdG8gb2ZmbG9hZCBvdGhlciB0aGluZ3MgaW4gdGhlIGZ1dHVyZSwgbGlrZSBhIFFVSUMg
ZXF1aXZhbGVudCB0byBMUk8vTFNPPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp
biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBNaWtrZWwgRmFobsO4ZSBK
w7hyZ2Vuc2VuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g
VGh1cnNkYXksIEFwcmlsIDUsIDIwMTggOTo0NSBQTTxicj4NCjxiPlRvOjwvYj4gSWFuIFN3ZXR0
ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0OzsgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1h
aWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVl
Zm91LmJlPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZs
dDs8YSBocmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBy
YXZiQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsgSUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWls
dG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSW1wYWN0IG9mIGhhcmR3YXJlIG9mZmxvYWRzIG9uIG5l
dHdvcmsgc3RhY2sgcGVyZm9ybWFuY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0ibV8x
ODgwNTcxMTYxNjQwMjc1Njc0bV8tMjAxNzcxNDA0MDEzNzExNjM0OWNvbXBvc2UtY29udGFpbmVy
Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VG8gYmUgY2xl
YXIgLSBJIGRvbuKAmXQgdGhpbmsgY3J5cHRvIGlzIG92ZXJzaGFkb3dpbmcgb3RoZXIgaXNzdWVz
IGFzIE1pa2UgcmVhZCBteSBwb3N0LiBJdCBjZXJ0YWlubHkgY29tZXMgYXQgYSBjb3N0LCBidXQg
ZWl0aGVyIG11bHRpcGxlIGNvcmVzIG9yIGNvLXByb2Nlc3NvcnMgd2lsbCBkZWFsIHdpdGggdGhp
cy4NCiAxMDAwbnMgaXMgMTBHYnBzIGNyeXB0byBzcGVlZCBvbiBvbmUgY29yZSBhbmQgaXQgaXMg
aGlnbHkgcGFyYWxsZWxpc2FibGUgYW5kIGNhY2hlIGZyaWVuZGx5LjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QnV0IGlmIHlvdSBoYXZl
IHRvIGRyaXAgeW91ciBwYWNrZXRzIHRocm91Z2ggYSB0cmFkaXRpb25hbCBzZW5kIGludGVyZmFj
ZSB0aGF0IGlzIGNvcHlpbmcsIGJ1ZmZlcmluZyBvciBibG9ja2luZywgYW5kIGNlcnRhaW5seSBz
eW5j4oCZaW5nIHdpdGggdGhlIGtlcm5lbCAtIGl0IGlzIGdvaW5nIHRvIGJlIHRvdWdoLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9y
IHJlY2VpdmUgeW91IHJpc2sgaGlnaCBsYXRlbmN5IG9yIHRvcCBtdWNoIHNjaGVkdWxpbmcgaW4g
cmVjZWl2ZSBidWZmZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i
dGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4NCjxociBzaXplPSIyIiB3aWR0
aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4MDU3
MTE2MTY0MDI3NTY3NG1fLTIwMTc3MTQwNDAxMzcxMTYzNDlkaXZScGx5RndkTXNnIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bh
bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gSWFuIFN3ZXR0ICZsdDs8YSBocmVmPSJt
YWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0QGdvb2ds
ZS5jb208L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDYsIDIwMTggNDow
NjowMSBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3A8YnI+DQo8Yj5DYzo8L2I+IE1pa2tl
bCBGYWhuw7hlIErDuHJnZW5zZW47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuOyBJRVRGIFFVSUMg
V0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBv
biBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBBcHIgNSwg
MjAxOCBhdCA1OjU3IFBNIE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBl
dmVxdWVmb3UuYmUiIHRhcmdldD0iX2JsYW5rIj5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu
IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp
bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5UaGF04oCZcyBpbnRlcmVzdGluZyBkYXRhLCBQcmF2ZWVuIOKAkyB0aGFua3MuJm5ic3A7
IFRoZXJlIGlzIG9uZSBjYXZlYXQgdGhlcmUsIHdoaWNoIGlzIHRoYXQgKElJVUMsIG9uIGN1cnJl
bnQgaGFyZHdhcmUpIHlvdSBjYW7igJl0IGRvIHBhY2tldCBwYWNpbmcgd2l0aCBMU08sIGFuZCBz
byBteSB1bmRlcnN0YW5kaW5nIGlzDQogdGhhdCBldmVuIGZvciBUQ1AgbWFueSBwcm92aWRlcnMg
ZGlzYWJsZSB0aGlzIGluIHB1cnN1aXQgb2YgYmV0dGVyIGVncmVzcyBtYW5hZ2VtZW50LiZuYnNw
OyBTbyB3aGF0IHdl4oCZcmUgcmVhbGx5IHNheWluZyBpcyB0aGF0OjxvOnA+PC9vOnA+PC9wPg0K
PHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZl
bDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gY3VycmVudCBoYXJkd2FyZSBhbmQgT1Mg
c2V0dXBzLCBVRFAgcnVucyBsZXNzIHRoYW4gaGFsZiBhcyBtdWNoIHRocm91Z2hwdXQgYXMgVENQ
OyB0aGF0IG5lZWRzIHNvbWUgb3B0aW1pemF0aW9uLCBhcyB3ZeKAmXZlIGFscmVhZHkgZGlzY3Vz
c2VkPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0
OmwyIGxldmVsMSBsZm8yIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UQ1Agd2lsbCBkcmFtYXRpY2Fs
bHkgZ2FpbiBwZXJmb3JtYW5jZSBvbmNlIGhhcmR3YXJlIG9mZmxvYWQgY2F0Y2hlcyB1cCBhbmQg
YWxsb3dzDQo8dT5wYWNlZDwvdT4gTFNPIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj4m
IzEyODUyMjs8L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3dldmVy
LCBhcyBNaWtrZWwgcG9pbnRzIG91dCwgdGhlIGNyeXB0byBjb3N0cyBhcmUgbGlrZWx5IHRvIG92
ZXJ3aGVsbSB0aGUgT1MgdGhyb3VnaHB1dCAvIHNjaGVkdWxpbmcgaXNzdWVzIGluIHJlYWwgZGVw
bG95bWVudHMuJm5ic3A7IFNvIEkgdGhpbmsgdGhlIG90aGVyIHJlbGV2YW50IHBpZWNlIHRvIHVu
ZGVyc3RhbmRpbmcNCiB0aGUgY29zdCBoZXJlIGlzIHRoaXM6PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPkkgaGF2ZSBhIGZldyBjYXNlcyhib3RoIGNsaWVudCBhbmQgc2VydmVyKSB3aGVyZSBteSBV
RFAgc2VuZCBjb3N0cyBhcmUgbW9yZSB0aGFuIDMwJShpbiBzb21lIGNhc2VzIDUwJSkgb2YgQ1BV
IGNvbnN1bXB0aW9uLCBhbmQgY3J5cHRvIGlzIGxlc3MgdGhhbiAxMCUuJm5ic3A7IFNvIGN1cnJl
bnRseSwgSSBhc3N1bWUNCiBjcnlwdG8gaXMgY2hlYXAoZXNwZWNpYWxseSBBRVMtR0NNIHdoZW4g
aGFyZHdhcmUgYWNjZWxlcmF0aW9uIGlzIGF2YWlsYWJsZSkgYW5kIGVncmVzcyBpcyBleHBlbnNp
dmUuJm5ic3A7IFVEUCBpbmdyZXMgaXMgbm90IHRoYXQgZXhwZW5zaXZlLCBidXQgY291bGQgdXNl
IGEgYml0IG9mIG9wdGltaXphdGlvbiBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIG9ubHkgJ2ZhbmN5JyB0aGluZyBv
dXIgY3VycmVudCBjb2RlIGlzIGRvaW5nIGZvciBjcnlwdG8gaXMgZW5jcnlwdGluZyBpbiBwbGFj
ZSwgd2hpY2ggd2FzIGEgfjIlIHdpbi4mbmJzcDsgTmljZSwgYnV0IG5vdCB0cmFuc2Zvcm1hdGl2
ZS4mbmJzcDsgU2VlDQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v
djIvdXJsP3U9aHR0cHMtM0FfX2NzLmNocm9taXVtLm9yZ19jaHJvbWl1bV9zcmNfbmV0X3F1aWNf
Y29yZV9xdWljLTVGZnJhbWVyLmNjLTNGc3EtM0RwYWNrYWdlLTNBY2hyb21pdW0tMjZsLTNEMTg5
MyZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1
dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPWtMbjJLZ0tMUHRHSnhS
dktYTC1GSjVKS2ItUnUwUDBqRUxkaHhwV3dNOFkmYW1wO3M9LS1Eb0FMUFpvYTBMNEllOVRaclBL
cER5MV9kbmIxa04tM0dhM01yWG5iMCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCkVuY3J5cHRJ
blBsYWNlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+SSBoYXZlbid0IGRvbmUgbXVjaCB3b3JrIGJlbmNobWFya2luZyBXaW5kb3dz
LCBzbyBwb3NzaWJseSB0aGUgV2luZG93cyBVRFAgc3RhY2sgaXMgcmVhbGx5IGZhc3QsIGFuZCBz
byBjcnlwdG8gc2VlbXMgcmVhbGx5IHNsb3cgaW4gY29tcGFyaXNvbj88bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6
NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvO21zby1saXN0OmwzIGxldmVsMSBsZm8zIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5XaGF0IGlz
IHRoZSB0aHJvdWdocHV0IGFuZCByZWxhdGl2ZSBjb3N0IG9mIFRMUy9UQ1AgdmVyc3VzIFFVSUMg
KGkuZS4gaG93IG11Y2ggYXJlIHRoZSBzbWFsbGVyIHVuaXRzIG9mIGVuY3J5cHRpb24gaHVydGlu
ZyB1cyB2ZXJzdXMsIHNheSwgMTZLQiBUTFMgcmVjb3Jkcyk/DQo8L3NwYW4+PG86cD48L286cD48
L2xpPjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzQiPg0KPHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPlRMUyBpbXBsZW1lbnRhdGlvbnMgYWxyZWFkeSB2YXJ5IGhlcmU6Jm5ic3A7IFNvbWUgaW1w
bGVtZW50YXRpb25zIGNob29zZSBsYXJnZSByZWNvcmQgc2l6ZXMsIHNvbWUgdmFyeSByZWNvcmQg
c2l6ZXMgdG8gcmVkdWNlIGRlbGF5IC8gSG9MQiwgc28gdGhpcyBwcm9iYWJseSBpc27igJl0IGEg
c2luZ2xlIG51bWJlci48L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPHVsIHR5
cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZv
NSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SG93IG11Y2ggYWRkaXRpb25hbCBsb2FkIGRvZXMgUE5F
IGFkZCB0byB0aGlzIGRpZmZlcmVuY2U/PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm81Ij4NCjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij5UbyB3aGF0IGV4dGVudCB3b3VsZCBQTkUgbWFrZSBmdXR1cmUgY3J5cHRvIG9mZmxvYWRzDQo8
aT5pbXBvc3NpYmxlPC9pPiB2ZXJzdXMgPGk+cmVxdWlyZXMgbW9yZSBSJmFtcDtEIHRvIGRldmVs
b3A8L2k+Pzwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOjxhIGhy
ZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJv
dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NaWtrZWwgRmFobsO4ZSBK
w7hyZ2Vuc2VuPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxOCAxOjM0
IFBNPGJyPg0KPGI+VG86PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmI9PGEg
aHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7OyBJRVRGIFFVSUMgV0cg
Jmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0Bp
ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJbXBhY3Qgb2YgaGFyZHdh
cmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3JtYW5jZTxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5
bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGZvciBzaGFyaW5nIHRoZXNlIG51bWJl
cnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2
NDAyNzU2NzRtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29w
X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzEx
NjE2NDAyNzU2NzRtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Js
b29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+TXkgZ3Vlc3MgaXMgdGhhdCB0aGVzZSBvZmZsb2FkcyBkZWFsIHdpdGgga2VybmVsIHNjaGVk
dWxpbmcsIG1lbW9yeSBjYWNoZSBpc3N1ZXMsIGFuZCBpbnRlcnJ1cHQgc2NoZWR1bGluZy48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3
NG1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9t
Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3
NTY3NG1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3Vz
dG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JdCBw
cm9iYWJseSBoYXMgdmVyeSBsaXR0bGUgdG8gZG8gd2l0aCBjcnlwdG8sIFRDUCBoZWFkZXJzLCBh
bmQgYW55IG90aGVyIGNwdSBzZW5zaXRpdmUgcHJvY2Vzc2luZy48L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3NG1fLTIwMTc3MTQwNDAx
MzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3NG1fLTIwMTc3MTQw
NDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIHdoZXJlIG5ldG1h
cCBlbnRlcnM6IHlvdSBjYW4gdHJhbnNwYXJlbnRseSBmZWVkIHRoZSBkYXRhIGFzIGl0IGJlY29t
ZXMgYXZhaWxhYmxlIHdpdGggdmVyeSBsaXR0bGUgc3luYw0KIHdvcmsgYW5kIHlvdSBjYW4gYWxz
byBlZmZpY2llbnRseSBwaXBlbGluZSBzbyB5b3UgcGFzcyBkYXRhIHRvIGRlY3J5cHRvciwgdGhl
biB0byBhcHAsIHdpdGggYXMgbGl0dGxlIGJ1cyB0cmFmZmljIGFzIHBvc3NpYmxlLiBObyBuZWVk
IHRvIGNvcHkgZGF0YSBvciBzeW5jaHJvbml6ZSBrZXJuZWwgc3BhY2UuPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRtXy0yMDE3NzE0
MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRtXy0yMDE3
NzE0MDQwMTM3MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Rm9yIDFLIHBhY2tldHMg
eW91IHdvdWxkIHVzZSBhYm91dCAxMDAwbnMgKDMgY3ljbGVzL2J5dGUpIG9uIGNyeXB0byBhbmQg
dGhpcyB3b3VsZCBoYXBwZW4gaW4gTDEgY2FjaGUuIEl0IHdvdWxkDQogb2YgY291cnNlIGNvbnN1
bWUgYSBjb3JlIHdoaWNoIGEgY3J5cHRvIG9mZmxvYWQgd291bGQgbm90LCBidXQgdGhhdCBjYW4g
YmUgZGViYXRlZCBiZWNhdXNlIHdpdGggMTggY29yZSBzeXN0ZW1zLCB5b3VyIHByb2JsZW0gaXMg
bWVtb3J5IGFuZCBuZXR3b3JrIG1vcmUgdGhhbiBDUFUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRtXy0yMDE3NzE0MDQwMTM3MTE2
MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRtXy0yMDE3NzE0MDQwMTM3
MTE2MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TXkgY29uY2VybiB3aXRoIFBORSBpcyBm
b3Igc21hbGwgcGFja2V0cyBhbmQgbG93IGxhdGVuY3kgd2hlcmU8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3NG1fLTIwMTc3MTQwNDAx
MzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4xKSBhbiBlc3RpbWF0ZWQgMjRucyBm
b3IgUE4gZW5jcnlwdGlvbiBhbmQgZGVjcnlwdGlvbiBiZWNvbWVzIG1lYXN1cmFibGUgaWYgeW91
ciBuZXR3b3JrIGlzIGZhc3QgZW5vdWdoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdiBpZD0ibV8xODgwNTcxMTYxNjQwMjc1Njc0bV8tMjAxNzcxNDA0MDEzNzExNjM0OW1fLTkw
MDQ5MTcxNDk0MDU1OTQxNDNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjIpIGFueSBkYW1hZ2UgdG8gdGhlIHBhY2tldCBidWZmZXIg
Y2F1c2UgYWxsIHNvcnRzIG9mIG1lbW9yeSBhbmQgY3B1IGJ1cyB0cmFmZmljIGlzc3Vlcy48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3
NG1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3VzdG9t
Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3
NTY3NG1fLTIwMTc3MTQwNDAxMzcxMTYzNDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3BfY3Vz
dG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4xKSBp
cyBhbm5veWluZy4gMikgaXMgYmFkLCBjb21wbGV0ZWx5IGF2b2lkYWJsZSBidXQgbm90IGFzIFBS
IDEwNzkgaXMgZm9ybXVsYXRlZCBjdXJyZW50bHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5
bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRtXy0yMDE3NzE0MDQwMTM3MTE2
MzQ5bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+MikgaXMgYWxzbyBsaWtlbHkgYmFkIGZvciBo
YXJkd2FyZSBvZmZsb2FkIHVuaXRzIGFzIHdlbGwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2IGlkPSJtXzE4ODA1NzExNjE2NDAyNzU2NzRtXy0yMDE3NzE0MDQwMTM3MTE2MzQ5
bV8tOTAwNDkxNzE0OTQwNTU5NDE0M2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BcyB0byBT
UlYtSU8gLSBJ4oCZbSBub3QgZmFtaWxpYXIgd2l0aCBpdCwgYnV0IG9idmlvdXNseSB0aGVyZSBp
cyBzb21lIElPIGFic3RyYWN0aW9uIGxheWVyIC0gdGhlIHF1ZXN0aW9uIGlzIGhvdw0KIHlvdSBt
YWtlIGl0IGFjY2Vzc2libGUgdG8gYXBwcyBhcyBvcHBvc2VkIHRvIGRldmljZSBkcml2ZXJzIHRo
YXQgZG9lcyBub3Igd29yayB3aXRoIHlvdSBRVUlDIGN1c3RvbSBzdGFjaywgYW5kIG5ldG1hcCBp
cyBvbmUgb3B0aW9uIGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxkaXYgaWQ9Im1fMTg4MDU3MTE2MTY0MDI3NTY3NG1fLTIwMTc3MTQwNDAxMzcxMTYz
NDltXy05MDA0OTE3MTQ5NDA1NTk0MTQzYmxvb3Bfc2lnbl8xNTIyODczMzUwNDE1MTIwMTI4Ij4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5LaW5kIFJl
Z2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu
MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
bTE4ODA1NzExNjE2NDAyNzU2NzRtLTIwMTc3MTQwNDAxMzcxMTYzNDltLTkwMDQ5MTcxNDk0MDU1
OTQxNDNhaXJtYWlsb24iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDQgQXByaWwgMjAxOCBhdCAy
Mi4xNS41MiwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gKDxhIGhyZWY9Im1haWx0bzpwcmF2Yj00
MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wcmF2Yj00MG1p
Y3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+KSB3cm90ZTo8L3NwYW4+PG86cD48L286cD48
L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPlNvbWUgY29tcGFyYXRpdmUgbnVtYmVycyBmcm9tIGFuIG91dCBvZiBib3gg
ZGVmYXVsdCBzZXR0aW5ncyBXaW5kb3dzIFNlcnZlciAyMDE2IChyZWxlYXNlZCB2ZXJzaW9uKSBm
b3IgYSBzaW5nbGUNCiBjb25uZWN0aW9uIHdpdGggYSBtaWNyb2JlbmNobWFyayB0b29sOjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFs
VGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0i
Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB3aWR0aD0iMTU2
IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi44NXB0O2JvcmRlcjpzb2xpZCAjOTk5OTk5
IDEuMHB0O2JvcmRlci1ib3R0b206c29saWQgIzY2NjY2NiAxLjVwdDtwYWRkaW5nOjBpbiA1LjRw
dCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+T2ZmbG9hZHMgZW5hYmxlZDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk
IHdpZHRoPSIxNTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2LjlwdDtib3JkZXItdG9w
OnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlk
ICM2NjY2NjYgMS41cHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7cGFkZGluZzow
aW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPlRDUCBnYnBzPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg
d2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6
c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQg
IzY2NjY2NiAxLjVwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBp
biA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+VURQIGdicHM8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+
DQo8dHI+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuODVw
dDtib3JkZXI6c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowaW4g
NS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPkxTTyAmIzQzOyBMUk8gJiM0MzsgY2hlY2tzdW08L3NwYW4+PC9iPjxvOnA+PC9vOnA+
PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjEx
Ni45cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xp
ZCAjOTk5OTk5IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRpbmc6
MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj4yNDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIg
dmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYuOXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXIt
bGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6
c29saWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+My42PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0
eWxlPSJ3aWR0aDoxMTYuODVwdDtib3JkZXI6c29saWQgIzk5OTk5OSAxLjBwdDtib3JkZXItdG9w
Om5vbmU7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWNrc3VtIG9ubHk8L3NwYW4+PC9iPjxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRo
OjExNi45cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpz
b2xpZCAjOTk5OTk5IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRp
bmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj43LjY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIx
NTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE2LjlwdDtib3JkZXItdG9wOm5vbmU7Ym9y
ZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVyLXJp
Z2h0OnNvbGlkICM5OTk5OTkgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjMuNjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHdpZHRoPSIxNTYiIHZhbGlnbj0idG9w
IiBzdHlsZT0id2lkdGg6MTE2Ljg1cHQ7Ym9yZGVyOnNvbGlkICM5OTk5OTkgMS4wcHQ7Ym9yZGVy
LXRvcDpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Ob25lPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwv
cD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjE1NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMTYu
OXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQg
Izk5OTk5OSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgIzk5OTk5OSAxLjBwdDtwYWRkaW5nOjBp
biA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+NS42PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTU2IiB2
YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExNi45cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1s
ZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjOTk5OTk5IDEuMHB0O2JvcmRlci1yaWdodDpz
b2xpZCAjOTk5OTk5IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yLjM8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBpcyBmb3IgYSBmdWxs
eSBib3R0bGVuZWNrZWQgQ1BVIGNvcmUgLS0NCjxpPmlmIHlvdSBydW4gbG93ZXIgZGF0YSByYXRl
cyB0aGVyZSBpcyBzdGlsbCBhIHNpZ25pZmljYW50IGRpZmZlcmVuY2UgaW4gQ3ljbGVzL2J5dGUg
Y29zdDwvaT4uIFNhbWUgaW5jcmVhc2VkIENQVSBjb3N0IGFwcGxpZXMgZm9yIGNsaWVudCBzeXN0
ZW1zIGdvaW5nIG92ZXIgaGlnaCBkYXRhIHJhdGUgV2lmaSBhbmQgY2VsbHVsYXIuDQo8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIHdpdGhvdXQgYW55IGNyeXB0by4gT25jZSB5b3UgYWRk
IGNyeXB0byB0aGUgbnVtYmVycyBiZWNvbWUgbXVjaCB3b3JzZQ0KPGk+d2l0aCBjcnlwdG8gY29z
dCBiZWNvbWluZyBkb21pbmFudDwvaT4uIEFkZGluZyBhbm90aGVyIGNyeXB0byBzdGVwIGZ1cnRo
ZXIgZXhhY2VyYmF0ZXMgdGhlIHByb2JsZW0uIEhlbmNlIGNyeXB0byBvZmZsb2FkIGdhaW5zIGlu
IGltcG9ydGFuY2UgZm9sbG93ZWQgYnkgdGhlc2UgYmF0Y2ggb2ZmbG9hZHMuPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+SWYgZm9sa3MgbmVlZCBhbnkgbW9yZSBudW1iZXJzIEnigJlkIGJlIGhhcHB5
IHRvIHByb3ZpZGUgdGhlbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3M8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_SN1PR08MB185446750FCDA2B58C9833C8DA890SN1PR08MB1854namp_--


From nobody Mon Apr 23 13:56:05 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBF912D96B for ; Mon, 23 Apr 2018 13:56: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 PRzqxznZCC_y for ; Mon, 23 Apr 2018 13:56:00 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 7167412D95A for ; Mon, 23 Apr 2018 13:56:00 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id y15-v6so8908121lfj.0 for ; Mon, 23 Apr 2018 13:56:00 -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=4/f+zZxsHYJN4nIgt4V/+7TDMagemBuiZfj0AxZ+k7o=; b=SH4WSTY6ipVVOkHZHKDlF2d97d3FFF89TPhcwkP70a8iyGnLekzUuwHvCSFNH7jf8Q QxqrZvpTMe9lFjHOnwZNpAJhWDubWq5yCnDC9wz1hzLiXRa+vS4syGBIR1zCeNPZ8j/7 pKtk3jtA2OeuV9bUpZKIj1WtU2BChkkwc9ICBMVYJXEcpBok5A4QdDj4L1mCcvHY1g/h psDNEGwpHWlVJKvPExWatlWhFfvw8Tbbcbp7TEFdNtcNAG2pH1MVth4G0jhqSVROzswh hbJrXyZR0g8yO2fw08e9IFXBlLYvv5NMWId7tThQuKglNpcWixXe/+1LO0aQzAzFpcLf 5DZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=4/f+zZxsHYJN4nIgt4V/+7TDMagemBuiZfj0AxZ+k7o=; b=L1Dqa7gzjhfYYRzpa7GB8/5tTbnCU2UKeGjZmHAumKfJ/Y0cN0iLwYYdIwKjmxw3Wr r3YhTqNvzqq/9p/ARL7mbW9L0wEvCP0hwiQ0eTfvI9SIn6veI6PQm8RYqDKZNPlr/T9f OegsvFCCljSwUWqIiTtkfqDLIVpPlr+MnbTskHAqcp0m23I+STqKa1NUUFkImEUbSg/A IpSDGd2THVTcEwnUaE0qsotr7neG1JYmufXya2OJrR46ucjAMQtDuft8nwD/gP5o2pvW b66E7z1GXwF0DugNUAK3kKNjQ4qD/yalgPlBW0PsXIz1GWIlAh5nnIFwSBxkXGAG49bh AxNw==
X-Gm-Message-State: ALQs6tAPgkDXXhRcfEovuq6fVv8TOFJ1dczuuD4Lx2K49hJ945wgRkBo pnuSjYXjrcefevOf3cCh57pTkzvj4oHmtDTCQ88=
X-Google-Smtp-Source: AB8JxZrWrSGgykKD3cH14WA+B9nY2lgVy41/q5dhmVttXZnNMQq/+ltlOjQlbTNmMurxSegd/idsFL/nRDwecTfVqho=
X-Received: by 2002:a19:c3d0:: with SMTP id t199-v6mr8588993lff.127.1524516957228;  Mon, 23 Apr 2018 13:55:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:cbd2:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 13:55:56 -0700 (PDT)
In-Reply-To: 
References:        <1F436ED13A22A246A59CA374CBC543998B60C7AD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B60C851@ORSMSX111.amr.corp.intel.com>    
From: Watson Ladd 
Date: Mon, 23 Apr 2018 13:55:56 -0700
Message-ID: 
Subject: Re: Impact of hardware offloads on network stack performance
To: Mike Bishop 
Cc: "Lubashev, Igor" , Ian Swett ,  =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= ,  Praveen Balasubramanian , IETF QUIC WG ,  "Deval, Manasi" 
Content-Type: multipart/alternative; boundary="000000000000b09da0056a8a4338"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 23 Apr 2018 20:56:03 -0000

--000000000000b09da0056a8a4338
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 23, 2018 at 1:06 PM, Mike Bishop  wrote:

> I agree =E2=80=93 the point of offloading the crypto is not only to spare=
 that
> cost on the CPU, though that can be useful, it=E2=80=99s to enable furthe=
r offloads
> that can=E2=80=99t be done on the encrypted packet.
>
>
>
> LRO that could simply group packets by CID and deliver a single batch of
> packets from a single CID in a single invocation seems like a great first
> step, and doesn=E2=80=99t even require crypto offload.  Once you have cry=
pto
> offload, of course those packets per CID could be delivered already
> decrypted.  I=E2=80=99d want to see data on whether there=E2=80=99s value=
 in making the
> received data look like one huge packet when there=E2=80=99s not a single
> bytestream, but that=E2=80=99s not something we need to specify here.
>
>
>
> LSO is more interesting, and the challenge there is that the transport
> stack still needs to know what data was in which packet so that it can do
> loss recovery properly.  QUIC explicitly disallows fragmentation of the U=
DP
> datagram, for the =E2=80=9Cpainful and potentially non-deterministic=E2=
=80=9D reasons you
> referenced.
>

Forgive my complete ignorance, but doesn't it just need to know what packet
it sent?

More explicitly the sender would maintain a queue of sendable packets, and
mark which have been sent. Acknowledged packets are removed from the queue.
In event of loss, they simply retransmit the same packet. It's up to higher
layers to pick the right size of packet and take data from the individual
QUIC streams. If you wanted to expose the stream structure, that sounds a
lot more complicated.

Sincerely,
Watson

--000000000000b09da0056a8a4338
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Apr 23, 2018 at 1:06 PM, Mike Bishop <mbishop@evequefou.be<=
/a>> wrote:











I agree =E2=80=93 the point of offloading the crypto=
 is not only to spare that cost on the CPU, though that can be useful, it=
=E2=80=99s to enable further offloads that can=E2=80=99t be done on the enc=
rypted packet.


=C2=A0


LRO that could simply group packets by CID and deliv=
er a single batch of packets from a single CID in a single invocation seems=
 like a great first step, and doesn=E2=80=99t even require crypto offload.=
=C2=A0 Once you have crypto offload, of course those
 packets per CID could be delivered already decrypted.=C2=A0 I=E2=80=99d wa=
nt to see data on whether there=E2=80=99s value in making the received data=
 look like one huge packet when there=E2=80=99s not a single bytestream, bu=
t that=E2=80=99s not something we need to specify here.


=C2=A0


LSO is more interesting, and the challenge there is =
that the transport stack still needs to know what data was in which packet =
so that it can do loss recovery properly.=C2=A0 QUIC explicitly disallows f=
ragmentation of the UDP datagram, for the
 =E2=80=9Cpainful and potentially non-determi=
nistic=E2=80=9D reasons you referenced.
=


Forgive my complete ignorance, but doesn't it just =
need to know what packet it sent?

More explicitly the sender would m=
aintain a queue of sendable packets, and mark which have been sent. Acknowl=
edged packets are removed from the queue. In event of loss, they simply ret=
ransmit the same packet. It's up to higher layers to pick the right siz=
e of packet and take data from the individual QUIC streams. If you wanted t=
o expose the stream structure, that sounds a lot more complicated.

Sincerely,






--000000000000b09da0056a8a4338--


From nobody Mon Apr 23 15:06:45 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66DF1200B9 for ; Mon, 23 Apr 2018 15:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtU7Wq4Emm4x for ; Mon, 23 Apr 2018 15:06:42 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0129.outbound.protection.outlook.com [104.47.33.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6385124B18 for ; Mon, 23 Apr 2018 15:06:41 -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=QAp8i+QVUDUZtmzzDNRIBnH2CIZlnS+kex4mgZ23as8=; b=FPyMLbiwvUAGbGNSatr98w/NfrWY1rIkJL/5GH4Q+8uzqLNvTmSfR/YV8W2Rm1ObeMHbN8Xj8ThjUUd9OBOd7h7OcN3dDe/NZfs2vRqjwr9NUrkaMW11ePUfZeDUf9B/FxDzhy+g+9sHcMB8osvYhK86EYBuR/7Q9PzoYXGgA7A=
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB0936.namprd21.prod.outlook.com (52.132.131.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.715.5; Mon, 23 Apr 2018 22:06:39 +0000
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::ac02:3f79:af:e239]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::ac02:3f79:af:e239%2]) with mapi id 15.20.0735.004; Mon, 23 Apr 2018 22:06:39 +0000
From: Nick Banks 
To: IETF QUIC WG 
Subject: QUIC Connection Close Reliability
Thread-Topic: QUIC Connection Close Reliability
Thread-Index: AdPbS1oyWnbH2U0CSPiNn9ybMzF86A==
Date: Mon, 23 Apr 2018 22:06:39 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-04-23T22:06:37.3674464Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:1::30c]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0936; 7:CDHe5EjKilV8E5pW5Mbe45CnzLtiRd56p3boHPOEalTGiwAJqxnGrsQP/h4CB58CyFSj7ZBwRk6kju4rz7oYn8HDFj3I+vHFPPLHbfZMxZKMGQOlsS/1tUVnTyHaeyZAOBRZbYlvGg6GRBxFKJy1kmRkmnxPFHWTJg6XfE30aeTsvxylzqlMuV5cSM5MjDtZXlPzrpuvpZjKC3j4uKxT9Diy/tvkDh2HqXiiF7ggNr/KcnxO7+LHATYcF/ToZci4; 20:8ZkTUResCLlfM+GSG1PG6/3TJGcShjdA7LqwnVcgFsNUDnSoxCguBqtO0qLUiEIOb1Sw7rGB7O20h2r5Ah95t/wO1l2pzQTuwmPmPEa/IyjvGmFAUCnNSkGIJLQZi2MSWjNuc3kHokAhdHjrsUX18xS7TOFfkCwvdDg0DCdXX3o=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR2101MB0936; 
x-ms-traffictypediagnostic: DM5PR2101MB0936:
authentication-results: outbound.protection.outlook.com; spf=skipped (originating message); dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=microsoft.com;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231232)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR2101MB0936; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0936; 
x-forefront-prvs: 06515DA04B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(396003)(346002)(366004)(39860400002)(7736002)(8936002)(3660700001)(6306002)(478600001)(5660300001)(55016002)(33656002)(102836004)(6436002)(9686003)(54896002)(236005)(86362001)(86612001)(59450400001)(6506007)(3280700002)(74316002)(316002)(606006)(6116002)(7696005)(46003)(790700001)(53936002)(2906002)(10290500003)(22452003)(6916009)(5250100002)(8676002)(2900100001)(25786009)(476003)(186003)(81166006)(3480700004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0936; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; 
x-microsoft-antispam-message-info: 9j0tLvcZn20rAdOK2P88jE8mZXQfYy8YTfE3stFrpk+gMP/CqSRLPbmHdWoILe6oyoWMvZSkpinbN5tlq76T3eVjWLxbO8TPqe1U6nCK8uu8kHAN9NIKqxKWKvYD+4nsL6+0hJtPMgVjGzmjkGHeg6rImq3kktC24x+8LqIk4QIsRptHIjDJsI+635Ck2vCK
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB090161AA6FD645EFFA1A1EFBB3890DM5PR2101MB0901_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: e0606d69-c85e-4924-e648-08d5a9667d32
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e0606d69-c85e-4924-e648-08d5a9667d32
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2018 22:06:39.3498 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0936
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 23 Apr 2018 22:06:45 -0000

--_000_DM5PR2101MB090161AA6FD645EFFA1A1EFBB3890DM5PR2101MB0901_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hey Folks,

I have been trying to work through an issue with reliability, related to co=
nnection close and I am trying to understand if this is a protocol issue fo=
r if I need to change my implementation.

Suppose you have an application protocol on top of QUIC where each side of =
the connection may use one or more streams and then immediately, but gracef=
ully, close the connection when they are done with all the streams. In that=
 kind of application protocol, one side of the connection generally ends up=
 closing immediately in response to receiving a FIN on a stream. Then you g=
et into a state where the peer won't necessarily get that FIN acknowledged.=
 Even if the endpoint sends an acknowledgment for the FIN (either as a sepa=
rate packet or with the close) it's possible that ACK is lost. Ideally (I t=
hink), the ACK is sent in the same packet as the close, so you can control =
the atomic state change on the peer. If the ACK was separate, and lost, but=
 the close wasn't lost, then the peer would treat the stream as abortively =
closed.

A -------- STREAM (w/FIN) ------> B
A <------- ACK, APP_CLOSE ------- B

But now the issue comes if the ACK/APP_CLOSE packet is lost. Per spec, the endpoint (B) that received the FIN and then closed the connection=
 enters the closing period. While in this state, the spec states that the e=
ndpoint SHOULD respond to any packet it receives [without a corresponding c=
lose frame] with another packet containing a closing frame. If the endpoint=
 does this, and includes the ACK again as well, I believe everything would =
work. The peer (A) would retransmit the STREAM packet, which would elicit a=
 new ACK/APP_CLOSE packet from (B). My fear though (from current interop ex=
perience) is that everyone will try to short circuit connection closure and=
 just immediately go away. If this behavior isn't completely standard acros=
s all implementations, then the application protocol would end up having di=
fferent results on different implementations. Some implementations, might n=
ot send the ACK at all with the initial close, causing the peer (A) to most=
 of the time interpret the stream as aborted. Other times, the endpoint (A)=
 might not continue to send the ACK frame with the close, or just not send =
anything any more at all, resulting in a timeout on the peer side, also res=
ulting in an abortive closure of the stream. This would probably cause the =
application protocol to end up creating it's own close semantics, on top of=
 QUIC.

Now, folks might not think this is a very important scenario, but I feel we=
 should aim for consistency here. Perhaps I have missed a different solutio=
n to the problem. I considered a design that always sends that last ACK wit=
h a PING frame, and waits for that to get acknowledged before closing, but =
I felt it was way too ugly.

Thanks,
- Nick

--_000_DM5PR2101MB090161AA6FD645EFFA1A1EFBB3890DM5PR2101MB0901_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hey Folks,


 


I have been trying to work through an issue with rel=
iability, related to connection close and I am trying to understand if this=
 is a protocol issue for if I need to change my implementation.<=
/p>

 


Suppose you have an application protocol on top of Q=
UIC where each side of the connection may use one or more streams and then =
immediately, but gracefully, close the connection when they are done with a=
ll the streams. In that kind of application
 protocol, one side of the connection generally ends up closing immediately=
 in response to receiving a FIN on a stream. Then you get into a state wher=
e the peer won’t necessarily get that FIN acknowledged. Even if the e=
ndpoint sends an acknowledgment for the
 FIN (either as a separate packet or with the close) it’s possible th=
at ACK is lost. Ideally (I think), the ACK is sent in the same packet as th=
e close, so you can control the atomic state change on the peer. If the ACK=
 was separate, and lost, but the close
 wasn’t lost, then the peer would treat the stream as abortively clos=
ed.


 


A -------- STREAM (w/FIN) ------> B

A <------- ACK, APP_CLOSE ------- B

 


But now the issue comes if the ACK/APP_CLOSE packet =
is lost.

Per spec, the endpoint (B) that received the FIN and then closed the co=
nnection enters the closing period. While in this state, the spec states th=
at the endpoint SHOULD respond to any packet it receives [without a corresp=
onding close frame] with another
 packet containing a closing frame. If the endpoint does this, and includes=
 the ACK again as well, I believe everything would work. The peer (A) would=
 retransmit the STREAM packet, which would elicit a new ACK/APP_CLOSE packe=
t from (B). My fear though (from
 current interop experience) is that everyone will try to short circuit con=
nection closure and just immediately go away. If this behavior isn’t =
completely standard across all implementations, then the application protoc=
ol would end up having different results
 on different implementations. Some implementations, might not send the ACK=
 at all with the initial close, causing the peer (A) to most of the time in=
terpret the stream as aborted. Other times, the endpoint (A) might not cont=
inue to send the ACK frame with
 the close, or just not send anything any more at all, resulting in a timeo=
ut on the peer side, also resulting in an abortive closure of the stream. T=
his would probably cause the application protocol to end up creating itR=
17;s own close semantics, on top of QUIC.


 


Now, folks might not think this is a very important =
scenario, but I feel we should aim for consistency here. Perhaps I have mis=
sed a different solution to the problem. I considered a design that always =
sends that last ACK with a PING frame,
 and waits for that to get acknowledged before closing, but I felt it was w=
ay too ugly.


 


Thanks,


- Nick






--_000_DM5PR2101MB090161AA6FD645EFFA1A1EFBB3890DM5PR2101MB0901_--


From nobody Mon Apr 23 15:49:20 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4474126C2F for ; Mon, 23 Apr 2018 15:49:18 -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 jDAf_UejErxw for ; Mon, 23 Apr 2018 15:49:17 -0700 (PDT)
Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A69E124319 for ; Mon, 23 Apr 2018 15:49:13 -0700 (PDT)
Received: by mail-wr0-x243.google.com with SMTP id z73-v6so45502235wrb.0 for ; Mon, 23 Apr 2018 15:49: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=3y9VYEUf4Kalm3ZgEgybYY01yblmXGjje5t5Fd5NqYk=; b=BbpVYagIdstKOxIyEi4r8yr0XncDeeu1Gj9HV26iPu/tLRwNSJ6hmglL1YvT39XpuF 6QetxUXE7u8f0Qu8E753CwtFRClqvfokyJvtSD/WU8dZY5qqrSQOd1QkhIVSYrm1uXUk Xz1ybdacKofUL8wkpUNgCIIuSGqVCZGmE7cBqOgZC3DgITVcofdTOyeUEToqaAerd3Y8 0zzDfnwDkeOdvfNHOMXLCu04IT1bX/F5pv8wBiFytY5X/UliABVJlnOMBct3K7gDwyfV 1o35CArvfx5j2XbqrwxPhPt4LX8AMErYELhoxoRENeImw/7BkSx+Nk1fxR/kEG21VgPp +1pA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=3y9VYEUf4Kalm3ZgEgybYY01yblmXGjje5t5Fd5NqYk=; b=gfDBjUVU9UdaCOPsvPF3wqy3Xh11kJJQ6Vp8GtA4082hCYlJh8WxJ/YstGf5x6kETG uCPlnbcRg0YULyKPYjPx/3SQ1LtSvZhx1vhWrSBIKkvsQ3L5AHJSnR6fPFYv6y/KfAb6 2yaWAQKkxsslG338AnKP1v7gAXR6RcCDWVzdOv/w5K3d0vFqki7URLz5tVpkQu+nN6fx C+Wh4/CeO0WoO8VWX/6bWUaRfoj8NXKSl6xUbkoD0mCKH6YR/PvyllwpyvsQ4IPCbWeZ mJG3bLTkoEiAo4y35NwsxW1eQMzc5k+NhZhIIUJQu3IS8Qj523roT2b3vDpL8B9nI0DB 3yAQ==
X-Gm-Message-State: ALQs6tDmPWBBt0gXF76wPMN1Pa5CEXb7NsPDUCkS3RWGLsAFvxcaRL+S Id2BaIGux4risMq20dNW6gNLCx1J2dfaaRIJQE0=
X-Google-Smtp-Source: AIpwx49xMN22p4izIB+Wx5wYEadmbqI5djIolWZcNeJAVVMG9HS2PEeo5PNDB39qgWP5DH0MJO04FUN214V2rVbU7a8=
X-Received: by 10.28.26.83 with SMTP id a80mr10822299wma.36.1524523751567; Mon, 23 Apr 2018 15:49:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.187.9 with HTTP; Mon, 23 Apr 2018 15:49:11 -0700 (PDT)
In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>
From: Jana Iyengar 
Date: Mon, 23 Apr 2018 15:49:11 -0700
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: "Deval, Manasi" 
Cc: Christian Huitema , Mark Nottingham ,  "quic@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114cce38a9f5c9056a8bd846"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 23 Apr 2018 22:49:19 -0000

--001a114cce38a9f5c9056a8bd846
Content-Type: text/plain; charset="UTF-8"

Thanks for the update, Manasi. In practice, can you state what this small
cost is? Is it the second crypto pass, or are there other deployment costs
that you are thinking about?

On Mon, Apr 23, 2018 at 10:55 AM, Deval, Manasi 
wrote:

> Hi All,
>
> I had brought up the issue with PNE several weeks ago as a barrier to
> hardware offload. After further review, it looks like a hardware offload
> can implement the PNE at a small cost.
>
> The implementation can modify current HW crypto accelerators to support
> encrypting a buffer in the first pass and then encrypting packet number in
> the 2nd pass as already discussed on this thread. The exact requirement
> (header checksum, packet length encoding) is still in flux so there may be
> some small variations depending on the accelerator and final algorithm
> chosen for PNE. Future offload designs can do more to further reduce the
> overhead.
>
> This re-opens the issue of crypto offload in the context of other
> offloads. There is another thread talking about the offload in context of
> segmentation. I'll respond to that thread separately.
>
> Thanks,
> Manasi
>
>
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
> Sent: Wednesday, April 18, 2018 9:38 AM
> To: Mark Nottingham 
> Cc: quic@ietf.org
> Subject: Re: Getting to consensus on packet number encryption
>
>
>
> On 4/18/2018 1:09 AM, Mark Nottingham wrote:
> > Thanks Christian; that's extremely helpful (and considering that I was
> about to embark on the same task, but do a much worse job, I'm especially
> appreciative).
> >
> > Everyone please have a read and direct your comments back here.
> >
> > One aspect that still hasn't been made clear AFAICT -- you say:
> >
> > """The process requires two passes, fetching some output of the
> encryption to seed the PN encryption. This is problematic for hardware
> implementations that typically don't buffer the output for further
> access."""
> >
> > .... and then later:
> >
> > """Single pass, thus mostly implementable in hardware if we assume that
> the PN encryption/decryption can be done in software."""
> >
> > Having a bit more context about the hardware implementation limitations
> here would be extremely helpful. Specifically, is "problematic" one of:
> >
> > * "More difficult for existing hardware (e.g., without firmware updates,
> etc.)"
> > * "Impossible for existing hardware, but possible for bespoke hardware"
> > * "Impossible in any hardware"
> > * Prohibitively expensive for current/future hardware
> > * Something else?
>
> I tried to express the issue in my own words, based on discussions in this
> list. But as I said, this is a Wiki. People with more hands-on experience
> on hardware acceleration would be welcome to add a small section describing
> the issue with hardware implementations.
>
> -- Christian Huitema
>
>

--001a114cce38a9f5c9056a8bd846
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for the update, Manasi. In practice, can you state =
what this small cost is? Is it the second crypto pass, or are there other d=
eployment costs that you are thinking about?

On Mon, Apr 23, 2018 at 10:55 AM, Deval, M=
anasi <manasi.deval@intel.com> wrote:
Hi All,



I had brought up the issue with PNE several weeks ago as a barrier to hardw=
are offload. After further review, it looks like a hardware offload can imp=
lement the PNE at a small cost. 



The implementation can modify current HW crypto accelerators to support enc=
rypting a buffer in the first pass and then encrypting packet number in the=
 2nd pass as already discussed on this thread. The exact requirement (heade=
r checksum, packet length encoding) is still in flux so there may be some s=
mall variations depending on the accelerator and final algorithm chosen for=
 PNE. Future offload designs can do more to further reduce the overhead.


This re-opens the issue of crypto offload in the context of other offloads.=
 There is another thread talking about the offload in context of segmentati=
on. I'll respond to that thread separately.



Thanks,

Manasi





-----Original Message-----

From: QUIC [mailto:quic-bounces@ie=
tf.org] On Behalf Of Christian Huitema

Sent: Wednesday, April 18, 2018 9:38 AM

To: Mark Nottingham <mnot@mnot.net&=
gt;

Cc: quic@=
ietf.org

Subject: Re: Getting to consensus on packet number encryption








On 4/18/2018 1:09 AM, Mark N=
ottingham wrote:

> Thanks Christian; that's extremely helpful (and considering that I=
 was about to embark on the same task, but do a much worse job, I'm esp=
ecially appreciative).

>

> Everyone please have a read and direct your comments back here.

>

> One aspect that still hasn't been made clear AFAICT -- you say:
>

> """The process requires two passes, fetching some outpu=
t of the encryption to seed the PN encryption. This is problematic for hard=
ware implementations that typically don't buffer the output for further=
 access."""

>

> .... and then later:

>

> """Single pass, thus mostly implementable in hardware i=
f we assume that the PN encryption/decryption can be done in software."=
;""

>

> Having a bit more context about the hardware implementation limitation=
s here would be extremely helpful. Specifically, is "problematic"=
 one of:

>

> * "More difficult for existing hardware (e.g., without firmware u=
pdates, etc.)"

> * "Impossible for existing hardware, but possible for bespoke har=
dware"

> * "Impossible in any hardware"

> * Prohibitively expensive for current/future hardware

> * Something else?



I tried to express the issue in my own words, based on discussions in this =
list. But as I said, this is a Wiki. People with more hands-on experience o=
n hardware acceleration would be welcome to add a small section describing =
the issue with hardware implementations.



-- Christian Huitema







--001a114cce38a9f5c9056a8bd846--


From nobody Mon Apr 23 16:22:22 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54274126FDC for ; Mon, 23 Apr 2018 16:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoMWNd6UqcOR for ; Mon, 23 Apr 2018 16:22:18 -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 9BD0A126D85 for ; Mon, 23 Apr 2018 16:22:18 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id q17-v6so1984140ywg.2 for ; Mon, 23 Apr 2018 16:22:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B6IX/YG4+KdhO0Oeq8jmGAPPOKLqmmdeQyWTtrpAJOc=; b=WwYQ4lFRSEimPcCd6ksgJ00uG4VhsfZtUIvRQo+Ix0/5ox2F5fVQad4TZwZSWaE+9z 47svmpTKj14wwbFlBai+2A5bL88MjrH3fBsRt/rjsCuvPw0eFxU0bC2lzM6uNUc+sFSd USSQmRryTl6iuLUCXyjHiFVxeW+HpXX+3CAShZKm7wEKVcnn+Yls+T3iQ6yMfxeG/lkF EJIctGnlRR2+P72aJ0PZTxsQC/4Z7WsqKHEZ4WtkgAiP75VVcd/jYqWJ/yAJ2xP4RGZQ sZ3PaQdV0ImD/e9zLEUeUooSZSKVLwz0PUBtq92g2D0xXm5vYEO3VU9gD3sHCSlWi3eE a29w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B6IX/YG4+KdhO0Oeq8jmGAPPOKLqmmdeQyWTtrpAJOc=; b=fdBtLAEZPTz5bMN2yP3S64SgGXBpptJAgiilchV5x3H5Efr0zmuNiu4JYifa6Nxnhu B2YjuACvLKlZJOEEI1jZmRI6YG09xc+LXNaVaQDAKIstmvC4FY901zb67Hsv9aS30b5k sNIod0y87kgVOY11fzWkzehncRe4JO3rXxF3eUso/yjFTi54hEl4Ekr9MRQVBwqHZ18J GDhzKDeEw+J09gjv2zJM8AvG6ylDTfK3u7s9EVmISnV7TVyXviw2e6LSkjKEPHeaDK/X /MNUSvtMQVzw8ed1VOrwlmlP6Mo2fRj8qXu0eirg9/y4h5FvDfXOoubipBTltfrPV8/Y IDUg==
X-Gm-Message-State: ALQs6tDKvteao136XV1rwtOatNJ00/E42enqluh9pp+ro1JkAozIVqbD iBEZQsOQ25PGExUIXDDY2+haYEfV8GXtH3THLesoCA==
X-Google-Smtp-Source: AIpwx48Rwfl9TwwPHV9JU3md+tWjZuypWxNr/EQeV7toS37P594btJc5aG/jisBLOKdvYsf1GBBYbNdRjplHuIK2jxc=
X-Received: by 2002:a81:32c1:: with SMTP id y184-v6mr11495104ywy.361.1524525737589;  Mon, 23 Apr 2018 16:22:17 -0700 (PDT)
MIME-Version: 1.0
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com> 
In-Reply-To: 
From: Ian Swett 
Date: Mon, 23 Apr 2018 23:22:06 +0000
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Jana Iyengar 
Cc: "Deval, Manasi" , Mark Nottingham ,  IETF QUIC WG , Christian Huitema 
Content-Type: multipart/alternative; boundary="0000000000000ac473056a8c4f06"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 23 Apr 2018 23:22:21 -0000

--0000000000000ac473056a8c4f06
Content-Type: text/plain; charset="UTF-8"

Yes, thanks for the update.

Can you estimate the portion of existing hardware(that supports TCP crypto
offload) which could support crypto offload for QUIC with PNE vs without
PNE?

On Mon, Apr 23, 2018 at 6:49 PM Jana Iyengar  wrote:

> Thanks for the update, Manasi. In practice, can you state what this small
> cost is? Is it the second crypto pass, or are there other deployment costs
> that you are thinking about?
>
> On Mon, Apr 23, 2018 at 10:55 AM, Deval, Manasi 
> wrote:
>
>> Hi All,
>>
>> I had brought up the issue with PNE several weeks ago as a barrier to
>> hardware offload. After further review, it looks like a hardware offload
>> can implement the PNE at a small cost.
>>
>> The implementation can modify current HW crypto accelerators to support
>> encrypting a buffer in the first pass and then encrypting packet number in
>> the 2nd pass as already discussed on this thread. The exact requirement
>> (header checksum, packet length encoding) is still in flux so there may be
>> some small variations depending on the accelerator and final algorithm
>> chosen for PNE. Future offload designs can do more to further reduce the
>> overhead.
>>
>> This re-opens the issue of crypto offload in the context of other
>> offloads. There is another thread talking about the offload in context of
>> segmentation. I'll respond to that thread separately.
>>
>> Thanks,
>> Manasi
>>
>>
>> -----Original Message-----
>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
>> Sent: Wednesday, April 18, 2018 9:38 AM
>> To: Mark Nottingham 
>> Cc: quic@ietf.org
>> Subject: Re: Getting to consensus on packet number encryption
>>
>>
>>
>> On 4/18/2018 1:09 AM, Mark Nottingham wrote:
>> > Thanks Christian; that's extremely helpful (and considering that I was
>> about to embark on the same task, but do a much worse job, I'm especially
>> appreciative).
>> >
>> > Everyone please have a read and direct your comments back here.
>> >
>> > One aspect that still hasn't been made clear AFAICT -- you say:
>> >
>> > """The process requires two passes, fetching some output of the
>> encryption to seed the PN encryption. This is problematic for hardware
>> implementations that typically don't buffer the output for further
>> access."""
>> >
>> > .... and then later:
>> >
>> > """Single pass, thus mostly implementable in hardware if we assume that
>> the PN encryption/decryption can be done in software."""
>> >
>> > Having a bit more context about the hardware implementation limitations
>> here would be extremely helpful. Specifically, is "problematic" one of:
>> >
>> > * "More difficult for existing hardware (e.g., without firmware
>> updates, etc.)"
>> > * "Impossible for existing hardware, but possible for bespoke hardware"
>> > * "Impossible in any hardware"
>> > * Prohibitively expensive for current/future hardware
>> > * Something else?
>>
>> I tried to express the issue in my own words, based on discussions in
>> this list. But as I said, this is a Wiki. People with more hands-on
>> experience on hardware acceleration would be welcome to add a small section
>> describing the issue with hardware implementations.
>>
>> -- Christian Huitema
>>
>>
>

--0000000000000ac473056a8c4f06
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yes, thanks for the update.

Can you=
 estimate the portion of existing hardware(that supports TCP crypto offload=
) which could support crypto offload for QUIC with PNE vs without PNE?

On Mon, Apr 23, 2018=
 at 6:49 PM Jana Iyengar <jri.ietf=
@gmail.com> wrote:
Thanks for the update, Manasi. In practice, can you state what thi=
s small cost is? Is it the second crypto pass, or are there other deploymen=
t costs that you are thinking about?

On Mon, Apr 23, 2018 at 10:55 AM, Deval, Manasi <manasi.deval@intel.com> wrote:
Hi All,



I had brought up the issue with PNE several weeks ago as a barrier to hardw=
are offload. After further review, it looks like a hardware offload can imp=
lement the PNE at a small cost. 



The implementation can modify current HW crypto accelerators to support enc=
rypting a buffer in the first pass and then encrypting packet number in the=
 2nd pass as already discussed on this thread. The exact requirement (heade=
r checksum, packet length encoding) is still in flux so there may be some s=
mall variations depending on the accelerator and final algorithm chosen for=
 PNE. Future offload designs can do more to further reduce the overhead.


This re-opens the issue of crypto offload in the context of other offloads.=
 There is another thread talking about the offload in context of segmentati=
on. I'll respond to that thread separately.



Thanks,

Manasi





-----Original Message-----

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema

Sent: Wednesday, April 18, 2018 9:38 AM

To: Mark Nottingham <=
mnot@mnot.net>

quic@ietf.org<=
br>
Subject: Re: Getting to consensus on packet number encryption








On 4/18/2018 1:09 AM, Mark Nottingham wrote:

> Thanks Christian; that's extremely helpful (and considering that I=
 was about to embark on the same task, but do a much worse job, I'm esp=
ecially appreciative).

>

> Everyone please have a read and direct your comments back here.

>

> One aspect that still hasn't been made clear AFAICT -- you say:
>

> """The process requires two passes, fetching some outpu=
t of the encryption to seed the PN encryption. This is problematic for hard=
ware implementations that typically don't buffer the output for further=
 access."""

>

> .... and then later:

>

> """Single pass, thus mostly implementable in hardware i=
f we assume that the PN encryption/decryption can be done in software."=
;""

>

> Having a bit more context about the hardware implementation limitation=
s here would be extremely helpful. Specifically, is "problematic"=
 one of:

>

> * "More difficult for existing hardware (e.g., without firmware u=
pdates, etc.)"

> * "Impossible for existing hardware, but possible for bespoke har=
dware"

> * "Impossible in any hardware"

> * Prohibitively expensive for current/future hardware

> * Something else?



I tried to express the issue in my own words, based on discussions in this =
list. But as I said, this is a Wiki. People with more hands-on experience o=
n hardware acceleration would be welcome to add a small section describing =
the issue with hardware implementations.



-- Christian Huitema









--0000000000000ac473056a8c4f06--


From nobody Mon Apr 23 18:16:23 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008CE12E034 for ; Mon, 23 Apr 2018 18:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g25K7F-0Xyzj for ; Mon, 23 Apr 2018 18:16:20 -0700 (PDT)
Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919E012DFE0 for ; Mon, 23 Apr 2018 18:16:19 -0700 (PDT)
Received: by mail-wr0-x244.google.com with SMTP id v60-v6so46021798wrc.7 for ; Mon, 23 Apr 2018 18:16:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gc3uISuhiv6dYDHQm+KnYRxPQqlEgOvaxtA8tkE75ys=; b=OcD+GhShmdRlqdEIJxxxvQ58JQMrTHwhKEAxhgWEaxmi3E5mIcf4TgmjEGcWWruLEj 6yp0UFQv0MA+vIeXrZkDVWUZ29BVRmhD5n0CggeRFA5WTR3cSALDiIyxiFTaDUqu0cWi ak2E/4fDE9orFcTMTuPLUCl06Es8ENCeTgFQa5ZitheFMuZ/90URX4g9yphRBwwU0/OI HXZJ/s1KcU/Y+7mkW8kyFxfVysNCC55cz0wUyaSf9B0E6TwhTatcPtE56bA5KdIgYzTP fIhVjzLRUf9IQrwvBpiYBaZpJdSyJGo8GLp40xf/e9Qyd5mFS8wO681H4AFTo/4Gmr4f Lvgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=gc3uISuhiv6dYDHQm+KnYRxPQqlEgOvaxtA8tkE75ys=; b=HiLtKhW+SBnNTr6058/62Q19F5QHiFS1LdA15yWRiLFzldMIpONyqXDqx+TyI8IlpH GhEF+UZH6T85AvJTT5SNoz+DFWzkcBWT/pk82oFpYtmoFKllQROHsK24OxgwHUJPdxNE fMVKtkcCNq3N54xLTEN7H2G25jmIT44NK3oUis4sa5IEtEMr7rTM/p6ULSSwLq/W+wXv /gK30ob1UEMSjlJuSOfO5bXrDJDG79I5PQ4BhhsB9LwaXc98RKnGcna+O4yK9UMjwHLa re/rb/ekTHgctguaZZGG3P8XsZ/6dfb9qnErnfG2th9n0W9TpXA5aRePy/xGQzt2veer o6IQ==
X-Gm-Message-State: ALQs6tBM2/W2pIhzaURPOTmvrpPWd4+rT7Y/85JW/+gJ/PqAKhJqEdE5 o0cKRUMx/TeZvQBbfRYxTDPi0ZoTp5x7kvVnU5E=
X-Google-Smtp-Source: AIpwx4/20p8uCbVAlMM0XNPznMp4W7aW/0MuhcHsdNy98y6qaxpBJnYiD2kGYiEtpR2iGrkzeKbZMYLZDj5seUYcJeQ=
X-Received: by 2002:adf:a4da:: with SMTP id h26-v6mr17726414wrb.164.1524532578106;  Mon, 23 Apr 2018 18:16:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.187.9 with HTTP; Mon, 23 Apr 2018 18:16:17 -0700 (PDT)
In-Reply-To: 
References:        <1F436ED13A22A246A59CA374CBC543998B60C7AD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B60C851@ORSMSX111.amr.corp.intel.com>     
From: Jana Iyengar 
Date: Mon, 23 Apr 2018 18:16:17 -0700
Message-ID: 
Subject: Re: Impact of hardware offloads on network stack performance
To: Watson Ladd 
Cc: Mike Bishop , Praveen Balasubramanian ,  "Lubashev, Igor" , Ian Swett ,  =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= ,  IETF QUIC WG , "Deval, Manasi" 
Content-Type: multipart/alternative; boundary="000000000000c44264056a8de634"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 24 Apr 2018 01:16:22 -0000

--000000000000c44264056a8de634
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'll echo the concern that there should not be partial segments at all.

One key difference between designing TCP and QUIC segmentation will be that
QUIC packets are not as fluid as TCP, since QUIC isn't a byte stream.
You'll need to respect the packet boundaries that the encryption is done
over... I would want a segmentation offload interface for QUIC to support
variable packet sizes, since there's no guarantee that any QUIC packet
boundary will exactly match the max MTU.  (I could be wrong but I don't
think Willem's patch does this yet either.)

On Mon, Apr 23, 2018 at 1:55 PM, Watson Ladd  wrote:

>
>
> On Mon, Apr 23, 2018 at 1:06 PM, Mike Bishop  wrote=
:
>
>> I agree =E2=80=93 the point of offloading the crypto is not only to spar=
e that
>> cost on the CPU, though that can be useful, it=E2=80=99s to enable furth=
er offloads
>> that can=E2=80=99t be done on the encrypted packet.
>>
>>
>>
>> LRO that could simply group packets by CID and deliver a single batch of
>> packets from a single CID in a single invocation seems like a great firs=
t
>> step, and doesn=E2=80=99t even require crypto offload.  Once you have cr=
ypto
>> offload, of course those packets per CID could be delivered already
>> decrypted.  I=E2=80=99d want to see data on whether there=E2=80=99s valu=
e in making the
>> received data look like one huge packet when there=E2=80=99s not a singl=
e
>> bytestream, but that=E2=80=99s not something we need to specify here.
>>
>>
>>
>> LSO is more interesting, and the challenge there is that the transport
>> stack still needs to know what data was in which packet so that it can d=
o
>> loss recovery properly.  QUIC explicitly disallows fragmentation of the =
UDP
>> datagram, for the =E2=80=9Cpainful and potentially non-deterministic=E2=
=80=9D reasons
>> you referenced.
>>
>
> Forgive my complete ignorance, but doesn't it just need to know what
> packet it sent?
>
> More explicitly the sender would maintain a queue of sendable packets, an=
d
> mark which have been sent. Acknowledged packets are removed from the queu=
e.
> In event of loss, they simply retransmit the same packet. It's up to high=
er
> layers to pick the right size of packet and take data from the individual
> QUIC streams. If you wanted to expose the stream structure, that sounds a
> lot more complicated.
>
> Sincerely,
> Watson
>
>
>

--000000000000c44264056a8de634
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'll echo the concern that there should not be partial=
 segments at all.=C2=A0

One key difference between desig=
ning TCP and QUIC segmentation will be that QUIC packets are not as fluid a=
s TCP, since QUIC isn't a byte stream. You'll need to respect the p=
acket boundaries that the encryption is done over... I would want a segment=
ation offload interface for QUIC to support variable packet sizes, since th=
ere's no guarantee that any QUIC packet boundary will exactly match the=
 max MTU.=C2=A0 (I could be wrong but I don't think Willem's patch =
does this yet either.)

On Mon, Apr 23, 2018 at 1:55 PM, Watson Ladd <watsonb=
ladd@gmail.com> wrote:


=
On Mon, Apr 23, 2018 at 1:06 PM, Mike Bishop <mbishop@=
evequefou.be> wrote:











I agree =E2=80=93 the point of offloading the crypto=
 is not only to spare that cost on the CPU, though that can be useful, it=
=E2=80=99s to enable further offloads that can=E2=80=99t be done on the enc=
rypted packet.


=C2=A0


LRO that could simply group packets by CID and deliv=
er a single batch of packets from a single CID in a single invocation seems=
 like a great first step, and doesn=E2=80=99t even require crypto offload.=
=C2=A0 Once you have crypto offload, of course those
 packets per CID could be delivered already decrypted.=C2=A0 I=E2=80=99d wa=
nt to see data on whether there=E2=80=99s value in making the received data=
 look like one huge packet when there=E2=80=99s not a single bytestream, bu=
t that=E2=80=99s not something we need to specify here.


=C2=A0


LSO is more interesting, and the challenge there is =
that the transport stack still needs to know what data was in which packet =
so that it can do loss recovery properly.=C2=A0 QUIC explicitly disallows f=
ragmentation of the UDP datagram, for the
 =E2=80=9Cpainful and potentially non-determi=
nistic=E2=80=9D reasons you referenced.
=


Forgive my complete ignorance, but doesn't i=
t just need to know what packet it sent?

More explicitly the sender =
would maintain a queue of sendable packets, and mark which have been sent. =
Acknowledged packets are removed from the queue. In event of loss, they sim=
ply retransmit the same packet. It's up to higher layers to pick the ri=
ght size of packet and take data from the individual QUIC streams. If you w=
anted to expose the stream structure, that sounds a lot more complicated.

Sincerely,
Watson









--000000000000c44264056a8de634--


From nobody Mon Apr 23 19:53:44 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0B612E040 for ; Mon, 23 Apr 2018 19:53:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFi8u4aUkTGn for ; Mon, 23 Apr 2018 19:53:41 -0700 (PDT)
Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098F612706D for ; Mon, 23 Apr 2018 19:53:40 -0700 (PDT)
Received: by mail-pg0-x241.google.com with SMTP id e9so9741765pgr.7 for ; Mon, 23 Apr 2018 19:53:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HmyNFDkQT+jb2aCwrmfYr8LX3Bi7yy1XNsLk+E6aTos=; b=YoMhS3Agr2m5f+3cp3KD8bGWXGGRhNURXGBKIkoU8SYGnTSvpigkeZdKDTHNkeew8i Y/rjsB1TcN0WIsJvaF0X5zPGxPyCjfRi4Ab4jFixnSrXC3d4D8+bX1h62nJw3cVb5/ih tGFpmpE3zaWTTu5AA4c/p4dfnZLranCG7FkGixInH6ZPMoO3CgbpUWF9eFKvhkYLUQl2 aDGJ66VoDAcOt3W3Kw6LaVPbzvEUMyty5t8QsLxL/cQgaS4mF+kNLFfTMdW8iVihJpIL Okfuet9SQkIqa8A1l/jwZtrcGHw6Gxby8feIcrOeSOfw4BKXobQ6XXVMoxTcfDk3r+pw XG3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=HmyNFDkQT+jb2aCwrmfYr8LX3Bi7yy1XNsLk+E6aTos=; b=C1Chd4RaPjnERKT5Y/3Rj1aUcQJCbKgfTWj24MX4xSM5FHWbjDU6jXHANagRNGNDq3 vGkgbOM+Fw8vBUd7sbRCP5QaE/Hg/EhwJMbFkGGdlbA9wrWur+mDQwYBzC4A9B1nLj7E KDFc2nPWR2YvBe1Z9JkGfEoHwx1JjDrgO2Km+KEqz+sNNBi6q8PeF/rnalWAukk8Ym1d 08zfflbHyj+XJ9kzZ6KRjNxaH3xGDKZh8DsjJjZVTQPsvEPQpolIcZN6KLTHLRRgVnvg Dvn/g6lYi2ZodA39hhUrbEhaKJPfCurFQAIjzQ//WuPDfMvJuUo0A0kp5nX/TyBToVpy 8WAg==
X-Gm-Message-State: ALQs6tBL+DJ8oMUVy0EJ/XijQtDtFSl6rqLUf9GkL2lpSqHeefYeOZAO 6hZEYBIj7QU17CI6RAfxq2vmtdhbfQJczlk+gLs=
X-Google-Smtp-Source: AIpwx498SnApOvj3mbioHUCNmMnZWI4cuNRVW3CpYKT/g4rNIDaB5Jl4JR9XVz1j+w1554XaiAvwFC4XGklafybaXDE=
X-Received: by 2002:a17:902:14cb:: with SMTP id y11-v6mr23135569plg.23.1524538420257;  Mon, 23 Apr 2018 19:53:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Mon, 23 Apr 2018 19:53:39 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>  
From: Kazuho Oku 
Date: Tue, 24 Apr 2018 11:53:39 +0900
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Ian Swett 
Cc: Jana Iyengar , Mark Nottingham , IETF QUIC WG ,  Christian Huitema , "Deval, Manasi" , antoine@delignat-lavaud.fr
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, 24 Apr 2018 02:53:43 -0000

Manasi, thank you for the update.

In addition to the points that Jana and Ian made, it would be great if
you could provide us some estimation on if using different keys for PN
encryption and payload encryption affects HW offload performance /
portion of existing hardware that can support this form of encryption.

On https://github.com/quicwg/base-drafts/pull/1079#issuecomment-382007477,
Antoine has recently suggested that the PNE scheme proposed in #1079
can be tweaked to use the same key for encrypting the PN and the
payload (they will use same key but different nonces).

This is minor to the points made by Jana and Ian, but I think it would
be something good to know to make a decision.

2018-04-24 8:22 GMT+09:00 Ian Swett :
> Yes, thanks for the update.
>
> Can you estimate the portion of existing hardware(that supports TCP crypto
> offload) which could support crypto offload for QUIC with PNE vs without
> PNE?
>
> On Mon, Apr 23, 2018 at 6:49 PM Jana Iyengar  wrote:
>>
>> Thanks for the update, Manasi. In practice, can you state what this small
>> cost is? Is it the second crypto pass, or are there other deployment costs
>> that you are thinking about?
>>
>> On Mon, Apr 23, 2018 at 10:55 AM, Deval, Manasi 
>> wrote:
>>>
>>> Hi All,
>>>
>>> I had brought up the issue with PNE several weeks ago as a barrier to
>>> hardware offload. After further review, it looks like a hardware offload can
>>> implement the PNE at a small cost.
>>>
>>> The implementation can modify current HW crypto accelerators to support
>>> encrypting a buffer in the first pass and then encrypting packet number in
>>> the 2nd pass as already discussed on this thread. The exact requirement
>>> (header checksum, packet length encoding) is still in flux so there may be
>>> some small variations depending on the accelerator and final algorithm
>>> chosen for PNE. Future offload designs can do more to further reduce the
>>> overhead.
>>>
>>> This re-opens the issue of crypto offload in the context of other
>>> offloads. There is another thread talking about the offload in context of
>>> segmentation. I'll respond to that thread separately.
>>>
>>> Thanks,
>>> Manasi
>>>
>>>
>>> -----Original Message-----
>>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
>>> Sent: Wednesday, April 18, 2018 9:38 AM
>>> To: Mark Nottingham 
>>> Cc: quic@ietf.org
>>> Subject: Re: Getting to consensus on packet number encryption
>>>
>>>
>>>
>>> On 4/18/2018 1:09 AM, Mark Nottingham wrote:
>>> > Thanks Christian; that's extremely helpful (and considering that I was
>>> > about to embark on the same task, but do a much worse job, I'm especially
>>> > appreciative).
>>> >
>>> > Everyone please have a read and direct your comments back here.
>>> >
>>> > One aspect that still hasn't been made clear AFAICT -- you say:
>>> >
>>> > """The process requires two passes, fetching some output of the
>>> > encryption to seed the PN encryption. This is problematic for hardware
>>> > implementations that typically don't buffer the output for further
>>> > access."""
>>> >
>>> > .... and then later:
>>> >
>>> > """Single pass, thus mostly implementable in hardware if we assume that
>>> > the PN encryption/decryption can be done in software."""
>>> >
>>> > Having a bit more context about the hardware implementation limitations
>>> > here would be extremely helpful. Specifically, is "problematic" one of:
>>> >
>>> > * "More difficult for existing hardware (e.g., without firmware
>>> > updates, etc.)"
>>> > * "Impossible for existing hardware, but possible for bespoke hardware"
>>> > * "Impossible in any hardware"
>>> > * Prohibitively expensive for current/future hardware
>>> > * Something else?
>>>
>>> I tried to express the issue in my own words, based on discussions in
>>> this list. But as I said, this is a Wiki. People with more hands-on
>>> experience on hardware acceleration would be welcome to add a small section
>>> describing the issue with hardware implementations.
>>>
>>> -- Christian Huitema
>>>
>>
>



-- 
Kazuho Oku


From nobody Tue Apr 24 09:28:59 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E75E12D77B for ; Tue, 24 Apr 2018 09:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=evequefou.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbEvci27S0D5 for ; Tue, 24 Apr 2018 09:28:54 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4F312702E for ; Tue, 24 Apr 2018 09:28:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+8WjPrB63XbFidZ2zxZ2aH6RUZnkc2Bjb/qKaULwjI8=; b=hqWVJTh79dg3C522JdTsF3UXlz56X0mg+oICGMBTJEWJj/y7cTFEvwPuVSLv/te/zkFh+3JDSg/gxjbUb3pPL7nc/z4ZK4yFq1DCcIvs9ev744OyPXTHWvxdJlNQpa89SWeaedVxz3MkXcQS7wcooJAOUt0xMF7RkeLag90TWRM=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1744.namprd08.prod.outlook.com (10.162.133.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.15; Tue, 24 Apr 2018 16:28:50 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::dd26:af46:4549:f472]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::dd26:af46:4549:f472%13]) with mapi id 15.20.0696.019; Tue, 24 Apr 2018 16:28:50 +0000
From: Mike Bishop 
To: Watson Ladd 
CC: "Lubashev, Igor" , Ian Swett , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Praveen Balasubramanian , IETF QUIC WG , "Deval, Manasi" 
Subject: RE: Impact of hardware offloads on network stack performance
Thread-Topic: Impact of hardware offloads on network stack performance
Thread-Index: AdPMUbL7T8nZAW2ySiO289IPTC0ttgAApm4AADSbFZAACUWYgAAFkLQAACA3b/AAAajkgANRfL2AAAA3SQAAAHMwgAAAR/kAAAEuygAAAJMTgAAAxh6AAAICTwAAKOV38A==
Date: Tue, 24 Apr 2018 16:28:50 +0000
Message-ID: 
References:        <1F436ED13A22A246A59CA374CBC543998B60C7AD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B60C851@ORSMSX111.amr.corp.intel.com>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; 
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1744; 7:vTGDtddGS2XjOxe3x2gqRoBA/jG5GeFWkQeJcAraNnyjMFLnc1CuO57k2/KbfUNhEPw7PKzZ5R/pZKoXlJe61yozsBG96t5q0qNetTCjGaycgZYCXXGAwD78GwGOctv64+Xz1O8gb5y1so8ZUg5eUGEXOaPqn3k4z3KFYpadkApkEevjdV+pPfVMnyk6HDYwemkPDabbUozCU4e2mCaX33nWJ/kzBhbRagtoiZlYNkR5kHKyOuWBLJRmAjX8SD02
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1744; 
x-ms-traffictypediagnostic: SN1PR08MB1744:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(21748063052155)(266576461109395)(228905959029699);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231232)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6041310)(20161123562045)(20161123558120)(20161123564045)(2016111802025)(20161123560045)(6043046)(6072148)(201708071742011); SRVR:SN1PR08MB1744; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1744; 
x-forefront-prvs: 0652EA5565
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39830400003)(366004)(39380400002)(189003)(199004)(26005)(3660700001)(81156014)(86362001)(81166006)(8676002)(8936002)(6436002)(74316002)(7736002)(55016002)(105586002)(6246003)(8666007)(6306002)(9686003)(2906002)(6916009)(19609705001)(33656002)(5660300001)(316002)(229853002)(3280700002)(39060400002)(53936002)(97736004)(236005)(54896002)(54906003)(106356001)(25786009)(11346002)(476003)(93886005)(102836004)(53546011)(2900100001)(4326008)(45080400002)(446003)(478600001)(6506007)(14454004)(76176011)(6116002)(74482002)(3846002)(790700001)(66066001)(5250100002)(68736007)(1411001)(99286004)(186003)(7696005)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1744; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: aiLKplXOvzvhcn4DHI/LXttYHcD+AfF+v2+uza0JS/NLUDqoJNzZKbKZ5qYCNFJ43f1oDfgTuFy6EUgfm3N7mSZEE+TgR/fogB1h28TmjwWh62ln6gBKrJCwt5L2kWlQ9s4U/wCafTKTGbrxPtuddCAh40z4HcUVyrZozSuhg2XTPehaamVAvh9DOZm8tIKC
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR08MB1854A941E8A703913ECBE821DA880SN1PR08MB1854namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 8958b7dd-71c9-4008-cee4-08d5aa007645
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 8958b7dd-71c9-4008-cee4-08d5aa007645
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2018 16:28:50.1457 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1744
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 24 Apr 2018 16:28:57 -0000

--_000_SN1PR08MB1854A941E8A703913ECBE821DA880SN1PR08MB1854namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

WWVzLCB0aGF0IHdvdWxkIGJlIHN1ZmZpY2llbnQuICBNeSBwb2ludCBpcyB0aGF0IHRoZSBvZmZs
b2FkIHByb2JhYmx5IG5lZWRzIHRvIGxlYXZlIHBhY2tldGl6YXRpb24gdG8gdGhlIHNvZnR3YXJl
IGFuZCBub3QgYXR0ZW1wdCB0byBwYXJjZWwgdGhlbSBvdXQgYXMgcGFydCBvZiB0aGUgb2ZmbG9h
ZC4NCg0KRnJvbTogV2F0c29uIExhZGQgW21haWx0bzp3YXRzb25ibGFkZEBnbWFpbC5jb21dDQpT
ZW50OiBNb25kYXksIEFwcmlsIDIzLCAyMDE4IDE6NTYgUE0NClRvOiBNaWtlIEJpc2hvcCA8bWJp
c2hvcEBldmVxdWVmb3UuYmU+DQpDYzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5j
b20+OyBJYW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz47IE1p
a2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT47IFByYXZlZW4gQmFs
YXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGll
dGYub3JnPjsgRGV2YWwsIE1hbmFzaSA8bWFuYXNpLmRldmFsQGludGVsLmNvbT4NClN1YmplY3Q6
IFJlOiBJbXBhY3Qgb2YgaGFyZHdhcmUgb2ZmbG9hZHMgb24gbmV0d29yayBzdGFjayBwZXJmb3Jt
YW5jZQ0KDQoNCg0KT24gTW9uLCBBcHIgMjMsIDIwMTggYXQgMTowNiBQTSwgTWlrZSBCaXNob3Ag
PG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+IHdyb3Rl
Og0KSSBhZ3JlZSDigJMgdGhlIHBvaW50IG9mIG9mZmxvYWRpbmcgdGhlIGNyeXB0byBpcyBub3Qg
b25seSB0byBzcGFyZSB0aGF0IGNvc3Qgb24gdGhlIENQVSwgdGhvdWdoIHRoYXQgY2FuIGJlIHVz
ZWZ1bCwgaXTigJlzIHRvIGVuYWJsZSBmdXJ0aGVyIG9mZmxvYWRzIHRoYXQgY2Fu4oCZdCBiZSBk
b25lIG9uIHRoZSBlbmNyeXB0ZWQgcGFja2V0Lg0KDQpMUk8gdGhhdCBjb3VsZCBzaW1wbHkgZ3Jv
dXAgcGFja2V0cyBieSBDSUQgYW5kIGRlbGl2ZXIgYSBzaW5nbGUgYmF0Y2ggb2YgcGFja2V0cyBm
cm9tIGEgc2luZ2xlIENJRCBpbiBhIHNpbmdsZSBpbnZvY2F0aW9uIHNlZW1zIGxpa2UgYSBncmVh
dCBmaXJzdCBzdGVwLCBhbmQgZG9lc27igJl0IGV2ZW4gcmVxdWlyZSBjcnlwdG8gb2ZmbG9hZC4g
IE9uY2UgeW91IGhhdmUgY3J5cHRvIG9mZmxvYWQsIG9mIGNvdXJzZSB0aG9zZSBwYWNrZXRzIHBl
ciBDSUQgY291bGQgYmUgZGVsaXZlcmVkIGFscmVhZHkgZGVjcnlwdGVkLiAgSeKAmWQgd2FudCB0
byBzZWUgZGF0YSBvbiB3aGV0aGVyIHRoZXJl4oCZcyB2YWx1ZSBpbiBtYWtpbmcgdGhlIHJlY2Vp
dmVkIGRhdGEgbG9vayBsaWtlIG9uZSBodWdlIHBhY2tldCB3aGVuIHRoZXJl4oCZcyBub3QgYSBz
aW5nbGUgYnl0ZXN0cmVhbSwgYnV0IHRoYXTigJlzIG5vdCBzb21ldGhpbmcgd2UgbmVlZCB0byBz
cGVjaWZ5IGhlcmUuDQoNCkxTTyBpcyBtb3JlIGludGVyZXN0aW5nLCBhbmQgdGhlIGNoYWxsZW5n
ZSB0aGVyZSBpcyB0aGF0IHRoZSB0cmFuc3BvcnQgc3RhY2sgc3RpbGwgbmVlZHMgdG8ga25vdyB3
aGF0IGRhdGEgd2FzIGluIHdoaWNoIHBhY2tldCBzbyB0aGF0IGl0IGNhbiBkbyBsb3NzIHJlY292
ZXJ5IHByb3Blcmx5LiAgUVVJQyBleHBsaWNpdGx5IGRpc2FsbG93cyBmcmFnbWVudGF0aW9uIG9m
IHRoZSBVRFAgZGF0YWdyYW0sIGZvciB0aGUg4oCccGFpbmZ1bCBhbmQgcG90ZW50aWFsbHkgbm9u
LWRldGVybWluaXN0aWPigJ0gcmVhc29ucyB5b3UgcmVmZXJlbmNlZC4NCg0KRm9yZ2l2ZSBteSBj
b21wbGV0ZSBpZ25vcmFuY2UsIGJ1dCBkb2Vzbid0IGl0IGp1c3QgbmVlZCB0byBrbm93IHdoYXQg
cGFja2V0IGl0IHNlbnQ/DQoNCk1vcmUgZXhwbGljaXRseSB0aGUgc2VuZGVyIHdvdWxkIG1haW50
YWluIGEgcXVldWUgb2Ygc2VuZGFibGUgcGFja2V0cywgYW5kIG1hcmsgd2hpY2ggaGF2ZSBiZWVu
IHNlbnQuIEFja25vd2xlZGdlZCBwYWNrZXRzIGFyZSByZW1vdmVkIGZyb20gdGhlIHF1ZXVlLiBJ
biBldmVudCBvZiBsb3NzLCB0aGV5IHNpbXBseSByZXRyYW5zbWl0IHRoZSBzYW1lIHBhY2tldC4g
SXQncyB1cCB0byBoaWdoZXIgbGF5ZXJzIHRvIHBpY2sgdGhlIHJpZ2h0IHNpemUgb2YgcGFja2V0
IGFuZCB0YWtlIGRhdGEgZnJvbSB0aGUgaW5kaXZpZHVhbCBRVUlDIHN0cmVhbXMuIElmIHlvdSB3
YW50ZWQgdG8gZXhwb3NlIHRoZSBzdHJlYW0gc3RydWN0dXJlLCB0aGF0IHNvdW5kcyBhIGxvdCBt
b3JlIGNvbXBsaWNhdGVkLg0KDQpTaW5jZXJlbHksDQpXYXRzb24NCg0KDQo=

--_000_SN1PR08MB1854A941E8A703913ECBE821DA880SN1PR08MB1854namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Z
ZXMsIHRoYXQgd291bGQgYmUgc3VmZmljaWVudC4mbmJzcDsgTXkgcG9pbnQgaXMgdGhhdCB0aGUg
b2ZmbG9hZCBwcm9iYWJseSBuZWVkcyB0byBsZWF2ZSBwYWNrZXRpemF0aW9uIHRvIHRoZSBzb2Z0
d2FyZSBhbmQgbm90IGF0dGVtcHQgdG8gcGFyY2VsIHRoZW0gb3V0IGFzIHBhcnQgb2YgdGhlIG9m
ZmxvYWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBXYXRzb24gTGFkZCBb
bWFpbHRvOndhdHNvbmJsYWRkQGdtYWlsLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwg
QXByaWwgMjMsIDIwMTggMTo1NiBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0O21i
aXNob3BAZXZlcXVlZm91LmJlJmd0Ozxicj4NCjxiPkNjOjwvYj4gTHViYXNoZXYsIElnb3IgJmx0
O2lsdWJhc2hlQGFrYW1haS5jb20mZ3Q7OyBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0PTQwZ29vZ2xl
LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs7IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0O21p
a2tlbGZqQGdtYWlsLmNvbSZndDs7IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBt
aWNyb3NvZnQuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgRGV2
YWwsIE1hbmFzaSAmbHQ7bWFuYXNpLmRldmFsQGludGVsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUmU6IEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBl
cmZvcm1hbmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEFwciAyMywgMjAxOCBhdCAxOjA2
IFBNLCBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJl
IiB0YXJnZXQ9Il9ibGFuayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0OyB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6
NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+SSBhZ3JlZSDigJMgdGhlIHBvaW50IG9mIG9mZmxvYWRpbmcgdGhlIGNyeXB0byBpcyBu
b3Qgb25seSB0byBzcGFyZSB0aGF0IGNvc3Qgb24gdGhlIENQVSwgdGhvdWdoIHRoYXQgY2FuIGJl
IHVzZWZ1bCwgaXTigJlzIHRvIGVuYWJsZSBmdXJ0aGVyIG9mZmxvYWRzIHRoYXQgY2Fu4oCZdCBi
ZSBkb25lIG9uIHRoZSBlbmNyeXB0ZWQNCiBwYWNrZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5MUk8gdGhhdCBjb3VsZCBzaW1wbHkgZ3JvdXAgcGFja2V0cyBieSBDSUQgYW5kIGRlbGl2
ZXIgYSBzaW5nbGUgYmF0Y2ggb2YgcGFja2V0cyBmcm9tIGEgc2luZ2xlIENJRCBpbiBhIHNpbmds
ZSBpbnZvY2F0aW9uIHNlZW1zIGxpa2UgYSBncmVhdCBmaXJzdCBzdGVwLCBhbmQgZG9lc27igJl0
IGV2ZW4gcmVxdWlyZQ0KIGNyeXB0byBvZmZsb2FkLiZuYnNwOyBPbmNlIHlvdSBoYXZlIGNyeXB0
byBvZmZsb2FkLCBvZiBjb3Vyc2UgdGhvc2UgcGFja2V0cyBwZXIgQ0lEIGNvdWxkIGJlIGRlbGl2
ZXJlZCBhbHJlYWR5IGRlY3J5cHRlZC4mbmJzcDsgSeKAmWQgd2FudCB0byBzZWUgZGF0YSBvbiB3
aGV0aGVyIHRoZXJl4oCZcyB2YWx1ZSBpbiBtYWtpbmcgdGhlIHJlY2VpdmVkIGRhdGEgbG9vayBs
aWtlIG9uZSBodWdlIHBhY2tldCB3aGVuIHRoZXJl4oCZcyBub3QgYSBzaW5nbGUgYnl0ZXN0cmVh
bSwNCiBidXQgdGhhdOKAmXMgbm90IHNvbWV0aGluZyB3ZSBuZWVkIHRvIHNwZWNpZnkgaGVyZS48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkxTTyBpcyBtb3JlIGludGVyZXN0aW5nLCBhbmQg
dGhlIGNoYWxsZW5nZSB0aGVyZSBpcyB0aGF0IHRoZSB0cmFuc3BvcnQgc3RhY2sgc3RpbGwgbmVl
ZHMgdG8ga25vdyB3aGF0IGRhdGEgd2FzIGluIHdoaWNoIHBhY2tldCBzbyB0aGF0IGl0IGNhbiBk
byBsb3NzIHJlY292ZXJ5IHByb3Blcmx5LiZuYnNwOyBRVUlDIGV4cGxpY2l0bHkNCiBkaXNhbGxv
d3MgZnJhZ21lbnRhdGlvbiBvZiB0aGUgVURQIGRhdGFncmFtLCBmb3IgdGhlIOKAnDxzcGFuIHN0
eWxlPSJjb2xvcjojMUY0OTdEIj5wYWluZnVsIGFuZCBwb3RlbnRpYWxseSBub24tZGV0ZXJtaW5p
c3RpYzwvc3Bhbj7igJ0gcmVhc29ucyB5b3UgcmVmZXJlbmNlZC48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5Gb3JnaXZlIG15IGNvbXBsZXRlIGlnbm9yYW5jZSwgYnV0IGRvZXNuJ3QgaXQganVzdCBuZWVk
IHRvIGtub3cgd2hhdCBwYWNrZXQgaXQgc2VudD88YnI+DQo8YnI+DQpNb3JlIGV4cGxpY2l0bHkg
dGhlIHNlbmRlciB3b3VsZCBtYWludGFpbiBhIHF1ZXVlIG9mIHNlbmRhYmxlIHBhY2tldHMsIGFu
ZCBtYXJrIHdoaWNoIGhhdmUgYmVlbiBzZW50LiBBY2tub3dsZWRnZWQgcGFja2V0cyBhcmUgcmVt
b3ZlZCBmcm9tIHRoZSBxdWV1ZS4gSW4gZXZlbnQgb2YgbG9zcywgdGhleSBzaW1wbHkgcmV0cmFu
c21pdCB0aGUgc2FtZSBwYWNrZXQuIEl0J3MgdXAgdG8gaGlnaGVyIGxheWVycyB0byBwaWNrIHRo
ZSByaWdodCBzaXplDQogb2YgcGFja2V0IGFuZCB0YWtlIGRhdGEgZnJvbSB0aGUgaW5kaXZpZHVh
bCBRVUlDIHN0cmVhbXMuIElmIHlvdSB3YW50ZWQgdG8gZXhwb3NlIHRoZSBzdHJlYW0gc3RydWN0
dXJlLCB0aGF0IHNvdW5kcyBhIGxvdCBtb3JlIGNvbXBsaWNhdGVkLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KU2luY2VyZWx5LDxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2F0c29uPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_SN1PR08MB1854A941E8A703913ECBE821DA880SN1PR08MB1854namp_--


From nobody Tue Apr 24 22:18:28 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F308126E64 for ; Tue, 24 Apr 2018 22:18:27 -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 cxcVTLSp3HcR for ; Tue, 24 Apr 2018 22:18:26 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC91126B7E for ; Tue, 24 Apr 2018 22:18:25 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2F0A5EB00B0A8 for ; Wed, 25 Apr 2018 06:18:23 +0100 (IST)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 25 Apr 2018 06:18:24 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0361.001; Wed, 25 Apr 2018 13:18:16 +0800
From: "Roni Even (A)" 
To: IETF QUIC WG 
Subject: Reserved bit in draft-ietf-quic-transport-11 short header
Thread-Topic: Reserved bit in draft-ietf-quic-transport-11 short header
Thread-Index: AdPcUoHHBncfVQK7RlSrCa3Kk42XsQ==
Date: Wed, 25 Apr 2018 05:18:16 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD877D4D@DGGEMM506-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.72]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD877D4DDGGEMM506MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Apr 2018 05:18:27 -0000

--_000_6E58094ECC8D8344914996DAD28F1CCD877D4DDGGEMM506MBXchina_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
I was surprised that there is no mention of the spin bit in the text "Reser=
ved:  The sixth bit (0x4) of octet 0 is reserved for experimentation." And =
expected to see a  reference to the spin-exp draft.

According to the meeting notes the hum was for option "b"  "Reserve bits, s=
eparate doc (soon) that may be incorporated in later consensus " . The bit =
was reserved for spin bit which was the topic of the discussion and the hum=
 and not for general experimentation.
At the meeting there were no suggestion for general experimentations and it=
 will not work if this bit may be used for other experiments without any sp=
ecific way to signal what experiment is running now.

Roni Even



--_000_6E58094ECC8D8344914996DAD28F1CCD877D4DDGGEMM506MBXchina_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


I was surprised that there is no mention of the spin=
 bit in the text “Reserved:  The six=
th bit (0x4) of octet 0 is reserved for experimentation.” And expecte=
d to see a  reference to the spin-exp draft.


 =



According to the meeting=
 notes the hum was for option “b”  “Reserve bits, separate doc (soon) tha=
t may be incorporated in later consensus “ . The bit was reserve=
d
 for spin bit which was the topic of the discussion and the hum and not for=
 general experimentation.


At th=
e meeting there were no suggestion for general experimentations and it will=
 not work if this bit may be used for other experiments without any specifi=
c way to signal what experiment is running
 now. 


=
 


Roni =
Even


 =



 






--_000_6E58094ECC8D8344914996DAD28F1CCD877D4DDGGEMM506MBXchina_--


From nobody Wed Apr 25 00:22:52 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CD3126579 for ; Wed, 25 Apr 2018 00:22:50 -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=TEm8Yd6S; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FaEpfqRc
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdmfioj7vsp6 for ; Wed, 25 Apr 2018 00:22:48 -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 2432D127077 for ; Wed, 25 Apr 2018 00:22:48 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3B462218FD; Wed, 25 Apr 2018 03:22:47 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 25 Apr 2018 03:22:47 -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; s=fm2; bh=wNp6Vz97BwYoZGJ3eIIL8radAHLZT ghjDthZwjJKHR4=; b=TEm8Yd6SE7JDWGBgmr0mYQ5TBnzjo4TcRRnDen13k0YMy gqm9yzVxQXO+SaGDSXXFiyHqSO66+BFeGZT4/Sj/U1JPSFle3JX5CK9UZ4cFlgdZ zmLd3Ao1eWrwC7JbJIDkmitjG5hVt0qsBJgpopQ/9ZgT51UtnuedOcN0kQZT1RtV pglkMIZQ/q70aa7r3AqCwrWPMbLPBqiUmThfId64dnoqBqOiOZbulhw5CaXz7FrD buEr0ewZOlqrr7I6XaiJvQD6ItFLfQ2nhgdrFZq4wV9FLjJIlDiDQre2pF5D00Fk bJO2Egi1Wx7MdSPIoVI6QTca6MeyBaFnFP/okpJng==
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; s=fm2; bh=wNp6Vz 97BwYoZGJ3eIIL8radAHLZTghjDthZwjJKHR4=; b=FaEpfqRcjYnvBBU91CSv4Q w1vZF7P3PxYdpHFaJP0p2OSQXH51ryGPLGN7y+SD99gKwq4ICawIFYSMTgAllR37 lSn+x94C5xFQ3g0XvMB55L7uGz1qTQ/ZL0j9Tmc1glPKyuVjjqRKgPwXGRLxKwgg /R5XDqlcYMUiPtvhtU16jEq2xvcpipDQvK19f7fqwJlpqn97jXkbLpFtP6Lk/Ttp XTYtWXaADjhGUeriOKQn/8FQLSRyHkYBM22I8CRrss3zflKEhyJhKY9PLS25UdTo yVOrGNKel0Mo/0YTCD5lNjoIiMX+2eiMTfuA1OA6pO8CgZ06NviWGSUmBLmsDbEg ==
X-ME-Sender: 
Received: from [10.188.210.187] (100.1.71.37.rev.sfr.net [37.71.1.100]) by mail.messagingengine.com (Postfix) with ESMTPA id 901601025E; Wed, 25 Apr 2018 03:22:46 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Reserved bit in draft-ietf-quic-transport-11 short header
From: Mark Nottingham 
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD877D4D@DGGEMM506-MBX.china.huawei.com>
Date: Wed, 25 Apr 2018 09:22:45 +0200
Cc: IETF QUIC WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <250D61A2-96D0-461D-93F7-F8306BDD88C1@mnot.net>
References: <6E58094ECC8D8344914996DAD28F1CCD877D4D@DGGEMM506-MBX.china.huawei.com>
To: "Roni Even (A)" 
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 25 Apr 2018 07:22:51 -0000

Roni,

The discussion in the room and the followup e-mail here made the =
distinction that these bits were for experimentation, not that they were =
specifically for the spin bit; that means that the current drafts don't =
need to incorporate any text specific to the spin bit, yet.

This isn't intended to be outlast our closed interop testing, so a =
signal isn't necessary.

Cheers,



> On 25 Apr 2018, at 7:18 am, Roni Even (A)  =
wrote:
>=20
> Hi,
> I was surprised that there is no mention of the spin bit in the text =
=E2=80=9CReserved:  The sixth bit (0x4) of octet 0 is reserved for =
experimentation.=E2=80=9D And expected to see a  reference to the =
spin-exp draft.
> =20
> According to the meeting notes the hum was for option =E2=80=9Cb=E2=80=9D=
  =E2=80=9CReserve bits, separate doc (soon) that may be incorporated in =
later consensus =E2=80=9C . The bit was reserved for spin bit which was =
the topic of the discussion and the hum and not for general =
experimentation.
> At the meeting there were no suggestion for general experimentations =
and it will not work if this bit may be used for other experiments =
without any specific way to signal what experiment is running now.=20
> =20
> Roni Even

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


From nobody Wed Apr 25 00:55:52 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F920127077 for ; Wed, 25 Apr 2018 00:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaaJ8Rl5bWw8 for ; Wed, 25 Apr 2018 00:55:49 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA3D127076 for ; Wed, 25 Apr 2018 00:55:49 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8544AE822DD6 for ; Wed, 25 Apr 2018 08:55:46 +0100 (IST)
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 25 Apr 2018 08:55:47 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0361.001; Wed, 25 Apr 2018 15:55:42 +0800
From: "Roni Even (A)" 
To: Mark Nottingham 
CC: IETF QUIC WG 
Subject: RE: Reserved bit in draft-ietf-quic-transport-11 short header
Thread-Topic: Reserved bit in draft-ietf-quic-transport-11 short header
Thread-Index: AdPcUoHHBncfVQK7RlSrCa3Kk42Xsf//oUmA//9x5ZA=
Date: Wed, 25 Apr 2018 07:55:41 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD877DCD@DGGEMM506-MBX.china.huawei.com>
References: <6E58094ECC8D8344914996DAD28F1CCD877D4D@DGGEMM506-MBX.china.huawei.com> <250D61A2-96D0-461D-93F7-F8306BDD88C1@mnot.net>
In-Reply-To: <250D61A2-96D0-461D-93F7-F8306BDD88C1@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.72]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Apr 2018 07:55:52 -0000

TWFyaywNCk15IHVuZGVyc3RhbmRpbmcgaXQgaXMgcmVzZXJ2ZWQgZm9yIHRlc3RpbmcgdGhlIHNw
aW4gYml0IGFuZCBub3QgZm9yIGFueSBvdGhlciBleHBlcmltZW50LiBJIGV4cGVjdGVkIHRoZSB0
ZXh0IHRvIGNsYXJpZnkgdGhhdCB0aGUgYml0IGlzIHJlc2VydmVkIGZvciBleHBlcmltZW50aW5n
IHRoZSBzcGluIGJpdCAodW50aWwgd2UgZGVjaWRlIGhvdyB0byBjb250aW51ZSkgYW5kIG5vdCBh
bnkgb3RoZXIgZmVhdHVyZSAsIGZvciBleGFtcGxlIHRvIGV4cGVyaW1lbnQgUE5FLg0KUm9uaQ0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFyayBOb3R0aW5naGFtIFttYWls
dG86bW5vdEBtbm90Lm5ldF0gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI1LCAyMDE4IDEwOjIz
IEFNDQpUbzogUm9uaSBFdmVuIChBKQ0KQ2M6IElFVEYgUVVJQyBXRw0KU3ViamVjdDogUmU6IFJl
c2VydmVkIGJpdCBpbiBkcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0LTExIHNob3J0IGhlYWRlcg0K
DQpSb25pLA0KDQpUaGUgZGlzY3Vzc2lvbiBpbiB0aGUgcm9vbSBhbmQgdGhlIGZvbGxvd3VwIGUt
bWFpbCBoZXJlIG1hZGUgdGhlIGRpc3RpbmN0aW9uIHRoYXQgdGhlc2UgYml0cyB3ZXJlIGZvciBl
eHBlcmltZW50YXRpb24sIG5vdCB0aGF0IHRoZXkgd2VyZSBzcGVjaWZpY2FsbHkgZm9yIHRoZSBz
cGluIGJpdDsgdGhhdCBtZWFucyB0aGF0IHRoZSBjdXJyZW50IGRyYWZ0cyBkb24ndCBuZWVkIHRv
IGluY29ycG9yYXRlIGFueSB0ZXh0IHNwZWNpZmljIHRvIHRoZSBzcGluIGJpdCwgeWV0Lg0KDQpU
aGlzIGlzbid0IGludGVuZGVkIHRvIGJlIG91dGxhc3Qgb3VyIGNsb3NlZCBpbnRlcm9wIHRlc3Rp
bmcsIHNvIGEgc2lnbmFsIGlzbid0IG5lY2Vzc2FyeS4NCg0KQ2hlZXJzLA0KDQoNCg0KPiBPbiAy
NSBBcHIgMjAxOCwgYXQgNzoxOCBhbSwgUm9uaSBFdmVuIChBKSA8cm9uaS5ldmVuQGh1YXdlaS5j
b20+IHdyb3RlOg0KPiANCj4gSGksDQo+IEkgd2FzIHN1cnByaXNlZCB0aGF0IHRoZXJlIGlzIG5v
IG1lbnRpb24gb2YgdGhlIHNwaW4gYml0IGluIHRoZSB0ZXh0IOKAnFJlc2VydmVkOiAgVGhlIHNp
eHRoIGJpdCAoMHg0KSBvZiBvY3RldCAwIGlzIHJlc2VydmVkIGZvciBleHBlcmltZW50YXRpb24u
4oCdIEFuZCBleHBlY3RlZCB0byBzZWUgYSAgcmVmZXJlbmNlIHRvIHRoZSBzcGluLWV4cCBkcmFm
dC4NCj4gIA0KPiBBY2NvcmRpbmcgdG8gdGhlIG1lZXRpbmcgbm90ZXMgdGhlIGh1bSB3YXMgZm9y
IG9wdGlvbiDigJxi4oCdICDigJxSZXNlcnZlIGJpdHMsIHNlcGFyYXRlIGRvYyAoc29vbikgdGhh
dCBtYXkgYmUgaW5jb3Jwb3JhdGVkIGluIGxhdGVyIGNvbnNlbnN1cyDigJwgLiBUaGUgYml0IHdh
cyByZXNlcnZlZCBmb3Igc3BpbiBiaXQgd2hpY2ggd2FzIHRoZSB0b3BpYyBvZiB0aGUgZGlzY3Vz
c2lvbiBhbmQgdGhlIGh1bSBhbmQgbm90IGZvciBnZW5lcmFsIGV4cGVyaW1lbnRhdGlvbi4NCj4g
QXQgdGhlIG1lZXRpbmcgdGhlcmUgd2VyZSBubyBzdWdnZXN0aW9uIGZvciBnZW5lcmFsIGV4cGVy
aW1lbnRhdGlvbnMgYW5kIGl0IHdpbGwgbm90IHdvcmsgaWYgdGhpcyBiaXQgbWF5IGJlIHVzZWQg
Zm9yIG90aGVyIGV4cGVyaW1lbnRzIHdpdGhvdXQgYW55IHNwZWNpZmljIHdheSB0byBzaWduYWwg
d2hhdCBleHBlcmltZW50IGlzIHJ1bm5pbmcgbm93LiANCj4gIA0KPiBSb25pIEV2ZW4NCg0KLS0N
Ck1hcmsgTm90dGluZ2hhbSAgIGh0dHBzOi8vd3d3Lm1ub3QubmV0Lw0KDQo=


From nobody Wed Apr 25 03:14:09 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F320912DA1D for ; Wed, 25 Apr 2018 03:14:06 -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 9hUIeS-1YT8u for ; Wed, 25 Apr 2018 03:14:04 -0700 (PDT)
Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B21612DA28 for ; Wed, 25 Apr 2018 03:14:02 -0700 (PDT)
Received: by mail-ot0-x22d.google.com with SMTP id t1-v6so4772996oth.8 for ; Wed, 25 Apr 2018 03:14:02 -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=zZnZsLNxGTiuwmyjBHZUPxU7sxUDGP9cnHdVmuPF68U=; b=uXrFLrht3NnV4F8Uvh8zc6qxIIIKvG9UWAdrr2vjQIdz98yHGQ3SQz9FhNsxoO7/dn srKWrxUkXVPGY/1qyfFOCoHTMIwBSzynBOrzx3xrVmvAeb04IcUR/QUW0eASkRc7Vrh1 1l3XG73VN9uyd07+C0M9zoa/d5NebJsDbnyl1RqJgGz5iCettUJwhvN8jf/mFYcAt7Ee dsLrhdDAZZ3B12nxNlHxysCXdhpgzltFrIueehuNF69us8Zx6RPRUySzopNiimMZTMdp FOxih62Tkc0j8kNaFFE35Yfb5uC/0H6Lpa/UIh1BbPyWEFX2c1IKj/zAKybkbtifCwwq gahA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=zZnZsLNxGTiuwmyjBHZUPxU7sxUDGP9cnHdVmuPF68U=; b=PmpLkvwpfcIgYPmxdCARwZ/Npmrwa5JVcmkWqICldYC+NiZ0OaCw7JakTUWULJCxJ4 2yqDHVOAUfCHQo+rzqHi+dCq7yN2aLmlKVpN1dMkfDVlVcdh5EJT8s7aYs1JXcjKgu2m nxg0Dp9ACTPR4eYy1ttQZBOFlkqWWMkwIWoxHpzO5YcrcTLMTUygU54mwejUs8nCMtrq F4m6Qwg2anbxCfNtH8vlj7ow5jNXium9PIop7ND99I1W4xYaN1WIYYnFZQp5TgrrnJ+X fIIlu5dOC0xuu3nI83ycoz5yReSeeHeaNNpFrJT2vUcAz/KFIDoZpWll5AGhxBkDCuTK pvWA==
X-Gm-Message-State: ALQs6tAxRWkW8ZfgiOjO4v7prpSQqMS74UfLbY2N5x27e1LXwoZiRhXH szc4PferPUIZFZuSeXC6go7MePN51WCJcx5JmzdIkQ==
X-Google-Smtp-Source: AB8JxZqJnTw6ddR3/ylFreSrWK8JhQ+71+sJxrp/oDo+N1Re32km6vd4EaH7AJTcYdqwdTw3l5/kl02LZUzJwKryt3k=
X-Received: by 2002:a9d:501e:: with SMTP id a30-v6mr5090845oth.15.1524651241196;  Wed, 25 Apr 2018 03:14:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:29ce:0:0:0:0:0 with HTTP; Wed, 25 Apr 2018 03:14:00 -0700 (PDT)
In-Reply-To: 
References: 
From: Martin Thomson 
Date: Wed, 25 Apr 2018 12:14:00 +0200
Message-ID: 
Subject: Re: QUIC Connection Close Reliability
To: Nick Banks 
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: Wed, 25 Apr 2018 10:14:07 -0000

Hi Nick,

It seems that you are having a problem with getting agreement between
peers about what the close state is.  In your example, if A cares that
the stream was completely received by B, then this is not an
appropriate way to negotiate a close in that application protocol.

You might interpret the receipt of APPLICATION_CLOSE as implicit
acknowledgment of all streams to avoid this particular problem, or to
create additional signals.

HTTP over QUIC does this largely by driving this from the client end,
which simplifies things considerably.

On Tue, Apr 24, 2018 at 12:06 AM, Nick Banks
 wrote:
> Hey Folks,
>
>
>
> I have been trying to work through an issue with reliability, related to
> connection close and I am trying to understand if this is a protocol issu=
e
> for if I need to change my implementation.
>
>
>
> Suppose you have an application protocol on top of QUIC where each side o=
f
> the connection may use one or more streams and then immediately, but
> gracefully, close the connection when they are done with all the streams.=
 In
> that kind of application protocol, one side of the connection generally e=
nds
> up closing immediately in response to receiving a FIN on a stream. Then y=
ou
> get into a state where the peer won=E2=80=99t necessarily get that FIN ac=
knowledged.
> Even if the endpoint sends an acknowledgment for the FIN (either as a
> separate packet or with the close) it=E2=80=99s possible that ACK is lost=
. Ideally
> (I think), the ACK is sent in the same packet as the close, so you can
> control the atomic state change on the peer. If the ACK was separate, and
> lost, but the close wasn=E2=80=99t lost, then the peer would treat the st=
ream as
> abortively closed.
>
>
>
> A -------- STREAM (w/FIN) ------> B
>
> A <------- ACK, APP_CLOSE ------- B
>
>
>
> But now the issue comes if the ACK/APP_CLOSE packet is lost. Per spec, th=
e
> endpoint (B) that received the FIN and then closed the connection enters =
the
> closing period. While in this state, the spec states that the endpoint
> SHOULD respond to any packet it receives [without a corresponding close
> frame] with another packet containing a closing frame. If the endpoint do=
es
> this, and includes the ACK again as well, I believe everything would work=
.
> The peer (A) would retransmit the STREAM packet, which would elicit a new
> ACK/APP_CLOSE packet from (B). My fear though (from current interop
> experience) is that everyone will try to short circuit connection closure
> and just immediately go away. If this behavior isn=E2=80=99t completely s=
tandard
> across all implementations, then the application protocol would end up
> having different results on different implementations. Some implementatio=
ns,
> might not send the ACK at all with the initial close, causing the peer (A=
)
> to most of the time interpret the stream as aborted. Other times, the
> endpoint (A) might not continue to send the ACK frame with the close, or
> just not send anything any more at all, resulting in a timeout on the pee=
r
> side, also resulting in an abortive closure of the stream. This would
> probably cause the application protocol to end up creating it=E2=80=99s o=
wn close
> semantics, on top of QUIC.
>
>
>
> Now, folks might not think this is a very important scenario, but I feel =
we
> should aim for consistency here. Perhaps I have missed a different soluti=
on
> to the problem. I considered a design that always sends that last ACK wit=
h a
> PING frame, and waits for that to get acknowledged before closing, but I
> felt it was way too ugly.
>
>
>
> Thanks,
>
> - Nick


From nobody Wed Apr 25 03:14:30 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC0212DA28 for ; Wed, 25 Apr 2018 03:14:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBTXL8AHjrwS for ; Wed, 25 Apr 2018 03:14:27 -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 BFEB512DA13 for ; Wed, 25 Apr 2018 03:14:20 -0700 (PDT)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx44.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fBHRF-0006hF-Hh for quic@ietf.org; Wed, 25 Apr 2018 12:14:19 +0200
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fBHQi-0001H8-QP for quic@ietf.org; Wed, 25 Apr 2018 06:14:11 -0400
Received: (qmail 10152 invoked from network); 25 Apr 2018 10:13:35 -0000
Received: from unknown (HELO [10.188.158.213]) (Authenticated-user:_huitema@huitema.net@[37.71.1.100]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Apr 2018 10:13:35 -0000
To: "Deval, Manasi" , Mark Nottingham 
Cc: "quic@ietf.org" 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>
From: Christian Huitema 
Openpgp: preference=signencrypt
Message-ID: 
Date: Wed, 25 Apr 2018 11:13:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Subject: Re: Getting to consensus on packet number encryption
X-Originating-IP: 168.144.250.232
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.16)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5iZANeazKMHMYiXw7z+O/ZF602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViALFR1wY4PPlU0jmvzkP1M87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB+FWCyy3VMwU/Tu6lpkyLYh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpXDzxM5P50wvQiu34cU//edF8FcHzzV3acxBudgYcInb7AMjIAzNNWm 1795oJZLpm6Z4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZuVGBtJ1DsK23UcLYdhI56FwBl1z1+w2zS/h3e6UiVReBILpm2AGusrXQ l3ZFE2I5CpkoeQQIGo2uHp2w1o0OHmeqA47D/juB1cx4exzYk7zESTfxsnn+QWY3vu7vIpAn647l NwN4qOsSZg+fYhVZG7jR1X6ZfhgbqJ49KX9lIV7VwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg
X-Report-Abuse-To: spam@quarantine6.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, 25 Apr 2018 10:14:29 -0000

On 4/23/2018 6:55 PM, Deval, Manasi wrote:

> I had brought up the issue with PNE several weeks ago as a barrier to hardware offload. After further review, it looks like a hardware offload can implement the PNE at a small cost. 
>
> The implementation can modify current HW crypto accelerators to support encrypting a buffer in the first pass and then encrypting packet number in the 2nd pass as already discussed on this thread. The exact requirement (header checksum, packet length encoding) is still in flux so there may be some small variations depending on the accelerator and final algorithm chosen for PNE. Future offload designs can do more to further reduce the overhead.

Thanks for the information, Manasi. I have modified the wiki page
describing the PNE issues and alternatives to reflect this new data:
https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-issues-and-alternatives.
With that new information, it appears that PR #1079 is superior to every
other alternative.

-- Christian Huitema


From nobody Wed Apr 25 04:53:36 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78721126D74 for ; Wed, 25 Apr 2018 04:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugXJOiEgnjYW for ; Wed, 25 Apr 2018 04:53:33 -0700 (PDT)
Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5664127522 for ; Wed, 25 Apr 2018 04:53:31 -0700 (PDT)
Received: by mail-io0-x242.google.com with SMTP id y128-v6so26457791iod.4 for ; Wed, 25 Apr 2018 04:53:31 -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=DcW7pZ+GoEFzJPQyCYgetbNb6Sf8rM3cw2fK+5BNfRc=; b=uSg2RymrqNhixB60kX6IoCX9S7CXvlK0/4JjQ/bNjwBofCKxEiOmRFi/UyA01h4NuZ CTOauKdkW7HnJ7ErMlaI45PqtIQBN7uKBKt4l8AY0izPSp3xACcwaUI+lETxgk4AMbME owkIePgGdl3/WsLsT021gsX0DsJmwvmm6P55IBZ95rDdplSY3mG8tlWtNm0zIRmNkWDS I58k2VbUd2R4UArjEdofeLa0gPYlGmtnVbr341ZXjuYvwx/u57aYNL+C8c6GGp9Y6mA0 vGHeRMurJvj06Ce4+4nXXB6ofFj13s6vHhTJpaNrI7fXxhuLUnBdOpfwsZD3So/WRx5p 0a8A==
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=DcW7pZ+GoEFzJPQyCYgetbNb6Sf8rM3cw2fK+5BNfRc=; b=M66l31ZUyO+ZmATeVngEZWDFxc6Q1Adx1Ey0HMl2KhxUL2iaTJhcBrYs0X8+pJY/xf DEOG9ocdwxKjYhVxZa03+73Wuoxuk4UarZ9cR6Fvfrbfmor3iU0Xwm1odyBU/oaK+niI DpHnlBz5CHw+CmZUwwI6w96oVHA3oCsPzeeFPYiHX649eZwSOAgTFgkA5+FcuxhHj1jE clqRDGNRP+RR3tijQGKz4joU85hVbfHRrjzzXykCbJ0LkZ8MbYAnVsAss4UcKPTtEBw9 7kPZpl2sf4hvZXhGu2Pl0xT7jq50APZUyP35/aVJi+rTZs2La4/SI4hb0AeBlMgsito+ 2rnA==
X-Gm-Message-State: ALQs6tBYDTC6toxLK7c3oS6csGt2wbJONfoxBOp8gigGLqez5k3B3BTU q77tUrGOtDjKwrbqmZzGwZli1YjEJ02ZcngUgek=
X-Google-Smtp-Source: AB8JxZpQIzNR/01ZVFtXSwunH4uhhChmNv41U7eAriguUC6pAEay0aXq+NASdvWHrYgB+dFAk6kX6gsVBivwih86E2U=
X-Received: by 2002:a6b:5010:: with SMTP id e16-v6mr22737398iob.274.1524657211195;  Wed, 25 Apr 2018 04:53:31 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 25 Apr 2018 07:53:29 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com> 
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 25 Apr 2018 07:53:29 -0400
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Mark Nottingham , Christian Huitema ,  "Deval, Manasi" 
Cc: "quic@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000007a47e1056aaaebe5"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 25 Apr 2018 11:53:35 -0000

--0000000000007a47e1056aaaebe5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Another observation point:

If there are so many concurrent paths in the host system that PNE matters,
then the cost of an additional keyed lookup is likely higher than PNE. You
can=E2=80=99t do much better than 40ns per lookup under ideal circumstances=
 where a
minimum number of cache lines are hit, unless your working set is small.
Red-Black tree easily gets up to 2-400ns with current hardware. PNE is
below 30ns estimated - iff the decryption context is readily available.

The question is then, would avoiding PNE lead to additional lookups that
would not otherwise be required. Or, on the contrary would PNE lead to
additional lookups due to a separate encryption context. Lookup broadly
means fetching cache lines not otherwise required.


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


On 25 April 2018 at 12.14.35, Christian Huitema (huitema@huitema.net) wrote=
:

On 4/23/2018 6:55 PM, Deval, Manasi wrote:

> I had brought up the issue with PNE several weeks ago as a barrier to
hardware offload. After further review, it looks like a hardware offload
can implement the PNE at a small cost.
>
> The implementation can modify current HW crypto accelerators to support
encrypting a buffer in the first pass and then encrypting packet number in
the 2nd pass as already discussed on this thread. The exact requirement
(header checksum, packet length encoding) is still in flux so there may be
some small variations depending on the accelerator and final algorithm
chosen for PNE. Future offload designs can do more to further reduce the
overhead.

Thanks for the information, Manasi. I have modified the wiki page
describing the PNE issues and alternatives to reflect this new data:
https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-iss=
ues-and-alternatives.

With that new information, it appears that PR #1079 is superior to every
other alternative.

-- Christian Huitema

--0000000000007a47e1056aaaebe5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
Another observation =
point:

If there are s=
o many concurrent paths in the host system that PNE matters, then the cost =
of an additional keyed lookup is likely higher than PNE. You can=E2=80=99t =
do much better than 40ns per lookup under ideal circumstances where a minim=
um number of cache lines are hit, unless your working set is small. Red-Bla=
ck tree easily gets up to 2-400ns with current hardware. PNE is below 30ns =
estimated - iff the decryption context is readily available.

The question is then, would avoid=
ing PNE lead to additional lookups that would not otherwise be required. Or=
, on the contrary would PNE lead to additional lookups due to a separate en=
cryption context. Lookup broadly means fetching cache lines not otherwise r=
equired.

=

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

 
On 25 A=
pril 2018 at 12.14.35, Christian Huitema (huitema@huitema.net) wrote:
 
On 4/23/2018 6:55 PM, Deval, Manas=
i wrote:



> I had brought up the issue with PNE several weeks ago as a barrier=
 to hardware offload. After further review, it looks like a hardware offloa=
d can implement the PNE at a small cost. =20

>

> The implementation can modify current HW crypto accelerators to su=
pport encrypting a buffer in the first pass and then encrypting packet numb=
er in the 2nd pass as already discussed on this thread. The exact requireme=
nt (header checksum, packet length encoding) is still in flux so there may =
be some small variations depending on the accelerator and final algorithm c=
hosen for PNE. Future offload designs can do more to further reduce the ove=
rhead.



Thanks for the information, Manasi. I have modified the wiki page

describing the PNE issues and alternatives to reflect this new data:

https://github.com/quicwg/base-drafts/=
wiki/Summary-of-the-PN-encryption-issues-and-alternatives.

With that new information, it appears that PR #1079 is superior to ever=
y

other alternative.



-- Christian Huitema





--0000000000007a47e1056aaaebe5--


From nobody Wed Apr 25 06:05:31 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB724126B6D for ; Wed, 25 Apr 2018 06:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asdS5kQOzSLJ for ; Wed, 25 Apr 2018 06:05:28 -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 97AF51205D3 for ; Wed, 25 Apr 2018 06:05:28 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id g9-v6so6498110ywb.12 for ; Wed, 25 Apr 2018 06:05:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h5UOKvjGregBILDgxbnloFBQ8U6JhsrYa3R0UFuLxtk=; b=sV1h8gimjaOOTKnJG/dI3tUxjshc0I6igeKctkSnvN4cmCLrzT+pszCmH4ZnHTBKaB d9tZuTIJHTwVtHQspnpE12PWut56FeKipWQm+tPth1nwqEUFYiIqvv6mGea/jCAVqI/U 7fraNUXJTf0AzxBg/e355vBnyl0slIS1F+ORHCdgWrdEJqVDTTcIIsuv9MDfDGJR+ypz OJE5vlZD7WLAjx7a1cyKCEmUKBwEaestwiV5SaFEm+xOY2roP/JuaOlT1EuSs+2JsZqb GlEqqunrXqw92rsGjnN64XoDQF2j7bdVTpo7IOSQvlAL3zoVth/yBdcq3q26RK/sePJ5 erMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h5UOKvjGregBILDgxbnloFBQ8U6JhsrYa3R0UFuLxtk=; b=p1THALuTMAaMFIaMvqQxJgPeA2IV0h2AmFtnNUuNVsnwcezFAbaAEKmc+RYywfGNAh /U3qWiz7WjOyLbJZN7xfRgDa24/dj5sJip1R+UxM/D3SBbQhS9c0vnDC/BojTqu1ZzOO 9gQJomCBjRdE203yemmRnFAKCxf8XKuFnBd1zk8CZ47lXkZlNs1Om1omZiETe3tBYMnN 9aT1xt/WY4GIu0l9Fs9pNigao4ukolENtoRB+KVfgSbUkoG2tYRbK7xB3e9uymh0u5CJ qWGjfoS7zSukN8yWcLsC05FkkgxhDFXdXyij14CrnPgTXyldKcJ7NXTOCRGVXtTvF5cB pxDg==
X-Gm-Message-State: ALQs6tDWiJT4ssjsIHElqn9+WXGIYzyqQNfZNlqJbRqoiHfB0Y+Lkknm gx6zOvbo3dtrPUbnTzWLg58KRyaeQNtT/b365TnHdw==
X-Google-Smtp-Source: AIpwx4+t6e0vy+2ZGMIXm54ZP214xUslrzqTKpoUdmJkUEoYlu9U1fg26deYYHn0xz4QxUab0al72h+eIILkS5B6T/M=
X-Received: by 2002:a81:32c1:: with SMTP id y184-v6mr14495924ywy.361.1524661527602;  Wed, 25 Apr 2018 06:05:27 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Ian Swett 
Date: Wed, 25 Apr 2018 13:05:15 +0000
Message-ID: 
Subject: Re: QUIC Connection Close Reliability
To: Martin Thomson 
Cc: nibanks=40microsoft.com@dmarc.ietf.org, IETF QUIC WG 
Content-Type: multipart/alternative; boundary="000000000000c2072a056aabec97"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 25 Apr 2018 13:05:30 -0000

--000000000000c2072a056aabec97
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Given the APP_CLOSE is closing the connection, I don't understand why the
ACK matters?  Once the connection is closed, the state is torn down and any
unacknowledged data is unnecessary.  I assume Martin's interpretation is
correct and this is a case where A wants to know the data was delivered,
and if you're immediately closing on fin receipt in your application,
Martin's suggestion that the APP_CLOSE implicitly acknowledges the data is
the obvious way to go.

However, I would expect most applications to have an idle period between
the last closed stream and when they close the connection, which ensures
the majority of connections are closed without unacknowledged data.

On Wed, Apr 25, 2018 at 6:14 AM Martin Thomson 
wrote:

> Hi Nick,
>
> It seems that you are having a problem with getting agreement between
> peers about what the close state is.  In your example, if A cares that
> the stream was completely received by B, then this is not an
> appropriate way to negotiate a close in that application protocol.
>
> You might interpret the receipt of APPLICATION_CLOSE as implicit
> acknowledgment of all streams to avoid this particular problem, or to
> create additional signals.
>
> HTTP over QUIC does this largely by driving this from the client end,
> which simplifies things considerably.
>
> On Tue, Apr 24, 2018 at 12:06 AM, Nick Banks
>  wrote:
> > Hey Folks,
> >
> >
> >
> > I have been trying to work through an issue with reliability, related t=
o
> > connection close and I am trying to understand if this is a protocol
> issue
> > for if I need to change my implementation.
> >
> >
> >
> > Suppose you have an application protocol on top of QUIC where each side
> of
> > the connection may use one or more streams and then immediately, but
> > gracefully, close the connection when they are done with all the
> streams. In
> > that kind of application protocol, one side of the connection generally
> ends
> > up closing immediately in response to receiving a FIN on a stream. Then
> you
> > get into a state where the peer won=E2=80=99t necessarily get that FIN
> acknowledged.
> > Even if the endpoint sends an acknowledgment for the FIN (either as a
> > separate packet or with the close) it=E2=80=99s possible that ACK is lo=
st..
> Ideally
> > (I think), the ACK is sent in the same packet as the close, so you can
> > control the atomic state change on the peer. If the ACK was separate, a=
nd
> > lost, but the close wasn=E2=80=99t lost, then the peer would treat the =
stream as
> > abortively closed.
> >
> >
> >
> > A -------- STREAM (w/FIN) ------> B
> >
> > A <------- ACK, APP_CLOSE ------- B
> >
> >
> >
> > But now the issue comes if the ACK/APP_CLOSE packet is lost. Per spec,
> the
> > endpoint (B) that received the FIN and then closed the connection enter=
s
> the
> > closing period. While in this state, the spec states that the endpoint
> > SHOULD respond to any packet it receives [without a corresponding close
> > frame] with another packet containing a closing frame. If the endpoint
> does
> > this, and includes the ACK again as well, I believe everything would
> work..
> > The peer (A) would retransmit the STREAM packet, which would elicit a n=
ew
> > ACK/APP_CLOSE packet from (B). My fear though (from current interop
> > experience) is that everyone will try to short circuit connection closu=
re
> > and just immediately go away. If this behavior isn=E2=80=99t completely=
 standard
> > across all implementations, then the application protocol would end up
> > having different results on different implementations. Some
> implementations,
> > might not send the ACK at all with the initial close, causing the peer
> (A)
> > to most of the time interpret the stream as aborted. Other times, the
> > endpoint (A) might not continue to send the ACK frame with the close, o=
r
> > just not send anything any more at all, resulting in a timeout on the
> peer
> > side, also resulting in an abortive closure of the stream. This would
> > probably cause the application protocol to end up creating it=E2=80=99s=
 own close
> > semantics, on top of QUIC.
> >
> >
> >
> > Now, folks might not think this is a very important scenario, but I fee=
l
> we
> > should aim for consistency here. Perhaps I have missed a different
> solution
> > to the problem. I considered a design that always sends that last ACK
> with a
> > PING frame, and waits for that to get acknowledged before closing, but =
I
> > felt it was way too ugly.
> >
> >
> >
> > Thanks,
> >
> > - Nick
>
>

--000000000000c2072a056aabec97
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Given the APP_CLOSE is closing the connection, I don't=
 understand why the ACK matters?=C2=A0 Once the connection is closed, the s=
tate is torn down and any unacknowledged data is unnecessary.=C2=A0 I assum=
e Martin's interpretation is correct and this is a case where A wants t=
o know the data was delivered, and if you're immediately closing on fin=
 receipt in your application, Martin's suggestion that the APP_CLOSE im=
plicitly acknowledges the data is the obvious way to go.

However, I would expect most applications to have an idle period betw=
een the last closed stream and when they close the connection, which ensure=
s the majority of connections are closed without unacknowledged data.
=


On Wed, Apr 25,=
 2018 at 6:14 AM Martin Thomson <martin.thomson@gmail.com> wrote:
Hi Nick,



It seems that you are having a problem with getting agreement between

peers about what the close state is.=C2=A0 In your example, if A cares that=


the stream was completely received by B, then this is not an

appropriate way to negotiate a close in that application protocol.



You might interpret the receipt of APPLICATION_CLOSE as implicit

acknowledgment of all streams to avoid this particular problem, or to

create additional signals.



HTTP over QUIC does this largely by driving this from the client end,

which simplifies things considerably.



On Tue, Apr 24, 2018 at 12:06 AM, Nick Banks

<nibanks=3D40microsoft.com@dmarc.ietf.org> wrote:

> Hey Folks,

>

>

>

> I have been trying to work through an issue with reliability, related =
to

> connection close and I am trying to understand if this is a protocol i=
ssue

> for if I need to change my implementation.

>

>

>

> Suppose you have an application protocol on top of QUIC where each sid=
e of

> the connection may use one or more streams and then immediately, but
> gracefully, close the connection when they are done with all the strea=
ms. In

> that kind of application protocol, one side of the connection generall=
y ends

> up closing immediately in response to receiving a FIN on a stream. The=
n you

> get into a state where the peer won=E2=80=99t necessarily get that FIN=
 acknowledged.

> Even if the endpoint sends an acknowledgment for the FIN (either as a<=
br>
> separate packet or with the close) it=E2=80=99s possible that ACK is l=
ost.. Ideally

> (I think), the ACK is sent in the same packet as the close, so you can=


> control the atomic state change on the peer. If the ACK was separate, =
and

> lost, but the close wasn=E2=80=99t lost, then the peer would treat the=
 stream as

> abortively closed.

>

>

>

> A -------- STREAM (w/FIN) ------> B

>

> A <------- ACK, APP_CLOSE ------- B

>

>

>

> But now the issue comes if the ACK/APP_CLOSE packet is lost. Per spec,=
 the

> endpoint (B) that received the FIN and then closed the connection ente=
rs the

> closing period. While in this state, the spec states that the endpoint=


> SHOULD respond to any packet it receives [without a corresponding clos=
e

> frame] with another packet containing a closing frame. If the endpoint=
 does

> this, and includes the ACK again as well, I believe everything would w=
ork..

> The peer (A) would retransmit the STREAM packet, which would elicit a =
new

> ACK/APP_CLOSE packet from (B). My fear though (from current interop
> experience) is that everyone will try to short circuit connection clos=
ure

> and just immediately go away. If this behavior isn=E2=80=99t completel=
y standard

> across all implementations, then the application protocol would end up=


> having different results on different implementations. Some implementa=
tions,

> might not send the ACK at all with the initial close, causing the peer=
 (A)

> to most of the time interpret the stream as aborted. Other times, the<=
br>
> endpoint (A) might not continue to send the ACK frame with the close, =
or

> just not send anything any more at all, resulting in a timeout on the =
peer

> side, also resulting in an abortive closure of the stream. This would<=
br>
> probably cause the application protocol to end up creating it=E2=80=99=
s own close

> semantics, on top of QUIC.

>

>

>

> Now, folks might not think this is a very important scenario, but I fe=
el we

> should aim for consistency here. Perhaps I have missed a different sol=
ution

> to the problem. I considered a design that always sends that last ACK =
with a

> PING frame, and waits for that to get acknowledged before closing, but=
 I

> felt it was way too ugly.

>

>

>

> Thanks,

>

> - Nick






--000000000000c2072a056aabec97--


From nobody Wed Apr 25 08:08:04 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6404D124239 for ; Wed, 25 Apr 2018 08:08:03 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=jVh7HQJ2; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=TljIzR2F
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtP5O6gbvvw0 for ; Wed, 25 Apr 2018 08:08:01 -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 E151E124205 for ; Wed, 25 Apr 2018 08:08:01 -0700 (PDT)
Received: from pps.filterd (m0148461.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3PF2gWM015781 for ; Wed, 25 Apr 2018 08:08: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=Rtmr/qtRhJ6HNg0GWJpUtB7QvLzGd3znq3HU4FdcaEA=; b=jVh7HQJ2w5A3q8HQPgHNjR5g1KvH1YaYqyngwCQ1fXQJZUkMP1KhohU8FUC0vxEQnoIC USAw4q5EVQNkpPMHsowPLNsftaTOcz9mhjRKRMpCZyiCFcrlEmMi4wFIq+4NiUnHfKOz 0SFna5yAaEJnJgIw21s7mjegHD9oBtMDrpc= 
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2hjrjx8h6s-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 25 Apr 2018 08:08:01 -0700
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.15) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Apr 2018 08:08:00 -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=Rtmr/qtRhJ6HNg0GWJpUtB7QvLzGd3znq3HU4FdcaEA=; b=TljIzR2FSWzvCQpHMkxRe4CCaFBKQQDWpXkuSILNZoAsKOdZ0JL0V0QbY4jLZGSrGDG2JOZz2PvBw7z8UE6Z6zBG+q1BJ0ucHYmU70Rjh2bM6rhN5eP6OELoBq2kGhrR5ajJAWuGRauatw43C7EUwm+a8ibdDVLXDbyjn+uDW3Q=
Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1423.namprd15.prod.outlook.com (10.173.234.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Wed, 25 Apr 2018 15:07:58 +0000
Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126%17]) with mapi id 15.20.0696.020; Wed, 25 Apr 2018 15:07:58 +0000
From: Subodh Iyengar 
To: "quic@ietf.org" 
Subject: ack delay in rx packets
Thread-Topic: ack delay in rx packets
Thread-Index: AQHT3KYtFrc5wMFDcECav0DMEKPj+Q==
Date: Wed, 25 Apr 2018 15:07:58 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2620:10d:c090:180::1:1f]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1423; 7:vvKjcOkhN8dszJLiwIegvqtw7p/aKaGnCL9AFy4T/Vlk1v1FOSXU082FkQoOXucXj+XdWljqzxUZEkOKpAyyr5sm8lb1TiM7dDsJwDMNUGbQ5dyUZjvqYQkLwRa19h5gOkhWfvINBxy+yalRnrUvasyGMxTb1mN9Hd9BRTU6qdFZSx1Wfx4hKOQ51ljenFcYSPZMeB1H0aY7I46yVx8fmAjuu4Wt6XpFVkepqquuTbjKUrqP7542OjMp94D9KUPe; 20:E0w/vu5xOv+bYVMgj+diFpIuf24J5RcAKcxoPpgxFhVMQWkfuIDXGM4+U7Qlsiewc64sgFj1Ru7FyTTT/jkBvchvnNFzE798gYumDHSfZRseV2HlMF5Ua2FCx/Nm1QpQoJ9a58pkgI439tbCkMAXbvnclIuxHbPTcWwdxjdTguE=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1423; 
x-ms-traffictypediagnostic: MWHPR15MB1423:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231232)(11241501184)(944501410)(52105095)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR15MB1423; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1423; 
x-forefront-prvs: 06530126A4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(39380400002)(346002)(376002)(396003)(199004)(189003)(186003)(3280700002)(3660700001)(6606003)(2906002)(19627405001)(7736002)(6916009)(6506007)(8676002)(5660300001)(102836004)(5250100002)(2501003)(2351001)(97736004)(86362001)(74316002)(55016002)(68736007)(9686003)(5640700003)(54896002)(6436002)(53936002)(2900100001)(105586002)(478600001)(33656002)(106356001)(25786009)(476003)(486006)(46003)(6116002)(81166006)(316002)(99286004)(81156014)(7696005)(8936002)(14454004)(1730700003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1423; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: IPqonCryyF26mJalmGGAOuG4TFnCdulq0xhOOJn090QSATuyDWu+AqKVmK++vtP73f2dwItIwQIxyXY+g8XXwzPxhxTJj7SOeLDPQC8v0RW8/PBiNS7SvF4scTjzb6HqFR/rvyJwLxnZGgkfd5gBTuRecN5B81/1yvhoAbdFIYlGKiJcUsiqN1o0DMQNzdPG
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1821770E698C99AAD160864EB68F0MWHPR15MB1821namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 9bb66bec-56a9-4263-4fde-08d5aabe54e4
X-MS-Exchange-CrossTenant-Network-Message-Id: 9bb66bec-56a9-4263-4fde-08d5aabe54e4
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2018 15:07:58.6456 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1423
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-25_04:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Apr 2018 15:08:03 -0000

--_000_MWHPR15MB1821770E698C99AAD160864EB68F0MWHPR15MB1821namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

We ran into very common cases where we might have all our data to send alre=
ady outstanding, so when a TLP and RTO alarm fires, we have no new data to =
send, so we resend data that was in previous packets.


In the time that the RTO fires, we might not have received any new packets,=
 however want to send ACKs in this new packet as well. Since no new packets=
 were received, this ACK will have the same largest acked as the previous p=
acket.


One question came up as to what the ack delay of an ACK in such a rx packet=
 should be. We could technically set it to the time since receipt of the pa=
cket, however with the new max_ack_delay computations, adding this might sc=
rew up our estimate of the normal ack delay, so I don't really want to do t=
hat. Is there a better option here, or does max_ack_delay not cover this ca=
se?


Subodh

--_000_MWHPR15MB1821770E698C99AAD160864EB68F0MWHPR15MB1821namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










We ran into very common cases whe=
re we might have all our data to send already outstanding, so when a TLP an=
d RTO alarm fires, we have no new data to send, so we resend data that was =
in previous packets.










In the time that the RTO fires, w=
e might not have received any new packets, however want to send ACKs in thi=
s new packet as well. Since no new packets were received, this ACK will hav=
e the same largest acked as the previous
 packet. 









One question came up as to what t=
he ack delay of an ACK in such a rx packet should be. We could technically =
set it to the time since receipt of the packet, however with the new max_ac=
k_delay computations, adding this
 might screw up our estimate of the normal ack delay, so I don't really wan=
t to do that. Is there a better option here, or does max_ack_delay not cove=
r this case?









Subodh








--_000_MWHPR15MB1821770E698C99AAD160864EB68F0MWHPR15MB1821namp_--


From nobody Wed Apr 25 08:53:28 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1684127775 for ; Wed, 25 Apr 2018 08:53:26 -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 J-09qifa5Sql for ; Wed, 25 Apr 2018 08:53:24 -0700 (PDT)
Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F27F127735 for ; Wed, 25 Apr 2018 08:53:24 -0700 (PDT)
Received: by mail-wr0-x244.google.com with SMTP id h3-v6so53853017wrh.5 for ; Wed, 25 Apr 2018 08:53:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t+rZzInr1cyDnlJX5LhSqhnz7xpJbSQODDL+FKxUQP0=; b=U37QhJucjbjr+ttjWMdaAyQkZ7j680EljjWv+j7xf/DzmdYHKqtMUaB8j0RzxJGDo2 CmqbZYzHg8i3ov6m/k7/PwlMKx09jAiEOIhc96EWqCHmok0GdB3Tipsz9o+M5luC67vm 9yBf3RYUSwsBftlFYP+UHGb5dABVfrcgRcgwT040by+M5RkPi9QvtHW0ZgyeYN9KTcIe VgOVtizQCSd0o52vm5+/tDC8FSem/roA/xdISVkDZ8yMe2pu5HkxRubuvRB3Qa3Yxrgq idAz6KAkCiTEBcBCq3k71/Vm3cnlsNw5PDIw+N7+IzcewxmVOgV1Rk5flfRJA+nPZokB Pnjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t+rZzInr1cyDnlJX5LhSqhnz7xpJbSQODDL+FKxUQP0=; b=pczPmmSKMFcnqHZixuKTOKfcXfyw1rsllucXQ5blVRAvql/Bztu6bykeIhzdyJgS5l ZfnXrzSzLdSoZj1O7xJinxng8MXJ2Ssxx3Smp4OM1mUiZt72JYk5XnJZ/FvkytVzgc4K m/BhKRMrNAAl7plZ1rjL8jX8KKxNBDCN+ItpAz5/G7AfnFAs3ztZwxJMwT1PM96GY9li OjeEZo6cFozHsvUvJl+eUK8mvq2ukwZLsbmnDZ/y2FCshjbipEeVkkJYlwACfpV3K+iQ VVAR5QebjgbbZjAmjdbcsUj0/p7DuHEma5JqF5a9I2C0fp6zKq9o01qv0BH61LmUU6aD oUzQ==
X-Gm-Message-State: ALQs6tB787SmgAZQ8EXqlM/s5c0l6j4ffJF3+iP7GJjaswJNM0njBjis X/N1hmKAFysv0JLbSlPWFge0n9jGkxEO6DWMJU8=
X-Google-Smtp-Source: AIpwx4+qM8O0R5IoZKLDp37QdBIgQiHeqGVRl/FD/4TkwACPhtSHTm8Jc2Rj7VhfrEpgFnnUEPeU7m3xxZF5s5sCOsw=
X-Received: by 2002:adf:b8b0:: with SMTP id i45-v6mr24025965wrf.105.1524671603035;  Wed, 25 Apr 2018 08:53:23 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Jana Iyengar 
Date: Wed, 25 Apr 2018 15:53:12 +0000
Message-ID: 
Subject: Re: ack delay in rx packets
To: Subodh Iyengar 
Cc: QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000004c5146056aae459b"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 25 Apr 2018 15:53:26 -0000

--0000000000004c5146056aae459b
Content-Type: text/plain; charset="UTF-8"

If the sender has seen a previous ack for the same largest received, then
it should basically ignore this new ack. If not, the ack delay will be
accurate... What concern do you see with having a large ack delay?

On Wed, Apr 25, 2018, 8:08 AM Subodh Iyengar  wrote:

> We ran into very common cases where we might have all our data to send
> already outstanding, so when a TLP and RTO alarm fires, we have no new data
> to send, so we resend data that was in previous packets.
>
>
> In the time that the RTO fires, we might not have received any new
> packets, however want to send ACKs in this new packet as well. Since no new
> packets were received, this ACK will have the same largest acked as the
> previous packet.
>
>
> One question came up as to what the ack delay of an ACK in such a rx
> packet should be. We could technically set it to the time since receipt of
> the packet, however with the new max_ack_delay computations, adding this
> might screw up our estimate of the normal ack delay, so I don't really want
> to do that. Is there a better option here, or does max_ack_delay not cover
> this case?
>
>
> Subodh
>

--0000000000004c5146056aae459b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


If the sender has seen a previous ack for the same larges=
t received, then it should basically ignore this new ack. If not, the ack d=
elay will be accurate... What concern do you see with having a large ack de=
lay?

On Wed, Apr 25, 2=
018, 8:08 AM Subodh Iyengar <subodh@fb.=
com> wrote:










We ran into very common cases whe=
re we might have all our data to send already outstanding, so when a TLP an=
d RTO alarm fires, we have no new data to send, so we resend data that was =
in previous packets.










In the time that the RTO fires, w=
e might not have received any new packets, however want to send ACKs in thi=
s new packet as well. Since no new packets were received, this ACK will hav=
e the same largest acked as the previous
 packet. 









One question came up as to what t=
he ack delay of an ACK in such a rx packet should be. We could technically =
set it to the time since receipt of the packet, however with the new max_ac=
k_delay computations, adding this
 might screw up our estimate of the normal ack delay, so I don't really=
 want to do that. Is there a better option here, or does max_ack_delay not =
cover this case?









Subodh











--0000000000004c5146056aae459b--


From nobody Wed Apr 25 09:09:57 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A95129BBF for ; Wed, 25 Apr 2018 09:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piG0vPQPKp31 for ; Wed, 25 Apr 2018 09:09:54 -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 EBEE3127909 for ; Wed, 25 Apr 2018 09:09:51 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id h6-v6so3243521ywj.9 for ; Wed, 25 Apr 2018 09:09:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NuFlgoN9f3b4U/jbfRYzfCPN9DsDKfyyphuhHQChiNo=; b=X65xys2GIVmZKxnH0QtjdY7CbcGSGSFwHeRY+lGG9ymQ08YQa2uhjhLgb5oHZ2+1z7 iLU2GH5sQ75Nr7CoGlMbDa3ZLTY836DYMeUfpzp5215b6g5Kf/I8qwFNzYkYq4r34hDC hBLrHidEzoIavbmi2vAkLW7AZuEQiN/Idm+2hFNKA113AGqeWuxmGdso5W4ZRLF10jpU phz4787VuaZIWC6+rOCK4yriIihaXqfoj9Qjzb+hauHH1zsuzT+4uqdfny/WB+9hEIjU yiyFNRkZpswt7fgGM/j3rrimy0QmwIdHsDHeNCIBGrcckdMT6G8tju21t4W+423LMV2C jwxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NuFlgoN9f3b4U/jbfRYzfCPN9DsDKfyyphuhHQChiNo=; b=fzICIgUDEc9ykQ5WdExG/DUWFa5KbgadEoPFkG8ULGle9NRsGEO52fGj+0g6x7qC+y L/IANZkvqqqdihFkvlSI00HVWD4BGSwelXgIPrfXi9LB1MXpr7/+7OxEvEpawhl6ilvZ dTBhCz0/RH9sgW69U6lUWVj4M//dvntT0UWPiWHyLZ1zq9rcOBBmuF5j80vO/Gm6Vl1h UIjgXU9hgTaF3/ljsFgXAd1owpLh/9eOKjo7vmWDTshsOTduoFAux1Z1D3VzRlH7maoH Bj6pFyQ8lRq2ce7lbF/fl3p6dnbSY0k/tk5ErGP2jBzRjqot0qNUzEKnsS0AMIkjWdA0 Lt6w==
X-Gm-Message-State: ALQs6tCuw4WO+4QXhsLOT4eXSOYyEfuwDcnCOxOvxhPOh/s+bLnQTimF aOQ73EJ5CrL0J2eX8qQOcJwd+QUruhMVNgZCDDmCNA==
X-Google-Smtp-Source: AIpwx4+bVPFSksHGHx4WZdCK+T6JjcZ0NUbo0tmT5hsWuf6aIpJJVJUpNC9/bs5jAKLCGEmzuC6ZHHhKM5A2tUU/HiY=
X-Received: by 2002:a81:a648:: with SMTP id d69-v6mr15213038ywh.173.1524672590923;  Wed, 25 Apr 2018 09:09:50 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Ian Swett 
Date: Wed, 25 Apr 2018 16:09:39 +0000
Message-ID: 
Subject: Re: ack delay in rx packets
To: Jana Iyengar 
Cc: Subodh Iyengar , IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000002f0331056aae80c0"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 25 Apr 2018 16:09:56 -0000

--0000000000002f0331056aae80c0
Content-Type: text/plain; charset="UTF-8"

Jana's right about ignoring the ack for RTT calculation if it doesn't
acknowledge a new packet, see section 3.1:
https://tools.ietf.org/html/draft-ietf-quic-recovery-11#section-3.1

If it did acknowledge a new packet because the previous ACK was lost, then
you end up with either a useless RTT, a useless max ack delay, or both.
Because of issues like this, I prefer sending acks in response to packets,
or within an alarm of packet receipt, rather than at other times.

On Wed, Apr 25, 2018 at 11:53 AM Jana Iyengar  wrote:

> If the sender has seen a previous ack for the same largest received, then
> it should basically ignore this new ack. If not, the ack delay will be
> accurate... What concern do you see with having a large ack delay?
>
> On Wed, Apr 25, 2018, 8:08 AM Subodh Iyengar  wrote:
>
>> We ran into very common cases where we might have all our data to send
>> already outstanding, so when a TLP and RTO alarm fires, we have no new data
>> to send, so we resend data that was in previous packets.
>>
>>
>> In the time that the RTO fires, we might not have received any new
>> packets, however want to send ACKs in this new packet as well. Since no new
>> packets were received, this ACK will have the same largest acked as the
>> previous packet.
>>
>>
>> One question came up as to what the ack delay of an ACK in such a rx
>> packet should be. We could technically set it to the time since receipt of
>> the packet, however with the new max_ack_delay computations, adding this
>> might screw up our estimate of the normal ack delay, so I don't really want
>> to do that. Is there a better option here, or does max_ack_delay not cover
>> this case?
>>
>>
>> Subodh
>>
>

--0000000000002f0331056aae80c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Jana's right about ignoring the ack for RTT calculatio=
n if it doesn't acknowledge a new packet, see section 3.1:=C2=A0ht=
tps://tools.ietf.org/html/draft-ietf-quic-recovery-11#section-3.1

If it did acknowledge a new packet because the previous A=
CK was lost, then you end up with either a useless RTT, a useless max ack d=
elay, or both.=C2=A0 Because of issues like this, I prefer sending acks in =
response to packets, or within an alarm of packet receipt, rather than at o=
ther times.

On W=
ed, Apr 25, 2018 at 11:53 AM Jana Iyengar <jri.ietf@gmail.com> wrote:
If the sender has seen a previous ack for the sam=
e largest received, then it should basically ignore this new ack. If not, t=
he ack delay will be accurate... What concern do you see with having a larg=
e ack delay?

On Wed, A=
pr 25, 2018, 8:08 AM Subodh Iyengar <subodh@fb.com> wrote:










We ran into very common cases whe=
re we might have all our data to send already outstanding, so when a TLP an=
d RTO alarm fires, we have no new data to send, so we resend data that was =
in previous packets.










In the time that the RTO fires, w=
e might not have received any new packets, however want to send ACKs in thi=
s new packet as well. Since no new packets were received, this ACK will hav=
e the same largest acked as the previous
 packet. 









One question came up as to what t=
he ack delay of an ACK in such a rx packet should be. We could technically =
set it to the time since receipt of the packet, however with the new max_ac=
k_delay computations, adding this
 might screw up our estimate of the normal ack delay, so I don't really=
 want to do that. Is there a better option here, or does max_ack_delay not =
cover this case?









Subodh













--0000000000002f0331056aae80c0--


From nobody Wed Apr 25 09:11:27 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871E71267BB for ; Wed, 25 Apr 2018 09:11:26 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=AH81c0qF; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=TKR68oq/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WoN8I4C_vET for ; Wed, 25 Apr 2018 09:11:24 -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 7E411127735 for ; Wed, 25 Apr 2018 09:11:24 -0700 (PDT)
Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3PFw2X8001245; Wed, 25 Apr 2018 09:11:21 -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=xjxcjrEhP5IdCBgc86Xd5d+zsq83Crh0IAiH72mzdRQ=; b=AH81c0qFMe6hEKGV5aE3/v8QHgC0EV+u/uwG+P65Avm9JrmAfYulsdU9epvDGaWA/qg2 3O3NSRrBue4DkCCIX5I38qGaFQ7ugDhso1lYIGP/5+VkH2PobH4iu0AJUhWYz8NDlbeL 8/6gvB0idBvrG7wo+05bo7dT6Vpobn52FAU= 
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2hjstu8j65-4 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Apr 2018 09:11:21 -0700
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.18) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Apr 2018 09:11:17 -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=xjxcjrEhP5IdCBgc86Xd5d+zsq83Crh0IAiH72mzdRQ=; b=TKR68oq/8xC7kmYuJe2BkNJuuZTjfAgewal2nSK/iUWTOLzSh3bOej+LQ0Nn6IfLVW6wD2vzEy02AKh7NVMUiqB7AXFbijqrzaCjrLPYxQVAJcqzrNGtr5h7sDE/8HlixUhBZm2f8tUFG/Skvt2mBeUaP247CkfkGpDJ8CK9+X8=
Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1757.namprd15.prod.outlook.com (10.174.255.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Wed, 25 Apr 2018 16:11:15 +0000
Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126%17]) with mapi id 15.20.0696.020; Wed, 25 Apr 2018 16:11:15 +0000
From: Subodh Iyengar 
To: Ian Swett , Jana Iyengar 
CC: IETF QUIC WG 
Subject: Re: ack delay in rx packets
Thread-Topic: ack delay in rx packets
Thread-Index: AQHT3KYtFrc5wMFDcECav0DMEKPj+aQRoboAgAAEmYCAAABT3w==
Date: Wed, 25 Apr 2018 16:11:15 +0000
Message-ID: 
References:  , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2620:10d:c090:180::1:b93]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1757; 7:f4uFdauXQphOAVQV+HTTmNtgrWtzcBPl1yJKQtNK5YWu03HRHXTVqTaqX8U7PNOcpB6J0zsPHaad6Xz7qKqs4N1ZHuux4hfRUOATrGU/VqRePMHtWM4YZwUaEe3AM07RXlL9Ox5rJzFXpqdyAAdmkAanQPI44Kdd0mPkmD+fIca+MZ/o1V5B7ekzO9iazXqM5bJbMWMHZhdqIb0lQniUBLUeGfYW766T4FZZNeoLvuEVsJ8h05/J5gfSGbt70htl; 20:CDFm607ieaC+dkYjvF7cEv3qs5FxOdbIbRNpFbd5NHHs2R6L9RToCkY7zNMwczpyxyQmHm90IAOXV4EZUOKIA7SEqsqTh6l4LZR4FGqAV+2NWeKZKpW6Skv3Bt218rolsBqzf775pVGpCa4LlVuGDzeFBUxCtPdVAf+4cq9he7o=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1757; 
x-ms-traffictypediagnostic: MWHPR15MB1757:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162)(85827821059158)(67672495146484); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231232)(11241501184)(944501410)(52105095)(93006095)(93001095)(6041310)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR15MB1757; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1757; 
x-forefront-prvs: 06530126A4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(396003)(39860400002)(346002)(376002)(189003)(199004)(186003)(5250100002)(236005)(6306002)(6116002)(9686003)(606006)(46003)(25786009)(3660700001)(55016002)(54896002)(3280700002)(19627405001)(478600001)(6606003)(11346002)(2906002)(68736007)(39060400002)(6436002)(6246003)(446003)(81166006)(8676002)(486006)(33656002)(476003)(81156014)(8936002)(53936002)(4326008)(5660300001)(7696005)(966005)(316002)(7736002)(6506007)(53546011)(86362001)(102836004)(74316002)(106356001)(110136005)(76176011)(99286004)(2900100001)(229853002)(97736004)(105586002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1757; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: HqXzS9kUeZiuPl+zgNR2Z2ym2a/udNltTOMgIQ6u2vDT2SprHOn9mEGUcqDAC8wXTqrRF/N0XQkssTrcGFOxZeOiSq+/3RspZhNVAyr13sKyJPVNWunvtnfr9CIlKnSPx/xmfaWoWX/o8iWCiTwSYUZ6AVS2ZZt6NsniQ04WOOPcLqov/qq3FVHSc807OF+0
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB18211154D0F967B0A31FC0EDB68F0MWHPR15MB1821namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: efaac1b7-8da6-449d-5113-08d5aac72c12
X-MS-Exchange-CrossTenant-Network-Message-Id: efaac1b7-8da6-449d-5113-08d5aac72c12
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2018 16:11:15.5998 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1757
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-25_05:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Apr 2018 16:11:26 -0000

--_000_MWHPR15MB18211154D0F967B0A31FC0EDB68F0MWHPR15MB1821namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

My concern is this situation: a "receiver" had not seen the original ACK (t=
he packet was lost), then the sender rtos and sends a large ack delay to co=
mpensate for the rto, the max filter for max ack delay would inflate the de=
lay for future packet.


if latest_rtt - min_rtt  > ack_delay:

   max_ack_delay =3D max(max_ack_delay, ack_delay)


latest_rtt in this case would be rto_timer + rtt because the sender sends a=
n ack after an rto.


The rtt cal So max ack delay would become the rto timer. Is this a correct =
characterization?


Subodh


________________________________
From: QUIC  on behalf of Ian Swett 
Sent: Wednesday, April 25, 2018 9:09:39 AM
To: Jana Iyengar
Cc: Subodh Iyengar; IETF QUIC WG
Subject: Re: ack delay in rx packets

Jana's right about ignoring the ack for RTT calculation if it doesn't ackno=
wledge a new packet, see section 3.1: https://tools.ietf.org/html/draft-iet=
f-quic-recovery-11#section-3.1

If it did acknowledge a new packet because the previous ACK was lost, then =
you end up with either a useless RTT, a useless max ack delay, or both.  Be=
cause of issues like this, I prefer sending acks in response to packets, or=
 within an alarm of packet receipt, rather than at other times.

On Wed, Apr 25, 2018 at 11:53 AM Jana Iyengar > wrote:
If the sender has seen a previous ack for the same largest received, then i=
t should basically ignore this new ack. If not, the ack delay will be accur=
ate... What concern do you see with having a large ack delay?

On Wed, Apr 25, 2018, 8:08 AM Subodh Iyengar > wrote:

We ran into very common cases where we might have all our data to send alre=
ady outstanding, so when a TLP and RTO alarm fires, we have no new data to =
send, so we resend data that was in previous packets.


In the time that the RTO fires, we might not have received any new packets,=
 however want to send ACKs in this new packet as well. Since no new packets=
 were received, this ACK will have the same largest acked as the previous p=
acket.


One question came up as to what the ack delay of an ACK in such a rx packet=
 should be. We could technically set it to the time since receipt of the pa=
cket, however with the new max_ack_delay computations, adding this might sc=
rew up our estimate of the normal ack delay, so I don't really want to do t=
hat. Is there a better option here, or does max_ack_delay not cover this ca=
se?


Subodh

--_000_MWHPR15MB18211154D0F967B0A31FC0EDB68F0MWHPR15MB1821namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable












My concern is this situation: a &=
quot;receiver" had not seen the original ACK (the packet was lost), th=
en the sender rtos and sends a large ack delay to compensate for the r=
to, the max filter for max ack delay would inflate
 the delay for future packet. 









if latest_rtt - min_rtt =
; > ack_delay:


   max_ack_delay =3D ma=
x(max_ack_delay, ack_delay)









latest_rtt in this case would be =
rto_timer + rtt because the sender sends an ack after an rto.










The rtt cal So max ack delay woul=
d become the rto timer. Is this a correct characterization?







Subodh












From: QUIC <quic-bounces=
@ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf=
.org>

Sent: Wednesday, April 25, 2018 9:09:39 AM

To: Jana Iyengar

Cc: Subodh Iyengar; IETF QUIC WG

Subject: Re: ack delay in rx packets

 






Jana's right about ignoring the ack for RTT calculation if=
 it doesn't acknowledge a new packet, see section 3.1: https://tools.ietf.org/html/draft-ietf-quic-recovery-11#secti=
on-3.1







If it did acknowledge a new packet because the previous ACK was lost, =
then you end up with either a useless RTT, a useless max ack delay, or both=
.  Because of issues like this, I prefer sending acks in response to p=
ackets, or within an alarm of packet
 receipt, rather than at other times.








On Wed, Apr 25, 2018 at 11:53 AM Jana Iyengar <jri.ietf@gmail.com> wrote:






If the sender has seen a previous ack for the same larges=
t received, then it should basically ignore this new ack. If not, the ack d=
elay will be accurate... What concern do you see with having a large ack de=
lay?






On Wed, Apr 25, 2018, 8:08 AM Subodh Iyengar <subodh@fb.com> wrote:









We ran into very common cases wh=
ere we might have all our data to send already outstanding, so when a TLP a=
nd RTO alarm fires, we have no new data to send, so we resend data that was=
 in previous packets.










In the time that the RTO fires, =
we might not have received any new packets, however want to send ACKs in th=
is new packet as well. Since no new packets were received, this ACK will ha=
ve the same largest acked as the previous
 packet. 









One question came up as to what =
the ack delay of an ACK in such a rx packet should be. We could technically=
 set it to the time since receipt of the packet, however with the new max_a=
ck_delay computations, adding this
 might screw up our estimate of the normal ack delay, so I don't really wan=
t to do that. Is there a better option here, or does max_ack_delay not cove=
r this case?









Subodh




















--_000_MWHPR15MB18211154D0F967B0A31FC0EDB68F0MWHPR15MB1821namp_--


From nobody Wed Apr 25 09:20:17 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9413D1200C5 for ; Wed, 25 Apr 2018 09:20:15 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=XR/jA4UB; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=J4hVCGn5
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIQhwmgGyHvJ for ; Wed, 25 Apr 2018 09:20:13 -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 BA42D128954 for ; Wed, 25 Apr 2018 09:20:13 -0700 (PDT)
Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3PGJhUl010854; Wed, 25 Apr 2018 09:20:10 -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=uLwZSfpxUFJ5iOb9O46YcAasVj+OknecARGLs1lYZQ0=; b=XR/jA4UB0fZ/dlhe4Z87i/jqUqh5qsltCBtbANX2M/Zyh6p9PhaKNucdk71zN5hg5XV+ 4dlQ8ns4pUTQR4EROzaf+L14LH4lzVl54Addl0rEAX199OoD+a0kLtVY7fVyjlhIlYaL l7tP4HwcbIQ/QJhm+xTd0dqvotUHiXKamjY= 
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2hjtsu0ej4-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Apr 2018 09:20:10 -0700
Received: from NAM02-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.361.1; Wed, 25 Apr 2018 09:20:08 -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=uLwZSfpxUFJ5iOb9O46YcAasVj+OknecARGLs1lYZQ0=; b=J4hVCGn5penuETkETMtdikaQSlG7+s9YOF2eyO6B/9jW9Y0zlCzlvXNP/2C5gHp1OwWNtMK31kQecQTbg53xLhZamq42j6RVwAdSjJ5OdBUSqTSm6R4GAWgoYzViRTln5BUtCBJSYFOGH90XtVFkqZcascwajbj2zWk3uMx3P9w=
Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1309.namprd15.prod.outlook.com (10.175.3.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Wed, 25 Apr 2018 16:20:07 +0000
Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126%17]) with mapi id 15.20.0696.020; Wed, 25 Apr 2018 16:20:07 +0000
From: Subodh Iyengar 
To: Ian Swett , Jana Iyengar , Ian Swett 
CC: IETF QUIC WG 
Subject: Re: ack delay in rx packets
Thread-Topic: ack delay in rx packets
Thread-Index: AQHT3KYtFrc5wMFDcECav0DMEKPj+aQRoboAgAAEmYCAAABT34AAAESi
Date: Wed, 25 Apr 2018 16:20:06 +0000
Message-ID: 
References:  , , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-Mentions: ianswett@google.com
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2620:10d:c090:180::1:b93]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1309; 7:hKopMJU0yJiO0yCuIWc3JausPE+k85Nr7uc3WjKwpWMnOgJLdQb8kxRQysDRkLru6TtgP6CaF7NJAfECHT48sE+fjgjuwYLoqJ8pmm/oIcVyqvgBO7WZn56adyDstCaZg809TAR41RHZTIZZMxT5ouhhQgJ1/6No/pKeWng0Q8ijEAFVHkC69OGP3GJmes440D+PTjd/MZQmnzzD9ls7iTA/eABLT3GKalrc/XVf6EZPX01oXHfhbZ6CyH0hZIcC; 20:rU9evlzcCK0VMRObq1MNuBY090wH6H8LdlpmDI25BANu5IkozQK0Ex+GKtePwVU9A/18X69La3jD24GvS1FlOik61eEaLpEhgdc8Unm/GpqhAXKyJywH/H4YAYIRrX+/b+d1VIPF7uRlHYWfDqTaOvc8t3AMC2cK56nX6L1r4A0=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1309; 
x-ms-traffictypediagnostic: MWHPR15MB1309:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162)(85827821059158)(67672495146484)(211936372134217); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231232)(11241501184)(944501410)(52105095)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR15MB1309; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1309; 
x-forefront-prvs: 06530126A4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39380400002)(366004)(39860400002)(396003)(189003)(199004)(6436002)(6506007)(606006)(2940100002)(6606003)(81166006)(105586002)(6116002)(25786009)(19627405001)(33656002)(106356001)(2906002)(81156014)(186003)(8676002)(8936002)(93886005)(7736002)(3660700001)(74316002)(478600001)(2900100001)(316002)(97736004)(6306002)(54896002)(55016002)(68736007)(236005)(39060400002)(53936002)(102836004)(9686003)(966005)(53546011)(14454004)(86362001)(476003)(11346002)(446003)(5250100002)(6246003)(3280700002)(229853002)(46003)(486006)(110136005)(76176011)(99286004)(7696005)(5660300001)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1309; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: qZQ3l11+95aqRv8+DoHf2jBuE5GyYVfmAfizLCwgER/nQs1wF69r0+4MEu5rIBsi8bSvsxvtG2H5eiv4HXDsUGVBVCqZdlrZmYtlk/a3wmZfY8UVNpIXjpozEcyIpXfgRdbgAYpnq9PL6dszKItJN0I7XwgF+fdUhtxyzcGC3OaMfN/v0OcIx96nGLHSyIRQ
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1821A5550632E66D8133F54CB68F0MWHPR15MB1821namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: e278b8c2-9900-4166-5465-08d5aac868ce
X-MS-Exchange-CrossTenant-Network-Message-Id: e278b8c2-9900-4166-5465-08d5aac868ce
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2018 16:20:06.9451 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1309
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-25_05:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Apr 2018 16:20:16 -0000

--_000_MWHPR15MB1821A5550632E66D8133F54CB68F0MWHPR15MB1821namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

@Ian Swett sending ACKs in response to packets =
or delay seems fine, and an implementation might choose to do that. If we h=
ave more opportunities to send an ACK and avoid an RTO on the peer, wouldn'=
t that be better? Is the objective of sending packets only during timer or =
recv data to simplify the ack delay calculation logic?


Subodh

________________________________
From: Subodh Iyengar
Sent: Wednesday, April 25, 2018 9:11:15 AM
To: Ian Swett; Jana Iyengar
Cc: IETF QUIC WG
Subject: Re: ack delay in rx packets


My concern is this situation: a "receiver" had not seen the original ACK (t=
he packet was lost), then the sender rtos and sends a large ack delay to co=
mpensate for the rto, the max filter for max ack delay would inflate the de=
lay for future packet.


if latest_rtt - min_rtt  > ack_delay:

   max_ack_delay =3D max(max_ack_delay, ack_delay)


latest_rtt in this case would be rto_timer + rtt because the sender sends a=
n ack after an rto.


The rtt cal So max ack delay would become the rto timer. Is this a correct =
characterization?


Subodh


________________________________
From: QUIC  on behalf of Ian Swett 
Sent: Wednesday, April 25, 2018 9:09:39 AM
To: Jana Iyengar
Cc: Subodh Iyengar; IETF QUIC WG
Subject: Re: ack delay in rx packets

Jana's right about ignoring the ack for RTT calculation if it doesn't ackno=
wledge a new packet, see section 3.1: https://tools.ietf.org/html/draft-iet=
f-quic-recovery-11#section-3.1

If it did acknowledge a new packet because the previous ACK was lost, then =
you end up with either a useless RTT, a useless max ack delay, or both.  Be=
cause of issues like this, I prefer sending acks in response to packets, or=
 within an alarm of packet receipt, rather than at other times.

On Wed, Apr 25, 2018 at 11:53 AM Jana Iyengar > wrote:
If the sender has seen a previous ack for the same largest received, then i=
t should basically ignore this new ack. If not, the ack delay will be accur=
ate... What concern do you see with having a large ack delay?

On Wed, Apr 25, 2018, 8:08 AM Subodh Iyengar > wrote:

We ran into very common cases where we might have all our data to send alre=
ady outstanding, so when a TLP and RTO alarm fires, we have no new data to =
send, so we resend data that was in previous packets.


In the time that the RTO fires, we might not have received any new packets,=
 however want to send ACKs in this new packet as well. Since no new packets=
 were received, this ACK will have the same largest acked as the previous p=
acket.


One question came up as to what the ack delay of an ACK in such a rx packet=
 should be. We could technically set it to the time since receipt of the pa=
cket, however with the new max_ack_delay computations, adding this might sc=
rew up our estimate of the normal ack delay, so I don't really want to do t=
hat. Is there a better option here, or does max_ack_delay not cover this ca=
se?


Subodh

--_000_MWHPR15MB1821A5550632E66D8133F54CB68F0MWHPR15MB1821namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











From: Subodh Iyengar

Sent: Wednesday, April 25, 2018 9:11:15 AM

To: Ian Swett; Jana Iyengar

Cc: IETF QUIC WG

Subject: Re: ack delay in rx packets

 











My concern is this situation: a =
"receiver" had not seen the original ACK (the packet was lost), t=
hen the sender rtos and sends a large ack delay to compensate for the =
rto, the max filter for max ack delay would inflate
 the delay for future packet. 









if latest_rtt - min_rtt&nbs=
p; > ack_delay:


   max_ack_delay =3D m=
ax(max_ack_delay, ack_delay)









latest_rtt in this case would be=
 rto_timer + rtt because the sender sends an ack after an rto.










The rtt cal So max ack delay wou=
ld become the rto timer. Is this a correct characterization?







Subodh












From: QUIC <quic-bounc=
es@ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ie=
tf.org>

Sent: Wednesday, April 25, 2018 9:09:39 AM

To: Jana Iyengar

Cc: Subodh Iyengar; IETF QUIC WG

Subject: Re: ack delay in rx packets

 






Jana's right about ignoring the ack for RTT calculation if=
 it doesn't acknowledge a new packet, see section 3.1: https://tools.ietf.org/html/draft-ietf-quic-recovery-11#secti=
on-3.1







If it did acknowledge a new packet because the previous ACK was lost, =
then you end up with either a useless RTT, a useless max ack delay, or both=
.  Because of issues like this, I prefer sending acks in response to p=
ackets, or within an alarm of packet
 receipt, rather than at other times.








On Wed, Apr 25, 2018 at 11:53 AM Jana Iyengar <jri.ietf@gmail.com> wrote:






If the sender has seen a previous ack for the same larges=
t received, then it should basically ignore this new ack. If not, the ack d=
elay will be accurate... What concern do you see with having a large ack de=
lay?






On Wed, Apr 25, 2018, 8:08 AM Subodh Iyengar <subodh@fb.com> wrote:









We ran into very common cases wh=
ere we might have all our data to send already outstanding, so when a TLP a=
nd RTO alarm fires, we have no new data to send, so we resend data that was=
 in previous packets.










In the time that the RTO fires, =
we might not have received any new packets, however want to send ACKs in th=
is new packet as well. Since no new packets were received, this ACK will ha=
ve the same largest acked as the previous
 packet. 









One question came up as to what =
the ack delay of an ACK in such a rx packet should be. We could technically=
 set it to the time since receipt of the packet, however with the new max_a=
ck_delay computations, adding this
 might screw up our estimate of the normal ack delay, so I don't really wan=
t to do that. Is there a better option here, or does max_ack_delay not cove=
r this case?









Subodh






















--_000_MWHPR15MB1821A5550632E66D8133F54CB68F0MWHPR15MB1821namp_--


From nobody Wed Apr 25 09:32:57 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F3A128D2E for ; Wed, 25 Apr 2018 09:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.721
X-Spam-Level: 
X-Spam-Status: No, score=-0.721 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SI9N6zNMlsc for ; Wed, 25 Apr 2018 09:32:52 -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 74E021200C5 for ; Wed, 25 Apr 2018 09:32:52 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id y3-v6so5426485ywi.10 for ; Wed, 25 Apr 2018 09:32:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FUTjzlplcN9Lp6rT1+HxtvACKwzHFqUVvW7tQrXeQRo=; b=wEET6Qy21MfNr3d1CZkJXad4j8+65VlaiWJInSQh1waovlMZuKTz4D9MLf9GRqbjD0 7bgvcY/WAGthRqyumaTsdbWRlpNYsUQJEdMitIbWwmUFwcV5UzMbkJ+VjCXyXkIFUGPI Odjg4fYYkeeiz8jfHj6AEhDNj/GbCdpc2EjQ3U2XdtFW/ZVX/IC58FS4Mup8e5cUMdv3 vDRElC1KY4JXyXazHXbwJJTyKmLoNguM45gAlkbFHurLewdpbvTd8y64+lAFeln+t11i 2n9w6/mS1J3vBby+pcpl2kmO/SPLTqj/kCeAP8FNBNgvHazcmzlowIxnRJ6mNapeLuwJ ncuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FUTjzlplcN9Lp6rT1+HxtvACKwzHFqUVvW7tQrXeQRo=; b=A1F2Aso/GrcoeGmRYYYDz3gQ0tqkra8t+h0LkhG4d88+H5SSRGZ8yNLKVGtHa+HFwT G2a+fgeP+7UNDJKCNQdSXpVmIhTLAhSOyCL3fW5HX8VBJSp5XfkGRTSrC7XcU0znqxSn QqG671UiHT4rvN3+0FieZC5ByOBmZnvxJ9F5PnmYFo9qAAscxFzBRWcsd1zKkv0rDnYG yMD6oZNhX5FgbsnjGU5duDfs/P7SMqndNj1iS+17Jwkwf4IAljRpD2tNUlSgggxYaA+o lPUQXo5ZDDx3tT4HHLh7RL2j/7DUmymbJ27K5LGJ8dnFvQKfcKavqNwdZ78HAgTYmw8K i0yg==
X-Gm-Message-State: ALQs6tDcE9ZMt3v6qFvIxvX/n/iD08aXtNRbw4q5bW1WjjcaT5oSF53d lyqs1mI3HfGRIk5Vq5wzvtCrNCRteXGFWFyVnIby4g==
X-Google-Smtp-Source: AIpwx4/3L1fchLMuVXONa9yHp3uAA9ZthRd0x/0TzBOpVf7lTLjli9Jn/MIBvtHyEo64tpMbkGfQ53kyZV2Ja7j33bM=
X-Received: by 2002:a81:26d7:: with SMTP id m206-v6mr15569697ywm.335.1524673971296;  Wed, 25 Apr 2018 09:32:51 -0700 (PDT)
MIME-Version: 1.0
References:     
In-Reply-To: 
From: Ian Swett 
Date: Wed, 25 Apr 2018 16:32:40 +0000
Message-ID: 
Subject: Re: ack delay in rx packets
To: Subodh Iyengar 
Cc: ianswett=40google.com@dmarc.ietf.org, Jana Iyengar ,  IETF QUIC WG 
Content-Type: multipart/alternative; boundary="00000000000075b753056aaed22e"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 25 Apr 2018 16:32:55 -0000

--00000000000075b753056aaed22e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm not sure it would be much better, but it's worth thinking through the
case you're describing.

It must be that no 'retransmittable'(I hate that term) packets are being
received, but you're sending packets.  If it's a one-way transfer, then
you're receiving ACKs for the data you're sending at a regular rate.  If
you bundled an ack with outgoing data every sometimes, the ack would have a
new largest acked of the received ACK packets, so all is well.

If it's a long pause, such as a TLP or RTO, then you've waited more than an
RTT and received no packets to acknowledge, but then you decide to bundle
an ACK?  At that point, it's likely the peer has already TLP'd around the
same time, so you're probably not saving them a retransmission.

It had never occurred to me to bundle an ACK in this case, but doing so
does have the side effect of creating useless RTT estimates.  We could have
a special value(already disliking this) for max_ack_delay which indicates
the ACK should not be used for RTT estimates, but I'm not sure it's
valuable to bundle an ACK with TLPs and RTOs.

On Wed, Apr 25, 2018 at 12:20 PM Subodh Iyengar  wrote:

> @Ian Swett  sending ACKs in response to packets or
> delay seems fine, and an implementation might choose to do that. If we ha=
ve
> more opportunities to send an ACK and avoid an RTO on the peer, wouldn't
> that be better? Is the objective of sending packets only during timer or
> recv data to simplify the ack delay calculation logic?
>
>
> Subodh
> ------------------------------
> *From:* Subodh Iyengar
> *Sent:* Wednesday, April 25, 2018 9:11:15 AM
> *To:* Ian Swett; Jana Iyengar
> *Cc:* IETF QUIC WG
> *Subject:* Re: ack delay in rx packets
>
>
> My concern is this situation: a "receiver" had not seen the original ACK
> (the packet was lost), then the sender rtos and sends a large ack delay t=
o
> compensate for the rto, the max filter for max ack delay would inflate th=
e
> delay for future packet.
>
>
> if latest_rtt - min_rtt  > ack_delay:
>
>    max_ack_delay =3D max(max_ack_delay, ack_delay)
>
>
> latest_rtt in this case would be rto_timer + rtt because the sender sends
> an ack after an rto.
>
>
> The rtt cal So max ack delay would become the rto timer. Is this a correc=
t
> characterization?
>
>
> Subodh
>
> ------------------------------
> *From:* QUIC  on behalf of Ian Swett  40google.com@dmarc.ietf.org>
> *Sent:* Wednesday, April 25, 2018 9:09:39 AM
> *To:* Jana Iyengar
> *Cc:* Subodh Iyengar; IETF QUIC WG
> *Subject:* Re: ack delay in rx packets
>
> Jana's right about ignoring the ack for RTT calculation if it doesn't
> acknowledge a new packet, see section 3.1:
> https://tools.ietf.org/html/draft-ietf-quic-recovery-11#section-3.1
> 
>
> If it did acknowledge a new packet because the previous ACK was lost, the=
n
> you end up with either a useless RTT, a useless max ack delay, or both.
> Because of issues like this, I prefer sending acks in response to packets=
,
> or within an alarm of packet receipt, rather than at other times.
>
> On Wed, Apr 25, 2018 at 11:53 AM Jana Iyengar  wrote:
>
> If the sender has seen a previous ack for the same largest received, then
> it should basically ignore this new ack. If not, the ack delay will be
> accurate... What concern do you see with having a large ack delay?
>
> On Wed, Apr 25, 2018, 8:08 AM Subodh Iyengar  wrote:
>
> We ran into very common cases where we might have all our data to send
> already outstanding, so when a TLP and RTO alarm fires, we have no new da=
ta
> to send, so we resend data that was in previous packets.
>
>
> In the time that the RTO fires, we might not have received any new
> packets, however want to send ACKs in this new packet as well. Since no n=
ew
> packets were received, this ACK will have the same largest acked as the
> previous packet.
>
>
> One question came up as to what the ack delay of an ACK in such a rx
> packet should be. We could technically set it to the time since receipt o=
f
> the packet, however with the new max_ack_delay computations, adding this
> might screw up our estimate of the normal ack delay, so I don't really wa=
nt
> to do that. Is there a better option here, or does max_ack_delay not cove=
r
> this case?
>
>
> Subodh
>
>

--00000000000075b753056aaed22e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'm not sure it would be much better, but it's wor=
th thinking through the case you're describing.

=
It must be that no 'retransmittable'(I hate that term) packets are =
being received, but you're sending packets.=C2=A0 If it's a one-way=
 transfer, then you're receiving ACKs for the data you're sending a=
t a regular rate.=C2=A0 If you bundled an ack with outgoing data every some=
times, the ack would have a new largest acked of the received ACK packets, =
so all is well.

If it's a long pause, such as =
a TLP or RTO, then you've waited more than an RTT and received no packe=
ts to acknowledge, but then you decide to bundle an ACK?=C2=A0 At that poin=
t, it's likely the peer has already TLP'd around the same time, so =
you're probably not saving them a retransmission.

<=
div>It had never occurred to me to bundle an ACK in this case, but doing so=
 does have the side effect of creating useless RTT estimates.=C2=A0 We coul=
d have a special value(already disliking this) for max_ack_delay which indi=
cates the ACK should not be used for RTT estimates, but I'm not sure it=
's valuable to bundle an ACK with TLPs and RTOs.
=

On Wed, Apr 25, 2018 at 12:=
20 PM Subodh Iyengar <subodh@fb.com=
> wrote:










@Ian Swett sending ACKs in response to packets or dela=
y seems fine, and an implementation might choose to do that. If we have
 more opportunities to send an ACK and avoid an RTO on the peer, wouldn'=
;t that be better? Is the objective of sending packets only during timer or=
 recv data to simplify the ack delay calculation logic?







Subodh








From: =
Subodh Iyengar

Sent: Wednesday, April 25, 2018 9:11:15 AM

To: Ian Swett; Jana Iyengar

Cc: IETF QUIC WG

Subject: Re: ack delay in rx packets

=C2=A0











My concern is this situation: a &=
quot;receiver" had not seen the original ACK (the packet was lost), th=
en the sender rtos and sends=C2=A0a large ack delay to compensate for the r=
to, the max filter for max ack delay would inflate
 the delay for future packet. 









if latest_rtt=C2=A0- min_rtt=C2=
=A0 > ack_delay:


=C2=A0 =C2=A0max_ack_delay =3D ma=
x(max_ack_delay, ack_delay)









latest_rtt in this case would be =
rto_timer + rtt because the sender sends an ack after an rto.










The rtt cal So max ack delay woul=
d become the rto timer. Is this a correct characterization?







Subodh












From: QUIC <quic-=
bounces@ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.iet=
f.org>

Sent: Wednesday, April 25, 2018 9:09:39 AM

To: Jana Iyengar

Cc: Subodh Iyengar; IETF QUIC WG

Subject: Re: ack delay in rx packets

=C2=A0






Jana's right about ignoring the ack for RTT calculatio=
n if it doesn't acknowledge a new packet, see section 3.1:=C2=A0https://tools.ietf.org/html/draft-i=
etf-quic-recovery-11#section-3.1







If it did acknowledge a new packet because the previous ACK was lost, =
then you end up with either a useless RTT, a useless max ack delay, or both=
.=C2=A0 Because of issues like this, I prefer sending acks in response to p=
ackets, or within an alarm of packet
 receipt, rather than at other times.








On Wed, Apr 25, 2018 at 11:53 AM Jana Iyengar <jri.ietf@gmail.com>=
 wrote:






If the sender has seen a previous ack for the same larges=
t received, then it should basically ignore this new ack. If not, the ack d=
elay will be accurate... What concern do you see with having a large ack de=
lay?






On Wed, Apr 25, 2018, 8:08 AM Subodh Iyengar <subodh@fb.com> wrote:









We ran into very common cases whe=
re we might have all our data to send already outstanding, so when a TLP an=
d RTO alarm fires, we have no new data to send, so we resend data that was =
in previous packets.










In the time that the RTO fires, w=
e might not have received any new packets, however want to send ACKs in thi=
s new packet as well. Since no new packets were received, this ACK will hav=
e the same largest acked as the previous
 packet. 









One question came up as to what t=
he ack delay of an ACK in such a rx packet should be. We could technically =
set it to the time since receipt of the packet, however with the new max_ac=
k_delay computations, adding this
 might screw up our estimate of the normal ack delay, so I don't really=
 want to do that. Is there a better option here, or does max_ack_delay not =
cover this case?









Subodh

























--00000000000075b753056aaed22e--


From nobody Wed Apr 25 09:48:14 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4111200C5 for ; Wed, 25 Apr 2018 09:48:12 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=lH3DDrYW; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=PoHQW8SV
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GU3SClTD-QeK for ; Wed, 25 Apr 2018 09:48:10 -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 C6939128C0A for ; Wed, 25 Apr 2018 09:48:10 -0700 (PDT)
Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3PGiUap019084; Wed, 25 Apr 2018 09:48:07 -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=s50CQA4YA9hximDi8m7S1WfhnBbDd9bQ+V1cXuSTR7E=; b=lH3DDrYWXqstGElUlGz8XTROrD0TztZzwk2jAtQR0p9tVWstOpxhdKjdlx1ag7fd08Sl p78FnYuqyFpdIEKvO6vN4WwxJe150n364THsb8uMEyYDtkzdyu6mpKOTVgZxcez7JBqm P8/CxRocKXcyYmfVVDDI+MMdolbO7GvK6ss= 
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2hjucsre48-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Apr 2018 09:48:07 -0700
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.30) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Apr 2018 12:48:05 -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=s50CQA4YA9hximDi8m7S1WfhnBbDd9bQ+V1cXuSTR7E=; b=PoHQW8SVntwGuGQrX1XAFBG9OOK8QRnowfG60BeFNxiVqrWKYwyPfA5rB7W4uasM4diPDDBMeqZH/szSoPF2TwdmDiOBeC7yXfT50pHyUogosubaamWkdNr1LxUPVRVSRDYNA3Ad3o9J1OQ1a0keFrFCliKIxRuEcvyHlOPQdY8=
Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1520.namprd15.prod.outlook.com (10.173.235.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.15; Wed, 25 Apr 2018 16:48:03 +0000
Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126%17]) with mapi id 15.20.0696.020; Wed, 25 Apr 2018 16:48:03 +0000
From: Subodh Iyengar 
To: Ian Swett 
CC: "ianswett=40google.com@dmarc.ietf.org" , Jana Iyengar , IETF QUIC WG 
Subject: Re: ack delay in rx packets
Thread-Topic: ack delay in rx packets
Thread-Index: AQHT3KYtFrc5wMFDcECav0DMEKPj+aQRoboAgAAEmYCAAABT34AAAESigAAF1wCAAACaBg==
Date: Wed, 25 Apr 2018 16:48:03 +0000
Message-ID: 
References:     , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2620:10d:c090:180::1:b93]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1520; 7:4M3HBVOZznOInoViAbgYGQgD6vxqBfcjH2Z43PGgfFoNt8H8XcMTVl8dYOQKf6Ay6GbQ58JAhj2L3/AFjqnktqApY4sxwQXJfhfZco6LlpRdKvk9lT1q4XNywIyMmfZrGj7a2oN6eN266y6OJahMmd5PQWOWq6bBGcgcv4YJ/IDCI2A1faszHvGvbomKNxwORJwPI1g7N1O8bJbPySTDNhs4f5IpQOOsXrj43CWZwfNANBoNZW67m2yAleQgGgh7; 20:sfilPjVztrS0cMck/aEutozlDesbjXwm8lT0X1VNygcrFvT1pa0bCkxVs/fZ9s3UA4ZdwGoEi8S50sAjZCV3FzbFS6Vt6vL2LG6nY2JuAERw/SwQb/81ed54kU0Ht43Uv0u+XDfl9GDqdleBH7f8UDcoUQIxjjidko618hslLUk=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1520; 
x-ms-traffictypediagnostic: MWHPR15MB1520:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(85827821059158)(265273979862326)(67672495146484)(211936372134217)(153496737603132);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231232)(11241501184)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:MWHPR15MB1520; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1520; 
x-forefront-prvs: 06530126A4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(346002)(376002)(396003)(366004)(39860400002)(189003)(199004)(99286004)(478600001)(106356001)(606006)(76176011)(14454004)(81156014)(966005)(81166006)(7696005)(6436002)(2900100001)(33656002)(8676002)(6606003)(186003)(6916009)(97736004)(476003)(7736002)(19627405001)(6116002)(55016002)(53936002)(236005)(11346002)(54906003)(446003)(9686003)(68736007)(486006)(6306002)(2906002)(6506007)(6246003)(229853002)(54896002)(5250100002)(5660300001)(86362001)(59450400001)(3280700002)(102836004)(39060400002)(4326008)(74316002)(316002)(53546011)(46003)(105586002)(3660700001)(8936002)(25786009)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1520; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: ZHiV24tS5c3HbZ4k744cPHx1Z2o70qPTYiLTfBV4TwEiYovo7CCFwOAui+MF6opEEFB50jpffOtu74EFl29e+fvg9MiabCI107YYtHJEEDx2yWAMf+pQ7b6ma491krKfckMqpXtuWAqESjCPXuSMOeMiwf/ut4KBPezY+n7f1hxNDS8ls+bn5wA9obZr5y0W
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB18219D3154C51A7B10C2D3F8B68F0MWHPR15MB1821namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 5f19f119-b5be-4fdf-a223-08d5aacc500e
X-MS-Exchange-CrossTenant-Network-Message-Id: 5f19f119-b5be-4fdf-a223-08d5aacc500e
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2018 16:48:03.4261 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1520
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-25_05:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Apr 2018 16:48:13 -0000

--_000_MWHPR15MB18219D3154C51A7B10C2D3F8B68F0MWHPR15MB1821namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It's possible that both sides will TLP at the same time assuming their RTT =
estimates are the same and both sides are tails. To see whether this happen=
s I'll have to actually look at data in practice to see whether we see whet=
her there is a delay between the server's TLP/RTO and the client's TLP/RTO.

There is also another class case which in which it might be useful to retra=
nsmit the ack without a new packet where one side does not have a tail but =
the other does. For example, in the case of a revproxy where there is an up=
stream server. The client has sent a tail request to the revproxy, which it=
 forwards to a webserver.


There are 2 cases here:

  1.  The webserver has some processing delay which is < 2 * RTT, so the re=
sponse comes back and we have new data to send. The server could also bundl=
e a duplicate ack with this packet.
  2.  The response is larger than the request, so we could have bundled som=
e dup ACKs with the response.


It is possible that the client would set an ACK timer < RTO timer and then =
send an ACK for this new packet, however if a server strictly does not ACK =
acks,  the client would still have to wait for the RTO timer.


Subodh

________________________________
From: Ian Swett 
Sent: Wednesday, April 25, 2018 9:32:40 AM
To: Subodh Iyengar
Cc: ianswett=3D40google.com@dmarc.ietf.org; Jana Iyengar; IETF QUIC WG
Subject: Re: ack delay in rx packets

I'm not sure it would be much better, but it's worth thinking through the c=
ase you're describing.

It must be that no 'retransmittable'(I hate that term) packets are being re=
ceived, but you're sending packets.  If it's a one-way transfer, then you'r=
e receiving ACKs for the data you're sending at a regular rate.  If you bun=
dled an ack with outgoing data every sometimes, the ack would have a new la=
rgest acked of the received ACK packets, so all is well.

If it's a long pause, such as a TLP or RTO, then you've waited more than an=
 RTT and received no packets to acknowledge, but then you decide to bundle =
an ACK?  At that point, it's likely the peer has already TLP'd around the s=
ame time, so you're probably not saving them a retransmission.

It had never occurred to me to bundle an ACK in this case, but doing so doe=
s have the side effect of creating useless RTT estimates.  We could have a =
special value(already disliking this) for max_ack_delay which indicates the=
 ACK should not be used for RTT estimates, but I'm not sure it's valuable t=
o bundle an ACK with TLPs and RTOs.

On Wed, Apr 25, 2018 at 12:20 PM Subodh Iyengar > wrote:

@Ian Swett sending ACKs in response to packets =
or delay seems fine, and an implementation might choose to do that. If we h=
ave more opportunities to send an ACK and avoid an RTO on the peer, wouldn'=
t that be better? Is the objective of sending packets only during timer or =
recv data to simplify the ack delay calculation logic?


Subodh

________________________________
From: Subodh Iyengar
Sent: Wednesday, April 25, 2018 9:11:15 AM
To: Ian Swett; Jana Iyengar
Cc: IETF QUIC WG
Subject: Re: ack delay in rx packets


My concern is this situation: a "receiver" had not seen the original ACK (t=
he packet was lost), then the sender rtos and sends a large ack delay to co=
mpensate for the rto, the max filter for max ack delay would inflate the de=
lay for future packet.


if latest_rtt - min_rtt  > ack_delay:

   max_ack_delay =3D max(max_ack_delay, ack_delay)


latest_rtt in this case would be rto_timer + rtt because the sender sends a=
n ack after an rto.


The rtt cal So max ack delay would become the rto timer. Is this a correct =
characterization?


Subodh


________________________________
From: QUIC > on behalf =
of Ian Swett >
Sent: Wednesday, April 25, 2018 9:09:39 AM
To: Jana Iyengar
Cc: Subodh Iyengar; IETF QUIC WG
Subject: Re: ack delay in rx packets

Jana's right about ignoring the ack for RTT calculation if it doesn't ackno=
wledge a new packet, see section 3.1: https://tools.ietf.org/html/draft-iet=
f-quic-recovery-11#section-3.1

If it did acknowledge a new packet because the previous ACK was lost, then =
you end up with either a useless RTT, a useless max ack delay, or both.  Be=
cause of issues like this, I prefer sending acks in response to packets, or=
 within an alarm of packet receipt, rather than at other times.

On Wed, Apr 25, 2018 at 11:53 AM Jana Iyengar > wrote:
If the sender has seen a previous ack for the same largest received, then i=
t should basically ignore this new ack. If not, the ack delay will be accur=
ate... What concern do you see with having a large ack delay?

On Wed, Apr 25, 2018, 8:08 AM Subodh Iyengar > wrote:

We ran into very common cases where we might have all our data to send alre=
ady outstanding, so when a TLP and RTO alarm fires, we have no new data to =
send, so we resend data that was in previous packets.


In the time that the RTO fires, we might not have received any new packets,=
 however want to send ACKs in this new packet as well. Since no new packets=
 were received, this ACK will have the same largest acked as the previous p=
acket.


One question came up as to what the ack delay of an ACK in such a rx packet=
 should be. We could technically set it to the time since receipt of the pa=
cket, however with the new max_ack_delay computations, adding this might sc=
rew up our estimate of the normal ack delay, so I don't really want to do t=
hat. Is there a better option here, or does max_ack_delay not cover this ca=
se?


Subodh

--_000_MWHPR15MB18219D3154C51A7B10C2D3F8B68F0MWHPR15MB1821namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable










It's possible that both sides wil=
l TLP at the same time assuming their RTT estimates are the same and both s=
ides are tails. To see whether this happens I'll have to actually look at d=
ata in practice to see whether we
 see whether there is a delay between the server's TLP/RTO and the client's=
 TLP/RTO.



There is also another class case which in which it might be useful to =
retransmit the ack without a new packet where one side does not have a tail=
 but the other does. For example, in the case of a revproxy where there is =
an upstream server. The client has sent
 a tail request to the revproxy, which it forwards to a webserver. 









There are 2 cases here:




    

  1. The webserver has some processing delay which is < 2 * RTT, so the r=
esponse comes back and we have new data to send. The server could also bund=
le a duplicate ack with this packet.

  2. The response is larger than the request, so we could have bundled =
some dup ACKs with the response.
    










It is possible that the client wo=
uld set an ACK timer < RTO timer and then send an ACK for this new packe=
t, however if a server strictly does not ACK acks,  the client would s=
till have to wait for the RTO timer.










Subodh








From: Ian Swett <ianswet=
t@google.com>

Sent: Wednesday, April 25, 2018 9:32:40 AM

To: Subodh Iyengar

Cc: ianswett=3D40google.com@dmarc.ietf.org; Jana Iyengar; IETF QUIC =
WG

Subject: Re: ack delay in rx packets

 






I'm not sure it would be much better, but it's worth think=
ing through the case you're describing.







It must be that no 'retransmittable'(I hate that term) packets are bei=
ng received, but you're sending packets.  If it's a one-way transfer, =
then you're receiving ACKs for the data you're sending at a regular rate.&n=
bsp; If you bundled an ack with outgoing data
 every sometimes, the ack would have a new largest acked of the received AC=
K packets, so all is well.







If it's a long pause, such as a TLP or RTO, then you've waited more th=
an an RTT and received no packets to acknowledge, but then you decide to bu=
ndle an ACK?  At that point, it's likely the peer has already TLP'd ar=
ound the same time, so you're probably
 not saving them a retransmission.







It had never occurred to me to bundle an ACK in this case, but doing s=
o does have the side effect of creating useless RTT estimates.  We cou=
ld have a special value(already disliking this) for max_ack_delay which ind=
icates the ACK should not be used for
 RTT estimates, but I'm not sure it's valuable to bundle an ACK with TLPs a=
nd RTOs.










On Wed, Apr 25, 2018 at 12:20 PM Subodh Iyengar <subodh@fb.com> wrote:








@Ian Swett sending
 ACKs in response to packets or delay seems fine, and an implementation mig=
ht choose to do that. If we have more opportunities to send an ACK and avoi=
d an RTO on the peer, wouldn't that be better? Is the objective of sending =
packets only during timer or recv
 data to simplify the ack delay calculation logic?







Subodh








From: Subodh Iyengar

Sent: Wednesday, April 25, 2018 9:11:15 AM

To: Ian Swett; Jana Iyengar

Cc: IETF QUIC WG

Subject: Re: ack delay in rx packets

 








My concern is this situation: a =
"receiver" had not seen the original ACK (the packet was lost), t=
hen the sender rtos and sends a large ack delay to compensate for the =
rto, the max filter for max ack delay would inflate
 the delay for future packet. 









if latest_rtt - min_rtt&nbs=
p; > ack_delay:


   max_ack_delay =3D m=
ax(max_ack_delay, ack_delay)









latest_rtt in this case would be=
 rto_timer + rtt because the sender sends an ack after an rto.










The rtt cal So max ack delay wou=
ld become the rto timer. Is this a correct characterization?







Subodh












From=
: QUIC <q=
uic-bounces@ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmar=
c.ietf.org>

Sent: Wednesday, April 25, 2018 9:09:39 AM

To: Jana Iyengar

Cc: Subodh Iyengar; IETF QUIC WG

Subject: Re: ack delay in rx packets

 






Jana's right about ignoring the ack for RTT calculation if=
 it doesn't acknowledge a new packet, see section 3.1: https://tools.ietf.org/html/draft-ietf-quic=
-recovery-11#section-3.1







If it did acknowledge a new packet because the previous ACK was lost, =
then you end up with either a useless RTT, a useless max ack delay, or both=
.  Because of issues like this, I prefer sending acks in response to p=
ackets, or within an alarm of packet
 receipt, rather than at other times.








On Wed, Apr 25, 2018 at 11:53 AM Jana Iyengar <jri.ietf@gmail.com>=
 wrote:






If the sender has seen a previous ack for the same larges=
t received, then it should basically ignore this new ack. If not, the ack d=
elay will be accurate... What concern do you see with having a large ack de=
lay?






On Wed, Apr 25, 2018, 8:08 AM Subodh Iyengar <subodh@fb.com> wrote:









We ran into very common cases wh=
ere we might have all our data to send already outstanding, so when a TLP a=
nd RTO alarm fires, we have no new data to send, so we resend data that was=
 in previous packets.










In the time that the RTO fires, =
we might not have received any new packets, however want to send ACKs in th=
is new packet as well. Since no new packets were received, this ACK will ha=
ve the same largest acked as the previous
 packet. 









One question came up as to what =
the ack delay of an ACK in such a rx packet should be. We could technically=
 set it to the time since receipt of the packet, however with the new max_a=
ck_delay computations, adding this
 might screw up our estimate of the normal ack delay, so I don't really wan=
t to do that. Is there a better option here, or does max_ack_delay not cove=
r this case?









Subodh






























--_000_MWHPR15MB18219D3154C51A7B10C2D3F8B68F0MWHPR15MB1821namp_--


From nobody Wed Apr 25 12:54:11 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F747129C6D for ; Wed, 25 Apr 2018 12:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tHmj7DuZu3I for ; Wed, 25 Apr 2018 12:54:07 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0114.outbound.protection.outlook.com [104.47.32.114]) (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 0B27712702E for ; Wed, 25 Apr 2018 12:54:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jcptBgnWu6h/zMIXaf+aonGKnlB4DQWF+YoUbmUgcJE=; b=XVkQy/6pm9JbQo9g+NzjOXp5ggmhN0EJNYTCynf/BxTd7vnUstLuVsU+VkWQwZe2bLN7CYY4NxiPnSdOkvLFPiMND3nmuX1O96BF0zgsUCIQ3lH4zCjWHneqyW/+llMwkJmHyM/wujvo6EGRs4FHzFn1f6Wrpuhn1t5MfEy8CQM=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1695.namprd08.prod.outlook.com (10.162.133.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.15; Wed, 25 Apr 2018 19:54:03 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::dd26:af46:4549:f472]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::dd26:af46:4549:f472%13]) with mapi id 15.20.0696.019; Wed, 25 Apr 2018 19:54:03 +0000
From: Mike Bishop 
To: Christian Huitema , "Deval, Manasi" , Mark Nottingham 
CC: "quic@ietf.org" 
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GX7TDeC7pGjkeFqjSFMKBzEaPwZ0sAgAC4ugCAAARcAIAAG5CAgAAFCACAAACJgIAAEVkAgACR+YCAB09lAIAFXyIAgAVK+oCAAJlSAIABxdSAgACOHICAB/EyAIACo7YAgABkBYA=
Date: Wed, 25 Apr 2018 19:54:03 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; 
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1695; 7:IqPV0pe+ynbQtkZcyMpxQU+WezJTpm77HCXmR6ZDcHBKBPySVfy/ysuDdGwiapiVxxJZNZRh5WT57JjpVS1P3j3aLxRo87CN99ErBToDrG/8w2HqeBnxzXUywkrnlQpcJGnyFo+qwxjpA/XDbQGXw2fQ0ntGnIIlXmjdwVnNKrlva/L11Jxsi09vLxfwD/LYgmWklWtWLwF3DODTPexCVvxokIaGaWwaJcmPB1cgIQCvWVZcVXDzoDrg5vC3xJpn
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1695; 
x-ms-traffictypediagnostic: SN1PR08MB1695:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317)(228905959029699); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231232)(944501410)(52105095)(6041310)(20161123562045)(20161123564045)(20161123560045)(2016111802025)(20161123558120)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1695; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1695; 
x-forefront-prvs: 06530126A4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(39830400003)(346002)(39380400002)(13464003)(51914003)(199004)(189003)(68736007)(106356001)(6436002)(3846002)(105586002)(6306002)(4326008)(6246003)(9686003)(53936002)(7696005)(26005)(966005)(14454004)(55016002)(478600001)(59450400001)(186003)(6116002)(305945005)(74316002)(99286004)(86362001)(76176011)(229853002)(486006)(25786009)(476003)(5250100002)(6506007)(11346002)(446003)(66066001)(3280700002)(3660700001)(81156014)(81166006)(8676002)(33656002)(316002)(2900100001)(102836004)(5660300001)(53546011)(7736002)(74482002)(97736004)(2906002)(8936002)(110136005)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1695; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 3/2gEgBghkLkA8Gp3W93w9QOUp1wML7ceHH0yDD3m+PvbPf0uZknLVPwibcyq0ivewB/oMufHZcgyWtJYUQ1w34TrRVA8ZC+7DVlN9B7Tfymk+7K4Bz21RCVb/xbGrDfncOGGsysnOMOAuZ6qxM0bgpLS00YkTdYNuOf8dPpoyhN2BZkAaEDPQZimA1JoQd3
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 3e7b056f-ee82-4088-a361-08d5aae64bcf
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e7b056f-ee82-4088-a361-08d5aae64bcf
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2018 19:54:03.2329 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1695
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 25 Apr 2018 19:54:09 -0000

WWVzIC0tIGl0IHNlZW1zIHRoYXQgdGhlIGJpZ2dlc3Qgb2JqZWN0aW9uIHRvICMxMDc5IHdhcyB0
aGUgZGlmZmljdWx0eSBpbiBoYXJkd2FyZSBpbXBsZW1lbnRhdGlvbi4gIElmIHdlJ3JlIGhlYXJp
bmcgdGhhdCBoYXJkd2FyZSBpbXBsZW1lbnRhdGlvbiBpcyBmZWFzaWJsZSBhdCBhIHJlYXNvbmFi
bGUgY29zdCwgdGhlbiBJIHRoaW5rIHdlIG1pZ2h0IGhhdmUgYSB3aW5uZXIuDQoNClRoZSBDUFUg
Y29zdCBmb3IgYSBzb2Z0d2FyZSBpbXBsZW1lbnRhdGlvbiBpcyBzdGlsbCB3b3J0aCBjb25zaWRl
cmluZywgYW5kIGFuIG9wdGlvbiB0byBub3QgZW5jcnlwdCBpcyBwcm9iYWJseSByZWFzb25hYmxl
IHRvIGxpbWl0IHRoYXQgYnVyZGVuIGZvciBpbXBsZW1lbnRhdGlvbnMgLyB1c2UgY2FzZXMgdGhh
dCBkb24ndCBjYXJlLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyA8
cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuIEh1aXRlbWENClNl
bnQ6IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTggMzoxNCBBTQ0KVG86IERldmFsLCBNYW5hc2kg
PG1hbmFzaS5kZXZhbEBpbnRlbC5jb20+OyBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ+
DQpDYzogcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9u
IHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpPbiA0LzIzLzIwMTggNjo1NSBQTSwgRGV2YWws
IE1hbmFzaSB3cm90ZToNCg0KPiBJIGhhZCBicm91Z2h0IHVwIHRoZSBpc3N1ZSB3aXRoIFBORSBz
ZXZlcmFsIHdlZWtzIGFnbyBhcyBhIGJhcnJpZXIgdG8gaGFyZHdhcmUgb2ZmbG9hZC4gQWZ0ZXIg
ZnVydGhlciByZXZpZXcsIGl0IGxvb2tzIGxpa2UgYSBoYXJkd2FyZSBvZmZsb2FkIGNhbiBpbXBs
ZW1lbnQgdGhlIFBORSBhdCBhIHNtYWxsIGNvc3QuIA0KPg0KPiBUaGUgaW1wbGVtZW50YXRpb24g
Y2FuIG1vZGlmeSBjdXJyZW50IEhXIGNyeXB0byBhY2NlbGVyYXRvcnMgdG8gc3VwcG9ydCBlbmNy
eXB0aW5nIGEgYnVmZmVyIGluIHRoZSBmaXJzdCBwYXNzIGFuZCB0aGVuIGVuY3J5cHRpbmcgcGFj
a2V0IG51bWJlciBpbiB0aGUgMm5kIHBhc3MgYXMgYWxyZWFkeSBkaXNjdXNzZWQgb24gdGhpcyB0
aHJlYWQuIFRoZSBleGFjdCByZXF1aXJlbWVudCAoaGVhZGVyIGNoZWNrc3VtLCBwYWNrZXQgbGVu
Z3RoIGVuY29kaW5nKSBpcyBzdGlsbCBpbiBmbHV4IHNvIHRoZXJlIG1heSBiZSBzb21lIHNtYWxs
IHZhcmlhdGlvbnMgZGVwZW5kaW5nIG9uIHRoZSBhY2NlbGVyYXRvciBhbmQgZmluYWwgYWxnb3Jp
dGhtIGNob3NlbiBmb3IgUE5FLiBGdXR1cmUgb2ZmbG9hZCBkZXNpZ25zIGNhbiBkbyBtb3JlIHRv
IGZ1cnRoZXIgcmVkdWNlIHRoZSBvdmVyaGVhZC4NCg0KVGhhbmtzIGZvciB0aGUgaW5mb3JtYXRp
b24sIE1hbmFzaS4gSSBoYXZlIG1vZGlmaWVkIHRoZSB3aWtpIHBhZ2UgZGVzY3JpYmluZyB0aGUg
UE5FIGlzc3VlcyBhbmQgYWx0ZXJuYXRpdmVzIHRvIHJlZmxlY3QgdGhpcyBuZXcgZGF0YToNCmh0
dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvd2lraS9TdW1tYXJ5LW9mLXRoZS1Q
Ti1lbmNyeXB0aW9uLWlzc3Vlcy1hbmQtYWx0ZXJuYXRpdmVzLg0KV2l0aCB0aGF0IG5ldyBpbmZv
cm1hdGlvbiwgaXQgYXBwZWFycyB0aGF0IFBSICMxMDc5IGlzIHN1cGVyaW9yIHRvIGV2ZXJ5IG90
aGVyIGFsdGVybmF0aXZlLg0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQo=


From nobody Wed Apr 25 12:57:13 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8416129C6E for ; Wed, 25 Apr 2018 12:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1vb-_SOfeGj for ; Wed, 25 Apr 2018 12:57:09 -0700 (PDT)
Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A18612702E for ; Wed, 25 Apr 2018 12:57:09 -0700 (PDT)
Received: by mail-yb0-x22f.google.com with SMTP id q74-v6so8667977ybg.6 for ; Wed, 25 Apr 2018 12:57:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5BkfTKIRIDA9kuGZtgqFZrkT2SoGCHIZJySq8w2YDQs=; b=pvDYNm1NxdSKf/R531/T2hy9tySBUC8O+9sZWscf8lhktQDSu2lgK6ZdBzqUDlc37v rD0lgJiB6oW3YRwjupcCPYo1faX1ztRvBKhIVfR2kGwwuEqxQSrXVcuE2boaD11KV/DJ I+3EfLnbhokdpxVlu0IKnFPQ5A7DtAe84UKix89MvwTuOS8rVhHpOB6ds4NP9cd2TR+y j+VsbRsJFfngHH8oSCl+ZXkAE6vLczCjoyXOIAvGdhdAzjJpTviD+Gv2EvaAhp1eH9LD k/251cDxLOLLjASq59Q2okeR1CDGPw5UjfsBb/9KDFHpzgIJLBZfrPxzl4ztQZw20gEZ 29rA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5BkfTKIRIDA9kuGZtgqFZrkT2SoGCHIZJySq8w2YDQs=; b=s19MEp9hr1iXdnZS+Y4+e9RXz06T5m+9UafmbaRE+s0iV0NA9C8xQqDAsP2D6GJLof BdZ+oTy2AKQJqk/4EV2E/dslO+Deiu7smfCzi2pV3yyafVbhNfArDoS+7MK4WnT958lE J1qL9lk6iQTmjtCNR78R3szJqWwCwdYXKqcXvClHqPkhwgQHvwkomtcJBYieYiKp+ceY 0cVkNSW0kW8YcRXDrF+sXZgmmtje9VegZGaedd6dVAGSaVYEOOdU7DHjcTmRsdobnQSk QbqneSoQEkwMNpKA0Hf4V4lDXf+ftYTYclGLpbSFoqwaghk/+VkMJ9MUUjoLv47L63i1 MUuw==
X-Gm-Message-State: ALQs6tA4GfG8HllaeHtpfi01bUIqwTjYRVzY/kBIic7a0QXcGNNON5d7 7DmmlpPvGsmxUS1Sn+4ngGzDzig9d81Oc0ohabpNmA==
X-Google-Smtp-Source: AIpwx4+xFvgoHxqrr9Je4itmZ6WxMV48h3lVJlAhUjbai565VN9f9D92YqvJv9lt9Xi8+D4lI5t2sMo6YC2Y55OfDGc=
X-Received: by 2002:a25:386:: with SMTP id 128-v6mr16723573ybd.241.1524686228572;  Wed, 25 Apr 2018 12:57:08 -0700 (PDT)
MIME-Version: 1.0
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>  
In-Reply-To: 
From: Ian Swett 
Date: Wed, 25 Apr 2018 19:56:57 +0000
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Mike Bishop 
Cc: Christian Huitema , "Deval, Manasi" ,  Mark Nottingham , IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000000cd473056ab1ad97"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 25 Apr 2018 19:57:12 -0000

--0000000000000cd473056ab1ad97
Content-Type: text/plain; charset="UTF-8"

Hi Mike,

To clarify, are you suggesting adding a way to disable packet number
encryption via negotiation in the v1 spec as well as adopting #1079?  Or
would the choice of whether PNE is to be used unilateral, such as a
transport param?

On Wed, Apr 25, 2018 at 3:54 PM Mike Bishop  wrote:

> Yes -- it seems that the biggest objection to #1079 was the difficulty in
> hardware implementation.  If we're hearing that hardware implementation is
> feasible at a reasonable cost, then I think we might have a winner.
>
> The CPU cost for a software implementation is still worth considering, and
> an option to not encrypt is probably reasonable to limit that burden for
> implementations / use cases that don't care.
>
> -----Original Message-----
> From: QUIC  On Behalf Of Christian Huitema
> Sent: Wednesday, April 25, 2018 3:14 AM
> To: Deval, Manasi ; Mark Nottingham  >
> Cc: quic@ietf.org
> Subject: Re: Getting to consensus on packet number encryption
>
> On 4/23/2018 6:55 PM, Deval, Manasi wrote:
>
> > I had brought up the issue with PNE several weeks ago as a barrier to
> hardware offload. After further review, it looks like a hardware offload
> can implement the PNE at a small cost.
> >
> > The implementation can modify current HW crypto accelerators to support
> encrypting a buffer in the first pass and then encrypting packet number in
> the 2nd pass as already discussed on this thread. The exact requirement
> (header checksum, packet length encoding) is still in flux so there may be
> some small variations depending on the accelerator and final algorithm
> chosen for PNE. Future offload designs can do more to further reduce the
> overhead.
>
> Thanks for the information, Manasi. I have modified the wiki page
> describing the PNE issues and alternatives to reflect this new data:
>
> https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-issues-and-alternatives
> .
> With that new information, it appears that PR #1079 is superior to every
> other alternative.
>
> -- Christian Huitema
>
>

--0000000000000cd473056ab1ad97
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Mike,

To clarify, are you sugges=
ting adding a way to disable packet number encryption via negotiation in th=
e v1 spec as well as adopting #1079?=C2=A0 Or would the choice of whether P=
NE is to be used unilateral, such as a transport param?

On Wed, Apr 25, 2018 at 3:54 PM Mik=
e Bishop <mbishop@evequefou.be> wrote:
Yes -- it seems that =
the biggest objection to #1079 was the difficulty in hardware implementatio=
n.=C2=A0 If we're hearing that hardware implementation is feasible at a=
 reasonable cost, then I think we might have a winner.



The CPU cost for a software implementation is still worth considering, and =
an option to not encrypt is probably reasonable to limit that burden for im=
plementations / use cases that don't care.



-----Original Message-----

From: QUIC <q=
uic-bounces@ietf.org> On Behalf Of Christian Huitema

Sent: Wednesday, April 25, 2018 3:14 AM

To: Deval, Manasi <manasi.deval@intel.com>; Mark Nottingham <mnot@mnot.net>

Cc: quic@ietf.org
Subject: Re: Getting to consensus on packet number encryption



On 4/23/2018 6:55 PM, Deval, Manasi wrote:



> I had brought up the issue with PNE several weeks ago as a barrier to =
hardware offload. After further review, it looks like a hardware offload ca=
n implement the PNE at a small cost. 

>

> The implementation can modify current HW crypto accelerators to suppor=
t encrypting a buffer in the first pass and then encrypting packet number i=
n the 2nd pass as already discussed on this thread. The exact requirement (=
header checksum, packet length encoding) is still in flux so there may be s=
ome small variations depending on the accelerator and final algorithm chose=
n for PNE. Future offload designs can do more to further reduce the overhea=
d.



Thanks for the information, Manasi. I have modified the wiki page describin=
g the PNE issues and alternatives to reflect this new data:

https=
://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-issues-a=
nd-alternatives.

With that new information, it appears that PR #1079 is superior to every ot=
her alternative.



-- Christian Huitema






--0000000000000cd473056ab1ad97--


From nobody Wed Apr 25 15:01:48 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D69126CBF for ; Wed, 25 Apr 2018 15:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJPmfik1MdUK for ; Wed, 25 Apr 2018 15:01:44 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0137.outbound.protection.outlook.com [104.47.40.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 8F2C212D82F for ; Wed, 25 Apr 2018 15:01:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8gZH5UO7PVn1jG4Gt0m3igP+ka4Zju2cMHkCvcSZiJQ=; b=kXvpKx6OGfL6RjxBnIXvLhwdroJFMiCtf92g6U9cP8q4Y/d2nCab0QFulTT0siSic8RxVQ+UY1fmD7LHQUf4YQWxB5bPLvbQU3+GDWHgInQBPQdF2uGTpq1yDccbWf8Fv79RcuNsKUVZ8+MQ4RcEQ/fgpbxloQPBXNizSbh3UKE=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1791.namprd08.prod.outlook.com (10.162.134.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.15; Wed, 25 Apr 2018 22:01:32 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::dd26:af46:4549:f472]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::dd26:af46:4549:f472%13]) with mapi id 15.20.0696.019; Wed, 25 Apr 2018 22:01:32 +0000
From: Mike Bishop 
To: Ian Swett 
CC: Christian Huitema , "Deval, Manasi" , Mark Nottingham , IETF QUIC WG 
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GX7TDeC7pGjkeFqjSFMKBzEaPwZ0sAgAC4ugCAAARcAIAAG5CAgAAFCACAAACJgIAAEVkAgACR+YCAB09lAIAFXyIAgAVK+oCAAJlSAIABxdSAgACOHICAB/EyAIACo7YAgABkBYCAAD76gIAAIlew
Date: Wed, 25 Apr 2018 22:01:32 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; 
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1791; 7:dutrBMhOmPu0EFtCnnvGavS343v6DvmCPl1x8KDHMhkYmlhkdVuCsGgFh2BySpGRC5lUgFkfSiuLIWK6b9j51KaAtxO5J3a+kMsHtrNHln3qIMGYqzxncq1Do5Vk0x/6swocK7XVTwRyouz9L2OIjlDYSQrq+0zzPub0tYBoJ+RQy3K+ir854SOtkmqQ2MjLmvneWAs70rnYCNZ5Z+1dX/9jpgwOrq+G4glMsKdSgvy7WIhbZ7Ocbxkpur89EtWb
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1791; 
x-ms-traffictypediagnostic: SN1PR08MB1791:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(211936372134217)(100405760836317)(21748063052155)(228905959029699);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231232)(944501410)(52105095)(10201501046)(3002001)(6041310)(20161123558120)(2016111802025)(20161123564045)(20161123560045)(20161123562045)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1791; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1791; 
x-forefront-prvs: 06530126A4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(346002)(396003)(366004)(39380400002)(376002)(51444003)(51914003)(13464003)(189003)(199004)(25786009)(86362001)(966005)(74316002)(476003)(186003)(8936002)(11346002)(236005)(54896002)(5250100002)(53936002)(81156014)(81166006)(9686003)(229853002)(7736002)(4326008)(106356001)(6436002)(14971765001)(59450400001)(6306002)(478600001)(6246003)(446003)(33656002)(6506007)(8676002)(55016002)(74482002)(2906002)(6116002)(76176011)(93886005)(6916009)(606006)(5660300001)(102836004)(790700001)(53546011)(99286004)(26005)(14454004)(2900100001)(3846002)(486006)(19609705001)(68736007)(3660700001)(316002)(66066001)(54906003)(105586002)(97736004)(7696005)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1791; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Rj7KN2iNmx5EK+I2N+HWwJ6F3ZfSKvC6O+qJwEVyU5PGK0Abk+e6enO8wl6vchdLBAHvVpEeoZwVeSuZRdWMJZ3JxI1oGLrC5p6uRDWHUNfxPgzrmaStYEwWtOReDZKMAHtvz8ciP4HkbpgLynBO/YgtzytzcxDJNJT1sm8kXyo4D8A3RkengbB/onQ9mQV/
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR08MB18545D0554DED1F83862EBFBDA8F0SN1PR08MB1854namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 660d37a2-d852-45b6-ac61-08d5aaf81ae1
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 660d37a2-d852-45b6-ac61-08d5aaf81ae1
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2018 22:01:32.1151 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1791
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 25 Apr 2018 22:01:47 -0000

--_000_SN1PR08MB18545D0554DED1F83862EBFBDA8F0SN1PR08MB1854namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB0aGluayB0aGF04oCZcyBiZWVuIHN1Z2dlc3RlZCBiZWZvcmUsIHRob3VnaCB3ZeKAmWQgbmVl
ZCB0byBzb3J0IG91dCB0aGUgZGV0YWlscyBvZiB3aGF0IHRoYXQgbG9va3MgbGlrZS4gIEkgZG9u
4oCZdCBoYXZlIGEgcGFydGljdWxhciBkZXNpZ24gaW4gbWluZC4NCg0KRnJvbTogSWFuIFN3ZXR0
IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjUs
IDIwMTggMTI6NTcgUE0NClRvOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU+DQpD
YzogQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+OyBEZXZhbCwgTWFuYXNp
IDxtYW5hc2kuZGV2YWxAaW50ZWwuY29tPjsgTWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0
PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IEdldHRpbmcgdG8g
Y29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpIaSBNaWtlLA0KDQpUbyBj
bGFyaWZ5LCBhcmUgeW91IHN1Z2dlc3RpbmcgYWRkaW5nIGEgd2F5IHRvIGRpc2FibGUgcGFja2V0
IG51bWJlciBlbmNyeXB0aW9uIHZpYSBuZWdvdGlhdGlvbiBpbiB0aGUgdjEgc3BlYyBhcyB3ZWxs
IGFzIGFkb3B0aW5nICMxMDc5PyAgT3Igd291bGQgdGhlIGNob2ljZSBvZiB3aGV0aGVyIFBORSBp
cyB0byBiZSB1c2VkIHVuaWxhdGVyYWwsIHN1Y2ggYXMgYSB0cmFuc3BvcnQgcGFyYW0/DQoNCk9u
IFdlZCwgQXByIDI1LCAyMDE4IGF0IDM6NTQgUE0gTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVl
Zm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+IHdyb3RlOg0KWWVzIC0tIGl0IHNl
ZW1zIHRoYXQgdGhlIGJpZ2dlc3Qgb2JqZWN0aW9uIHRvICMxMDc5IHdhcyB0aGUgZGlmZmljdWx0
eSBpbiBoYXJkd2FyZSBpbXBsZW1lbnRhdGlvbi4gIElmIHdlJ3JlIGhlYXJpbmcgdGhhdCBoYXJk
d2FyZSBpbXBsZW1lbnRhdGlvbiBpcyBmZWFzaWJsZSBhdCBhIHJlYXNvbmFibGUgY29zdCwgdGhl
biBJIHRoaW5rIHdlIG1pZ2h0IGhhdmUgYSB3aW5uZXIuDQoNClRoZSBDUFUgY29zdCBmb3IgYSBz
b2Z0d2FyZSBpbXBsZW1lbnRhdGlvbiBpcyBzdGlsbCB3b3J0aCBjb25zaWRlcmluZywgYW5kIGFu
IG9wdGlvbiB0byBub3QgZW5jcnlwdCBpcyBwcm9iYWJseSByZWFzb25hYmxlIHRvIGxpbWl0IHRo
YXQgYnVyZGVuIGZvciBpbXBsZW1lbnRhdGlvbnMgLyB1c2UgY2FzZXMgdGhhdCBkb24ndCBjYXJl
Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2Vz
QGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgQ2hy
aXN0aWFuIEh1aXRlbWENClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTggMzoxNCBBTQ0K
VG86IERldmFsLCBNYW5hc2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5jb208bWFpbHRvOm1hbmFzaS5k
ZXZhbEBpbnRlbC5jb20+PjsgTWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0PG1haWx0bzpt
bm90QG1ub3QubmV0Pj4NCkNjOiBxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPg0K
U3ViamVjdDogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlw
dGlvbg0KDQpPbiA0LzIzLzIwMTggNjo1NSBQTSwgRGV2YWwsIE1hbmFzaSB3cm90ZToNCg0KPiBJ
IGhhZCBicm91Z2h0IHVwIHRoZSBpc3N1ZSB3aXRoIFBORSBzZXZlcmFsIHdlZWtzIGFnbyBhcyBh
IGJhcnJpZXIgdG8gaGFyZHdhcmUgb2ZmbG9hZC4gQWZ0ZXIgZnVydGhlciByZXZpZXcsIGl0IGxv
b2tzIGxpa2UgYSBoYXJkd2FyZSBvZmZsb2FkIGNhbiBpbXBsZW1lbnQgdGhlIFBORSBhdCBhIHNt
YWxsIGNvc3QuDQo+DQo+IFRoZSBpbXBsZW1lbnRhdGlvbiBjYW4gbW9kaWZ5IGN1cnJlbnQgSFcg
Y3J5cHRvIGFjY2VsZXJhdG9ycyB0byBzdXBwb3J0IGVuY3J5cHRpbmcgYSBidWZmZXIgaW4gdGhl
IGZpcnN0IHBhc3MgYW5kIHRoZW4gZW5jcnlwdGluZyBwYWNrZXQgbnVtYmVyIGluIHRoZSAybmQg
cGFzcyBhcyBhbHJlYWR5IGRpc2N1c3NlZCBvbiB0aGlzIHRocmVhZC4gVGhlIGV4YWN0IHJlcXVp
cmVtZW50IChoZWFkZXIgY2hlY2tzdW0sIHBhY2tldCBsZW5ndGggZW5jb2RpbmcpIGlzIHN0aWxs
IGluIGZsdXggc28gdGhlcmUgbWF5IGJlIHNvbWUgc21hbGwgdmFyaWF0aW9ucyBkZXBlbmRpbmcg
b24gdGhlIGFjY2VsZXJhdG9yIGFuZCBmaW5hbCBhbGdvcml0aG0gY2hvc2VuIGZvciBQTkUuIEZ1
dHVyZSBvZmZsb2FkIGRlc2lnbnMgY2FuIGRvIG1vcmUgdG8gZnVydGhlciByZWR1Y2UgdGhlIG92
ZXJoZWFkLg0KDQpUaGFua3MgZm9yIHRoZSBpbmZvcm1hdGlvbiwgTWFuYXNpLiBJIGhhdmUgbW9k
aWZpZWQgdGhlIHdpa2kgcGFnZSBkZXNjcmliaW5nIHRoZSBQTkUgaXNzdWVzIGFuZCBhbHRlcm5h
dGl2ZXMgdG8gcmVmbGVjdCB0aGlzIG5ldyBkYXRhOg0KaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3
Zy9iYXNlLWRyYWZ0cy93aWtpL1N1bW1hcnktb2YtdGhlLVBOLWVuY3J5cHRpb24taXNzdWVzLWFu
ZC1hbHRlcm5hdGl2ZXMuDQpXaXRoIHRoYXQgbmV3IGluZm9ybWF0aW9uLCBpdCBhcHBlYXJzIHRo
YXQgUFIgIzEwNzkgaXMgc3VwZXJpb3IgdG8gZXZlcnkgb3RoZXIgYWx0ZXJuYXRpdmUuDQoNCi0t
IENocmlzdGlhbiBIdWl0ZW1hDQo=

--_000_SN1PR08MB18545D0554DED1F83862EBFBDA8F0SN1PR08MB1854namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
IHRoaW5rIHRoYXTigJlzIGJlZW4gc3VnZ2VzdGVkIGJlZm9yZSwgdGhvdWdoIHdl4oCZZCBuZWVk
IHRvIHNvcnQgb3V0IHRoZSBkZXRhaWxzIG9mIHdoYXQgdGhhdCBsb29rcyBsaWtlLiZuYnNwOyBJ
IGRvbuKAmXQgaGF2ZSBhIHBhcnRpY3VsYXIgZGVzaWduIGluIG1pbmQuPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxiPkZyb206PC9iPiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUu
Y29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxOCAxMjo1NyBQ
TTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJlJmd0
Ozxicj4NCjxiPkNjOjwvYj4gQ2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5u
ZXQmZ3Q7OyBEZXZhbCwgTWFuYXNpICZsdDttYW5hc2kuZGV2YWxAaW50ZWwuY29tJmd0OzsgTWFy
ayBOb3R0aW5naGFtICZsdDttbm90QG1ub3QubmV0Jmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWlj
QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogR2V0dGluZyB0byBjb25zZW5z
dXMgb24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5IaSBNaWtlLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+VG8gY2xhcmlmeSwgYXJlIHlvdSBzdWdnZXN0aW5nIGFkZGluZyBhIHdheSB0byBkaXNhYmxl
IHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbiB2aWEgbmVnb3RpYXRpb24gaW4gdGhlIHYxIHNwZWMg
YXMgd2VsbCBhcyBhZG9wdGluZyAjMTA3OT8mbmJzcDsgT3Igd291bGQgdGhlIGNob2ljZSBvZiB3
aGV0aGVyIFBORSBpcyB0byBiZSB1c2VkIHVuaWxhdGVyYWwsIHN1Y2ggYXMgYSB0cmFuc3BvcnQg
cGFyYW0/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk9uIFdlZCwgQXByIDI1LCAyMDE4IGF0IDM6NTQgUE0gTWlrZSBCaXNob3AgJmx0OzxhIGhy
ZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+WWVzIC0tIGl0IHNlZW1z
IHRoYXQgdGhlIGJpZ2dlc3Qgb2JqZWN0aW9uIHRvICMxMDc5IHdhcyB0aGUgZGlmZmljdWx0eSBp
biBoYXJkd2FyZSBpbXBsZW1lbnRhdGlvbi4mbmJzcDsgSWYgd2UncmUgaGVhcmluZyB0aGF0IGhh
cmR3YXJlIGltcGxlbWVudGF0aW9uIGlzIGZlYXNpYmxlIGF0IGEgcmVhc29uYWJsZSBjb3N0LCB0
aGVuIEkgdGhpbmsgd2UgbWlnaHQgaGF2ZQ0KIGEgd2lubmVyLjxicj4NCjxicj4NClRoZSBDUFUg
Y29zdCBmb3IgYSBzb2Z0d2FyZSBpbXBsZW1lbnRhdGlvbiBpcyBzdGlsbCB3b3J0aCBjb25zaWRl
cmluZywgYW5kIGFuIG9wdGlvbiB0byBub3QgZW5jcnlwdCBpcyBwcm9iYWJseSByZWFzb25hYmxl
IHRvIGxpbWl0IHRoYXQgYnVyZGVuIGZvciBpbXBsZW1lbnRhdGlvbnMgLyB1c2UgY2FzZXMgdGhh
dCBkb24ndCBjYXJlLjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K
RnJvbTogUVVJQyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBD
aHJpc3RpYW4gSHVpdGVtYTxicj4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTggMzox
NCBBTTxicj4NClRvOiBEZXZhbCwgTWFuYXNpICZsdDs8YSBocmVmPSJtYWlsdG86bWFuYXNpLmRl
dmFsQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hbmFzaS5kZXZhbEBpbnRlbC5jb208L2E+
Jmd0OzsgTWFyayBOb3R0aW5naGFtICZsdDs8YSBocmVmPSJtYWlsdG86bW5vdEBtbm90Lm5ldCIg
dGFyZ2V0PSJfYmxhbmsiPm1ub3RAbW5vdC5uZXQ8L2E+Jmd0Ozxicj4NCkNjOiA8YSBocmVmPSJt
YWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+PGJy
Pg0KU3ViamVjdDogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5j
cnlwdGlvbjxicj4NCjxicj4NCk9uIDQvMjMvMjAxOCA2OjU1IFBNLCBEZXZhbCwgTWFuYXNpIHdy
b3RlOjxicj4NCjxicj4NCiZndDsgSSBoYWQgYnJvdWdodCB1cCB0aGUgaXNzdWUgd2l0aCBQTkUg
c2V2ZXJhbCB3ZWVrcyBhZ28gYXMgYSBiYXJyaWVyIHRvIGhhcmR3YXJlIG9mZmxvYWQuIEFmdGVy
IGZ1cnRoZXIgcmV2aWV3LCBpdCBsb29rcyBsaWtlIGEgaGFyZHdhcmUgb2ZmbG9hZCBjYW4gaW1w
bGVtZW50IHRoZSBQTkUgYXQgYSBzbWFsbCBjb3N0Lg0KPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhl
IGltcGxlbWVudGF0aW9uIGNhbiBtb2RpZnkgY3VycmVudCBIVyBjcnlwdG8gYWNjZWxlcmF0b3Jz
IHRvIHN1cHBvcnQgZW5jcnlwdGluZyBhIGJ1ZmZlciBpbiB0aGUgZmlyc3QgcGFzcyBhbmQgdGhl
biBlbmNyeXB0aW5nIHBhY2tldCBudW1iZXIgaW4gdGhlIDJuZCBwYXNzIGFzIGFscmVhZHkgZGlz
Y3Vzc2VkIG9uIHRoaXMgdGhyZWFkLiBUaGUgZXhhY3QgcmVxdWlyZW1lbnQgKGhlYWRlciBjaGVj
a3N1bSwgcGFja2V0IGxlbmd0aCBlbmNvZGluZykNCiBpcyBzdGlsbCBpbiBmbHV4IHNvIHRoZXJl
IG1heSBiZSBzb21lIHNtYWxsIHZhcmlhdGlvbnMgZGVwZW5kaW5nIG9uIHRoZSBhY2NlbGVyYXRv
ciBhbmQgZmluYWwgYWxnb3JpdGhtIGNob3NlbiBmb3IgUE5FLiBGdXR1cmUgb2ZmbG9hZCBkZXNp
Z25zIGNhbiBkbyBtb3JlIHRvIGZ1cnRoZXIgcmVkdWNlIHRoZSBvdmVyaGVhZC48YnI+DQo8YnI+
DQpUaGFua3MgZm9yIHRoZSBpbmZvcm1hdGlvbiwgTWFuYXNpLiBJIGhhdmUgbW9kaWZpZWQgdGhl
IHdpa2kgcGFnZSBkZXNjcmliaW5nIHRoZSBQTkUgaXNzdWVzIGFuZCBhbHRlcm5hdGl2ZXMgdG8g
cmVmbGVjdCB0aGlzIG5ldyBkYXRhOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9x
dWljd2cvYmFzZS1kcmFmdHMvd2lraS9TdW1tYXJ5LW9mLXRoZS1QTi1lbmNyeXB0aW9uLWlzc3Vl
cy1hbmQtYWx0ZXJuYXRpdmVzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3F1
aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL1N1bW1hcnktb2YtdGhlLVBOLWVuY3J5cHRpb24taXNzdWVz
LWFuZC1hbHRlcm5hdGl2ZXM8L2E+Ljxicj4NCldpdGggdGhhdCBuZXcgaW5mb3JtYXRpb24sIGl0
IGFwcGVhcnMgdGhhdCBQUiAjMTA3OSBpcyBzdXBlcmlvciB0byBldmVyeSBvdGhlciBhbHRlcm5h
dGl2ZS48YnI+DQo8YnI+DQotLSBDaHJpc3RpYW4gSHVpdGVtYTxvOnA+PC9vOnA+PC9wPg0KPC9i
bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_SN1PR08MB18545D0554DED1F83862EBFBDA8F0SN1PR08MB1854namp_--


From nobody Wed Apr 25 17:21:21 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B101912DA0C for ; Wed, 25 Apr 2018 17:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnfIEPltwlbF for ; Wed, 25 Apr 2018 17:21:17 -0700 (PDT)
Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4EF512D965 for ; Wed, 25 Apr 2018 17:21:16 -0700 (PDT)
Received: by mail-yb0-x231.google.com with SMTP id q74-v6so8864456ybg.6 for ; Wed, 25 Apr 2018 17:21:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lgKKUS20Zkpom8wkIc5zLEv5iNXw7MsefjQGmCAgf3M=; b=opXMe/4t/FRQa6ftG0tyOKQwnRCvHz7f8RUFXB9oTUL+tNmj2K1N50mG0AuRfNYruo +FEs2RKK5ZClRttfdeNqLUEnD30YQs1II2bDbfSpjUN8QLDlBzOOInULcuEMS7TdWPHN eALYI70Yhq+huftWjHDRWLiTQlyGYRRgh4jz/WKSOvHwR/sVFrfbiTd7/ocAtt6aY6Du FcA5vwd6wOulMauZ0z+mjvTT3HfZInxhzkxEv8sR8qg4HZc2BWrVrRzOBM60jj4bka0N c1QDQ4101RQlXSVNx5uJr3i8oXpcrVQbKETPl8psRNnBVPKw7gYdX0OfZFa31p0cJ+pY hbMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lgKKUS20Zkpom8wkIc5zLEv5iNXw7MsefjQGmCAgf3M=; b=Mf+rmUEnhrJaE7HPFbPemPgRLBYh85pp6OrKfqTuBwQ8es0eCVBfFWVBGTJziGETvV kt0YJex30ugd7qpdWwmBsic9wPGSn6bOcGt1kId8s1sUrUvbT446sAcSpX7tHFqTu3Sk QNak+0IyfhmLw+B9eiZQMwPiEJISGzxJw9tyci4FUOsqZ/NQBHYUBd8HyAuTZda0FeAK k+3I/o7aNs36nYGsrWeEC6BTxaZXcVJ+T+DaCjIVrrxI2D47yFqeqLKKyqTP0xvJtJoz 74zHLooTjGSruQwwajQrAh8rxSnq3kJ/HbkYaUrXmM+eh1eokr3pODzpk8+npc37zaXI 6zkg==
X-Gm-Message-State: ALQs6tC529tSvy/5/KYKOXU3y8hT0UHiTwq8S9cQ047QtKumQ8LFn1DY LokrMJfdVFBg12cT9K8mKTEU/Gg60uxK63IFHTP/iQ==
X-Google-Smtp-Source: AIpwx48udS7f1T4YwvJLbiIskK15+cpAAuyl1LmF5kRHfrXttzW+qZ2N+8GMMJ9iTAfhuMbhzpA7fPskrj4VqSSHuvk=
X-Received: by 2002:a5b:c0e:: with SMTP id f14-v6mr17102764ybq.107.1524702075819;  Wed, 25 Apr 2018 17:21:15 -0700 (PDT)
MIME-Version: 1.0
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>    
In-Reply-To: 
From: Ian Swett 
Date: Thu, 26 Apr 2018 00:21:05 +0000
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Mike Bishop 
Cc: Christian Huitema , "Deval, Manasi" ,  Mark Nottingham , IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000009ec683056ab55dd9"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 26 Apr 2018 00:21:20 -0000

--0000000000009ec683056ab55dd9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It has been, and I'm personally supportive of it, because I believe it'll
be useful for datacenter QUIC use cases.

But the WG has to decide:
 1) Is it allowable to disable PNE?
 2) What the mechanism is?  ie: Unilateral via TransportParams or
negotiated via an extension or ?

On Wed, Apr 25, 2018 at 6:01 PM Mike Bishop  wrote:

> I think that=E2=80=99s been suggested before, though we=E2=80=99d need to=
 sort out the
> details of what that looks like.  I don=E2=80=99t have a particular desig=
n in mind.
>
>
>
> *From:* Ian Swett [mailto:ianswett@google.com]
> *Sent:* Wednesday, April 25, 2018 12:57 PM
> *To:* Mike Bishop 
> *Cc:* Christian Huitema ; Deval, Manasi <
> manasi.deval@intel.com>; Mark Nottingham ; IETF QUIC WG <
> quic@ietf.org>
> *Subject:* Re: Getting to consensus on packet number encryption
>
>
>
> Hi Mike,
>
>
>
> To clarify, are you suggesting adding a way to disable packet number
> encryption via negotiation in the v1 spec as well as adopting #1079?  Or
> would the choice of whether PNE is to be used unilateral, such as a
> transport param?
>
>
>
> On Wed, Apr 25, 2018 at 3:54 PM Mike Bishop  wrote:
>
> Yes -- it seems that the biggest objection to #1079 was the difficulty in
> hardware implementation.  If we're hearing that hardware implementation i=
s
> feasible at a reasonable cost, then I think we might have a winner.
>
> The CPU cost for a software implementation is still worth considering, an=
d
> an option to not encrypt is probably reasonable to limit that burden for
> implementations / use cases that don't care.
>
> -----Original Message-----
> From: QUIC  On Behalf Of Christian Huitema
> Sent: Wednesday, April 25, 2018 3:14 AM
> To: Deval, Manasi ; Mark Nottingham  >
> Cc: quic@ietf.org
> Subject: Re: Getting to consensus on packet number encryption
>
> On 4/23/2018 6:55 PM, Deval, Manasi wrote:
>
> > I had brought up the issue with PNE several weeks ago as a barrier to
> hardware offload. After further review, it looks like a hardware offload
> can implement the PNE at a small cost.
> >
> > The implementation can modify current HW crypto accelerators to support
> encrypting a buffer in the first pass and then encrypting packet number i=
n
> the 2nd pass as already discussed on this thread. The exact requirement
> (header checksum, packet length encoding) is still in flux so there may b=
e
> some small variations depending on the accelerator and final algorithm
> chosen for PNE. Future offload designs can do more to further reduce the
> overhead.
>
> Thanks for the information, Manasi. I have modified the wiki page
> describing the PNE issues and alternatives to reflect this new data:
>
> https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-i=
ssues-and-alternatives
> .
> With that new information, it appears that PR #1079 is superior to every
> other alternative.
>
> -- Christian Huitema
>
>

--0000000000009ec683056ab55dd9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


It has been, and I'm personally supportive of it, beca=
use I believe it'll be useful for datacenter QUIC use cases.
But the WG has to decide:
=C2=A01) Is it allowable t=
o disable PNE?
=C2=A02) What the mechanism is?=C2=A0 ie: Unilater=
al via TransportParams or negotiated via an extension or ?

<=
div class=3D"gmail_quote">
On Wed, Apr 25, 2018 at 6:01 PM =
Mike Bishop <mbishop@evequefou.b=
e> wrote:











I think that=E2=80=99s been suggested before, though=
 we=E2=80=99d need to sort out the details of what that looks like.=C2=A0 I=
 don=E2=80=99t have a particular design in mind.


=C2=A0


From: Ian Swett [mailto:ianswett@google.com] 

Sent: Wednesday, April 25, 2018 12:57 PM

To: Mike Bishop <mbishop@evequefou.be>

Cc: Christian Huitema <huitema@huitema.net>; Deval, Manasi <manasi.deval@intel.com&g=
t;; Mark Nottingham <=
mnot@mnot.net>; IETF QUIC WG <quic@ietf.org>

Subject: Re: Getting to consensus on packet number encryption=



=C2=A0




Hi Mike,




=C2=A0






To clarify, are you suggesting adding a way to disab=
le packet number encryption via negotiation in the v1 spec as well as adopt=
ing #1079?=C2=A0 Or would the choice of whether PNE is to be used unilatera=
l, such as a transport param?






=C2=A0






On Wed, Apr 25, 2018 at 3:54 PM Mike Bishop <mbishop@evequefou.be<=
/a>> wrote:






Yes -- it seems that =
the biggest objection to #1079 was the difficulty in hardware implementatio=
n.=C2=A0 If we're hearing that hardware implementation is feasible at a=
 reasonable cost, then I think we might have
 a winner.



The CPU cost for a software implementation is still worth considering, and =
an option to not encrypt is probably reasonable to limit that burden for im=
plementations / use cases that don't care.



-----Original Message-----

From: QUIC <q=
uic-bounces@ietf.org> On Behalf Of Christian Huitema

Sent: Wednesday, April 25, 2018 3:14 AM

To: Deval, Manasi <manasi.deval@intel.com>; Mark Nottingham <mnot@mnot.net>

Cc: quic@ietf.org
Subject: Re: Getting to consensus on packet number encryption



On 4/23/2018 6:55 PM, Deval, Manasi wrote:



> I had brought up the issue with PNE several weeks ago as a barrier to =
hardware offload. After further review, it looks like a hardware offload ca=
n implement the PNE at a small cost.


>

> The implementation can modify current HW crypto accelerators to suppor=
t encrypting a buffer in the first pass and then encrypting packet number i=
n the 2nd pass as already discussed on this thread. The exact requirement (=
header checksum, packet length encoding)
 is still in flux so there may be some small variations depending on the ac=
celerator and final algorithm chosen for PNE. Future offload designs can do=
 more to further reduce the overhead.



Thanks for the information, Manasi. I have modified the wiki page describin=
g the PNE issues and alternatives to reflect this new data:

https://github.com/quicw=
g/base-drafts/wiki/Summary-of-the-PN-encryption-issues-and-alternatives=
.

With that new information, it appears that PR #1079 is superior to every ot=
her alternative.



-- Christian Huitema













--0000000000009ec683056ab55dd9--


From nobody Wed Apr 25 18:22:42 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B0712D95F for ; Wed, 25 Apr 2018 18:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 q6bdi01geKcT for ; Wed, 25 Apr 2018 18:22:39 -0700 (PDT)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 EA389128961 for ; Wed, 25 Apr 2018 18:22:38 -0700 (PDT)
Received: by mail-pf0-x232.google.com with SMTP id v63so7192265pfk.8 for ; Wed, 25 Apr 2018 18:22:38 -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=LGgMophi6t/f9+5Oe4AmjdfL5+6vZA38GRWuk9PeO0k=; b=Qm+TUp2+oKRFJkWh9Sw/4SpmvZUe6AzvjHGYzrpXYNF89jdLvD9aiNQHgLsxOvg0WZ dhXztJf2L1LbgBp9NO8hgQDJFFUzoE0D+izsKHKEgD2CGRLEaWar0eytlUCZXmQg4C1O u58cBW8/Y9ddZsd/3VBVAh964uHbtosCLyoT32jstk/NvOIF/hjfBaYN371N32OIxt5b 0g3NQCiHY7pciGmj0igormhoZpvrbXeW5r5nZQ2Hc8/BNoEMz+JOquyV/yL3UqQ8Byft au21P2d3yRwxhxaCa0pAqd0w1mN9InniRVLB3+W2eV4xU6R7mJw9b8EBj1tVvtnn1Sat 8FHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=LGgMophi6t/f9+5Oe4AmjdfL5+6vZA38GRWuk9PeO0k=; b=eqkUTOhi9C3lvX8nAZ7ga22P0IZph0+v/RZ83QWRl0Cwqkxmjc2jSY0SebmlwfKxac rh6pIP8IC1AeOP2wNt5BXhDtFC09rhItrj/enul4v4QV5b7PCJs0SoeO4LR6gUPsFgu+ PxSGc3J2pgx+YaLahtnZMMHp3greob0Xt8zQo3afJRYTFoZf6s7MLAIzLuNSpwPcJKK8 0Ek0x0e9mFqjCGcel/qQx6MH3q/LCCfCJiltppx0tOlNHnJBgjhcF3Pvo3mwd1YuMqKm vex93cdAPVgKtZ/O2jaXje/mRXnHlnYX8fv6NipU3l9tQggoefFVTDYWeHd7++SOq9F0 CYLA==
X-Gm-Message-State: ALQs6tAbXS1c6M6QWmPKTS/mhcrj89qvI2or8gcm6JE3xoRHhd0Xi/Ht LxFy8d9Nx7EpN9O2UbZsg8GNalkAYldIWcRS5UY=
X-Google-Smtp-Source: AB8JxZocLC+qm5yXTpFsKsT6EOOjVZWVJe+cz6TWk/8QKf5O+GMbB18n2n7Do60Rcg5wkTRBpBPb+slAxcgQnZgjVmk=
X-Received: by 10.98.231.16 with SMTP id s16mr4833879pfh.227.1524705758220; Wed, 25 Apr 2018 18:22:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Wed, 25 Apr 2018 18:22:37 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>     
From: Kazuho Oku 
Date: Thu, 26 Apr 2018 10:22:37 +0900
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Ian Swett 
Cc: Mike Bishop , Mark Nottingham , IETF QUIC WG ,  Christian Huitema , "Deval, Manasi" 
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, 26 Apr 2018 01:22:42 -0000

2018-04-26 9:21 GMT+09:00 Ian Swett :
> It has been, and I'm personally supportive of it, because I believe it'll=
 be
> useful for datacenter QUIC use cases.
>
> But the WG has to decide:
>  1) Is it allowable to disable PNE?

There are two concerns that PNE is trying to address: ossification and priv=
acy.

I won't mind if some portion of QUIC-like traffic has no mechanism to
prevent ossification. This is because we can train the middleboxes to
not ossify the PN field by having PNE in the majority of the traffic
that they will see.

OTOH, I would be worried of privacy implications. Once you define a
protocol, it is hard to control how it is going to be used.

But with that said, I think we might better wait to see if somebody
still thinks he/she *needs* QUIC without PNE.

>  2) What the mechanism is?  ie: Unilateral via TransportParams or negotia=
ted
> via an extension or ?
>
> On Wed, Apr 25, 2018 at 6:01 PM Mike Bishop  wrote:
>>
>> I think that=E2=80=99s been suggested before, though we=E2=80=99d need t=
o sort out the
>> details of what that looks like.  I don=E2=80=99t have a particular desi=
gn in mind.
>>
>>
>>
>> From: Ian Swett [mailto:ianswett@google.com]
>> Sent: Wednesday, April 25, 2018 12:57 PM
>> To: Mike Bishop 
>> Cc: Christian Huitema ; Deval, Manasi
>> ; Mark Nottingham ; IETF QUIC WG
>> 
>> Subject: Re: Getting to consensus on packet number encryption
>>
>>
>>
>> Hi Mike,
>>
>>
>>
>> To clarify, are you suggesting adding a way to disable packet number
>> encryption via negotiation in the v1 spec as well as adopting #1079?  Or
>> would the choice of whether PNE is to be used unilateral, such as a
>> transport param?
>>
>>
>>
>> On Wed, Apr 25, 2018 at 3:54 PM Mike Bishop  wrote=
:
>>
>> Yes -- it seems that the biggest objection to #1079 was the difficulty i=
n
>> hardware implementation.  If we're hearing that hardware implementation =
is
>> feasible at a reasonable cost, then I think we might have a winner.
>>
>> The CPU cost for a software implementation is still worth considering, a=
nd
>> an option to not encrypt is probably reasonable to limit that burden for
>> implementations / use cases that don't care.
>>
>> -----Original Message-----
>> From: QUIC  On Behalf Of Christian Huitema
>> Sent: Wednesday, April 25, 2018 3:14 AM
>> To: Deval, Manasi ; Mark Nottingham
>> 
>> Cc: quic@ietf.org
>> Subject: Re: Getting to consensus on packet number encryption
>>
>> On 4/23/2018 6:55 PM, Deval, Manasi wrote:
>>
>> > I had brought up the issue with PNE several weeks ago as a barrier to
>> > hardware offload. After further review, it looks like a hardware offlo=
ad can
>> > implement the PNE at a small cost.
>> >
>> > The implementation can modify current HW crypto accelerators to suppor=
t
>> > encrypting a buffer in the first pass and then encrypting packet numbe=
r in
>> > the 2nd pass as already discussed on this thread. The exact requiremen=
t
>> > (header checksum, packet length encoding) is still in flux so there ma=
y be
>> > some small variations depending on the accelerator and final algorithm
>> > chosen for PNE. Future offload designs can do more to further reduce t=
he
>> > overhead.
>>
>> Thanks for the information, Manasi. I have modified the wiki page
>> describing the PNE issues and alternatives to reflect this new data:
>>
>> https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-=
issues-and-alternatives..
>> With that new information, it appears that PR #1079 is superior to every
>> other alternative.
>>
>> -- Christian Huitema



--=20
Kazuho Oku


From nobody Wed Apr 25 18:46:37 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0991B12D95F for ; Wed, 25 Apr 2018 18:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBDj0wLXUSu1 for ; Wed, 25 Apr 2018 18:46:32 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c: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 B9B78128961 for ; Wed, 25 Apr 2018 18:46:31 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id f6so10171975wmc.4 for ; Wed, 25 Apr 2018 18:46: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=1SWHyw5Oonm1nbQ0W6KvPfh3S31OKnNp3H6AfLED5/U=; b=Ah59KXFWr9gp7XQ2K3z5qzdNQHDUzEVY2FZfJ2hDHKw8wLoAqrggNsCggswM5qMUPe MDBqxCbJP3D41vg/F2gLBb8mYia1WjArj3bpZwFQa6WaXlWiAOAjdt9REbAcD/uDxzci 9XJHPK1xBMr1RHNbzUcr/OQKz7FtV4N+0QoxiQQETwvMhnDvUvTsZ4yQrg6gKeXv37Y/ LhxO+9CC0dEcxTKlRfw3ME1yQtpBzkqWmtIP2ZqYsWh0Kj90VGWC9rf1g7RDd+LXjojm 2LXNjikA29Ts++h0GZgdM3YlS2IoOBdwdDS+sXXuGarVQ2z5LZOHu2LobG7iR/IE/bo0 DUhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=1SWHyw5Oonm1nbQ0W6KvPfh3S31OKnNp3H6AfLED5/U=; b=ubEfc5ixhJ/agZyETlZtBKVZr7mV8tG3m8IYjkFp1kMw1Ea3EBXAopTNsQi6HBUWIH yZLOA/V2hmsOKCmkdjYYpxRApHmSKDnwojdYMvQq/UaSuIumVecfepFLy6zBgwKBwdq4 b8X7AxtcrLMgfoQxvptkY4VS3LNhq0NSU2sA16azrSoMoW/8LX/CJIsKMri0W/LqGEXY 79XaE2Pz3XyAvPqU/RcYFWMumNm8/cpwafIotc5IGk+uNBjIgCR4QrXjTP0W6NReNSfS /u5TgBi+6iGhKQtnvy5x/kKe/G93TBsKISDxQmfB1F7Cle0/jJayuii6VAz598mphXjG obmQ==
X-Gm-Message-State: ALQs6tB4HEfKnULwJz9IUsGSTKsk3pfsO6fSE2yjPkVH9JlFYWvv6S91 QIqu2DEHFaYAKlFh9xWZQZWfqWAfxrhN7G2n9brzOQ==
X-Google-Smtp-Source: AIpwx4/r1Pd8a4Ao5oGUYOf6+V9J0TySmMU42Z7LzLB2GfBMUSrtYB9OUgccA9RrUjcUojBv39gbXJvEWOIyUM2vzt4=
X-Received: by 10.28.6.149 with SMTP id 143mr17141469wmg.61.1524707189593; Wed, 25 Apr 2018 18:46:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.146.143 with HTTP; Wed, 25 Apr 2018 18:46:08 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>      
From: Erik Kline 
Date: Thu, 26 Apr 2018 01:46:08 +0000
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Kazuho Oku 
Cc: Ian Swett ,  Christian Huitema , Mark Nottingham , IETF QUIC WG ,  Mike Bishop , "Deval, Manasi" 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1144234877640c056ab68e76"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 26 Apr 2018 01:46:36 -0000

--001a1144234877640c056ab68e76
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Couldn't a middlebox have a policy where it permits QUIC sessions w/o
PNE but blocks sessions with PNE?  Then implementations would be
forced to choose how adapt: break altogether, maybe try TCP, or
disable PNE and carry on.

On 26 April 2018 at 01:22, Kazuho Oku  wrote:
> 2018-04-26 9:21 GMT+09:00 Ian Swett :
>> It has been, and I'm personally supportive of it, because I believe it'l=
l be
>> useful for datacenter QUIC use cases.
>>
>> But the WG has to decide:
>>  1) Is it allowable to disable PNE?
>
> There are two concerns that PNE is trying to address: ossification and pr=
ivacy.
>
> I won't mind if some portion of QUIC-like traffic has no mechanism to
> prevent ossification. This is because we can train the middleboxes to
> not ossify the PN field by having PNE in the majority of the traffic
> that they will see.
>
> OTOH, I would be worried of privacy implications. Once you define a
> protocol, it is hard to control how it is going to be used.
>
> But with that said, I think we might better wait to see if somebody
> still thinks he/she *needs* QUIC without PNE.
>
>>  2) What the mechanism is?  ie: Unilateral via TransportParams or negoti=
ated
>> via an extension or ?
>>
>> On Wed, Apr 25, 2018 at 6:01 PM Mike Bishop  wrote=
:
>>>
>>> I think that=E2=80=99s been suggested before, though we=E2=80=99d need =
to sort out the
>>> details of what that looks like.  I don=E2=80=99t have a particular des=
ign in mind.
>>>
>>>
>>>
>>> From: Ian Swett [mailto:ianswett@google.com]
>>> Sent: Wednesday, April 25, 2018 12:57 PM
>>> To: Mike Bishop 
>>> Cc: Christian Huitema ; Deval, Manasi
>>> ; Mark Nottingham ; IETF QUIC WG
>>> 
>>> Subject: Re: Getting to consensus on packet number encryption
>>>
>>>
>>>
>>> Hi Mike,
>>>
>>>
>>>
>>> To clarify, are you suggesting adding a way to disable packet number
>>> encryption via negotiation in the v1 spec as well as adopting #1079?  O=
r
>>> would the choice of whether PNE is to be used unilateral, such as a
>>> transport param?
>>>
>>>
>>>
>>> On Wed, Apr 25, 2018 at 3:54 PM Mike Bishop  wrot=
e:
>>>
>>> Yes -- it seems that the biggest objection to #1079 was the difficulty =
in
>>> hardware implementation.  If we're hearing that hardware implementation=
 is
>>> feasible at a reasonable cost, then I think we might have a winner.
>>>
>>> The CPU cost for a software implementation is still worth considering, =
and
>>> an option to not encrypt is probably reasonable to limit that burden fo=
r
>>> implementations / use cases that don't care.
>>>
>>> -----Original Message-----
>>> From: QUIC  On Behalf Of Christian Huitema
>>> Sent: Wednesday, April 25, 2018 3:14 AM
>>> To: Deval, Manasi ; Mark Nottingham
>>> 
>>> Cc: quic@ietf.org
>>> Subject: Re: Getting to consensus on packet number encryption
>>>
>>> On 4/23/2018 6:55 PM, Deval, Manasi wrote:
>>>
>>> > I had brought up the issue with PNE several weeks ago as a barrier to
>>> > hardware offload. After further review, it looks like a hardware offl=
oad can
>>> > implement the PNE at a small cost.
>>> >
>>> > The implementation can modify current HW crypto accelerators to suppo=
rt
>>> > encrypting a buffer in the first pass and then encrypting packet numb=
er in
>>> > the 2nd pass as already discussed on this thread. The exact requireme=
nt
>>> > (header checksum, packet length encoding) is still in flux so there m=
ay be
>>> > some small variations depending on the accelerator and final algorith=
m
>>> > chosen for PNE. Future offload designs can do more to further reduce =
the
>>> > overhead.
>>>
>>> Thanks for the information, Manasi. I have modified the wiki page
>>> describing the PNE issues and alternatives to reflect this new data:
>>>
>>> https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption=
-issues-and-alternatives..
>>> With that new information, it appears that PR #1079 is superior to ever=
y
>>> other alternative.
>>>
>>> -- Christian Huitema
>
>
>
> --
> Kazuho Oku
>

--001a1144234877640c056ab68e76
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE
BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy
c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw
NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG
A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F
GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes
BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3
Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6
6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB
/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB
ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt
r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n
c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG
9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse
Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x
t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h
isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA
NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA
AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt
IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw
MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB
MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB
Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge
C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2
52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua
eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD
rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY
MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt
7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e
oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7
qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT
Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk
WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw
TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x
EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG
A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi
FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X
17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm
KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp
sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7
DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL
QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s
bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV
3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr
VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMfg1wtYggohADxbT3MA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDIxNTA2MzcxNVoXDTE4MDgx
NDA2MzcxNVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBANinyejqC3lpuuurPEnTTJsSB+LPui3CT4Cg4PEUVzKZf9l4ircMhwI8
LZmiRwWqg1CReYbVM1JTiQ6gJpWdGaiEdylfMEcCm6RMnuHA8k97/AqBUZti6ZGbtl77UEblK2Ok
Qwai1Kza2k2CkjfnzfugTdF/XzOCF9BOYrW/B+fM2MGf7e48qKtoA2FGlTOOaitLYJJBaixBWQUZ
oVO6XVPC7mhSoW1Wc7uwD85Yvuf1Qq0MXkxqgAXxJ1xBSS7KVJAIPPlXS3vtxFwmeqDlFIqNB9lY
KwU08whM2akO03ENo0ixPJL3kSEafnFiQzVhXTLsgqbCA0lrfH2j4F8/wrMCAwEAAaOCAWowggFm
MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo
dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud
DgQWBBS6wTowyOTvuUJ3LG0j/H1PWoaTrjAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg
PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i
YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh
bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAavJqbhv0cDn0rYD5aMbNL6cvp5a2
9oeeMhRGx55RMI7YywkO91RBJjzKAHWvb9Q2sdoQ/5PBmzEsFyYRhK68AnDE/h/GMhZPqK0p9JMe
e1OSiWYexcjPi4ibnMkIBO+GMeTYQPweBfiD4pTwDPaKib+29SM5520Ba6C88h2wNEabdWj9EypL
i/utAs30iZ97nKVXDFAgYvOORj5bQAnGAIZHIqSw2xAUu0l59uxdqW3mcZs/6JPrWEGjDh2enVmp
BIiQJzNtVktT+lQInKeeJQM4jt+s/RE1m/GacTJZ63MNk9mE5Xn/hbmTkEgBSPu6/6gl1JnrIdTf
Aex0alwnMTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH4NcLWIIKIQA8W09zAN
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgbzP5D7elmJe+/NO34inHCWmfipYjeQ1y
qtQfvNktcZ8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwNDI2
MDE0NjMwWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBAHC1eh35pLrJyJAPEqXirqfJwU2Tt1y4ub1NQ3gLHAIGh8pfHXN+
N4suawXfNINSPs6/Ng4+59DRadrRA5QExvmDucjX6VD+TRutonyTyCi+ULKY0r/gdyeDyL4Ljmmx
ZKKWHz66uLs1F2TFWPE9jMxc7kVkB3BcyI7MIYs049POdDWF2y1TzwUBmwZnpfDDf6+w1InYailz
MNbasYkFVxN+cBomsh336cObIn0gsQ86Kd0lotkwoWnMHBTiQip3AFPGJfstpc2k0m4RFt3MTUoD
aKI5gBM0/11DJVw1axwEXK+bgbCPLLBriMrEwX4HYaHUqfGb91GwergRhQZA0/g=
--001a1144234877640c056ab68e76--


From nobody Wed Apr 25 19:25:16 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BC312D9FE for ; Wed, 25 Apr 2018 19:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNdq_Ma8X3fO for ; Wed, 25 Apr 2018 19:25:11 -0700 (PDT)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 8CF2D128961 for ; Wed, 25 Apr 2018 19:25:11 -0700 (PDT)
Received: by mail-pf0-x22b.google.com with SMTP id z9so16915428pfe.6 for ; Wed, 25 Apr 2018 19:25:11 -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=hKFYTK9lDeN2VFZ67vw9N+A7FEDTlB593zeLNB0mnaU=; b=KlczAZ/vLgbNd8bcubUoiiZUu+Rpmr4BpIepqennyk3BTYvjvkOXF0MX+Ag9iIQvgH cWiBE/62m83obNS1zb35dAuhvRODqIWn2cCExh8s2wMFN92nZ5sfGAj5WKSFKxvmMSC9 SW5CsccEMlNb5M+2oMNevwdhySbP7A1UOPWCdBZDm8hgA90T9AkXJUr1QYyuxrf4USiL QfSHySj4HRIc/HgavGXmjGQ3ov/iNDuaIV804eevRt22D51ctf8OcXafhtGw+vHdCvA6 TDsjVfAyr7CMkZ7/aUPOLYiqeRdlS3i7Rkv1R0Nswl8KC3kJnNmTh1TPfuM5OA2VEz2a LGHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=hKFYTK9lDeN2VFZ67vw9N+A7FEDTlB593zeLNB0mnaU=; b=qiHLiKB4KKzyGcwPlvMllvPNV12fBS9tCm6nYVaSl5unhYOG9qnx+YBaWRZIp8jfhK 6PcYFr9+S8fphXo3tu6X8ZHIaeEpDRxp6hX8rOY4+jtGQXLwpXtsZGr9Pc1WOWHeYRMz k/k0CHiwyCEGXmgmHAZZz7EcHe8c64asG+rAbd90ZW25U24BwMXe67I05tLByB4e/IXz eBiVwJ1Bq3bFqmH5lR+Zz7VXKHKqeeHL3dg/IyJuhsIO1S3+xRTiFUNJkaSNlPyvd4DW LJh7uDgx3jHni6M9eEsU1kRy0/RQdpGOtxj/LD1wNmVktXkXeYM+z3BPdqwnVamdUjJJ 8ScA==
X-Gm-Message-State: ALQs6tB2GiXQfRmL9kG2oNqgvlHC31nPjNHgzWHzMwk/WA1BTDsh45BA MdsBRRN0ZxxZKq5ra3N9HnouPjTExDz95965Tpci3S6I
X-Google-Smtp-Source: AIpwx48f7qzBQS6SldTi/PxcktF/1NJbRELkiEkGbKnfdxGTUd9b0zIv8QDVYJpnxJYcpw/PNBnitUOnmMamcUa1TiM=
X-Received: by 10.101.66.139 with SMTP id j11mr25430939pgp.370.1524709510940;  Wed, 25 Apr 2018 19:25:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Wed, 25 Apr 2018 19:25:10 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>       
From: Kazuho Oku 
Date: Thu, 26 Apr 2018 11:25:10 +0900
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Erik Kline 
Cc: Ian Swett ,  Christian Huitema , Mark Nottingham , IETF QUIC WG ,  Mike Bishop , "Deval, Manasi" 
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, 26 Apr 2018 02:25:14 -0000

2018-04-26 10:46 GMT+09:00 Erik Kline :
> Couldn't a middlebox have a policy where it permits QUIC sessions w/o
> PNE but blocks sessions with PNE?  Then implementations would be
> forced to choose how adapt: break altogether, maybe try TCP, or
> disable PNE and carry on.

There are two ways of negotiating the use (or non-use) of PNE. One is
use Transport Parameters and the other is to use a different QUIC
version.

Use of Transport Parameters is secure because it is part of the TLS
handshake. Version negotiation has it's own protection against
downgrade (or upgrade) attacks (see
https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.sec=
tion.6.4.4).

So I would assume that a middlebox trying to intervene in the
negotiation of PNE use can be detected.

That said, I do see your point that if some middleboxes decide to pass
QUIC without PNE but block QUIC with PNE, we might be incentivized to
use QUIC without PNE. In such case, we might end up having privacy
leaks & ossification.

I think that is a good argument for always having PNE turned on.

>
> On 26 April 2018 at 01:22, Kazuho Oku  wrote:
>> 2018-04-26 9:21 GMT+09:00 Ian Swett :
>>> It has been, and I'm personally supportive of it, because I believe it'=
ll be
>>> useful for datacenter QUIC use cases.
>>>
>>> But the WG has to decide:
>>>  1) Is it allowable to disable PNE?
>>
>> There are two concerns that PNE is trying to address: ossification and p=
rivacy.
>>
>> I won't mind if some portion of QUIC-like traffic has no mechanism to
>> prevent ossification. This is because we can train the middleboxes to
>> not ossify the PN field by having PNE in the majority of the traffic
>> that they will see.
>>
>> OTOH, I would be worried of privacy implications. Once you define a
>> protocol, it is hard to control how it is going to be used.
>>
>> But with that said, I think we might better wait to see if somebody
>> still thinks he/she *needs* QUIC without PNE.
>>
>>>  2) What the mechanism is?  ie: Unilateral via TransportParams or negot=
iated
>>> via an extension or ?
>>>
>>> On Wed, Apr 25, 2018 at 6:01 PM Mike Bishop  wrot=
e:
>>>>
>>>> I think that=E2=80=99s been suggested before, though we=E2=80=99d need=
 to sort out the
>>>> details of what that looks like.  I don=E2=80=99t have a particular de=
sign in mind.
>>>>
>>>>
>>>>
>>>> From: Ian Swett [mailto:ianswett@google.com]
>>>> Sent: Wednesday, April 25, 2018 12:57 PM
>>>> To: Mike Bishop 
>>>> Cc: Christian Huitema ; Deval, Manasi
>>>> ; Mark Nottingham ; IETF QUIC W=
G
>>>> 
>>>> Subject: Re: Getting to consensus on packet number encryption
>>>>
>>>>
>>>>
>>>> Hi Mike,
>>>>
>>>>
>>>>
>>>> To clarify, are you suggesting adding a way to disable packet number
>>>> encryption via negotiation in the v1 spec as well as adopting #1079?  =
Or
>>>> would the choice of whether PNE is to be used unilateral, such as a
>>>> transport param?
>>>>
>>>>
>>>>
>>>> On Wed, Apr 25, 2018 at 3:54 PM Mike Bishop  wro=
te:
>>>>
>>>> Yes -- it seems that the biggest objection to #1079 was the difficulty=
 in
>>>> hardware implementation.  If we're hearing that hardware implementatio=
n is
>>>> feasible at a reasonable cost, then I think we might have a winner.
>>>>
>>>> The CPU cost for a software implementation is still worth considering,=
 and
>>>> an option to not encrypt is probably reasonable to limit that burden f=
or
>>>> implementations / use cases that don't care.
>>>>
>>>> -----Original Message-----
>>>> From: QUIC  On Behalf Of Christian Huitema
>>>> Sent: Wednesday, April 25, 2018 3:14 AM
>>>> To: Deval, Manasi ; Mark Nottingham
>>>> 
>>>> Cc: quic@ietf.org
>>>> Subject: Re: Getting to consensus on packet number encryption
>>>>
>>>> On 4/23/2018 6:55 PM, Deval, Manasi wrote:
>>>>
>>>> > I had brought up the issue with PNE several weeks ago as a barrier t=
o
>>>> > hardware offload. After further review, it looks like a hardware off=
load can
>>>> > implement the PNE at a small cost.
>>>> >
>>>> > The implementation can modify current HW crypto accelerators to supp=
ort
>>>> > encrypting a buffer in the first pass and then encrypting packet num=
ber in
>>>> > the 2nd pass as already discussed on this thread. The exact requirem=
ent
>>>> > (header checksum, packet length encoding) is still in flux so there =
may be
>>>> > some small variations depending on the accelerator and final algorit=
hm
>>>> > chosen for PNE. Future offload designs can do more to further reduce=
 the
>>>> > overhead.
>>>>
>>>> Thanks for the information, Manasi. I have modified the wiki page
>>>> describing the PNE issues and alternatives to reflect this new data:
>>>>
>>>> https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryptio=
n-issues-and-alternatives..
>>>> With that new information, it appears that PR #1079 is superior to eve=
ry
>>>> other alternative.
>>>>
>>>> -- Christian Huitema
>>
>>
>>
>> --
>> Kazuho Oku
>>



--=20
Kazuho Oku


From nobody Thu Apr 26 02:45:01 2018
Return-Path: 
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C47AF1241F3; Thu, 26 Apr 2018 02:44:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: quic@ietf.org
Subject: I-D Action: draft-ietf-quic-spin-exp-00.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.79.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152473589471.22858.15059459149798298730@ietfa.amsl.com>
Date: Thu, 26 Apr 2018 02:44:54 -0700
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Apr 2018 09:44:55 -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           : The QUIC Latency Spin Bit
        Authors         : Brian Trammell
                          Mirja Kuehlewind
	Filename        : draft-ietf-quic-spin-exp-00.txt
	Pages           : 8
	Date            : 2018-04-26

Abstract:
   This document specifies the addition of a latency spin bit to the
   QUIC transport protocol and describes how to use it to measure end-
   to-end latency.

Note to Readers

   This document specifies an experimental delta to the QUIC transport
   protocol.  Specifically, this experimentation is intended to
   determine:

   o  the impact of the addition of the latency spin bit on
      implementation and specification complexity; and

   o  the accuracy and value of the information derived from spin bit
      measurement on live network traffic.

   The information generated by this experiment will be used by the QUIC
   working group as input to a decision about the standardization of the
   latency spin bit.  Although this is a Working Group document, it is
   currently NOT a Working Group deliverable.

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/search/?email_list=quic [1].

   Working Group information can be found at https://github.com/quicwg
   [2]; source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-spin [3].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-spin-exp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-quic-spin-exp-00
https://datatracker.ietf.org/doc/html/draft-ietf-quic-spin-exp-00


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Apr 26 05:38:22 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA021201F2 for ; Thu, 26 Apr 2018 05:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.233
X-Spam-Level: 
X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XfCGHMUNlmm for ; Thu, 26 Apr 2018 05:38:13 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5F574126D74 for ; Thu, 26 Apr 2018 05:38:13 -0700 (PDT)
Received: from mail-ot0-f170.google.com (mail-ot0-f170.google.com [74.125.82.170]) by linode64.ducksong.com (Postfix) with ESMTPSA id 304DA3A068 for ; Thu, 26 Apr 2018 08:37:42 -0400 (EDT)
Received: by mail-ot0-f170.google.com with SMTP id h8-v6so29193901otj.7 for ; Thu, 26 Apr 2018 05:37:42 -0700 (PDT)
X-Gm-Message-State: ALQs6tBO1xlJUU12+/txfRIpAuclTvum35cLMXwFIGM1XskhJZZ9sSdC uATfDUwVKzdb4KsjUN2/HD4uN6EK5cGnBVHshqI=
X-Google-Smtp-Source: AIpwx4/6x0hG7ndOdVoYIBfDmlEZ/ULryz6pO5eyAzsyDKw8ikz049404QVHtFemSsVv9pQ9H4abjgJaLBT+0rlCoZE=
X-Received: by 2002:a9d:5014:: with SMTP id a20-v6mr20904073oth.205.1524746260679;  Thu, 26 Apr 2018 05:37:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.138.36 with HTTP; Thu, 26 Apr 2018 05:37:39 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>     
From: Patrick McManus 
Date: Thu, 26 Apr 2018 08:37:39 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Ian Swett 
Cc: Mike Bishop , Mark Nottingham , IETF QUIC WG ,  Christian Huitema , "Deval, Manasi" 
Content-Type: multipart/alternative; boundary="0000000000003d95a4056abfa7ce"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 26 Apr 2018 12:38:16 -0000

--0000000000003d95a4056abfa7ce
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 25, 2018 at 8:21 PM, Ian Swett <
ianswett=40google.com@dmarc.ietf.org> wrote:

> It has been, and I'm personally supportive of it, because I believe it'll
> be useful for datacenter QUIC use cases.
>

can you layout the datacenter and PNE mismatch? It is just "more work" or
is it an interaction with other hardware offloads?

--0000000000003d95a4056abfa7ce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Apr 25, 2018 at 8:21 PM, Ian Swett <iansw=
ett=3D40google.com@dmarc.ietf.org> wrote:
It has been, and I'm personally support=
ive of it, because I believe it'll be useful for datacenter QUIC use ca=
ses.

can you layout the datacente=
r and PNE mismatch? It is just "more work" or is it an interactio=
n with other hardware offloads?

 
<=
/div>


--0000000000003d95a4056abfa7ce--


From nobody Thu Apr 26 09:13:11 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BAB126DED for ; Thu, 26 Apr 2018 09:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=4QOun8TS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WtSVGEUd
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k76IbrxQq5Zq for ; Thu, 26 Apr 2018 09:13:08 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC51124205 for ; Thu, 26 Apr 2018 09:13:07 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C10EE2112E; Thu, 26 Apr 2018 12:13:06 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 26 Apr 2018 12:13:06 -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; s=fm2; bh=Ye+/uUBWw39h9ssTqED+I/y19B8aP HpuyX+UtT6ZdKg=; b=4QOun8TSAjkg5qEAp6hrcol+275Jwl3cMHrCKpWzycNG2 JDv3GI/XxJwrkR/JxP1ylgbTXDnCrB1WrX6F3Q0NmlQSbe7kMO7y+qdj0CsUkUeU lsY866Z6xFFA2khLZPSiYLeJ00rXKMgbaVdU79txaPLKmcLomSAyZ/DibETXJcC2 w53LwR+CTarkz8RCyxj5SfqPOhaiNLiYc5DK0ZQbK7G2zHtEzE4o5GmR3AM7Ljkt idhzhUB10jaNydQWftM3e72glYb20GkzIfZuAhgcfmkbXbbjueTnHOZEFDUPjXeD 7mJQ95SfuOQzuE6YP4+6ToAiv2O7QTYBTaKlvQM1A==
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; s=fm2; bh=Ye+/uU BWw39h9ssTqED+I/y19B8aPHpuyX+UtT6ZdKg=; b=WtSVGEUdWavX+5lwJvQNjf OJlp47c3wI3Y9LByLzjXye7MT9OdzXEOFoQbP68OGvtsi/j80aiL/Jxi3flGIiwz KZb1APxh+/gPCqfrRtc3qNwY0IBskhRrI3jvZ8nt6RIsvT+T6flLeoMzxoDQgsFP RWltEkfRRuDmhnT9/xItGRDuPvvhTYMBgLuU3jVXFpwH3H42b9rAYERNOpanfk7k +7W1Pvb6p2e6yJYHrtAMsG3uqhAbiduPo838sOxDhJFyZlIZi4unxsSaLMKlqmbF EeXGxXedlRs7nO6Whw0AS3/Xlz/eDO7lDM8VGgJPKcz41AnWMhf9NRfM68h3zbSA ==
X-ME-Sender: 
Received: from [10.188.210.187] (100.1.71.37.rev.sfr.net [37.71.1.100]) by mail.messagingengine.com (Postfix) with ESMTPA id A2A7110264; Thu, 26 Apr 2018 12:13:05 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: QUIC (quic) WG Interim Meeting: 2018-06-06
From: Mark Nottingham 
In-Reply-To: <80C50C46-2BCF-4716-B239-FEE5F1264AD0@mnot.net>
Date: Thu, 26 Apr 2018 18:13:04 +0200
Cc: Lars Eggert 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <151809506296.17228.17281018611304930059@ietfa.amsl.com> <6203282A-CD65-4049-A499-DED34431E912@mnot.net> <80C50C46-2BCF-4716-B239-FEE5F1264AD0@mnot.net>
To: QUIC WG 
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 26 Apr 2018 16:13:10 -0000

Final reminder: registration -- both for remote and onsite participation =
-- closes in one week.

Cheers,


> On 3 Apr 2018, at 5:45 am, Mark Nottingham  wrote:
>=20
> Reminder: registration closes in about a month.
>=20
>=20
>> On 9 Feb 2018, at 10:02 am, Mark Nottingham  wrote:
>>=20
>> Registration is now open; see the arrangements page. Please note the =
guidelines for attendance there.
>>=20
>> Cheers,
>>=20
>>=20
>>> On 9 Feb 2018, at 12:04 am, IESG Secretary  =
wrote:
>>>=20
>>> The QUIC (quic) Working Group will hold
>>> a multi-day interim meeting.
>>>=20
>>> Session 1:
>>> 2018-06-06     09:00 to 17:00  Europe/Berlin
>>> Session 2:
>>> 2018-06-07     09:00 to 17:00  Europe/Berlin
>>>=20
>>> Meeting Location:
>>> Kista, SE
>>>=20
>>> Agenda:
>>> =
https://github.com/quicwg/wg-materials/blob/master/interim-18-06/agenda.md=

>>>=20
>>> Information about remote participation:
>>> =
https://github.com/quicwg/wg-materials/blob/master/interim-18-06/arrangeme=
nts.md
>>>=20
>>> Preceded by non-IETF QUIC interop event on June 4-5, same location
>>>=20

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


From nobody Thu Apr 26 09:15:55 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129BC126E64 for ; Thu, 26 Apr 2018 09:15:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmGX2hsyNqiP for ; Thu, 26 Apr 2018 09:15:51 -0700 (PDT)
Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAA9126DFB for ; Thu, 26 Apr 2018 09:15:51 -0700 (PDT)
Received: by mail-yb0-x229.google.com with SMTP id i13-v6so9609368ybl.4 for ; Thu, 26 Apr 2018 09:15:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KLQQLzRvSlc3Fkam6VtAcihUUrDlYBatfVEqODRXXXA=; b=UQ81A6nKUc8hI1Oivg+2FUfiYrEgzxHASlUeJhJNY740KsiIjS6ByJyXkB0YIjqtvT ywSX8mcVB/AMwiDxQ9AUrVnnlmSR5gX7MzY9ZeI53uBoNNqvRvVtg8G8zR9QJLDVw7uA efGFq2SzgllGx0FZVDlEtTcSh59eg1xzb0WhgEEohIpKNTPloC+SQYgj8wjUWY0s8xNf U8tRSYs6EhiwwJhoCuRT/z9uopiv00yNCTb5eNkGQPhyG/zBrVcoBw56slKB2S/FcU/6 cCA1YFqLYaJtDBb72cxMBB+Yro2eFterTZfaNpBHEMQASeYZjUpkK3ouZTj3d20tyYYw p9jA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KLQQLzRvSlc3Fkam6VtAcihUUrDlYBatfVEqODRXXXA=; b=TapNSh6PVvmM1ajFtne+HKsqvyWilPk5xJ8tPi7u92RHRjL9b3F59FFF4HI2XjCbNw jH8m2QYHPSReIMUXd6rN0+T3cLbVAyS/iRgbhjjLm+RyByTrLlwFm5uXU2kHgq3V/6+J MafDd8TFj74uebf3Ob+tcTVM/i/LFFETv1glbKYB3wyT69FDN7NYxqthjxiedk+qNmgi Rpvkq/6r07akBUL+gruRZA1vEXiodjHPKZACnANay5OL6Bmu2WJ0SYfIDLg2orZDGNJ8 dRbcRAY6/2I7Yezr8z+orVZo+pqo0cTG2SISwOxoLjVB18F0AgZSIpH1rbf+HCQZjzaP pdqA==
X-Gm-Message-State: ALQs6tBAV2vrwZV4jxCHLPQY6IXQDH+wTn+R2sHfpqHfFD8F1vI/FPAz Stg4EQtP5Xno8DJyUmPrJ942e103n5TNg7Hb2Oo6Zw==
X-Google-Smtp-Source: AIpwx48mzNMhTW5mhD9M3f/qaPFwUFm9EAVTZtGby9PQzu7Kii+8em3L7+u0vbpVV/c/DPJgpYYC+Bw9Ks4tYozZXrc=
X-Received: by 2002:a25:2185:: with SMTP id h127-v6mr18940556ybh.206.1524759349871;  Thu, 26 Apr 2018 09:15:49 -0700 (PDT)
MIME-Version: 1.0
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>      
In-Reply-To: 
From: Ian Swett 
Date: Thu, 26 Apr 2018 16:15:39 +0000
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Patrick McManus 
Cc: Mike Bishop , Mark Nottingham , IETF QUIC WG ,  Christian Huitema , "Deval, Manasi" 
Content-Type: multipart/alternative; boundary="0000000000006b9079056ac2b3ad"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 26 Apr 2018 16:15:53 -0000

--0000000000006b9079056ac2b3ad
Content-Type: text/plain; charset="UTF-8"

>From my perspective, it's just "more work" and certain workloads are really
CPU cost sensitive in datacenters in a way that isn't true on the public
internet.

That being said, datacenters may start moving to large MTUs earlier than
the public internet, which would greatly decrease the practical cost of PNE.

Given where we're at, even though I believe it's likely someone will want
to disable PNE for some use case at some point, I think we should spec PNE
as the only option for now and when someone needs to disable it, it can be
up to them to create a mechanism, use it in their own implementation, and
if they care to standardize it, they can?

On Thu, Apr 26, 2018 at 8:38 AM Patrick McManus 
wrote:

>
>
> On Wed, Apr 25, 2018 at 8:21 PM, Ian Swett <
> ianswett=40google.com@dmarc.ietf.org> wrote:
>
>> It has been, and I'm personally supportive of it, because I believe it'll
>> be useful for datacenter QUIC use cases.
>>
>
> can you layout the datacenter and PNE mismatch? It is just "more work" or
> is it an interaction with other hardware offloads?
>
>
>

--0000000000006b9079056ac2b3ad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


From my perspective, it's just "more work" a=
nd certain workloads are really CPU cost sensitive in datacenters in a way =
that isn't true on the public internet.

That bei=
ng said, datacenters may start moving to large MTUs earlier than the public=
 internet, which would greatly decrease the practical cost of PNE.

Given where we're at, even though I believe it's l=
ikely someone will want to disable PNE for some use case at some point, I t=
hink we should spec PNE as the only option for now and when someone needs t=
o disable it, it can be up to them to create a mechanism, use it in their o=
wn implementation, and if they care to standardize it, they can?

On Thu, Apr 26, 2018 at 8:=
38 AM Patrick McManus <pmcmanus@=
mozilla.com> wrote:


On W=
ed, Apr 25, 2018 at 8:21 PM, Ian Swett <ianswett=3D40=
google.com@dmarc.ietf.org> wrote:
It has been, and I'm personally supportive of i=
t, because I believe it'll be useful for datacenter QUIC use cases.
=


can you layout the datacenter and PN=
E mismatch? It is just "more work" or is it an interaction with o=
ther hardware offloads?

 




--0000000000006b9079056ac2b3ad--


From nobody Thu Apr 26 09:36:33 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CF21276AF for ; Thu, 26 Apr 2018 09:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.233
X-Spam-Level: 
X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BKG_wxsk7rr for ; Thu, 26 Apr 2018 09:36:29 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 58B7D126DFB for ; Thu, 26 Apr 2018 09:36:29 -0700 (PDT)
Received: from mail-ot0-f178.google.com (mail-ot0-f178.google.com [74.125.82.178]) by linode64.ducksong.com (Postfix) with ESMTPSA id EEB803A082 for ; Thu, 26 Apr 2018 12:35:57 -0400 (EDT)
Received: by mail-ot0-f178.google.com with SMTP id l12-v6so2205102oth.6 for ; Thu, 26 Apr 2018 09:35:57 -0700 (PDT)
X-Gm-Message-State: ALQs6tCJ6nNRQjuqqBBAylqyiC6GWp20eJ5aETBGN8jIfFKfeZ5+5z4p BFphesJcoyNEORrx7lQnnJ5e42RoeqVJuhgnnQY=
X-Google-Smtp-Source: AB8JxZo0xDubyjLFKx/9tFwMi+SB1xnU26rgOsL068WO3GTqlfhQE/Smf5dKEg4S9TUvyOW09mKGFdPvpkhbVyd5bl8=
X-Received: by 2002:a9d:4181:: with SMTP id p1-v6mr18950670ote.2.1524760557707;  Thu, 26 Apr 2018 09:35:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.138.36 with HTTP; Thu, 26 Apr 2018 09:35:57 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>       
From: Patrick McManus 
Date: Thu, 26 Apr 2018 12:35:57 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Ian Swett 
Cc: Patrick McManus , Mike Bishop , Mark Nottingham , IETF QUIC WG , Christian Huitema ,  "Deval, Manasi" 
Content-Type: multipart/alternative; boundary="00000000000068e8ec056ac2fba5"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 26 Apr 2018 16:36:31 -0000

--00000000000068e8ec056ac2fba5
Content-Type: text/plain; charset="UTF-8"

sgtm

On Thu, Apr 26, 2018 at 12:15 PM, Ian Swett  wrote:

> From my perspective, it's just "more work" and certain workloads are
> really CPU cost sensitive in datacenters in a way that isn't true on the
> public internet.
>
> That being said, datacenters may start moving to large MTUs earlier than
> the public internet, which would greatly decrease the practical cost of PNE.
>
> Given where we're at, even though I believe it's likely someone will want
> to disable PNE for some use case at some point, I think we should spec PNE
> as the only option for now and when someone needs to disable it, it can be
> up to them to create a mechanism, use it in their own implementation, and
> if they care to standardize it, they can?
>
> On Thu, Apr 26, 2018 at 8:38 AM Patrick McManus 
> wrote:
>
>>
>>
>> On Wed, Apr 25, 2018 at 8:21 PM, Ian Swett > ietf.org> wrote:
>>
>>> It has been, and I'm personally supportive of it, because I believe
>>> it'll be useful for datacenter QUIC use cases.
>>>
>>
>> can you layout the datacenter and PNE mismatch? It is just "more work" or
>> is it an interaction with other hardware offloads?
>>
>>
>>

--00000000000068e8ec056ac2fba5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


sgtm

On Thu, Apr 26, 2018 at 12:15 PM, Ian Swett <ianswett@goog=
le.com> wrote:
From my perspective, it's just "more work" and certain w=
orkloads are really CPU cost sensitive in datacenters in a way that isn'=
;t true on the public internet.

That being said, dat=
acenters may start moving to large MTUs earlier than the public internet, w=
hich would greatly decrease the practical cost of PNE.

=

Given where we're at, even though I believe it's likely someon=
e will want to disable PNE for some use case at some point, I think we shou=
ld spec PNE as the only option for now and when someone needs to disable it=
, it can be up to them to create a mechanism, use it in their own implement=
ation, and if they care to standardize it, they can?

On Thu, Apr 26, 2018 at 8:38 AM Patrick McManus <pmcmanus@mozilla.com> wrote:


On Wed, Apr 25, 2018 at 8:21 PM,=
 Ian Swett <ianswett=3D40google.com@dmarc.ietf.o=
rg> wrote:
It has been, and I'm personally supportive of it, because I believe it=
'll be useful for datacenter QUIC use cases.

can you layout the datacenter and PNE mismatch? It is just =
"more work" or is it an interaction with other hardware offloads?=


 







--00000000000068e8ec056ac2fba5--


From nobody Thu Apr 26 09:52:10 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DDF127863 for ; Thu, 26 Apr 2018 09:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 70LHDRhTaLlA for ; Thu, 26 Apr 2018 09:52:06 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429491267BB for ; Thu, 26 Apr 2018 09:52:06 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w3QGhn2t026408; Thu, 26 Apr 2018 17:51:54 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=wENYYY07Ngdmkd2hXSpGCul/xBQfiNDNBqpJ1mAM8Iw=; b=TNeEJ1ITYsXpDFDGTHTxqElBNWG+MiyOvgGP8d7GAil8qCehOkn1GGWjlNp56QCU4FOp 5KRgMxF8o0csbyZqTW8AK+/YzYPCKYLFbI1u3Uzj0mmUxm/4eIeJNM84Edn5LwT+R+7g SX5G+TyUPM9Stj1LFyMssbgD7GeIAUNHw0Yp8mESvnRdjzSGnk9rHlpGnIP/YR9D7jWE 3pL3j25umJwsltCirtq4u6gL1OgYQcNgZNbzl6l8ehPo7RYX7HDSsHJmfuAlP88LW/Ld 9lqhCkgjuJDkZa02Sr/8FHb++TCW4j2QGETzRfReJEMXR4Z6+O8GN/HYxbOtU7uYYz46 Cw== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2hjp9gutw7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Apr 2018 17:51:54 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3QGpDin026424; Thu, 26 Apr 2018 12:51:50 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint3.akamai.com with ESMTP id 2hg0nc5h2v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 26 Apr 2018 12:51:50 -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.1365.1; Thu, 26 Apr 2018 12:51:47 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1365.000; Thu, 26 Apr 2018 12:51:47 -0400
From: "Lubashev, Igor" 
To: Kazuho Oku , Erik Kline 
CC: Mark Nottingham , Mike Bishop , "Ian Swett" , Christian Huitema , IETF QUIC WG , "Deval, Manasi" 
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GWvgm/QKk890OIh9EYaPY3H6PwqlkAgAC4ugCAAARcAIAAG5CAgAAFCQCAAACJgIAAEVgAgACR+YCAB09lAIAFXyIAgAVK+oCAAJlSAIABxdSAgACOHYCAB/ExAIACo7YAgACiMICAAADPgIAAIs8AgAAm/YCAABEygIAABpIAgAAK6ACAAK10MA==
Date: Thu, 26 Apr 2018 16:51:46 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>        
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.33.80]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-26_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804260157
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-26_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804260156
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 26 Apr 2018 16:52:08 -0000

PiBpZiBzb21lIG1pZGRsZWJveGVzIGRlY2lkZSB0byBwYXNzIFFVSUMgd2l0aG91dCBQTkUgYnV0
IGJsb2NrIFFVSUMgd2l0aCBQTkUsIHdlIG1pZ2h0IGJlIGluY2VudGl2aXplZCB0byB1c2UgUVVJ
QyB3aXRob3V0IFBORS4NCg0KSWYgYSBtaWRkbGVib3ggcmVhbGx5IGRpc2xpa2VzIFBORSwgaXQg
Y2FuIGp1c3QgYmxvY2sgUVVJQyBhbHRvZ2V0aGVyLCBmb3JjaW5nIGEgVENQIGZhbGxiYWNrLiAg
SXMgVENQIGJldHRlciB0aGFuIFFVSUMtd2l0aG91dC1QTkUgZnJvbSBhbnkgUE9WIGluIHRoYXQg
c2l0dWF0aW9uPyAgKEFuZCBpZiBzbywgdGhpcyBzaG91bGQgYmUgdGhlIHJlY29tbWVuZGF0aW9u
IHRvIFFVSUMgc3RhY2tzIHdpdGggbmVnb3RpYWJsZSBQTkUgLS0gZmFsbGJhY2sgdG8gVENQLCBp
ZiBwYXRoIGlzIGJsb2NraW5nIFBORS4pDQoNCi0gSWdvcg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KRnJvbTogS2F6dWhvIE9rdSBbbWFpbHRvOmthenVob29rdUBnbWFpbC5jb21dIA0K
U2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxOCAxMDoyNSBQTQ0KVG86IEVyaWsgS2xpbmUg
PGVrQGdvb2dsZS5jb20+DQpDYzogTWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0PjsgTWlr
ZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdv
b2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0
ZW1hLm5ldD47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IERldmFsLCBNYW5hc2kgPG1h
bmFzaS5kZXZhbEBpbnRlbC5jb20+DQpTdWJqZWN0OiBSZTogR2V0dGluZyB0byBjb25zZW5zdXMg
b24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCjIwMTgtMDQtMjYgMTA6NDYgR01UKzA5OjAw
IEVyaWsgS2xpbmUgPGVrQGdvb2dsZS5jb20+Og0KPiBDb3VsZG4ndCBhIG1pZGRsZWJveCBoYXZl
IGEgcG9saWN5IHdoZXJlIGl0IHBlcm1pdHMgUVVJQyBzZXNzaW9ucyB3L28gDQo+IFBORSBidXQg
YmxvY2tzIHNlc3Npb25zIHdpdGggUE5FPyAgVGhlbiBpbXBsZW1lbnRhdGlvbnMgd291bGQgYmUg
DQo+IGZvcmNlZCB0byBjaG9vc2UgaG93IGFkYXB0OiBicmVhayBhbHRvZ2V0aGVyLCBtYXliZSB0
cnkgVENQLCBvciANCj4gZGlzYWJsZSBQTkUgYW5kIGNhcnJ5IG9uLg0KDQpUaGVyZSBhcmUgdHdv
IHdheXMgb2YgbmVnb3RpYXRpbmcgdGhlIHVzZSAob3Igbm9uLXVzZSkgb2YgUE5FLiBPbmUgaXMg
dXNlIFRyYW5zcG9ydCBQYXJhbWV0ZXJzIGFuZCB0aGUgb3RoZXIgaXMgdG8gdXNlIGEgZGlmZmVy
ZW50IFFVSUMgdmVyc2lvbi4NCg0KVXNlIG9mIFRyYW5zcG9ydCBQYXJhbWV0ZXJzIGlzIHNlY3Vy
ZSBiZWNhdXNlIGl0IGlzIHBhcnQgb2YgdGhlIFRMUyBoYW5kc2hha2UuIFZlcnNpb24gbmVnb3Rp
YXRpb24gaGFzIGl0J3Mgb3duIHByb3RlY3Rpb24gYWdhaW5zdCBkb3duZ3JhZGUgKG9yIHVwZ3Jh
ZGUpIGF0dGFja3MgKHNlZSBodHRwczovL3F1aWN3Zy5naXRodWIuaW8vYmFzZS1kcmFmdHMvZHJh
ZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC5odG1sI3JmYy5zZWN0aW9uLjYuNC40KS4NCg0KU28gSSB3
b3VsZCBhc3N1bWUgdGhhdCBhIG1pZGRsZWJveCB0cnlpbmcgdG8gaW50ZXJ2ZW5lIGluIHRoZSBu
ZWdvdGlhdGlvbiBvZiBQTkUgdXNlIGNhbiBiZSBkZXRlY3RlZC4NCg0KVGhhdCBzYWlkLCBJIGRv
IHNlZSB5b3VyIHBvaW50IHRoYXQgaWYgc29tZSBtaWRkbGVib3hlcyBkZWNpZGUgdG8gcGFzcyBR
VUlDIHdpdGhvdXQgUE5FIGJ1dCBibG9jayBRVUlDIHdpdGggUE5FLCB3ZSBtaWdodCBiZSBpbmNl
bnRpdml6ZWQgdG8gdXNlIFFVSUMgd2l0aG91dCBQTkUuIEluIHN1Y2ggY2FzZSwgd2UgbWlnaHQg
ZW5kIHVwIGhhdmluZyBwcml2YWN5IGxlYWtzICYgb3NzaWZpY2F0aW9uLg0KDQpJIHRoaW5rIHRo
YXQgaXMgYSBnb29kIGFyZ3VtZW50IGZvciBhbHdheXMgaGF2aW5nIFBORSB0dXJuZWQgb24uDQoN
Cj4NCj4gT24gMjYgQXByaWwgMjAxOCBhdCAwMToyMiwgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdt
YWlsLmNvbT4gd3JvdGU6DQo+PiAyMDE4LTA0LTI2IDk6MjEgR01UKzA5OjAwIElhbiBTd2V0dCA8
aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPjoNCj4+PiBJdCBoYXMgYmVlbiwg
YW5kIEknbSBwZXJzb25hbGx5IHN1cHBvcnRpdmUgb2YgaXQsIGJlY2F1c2UgSSBiZWxpZXZlIA0K
Pj4+IGl0J2xsIGJlIHVzZWZ1bCBmb3IgZGF0YWNlbnRlciBRVUlDIHVzZSBjYXNlcy4NCj4+Pg0K
Pj4+IEJ1dCB0aGUgV0cgaGFzIHRvIGRlY2lkZToNCj4+PiAgMSkgSXMgaXQgYWxsb3dhYmxlIHRv
IGRpc2FibGUgUE5FPw0KPj4NCj4+IFRoZXJlIGFyZSB0d28gY29uY2VybnMgdGhhdCBQTkUgaXMg
dHJ5aW5nIHRvIGFkZHJlc3M6IG9zc2lmaWNhdGlvbiBhbmQgcHJpdmFjeS4NCj4+DQo+PiBJIHdv
bid0IG1pbmQgaWYgc29tZSBwb3J0aW9uIG9mIFFVSUMtbGlrZSB0cmFmZmljIGhhcyBubyBtZWNo
YW5pc20gdG8gDQo+PiBwcmV2ZW50IG9zc2lmaWNhdGlvbi4gVGhpcyBpcyBiZWNhdXNlIHdlIGNh
biB0cmFpbiB0aGUgbWlkZGxlYm94ZXMgdG8gDQo+PiBub3Qgb3NzaWZ5IHRoZSBQTiBmaWVsZCBi
eSBoYXZpbmcgUE5FIGluIHRoZSBtYWpvcml0eSBvZiB0aGUgdHJhZmZpYyANCj4+IHRoYXQgdGhl
eSB3aWxsIHNlZS4NCj4+DQo+PiBPVE9ILCBJIHdvdWxkIGJlIHdvcnJpZWQgb2YgcHJpdmFjeSBp
bXBsaWNhdGlvbnMuIE9uY2UgeW91IGRlZmluZSBhIA0KPj4gcHJvdG9jb2wsIGl0IGlzIGhhcmQg
dG8gY29udHJvbCBob3cgaXQgaXMgZ29pbmcgdG8gYmUgdXNlZC4NCj4+DQo+PiBCdXQgd2l0aCB0
aGF0IHNhaWQsIEkgdGhpbmsgd2UgbWlnaHQgYmV0dGVyIHdhaXQgdG8gc2VlIGlmIHNvbWVib2R5
IA0KPj4gc3RpbGwgdGhpbmtzIGhlL3NoZSAqbmVlZHMqIFFVSUMgd2l0aG91dCBQTkUuDQo+Pg0K
Pj4+ICAyKSBXaGF0IHRoZSBtZWNoYW5pc20gaXM/ICBpZTogVW5pbGF0ZXJhbCB2aWEgVHJhbnNw
b3J0UGFyYW1zIG9yIA0KPj4+IG5lZ290aWF0ZWQgdmlhIGFuIGV4dGVuc2lvbiBvciA/DQo+Pj4N
Cj4+PiBPbiBXZWQsIEFwciAyNSwgMjAxOCBhdCA2OjAxIFBNIE1pa2UgQmlzaG9wIDxtYmlzaG9w
QGV2ZXF1ZWZvdS5iZT4gd3JvdGU6DQo+Pj4+DQo+Pj4+IEkgdGhpbmsgdGhhdOKAmXMgYmVlbiBz
dWdnZXN0ZWQgYmVmb3JlLCB0aG91Z2ggd2XigJlkIG5lZWQgdG8gc29ydCBvdXQgDQo+Pj4+IHRo
ZSBkZXRhaWxzIG9mIHdoYXQgdGhhdCBsb29rcyBsaWtlLiAgSSBkb27igJl0IGhhdmUgYSBwYXJ0
aWN1bGFyIGRlc2lnbiBpbiBtaW5kLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBGcm9tOiBJYW4g
U3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXQ0KPj4+PiBTZW50OiBXZWRuZXNkYXks
IEFwcmlsIDI1LCAyMDE4IDEyOjU3IFBNDQo+Pj4+IFRvOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBl
dmVxdWVmb3UuYmU+DQo+Pj4+IENjOiBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1h
Lm5ldD47IERldmFsLCBNYW5hc2kgDQo+Pj4+IDxtYW5hc2kuZGV2YWxAaW50ZWwuY29tPjsgTWFy
ayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0PjsgSUVURiANCj4+Pj4gUVVJQyBXRyA8cXVpY0Bp
ZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tl
dCBudW1iZXIgZW5jcnlwdGlvbg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBIaSBNaWtlLA0KPj4+
Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBUbyBjbGFyaWZ5LCBhcmUgeW91IHN1Z2dlc3RpbmcgYWRkaW5n
IGEgd2F5IHRvIGRpc2FibGUgcGFja2V0IA0KPj4+PiBudW1iZXIgZW5jcnlwdGlvbiB2aWEgbmVn
b3RpYXRpb24gaW4gdGhlIHYxIHNwZWMgYXMgd2VsbCBhcyANCj4+Pj4gYWRvcHRpbmcgIzEwNzk/
ICBPciB3b3VsZCB0aGUgY2hvaWNlIG9mIHdoZXRoZXIgUE5FIGlzIHRvIGJlIHVzZWQgDQo+Pj4+
IHVuaWxhdGVyYWwsIHN1Y2ggYXMgYSB0cmFuc3BvcnQgcGFyYW0/DQo+Pj4+DQo+Pj4+DQo+Pj4+
DQo+Pj4+IE9uIFdlZCwgQXByIDI1LCAyMDE4IGF0IDM6NTQgUE0gTWlrZSBCaXNob3AgPG1iaXNo
b3BAZXZlcXVlZm91LmJlPiB3cm90ZToNCj4+Pj4NCj4+Pj4gWWVzIC0tIGl0IHNlZW1zIHRoYXQg
dGhlIGJpZ2dlc3Qgb2JqZWN0aW9uIHRvICMxMDc5IHdhcyB0aGUgDQo+Pj4+IGRpZmZpY3VsdHkg
aW4gaGFyZHdhcmUgaW1wbGVtZW50YXRpb24uICBJZiB3ZSdyZSBoZWFyaW5nIHRoYXQgDQo+Pj4+
IGhhcmR3YXJlIGltcGxlbWVudGF0aW9uIGlzIGZlYXNpYmxlIGF0IGEgcmVhc29uYWJsZSBjb3N0
LCB0aGVuIEkgdGhpbmsgd2UgbWlnaHQgaGF2ZSBhIHdpbm5lci4NCj4+Pj4NCj4+Pj4gVGhlIENQ
VSBjb3N0IGZvciBhIHNvZnR3YXJlIGltcGxlbWVudGF0aW9uIGlzIHN0aWxsIHdvcnRoIA0KPj4+
PiBjb25zaWRlcmluZywgYW5kIGFuIG9wdGlvbiB0byBub3QgZW5jcnlwdCBpcyBwcm9iYWJseSBy
ZWFzb25hYmxlIHRvIA0KPj4+PiBsaW1pdCB0aGF0IGJ1cmRlbiBmb3IgaW1wbGVtZW50YXRpb25z
IC8gdXNlIGNhc2VzIHRoYXQgZG9uJ3QgY2FyZS4NCj4+Pj4NCj4+Pj4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBC
ZWhhbGYgT2YgQ2hyaXN0aWFuIEh1aXRlbWENCj4+Pj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAy
NSwgMjAxOCAzOjE0IEFNDQo+Pj4+IFRvOiBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuZGV2YWxAaW50
ZWwuY29tPjsgTWFyayBOb3R0aW5naGFtIA0KPj4+PiA8bW5vdEBtbm90Lm5ldD4NCj4+Pj4gQ2M6
IHF1aWNAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9u
IHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KPj4+Pg0KPj4+PiBPbiA0LzIzLzIwMTggNjo1NSBQ
TSwgRGV2YWwsIE1hbmFzaSB3cm90ZToNCj4+Pj4NCj4+Pj4gPiBJIGhhZCBicm91Z2h0IHVwIHRo
ZSBpc3N1ZSB3aXRoIFBORSBzZXZlcmFsIHdlZWtzIGFnbyBhcyBhIA0KPj4+PiA+IGJhcnJpZXIg
dG8gaGFyZHdhcmUgb2ZmbG9hZC4gQWZ0ZXIgZnVydGhlciByZXZpZXcsIGl0IGxvb2tzIGxpa2Ug
DQo+Pj4+ID4gYSBoYXJkd2FyZSBvZmZsb2FkIGNhbiBpbXBsZW1lbnQgdGhlIFBORSBhdCBhIHNt
YWxsIGNvc3QuDQo+Pj4+ID4NCj4+Pj4gPiBUaGUgaW1wbGVtZW50YXRpb24gY2FuIG1vZGlmeSBj
dXJyZW50IEhXIGNyeXB0byBhY2NlbGVyYXRvcnMgdG8gDQo+Pj4+ID4gc3VwcG9ydCBlbmNyeXB0
aW5nIGEgYnVmZmVyIGluIHRoZSBmaXJzdCBwYXNzIGFuZCB0aGVuIGVuY3J5cHRpbmcgDQo+Pj4+
ID4gcGFja2V0IG51bWJlciBpbiB0aGUgMm5kIHBhc3MgYXMgYWxyZWFkeSBkaXNjdXNzZWQgb24g
dGhpcyANCj4+Pj4gPiB0aHJlYWQuIFRoZSBleGFjdCByZXF1aXJlbWVudCAoaGVhZGVyIGNoZWNr
c3VtLCBwYWNrZXQgbGVuZ3RoIA0KPj4+PiA+IGVuY29kaW5nKSBpcyBzdGlsbCBpbiBmbHV4IHNv
IHRoZXJlIG1heSBiZSBzb21lIHNtYWxsIHZhcmlhdGlvbnMgDQo+Pj4+ID4gZGVwZW5kaW5nIG9u
IHRoZSBhY2NlbGVyYXRvciBhbmQgZmluYWwgYWxnb3JpdGhtIGNob3NlbiBmb3IgUE5FLiANCj4+
Pj4gPiBGdXR1cmUgb2ZmbG9hZCBkZXNpZ25zIGNhbiBkbyBtb3JlIHRvIGZ1cnRoZXIgcmVkdWNl
IHRoZSBvdmVyaGVhZC4NCj4+Pj4NCj4+Pj4gVGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24sIE1h
bmFzaS4gSSBoYXZlIG1vZGlmaWVkIHRoZSB3aWtpIHBhZ2UgDQo+Pj4+IGRlc2NyaWJpbmcgdGhl
IFBORSBpc3N1ZXMgYW5kIGFsdGVybmF0aXZlcyB0byByZWZsZWN0IHRoaXMgbmV3IGRhdGE6DQo+
Pj4+DQo+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvd2lraS9TdW1t
YXJ5LW9mLXRoZS1QTi1lbmNyeXB0aW9uLWlzc3Vlcy1hbmQtYWx0ZXJuYXRpdmVzLi4NCj4+Pj4g
V2l0aCB0aGF0IG5ldyBpbmZvcm1hdGlvbiwgaXQgYXBwZWFycyB0aGF0IFBSICMxMDc5IGlzIHN1
cGVyaW9yIHRvIA0KPj4+PiBldmVyeSBvdGhlciBhbHRlcm5hdGl2ZS4NCj4+Pj4NCj4+Pj4gLS0g
Q2hyaXN0aWFuIEh1aXRlbWENCj4+DQo+Pg0KPj4NCj4+IC0tDQo+PiBLYXp1aG8gT2t1DQo+Pg0K
DQoNCg0KLS0NCkthenVobyBPa3UNCg0K


From nobody Thu Apr 26 11:41:59 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0AB129C6A for ; Thu, 26 Apr 2018 11:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 XfPJNEym0wDs for ; Thu, 26 Apr 2018 11:41:56 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0097.outbound.protection.outlook.com [104.47.32.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D131200E5 for ; Thu, 26 Apr 2018 11:41:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9Jvf8F8Kmk0Nhb9fM9air0Y8eAs1qEOI0R0fIY2kOVw=; b=BTtpv6ckb4IX2ZzlPMKe/EGq/c4NvaLz61fyPYKIw/cU9U90avSdMenhDdRccfz4x+ss2iPl37/13G6ccyTzl6tStnDeTrXoww7pO2R7Hs9TRcJQ5Yj+HaGzLNqjtbeFEKZLSgyHopA+qAgJ9Qvok/mUyok8t0otbSO83cNzNHw=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0821.namprd21.prod.outlook.com (10.173.192.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.735.5; Thu, 26 Apr 2018 18:41:53 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::d528:81b1:ca53:b9e9]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::d528:81b1:ca53:b9e9%9]) with mapi id 15.20.0735.006; Thu, 26 Apr 2018 18:41:52 +0000
From: Praveen Balasubramanian 
To: Patrick McManus , Ian Swett 
CC: Mark Nottingham , huitema , Mike Bishop , IETF QUIC WG , "Deval, Manasi" 
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwZ0sAgAC4ugCAAARcAIAAFTbwgAALYgCAAAAgYIAAEcIAgACR+YCAB09lAIAFXyIAgAVK+oCAAJlSAIABxdSAgACOHICAB/EyAIACo7YAgACiMICAAADPgIAAIs8AgAAm/YCAAM3MgIAAPOiAgAAFrICAACDjwA==
Date: Thu, 26 Apr 2018 18:41:52 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>        
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:b::1d3]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0821; 7:Rpi5OfxV1YDPjZZf6EnTKKMZ4Bge+cCrjXC3jWIR9eaiX7M9SxhI7YCXzZCAJ0C+u0zPtOVMT3II5y33qU5jwjTlERFfljAMW6XNDrUl1IHOez8LbY2BKpYpGa8/iQvn4FrhsLbd6dtabnZK7hFGlBwc5Hcg/Y5zx5Vh85/I2UvhbyLP6TZZwWvLCw4BSzbMC5DnJfvSOPi3+C+yBBGIfmOpQxvOH6rMGnLXRhlmsMAxHnLK32WMqAUv9cz7roDO; 20:KF5fvvsB4XdL8ieiEbwSq5BPgpjImASzNFBsJL+vGMi69aCxluf+yrPLP6Fsjr3Rdg5JgdAUeBC0QvDiQsqAeJL8x21O56XUPbFpLktVSKJXKemoFqj+MkxQwuxweqznRj5dohaXAvvDKKddrLg3wadz5XUH+HWxJgFqr6jWVEM=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0821; 
x-ms-traffictypediagnostic: CY4PR21MB0821:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(189930954265078)(211936372134217)(100405760836317)(153496737603132)(219752817060721)(21748063052155)(228905959029699);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231232)(944501410)(52105095)(10201501046)(3002001)(6055026)(6041310)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0821; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0821; 
x-forefront-prvs: 0654257CF5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39380400002)(39860400002)(346002)(396003)(189003)(199004)(86612001)(10290500003)(3280700002)(105586002)(3660700001)(99286004)(86362001)(486006)(110136005)(7736002)(10090500001)(6436002)(93886005)(8936002)(6506007)(476003)(53546011)(76176011)(7696005)(74316002)(97736004)(106356001)(46003)(446003)(8990500004)(186003)(11346002)(2906002)(478600001)(102836004)(68736007)(8676002)(22452003)(5660300001)(25786009)(5250100002)(316002)(81156014)(33656002)(2900100001)(81166006)(6116002)(229853002)(606006)(790700001)(4326008)(19609705001)(54896002)(14454004)(6306002)(54906003)(6246003)(9686003)(236005)(55016002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0821; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Y3t2qAG0mi6QP32OGmhPRaNL9Lnre5h0J6qjklwt2Fy7PNQECDxniAtrg7xa4aw4fUaQv7GAKR/S3FWezjl5hGX4q/j/jhVMnvTTHwMvy8Rc5wTQMwxRO0Ng8QpGXJ5AUUI3DWM8pDwhhHZJynHKkeOMvclFvVc/FsVatgnwy1s6lAC18BH0/FLU/LEimPyN
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB063070BA1A6F891E58D91983B68E0CY4PR21MB0630namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: a4305d87-73d1-493d-eea5-08d5aba56119
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a4305d87-73d1-493d-eea5-08d5aba56119
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2018 18:41:52.8184 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0821
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 26 Apr 2018 18:41:58 -0000

--_000_CY4PR21MB063070BA1A6F891E58D91983B68E0CY4PR21MB0630namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiBpdCdzIGxpa2VseSBzb21lb25lIHdpbGwgd2FudCB0byBkaXNhYmxlIFBORSBmb3Igc29tZSB1
c2UgY2FzZSBhdCBzb21lIHBvaW50DQpZZXMgdGhlcmUgaXMgYSB2ZXJ5IGdvb2QgdXNlIGNhc2Ug
Zm9yIHRoaXMgaW4gZGF0YWNlbnRlciBhbmQgcHJpdmF0ZSBuZXR3b3JrcyBiZWNhdXNlIG9zc2lm
aWNhdGlvbiBvciBwcml2YWN5IGNvbmNlcm5zIGRvIG5vdCBhcHBseSBhbmQgdGhlIENQVSBjb3N0
IGlzIGhpZ2hlci4gQW5kIHRoZSBhZGRlZCBDUFUgY29zdCB3aWxsIGJlIGEgbXVjaCBoaWdoZXIg
cGVyY2VudGFnZSBmb3Igc21hbGxlciBwYWNrZXRzIGxpa2UgQUNLcy4gSGFyZHdhcmUgb2ZmbG9h
ZHMgd2lsbCB0YWtlIHNvbWUgdGltZSB0byBzaGlwLCBzdGFiaWxpemUgYW5kIGRlcGxveS4NCg0K
SW50cmEtZGF0YWNlbnRlciBkb2VzIG5vdCBpbXBseSBvbmx5IGEgc2luZ2xlIGltcGxlbWVudGF0
aW9uIGRvaW5nIHNvbWV0aGluZyBjdXN0b20uIFdlIGhhdmUgYSBsb3Qgb2YgVENQIHRyYWZmaWMg
YmV0d2VlbiBXaW5kb3dzIGFuZCBMaW51eCBzeXN0ZW1zIGZvciBleGFtcGxlLiBUaGUgbWVjaGFu
aXNtIG11c3QgYmUgc3RhbmRhcmRpemVkIG90aGVyd2lzZSBpdCBicmVha3MgaW50ZXJvcC4gVHJh
bnNwb3J0IHBhcmFtZXRlciBpcyBhIGJldHRlciBuZWdvdGlhdGlvbiBtZWNoYW5pc20gdGhhbiB2
ZXJzaW9ucyBiZWNhdXNlIG90aGVyd2lzZSBlYWNoIHN1Y2ggY3VzdG9taXphdGlvbiB3aWxsIGN1
dCB0aGUgdmVyc2lvbiBzcGFjZSBpbiBoYWxmLiBJc3N1ZSAjMTI5NjxodHRwczovL25hMDEuc2Fm
ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5j
b20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRmlzc3VlcyUyRjEyOTYmZGF0YT0wMiU3QzAxJTdD
cHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDYzQ2OTVjNDA1MDlhNGYzNzc3NDIwOGQ1YTQ5NmNkOGMl
N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTk1ODg5OTcx
NDQ4NjkxJnNkYXRhPUFmZmo1bDUlMkJuTENUd3ZMTGdTOSUyQjNnemUlMkY5YzlScmhGWklId0gl
MkZrMUxqdyUzRCZyZXNlcnZlZD0wPiB0cmFja3MgUE4gdHJhbnNmb3JtIG5lZ290aWF0aW9uLg0K
DQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
UGF0cmljayBNY01hbnVzDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjYsIDIwMTggOTozNiBBTQ0K
VG86IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT4NCkNjOiBNYXJrIE5vdHRpbmdoYW0g
PG1ub3RAbW5vdC5uZXQ+OyBodWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PjsgUGF0cmljayBN
Y01hbnVzIDxwbWNtYW51c0Btb3ppbGxhLmNvbT47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1
ZWZvdS5iZT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IERldmFsLCBNYW5hc2kgPG1h
bmFzaS5kZXZhbEBpbnRlbC5jb20+DQpTdWJqZWN0OiBSZTogR2V0dGluZyB0byBjb25zZW5zdXMg
b24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCnNndG0NCg0KT24gVGh1LCBBcHIgMjYsIDIw
MTggYXQgMTI6MTUgUE0sIElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFu
c3dldHRAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KRnJvbSBteSBwZXJzcGVjdGl2ZSwgaXQncyBqdXN0
ICJtb3JlIHdvcmsiIGFuZCBjZXJ0YWluIHdvcmtsb2FkcyBhcmUgcmVhbGx5IENQVSBjb3N0IHNl
bnNpdGl2ZSBpbiBkYXRhY2VudGVycyBpbiBhIHdheSB0aGF0IGlzbid0IHRydWUgb24gdGhlIHB1
YmxpYyBpbnRlcm5ldC4NCg0KVGhhdCBiZWluZyBzYWlkLCBkYXRhY2VudGVycyBtYXkgc3RhcnQg
bW92aW5nIHRvIGxhcmdlIE1UVXMgZWFybGllciB0aGFuIHRoZSBwdWJsaWMgaW50ZXJuZXQsIHdo
aWNoIHdvdWxkIGdyZWF0bHkgZGVjcmVhc2UgdGhlIHByYWN0aWNhbCBjb3N0IG9mIFBORS4NCg0K
R2l2ZW4gd2hlcmUgd2UncmUgYXQsIGV2ZW4gdGhvdWdoIEkgYmVsaWV2ZSBpdCdzIGxpa2VseSBz
b21lb25lIHdpbGwgd2FudCB0byBkaXNhYmxlIFBORSBmb3Igc29tZSB1c2UgY2FzZSBhdCBzb21l
IHBvaW50LCBJIHRoaW5rIHdlIHNob3VsZCBzcGVjIFBORSBhcyB0aGUgb25seSBvcHRpb24gZm9y
IG5vdyBhbmQgd2hlbiBzb21lb25lIG5lZWRzIHRvIGRpc2FibGUgaXQsIGl0IGNhbiBiZSB1cCB0
byB0aGVtIHRvIGNyZWF0ZSBhIG1lY2hhbmlzbSwgdXNlIGl0IGluIHRoZWlyIG93biBpbXBsZW1l
bnRhdGlvbiwgYW5kIGlmIHRoZXkgY2FyZSB0byBzdGFuZGFyZGl6ZSBpdCwgdGhleSBjYW4/DQoN
Ck9uIFRodSwgQXByIDI2LCAyMDE4IGF0IDg6MzggQU0gUGF0cmljayBNY01hbnVzIDxwbWNtYW51
c0Btb3ppbGxhLmNvbTxtYWlsdG86cG1jbWFudXNAbW96aWxsYS5jb20+PiB3cm90ZToNCg0KDQpP
biBXZWQsIEFwciAyNSwgMjAxOCBhdCA4OjIxIFBNLCBJYW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29v
Z2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJj
LmlldGYub3JnPj4gd3JvdGU6DQpJdCBoYXMgYmVlbiwgYW5kIEknbSBwZXJzb25hbGx5IHN1cHBv
cnRpdmUgb2YgaXQsIGJlY2F1c2UgSSBiZWxpZXZlIGl0J2xsIGJlIHVzZWZ1bCBmb3IgZGF0YWNl
bnRlciBRVUlDIHVzZSBjYXNlcy4NCg0KY2FuIHlvdSBsYXlvdXQgdGhlIGRhdGFjZW50ZXIgYW5k
IFBORSBtaXNtYXRjaD8gSXQgaXMganVzdCAibW9yZSB3b3JrIiBvciBpcyBpdCBhbiBpbnRlcmFj
dGlvbiB3aXRoIG90aGVyIGhhcmR3YXJlIG9mZmxvYWRzPw0KDQoNCg0K

--_000_CY4PR21MB063070BA1A6F891E58D91983B68E0CY4PR21MB0630namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC
My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv
ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S
RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj
b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt
LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft
YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9
DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu
aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs
dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw
ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN
Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs
MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn
aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN
CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh
W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9
ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv
dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jmd0OyBpdCdzIGxpa2VseSBzb21lb25lIHdpbGwgd2FudCB0byBkaXNh
YmxlIFBORSBmb3Igc29tZSB1c2UgY2FzZSBhdCBzb21lIHBvaW50PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMgdGhlcmUgaXMgYSB2ZXJ5IGdvb2QgdXNlIGNhc2UgZm9y
IHRoaXMgaW4gZGF0YWNlbnRlciBhbmQgcHJpdmF0ZSBuZXR3b3JrcyBiZWNhdXNlIG9zc2lmaWNh
dGlvbiBvciBwcml2YWN5IGNvbmNlcm5zIGRvIG5vdCBhcHBseSBhbmQgdGhlIENQVSBjb3N0IGlz
IGhpZ2hlci4gQW5kIHRoZSBhZGRlZCBDUFUgY29zdCB3aWxsIGJlIGEgbXVjaCBoaWdoZXIgcGVy
Y2VudGFnZSBmb3Igc21hbGxlciBwYWNrZXRzDQogbGlrZSBBQ0tzLiBIYXJkd2FyZSBvZmZsb2Fk
cyB3aWxsIHRha2Ugc29tZSB0aW1lIHRvIHNoaXAsIHN0YWJpbGl6ZSBhbmQgZGVwbG95LjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JbnRyYS1kYXRhY2VudGVyIGRvZXMgbm90IGltcGx5IG9ubHkg
YSBzaW5nbGUgaW1wbGVtZW50YXRpb24gZG9pbmcgc29tZXRoaW5nIGN1c3RvbS4gV2UgaGF2ZSBh
IGxvdCBvZiBUQ1AgdHJhZmZpYyBiZXR3ZWVuIFdpbmRvd3MgYW5kIExpbnV4IHN5c3RlbXMgZm9y
IGV4YW1wbGUuIFRoZSBtZWNoYW5pc20gbXVzdCBiZSBzdGFuZGFyZGl6ZWQgb3RoZXJ3aXNlIGl0
IGJyZWFrcyBpbnRlcm9wLiBUcmFuc3BvcnQgcGFyYW1ldGVyDQogaXMgYSBiZXR0ZXIgbmVnb3Rp
YXRpb24gbWVjaGFuaXNtIHRoYW4gdmVyc2lvbnMgYmVjYXVzZSBvdGhlcndpc2UgZWFjaCBzdWNo
IGN1c3RvbWl6YXRpb24gd2lsbCBjdXQgdGhlIHZlcnNpb24gc3BhY2UgaW4gaGFsZi4gSXNzdWUN
CjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/
dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGaXNz
dWVzJTJGMTI5NiZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDYzQ2
OTVjNDA1MDlhNGYzNzc3NDIwOGQ1YTQ5NmNkOGMlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk
MDExZGI0NyU3QzElN0MwJTdDNjM2NTk1ODg5OTcxNDQ4NjkxJmFtcDtzZGF0YT1BZmZqNWw1JTJC
bkxDVHd2TExnUzklMkIzZ3plJTJGOWM5UnJoRlpJSHdIJTJGazFManclM0QmYW1wO3Jlc2VydmVk
PTAiPg0KIzEyOTY8L2E+IHRyYWNrcyBQTiB0cmFuc2Zvcm0gbmVnb3RpYXRpb24uPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGll
dGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5QYXRyaWNrIE1jTWFudXM8YnI+DQo8Yj5TZW50
OjwvYj4gVGh1cnNkYXksIEFwcmlsIDI2LCAyMDE4IDk6MzYgQU08YnI+DQo8Yj5Ubzo8L2I+IElh
biBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1hcmsg
Tm90dGluZ2hhbSAmbHQ7bW5vdEBtbm90Lm5ldCZndDs7IGh1aXRlbWEgJmx0O2h1aXRlbWFAaHVp
dGVtYS5uZXQmZ3Q7OyBQYXRyaWNrIE1jTWFudXMgJmx0O3BtY21hbnVzQG1vemlsbGEuY29tJmd0
OzsgTWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJlJmd0OzsgSUVURiBRVUlDIFdH
ICZsdDtxdWljQGlldGYub3JnJmd0OzsgRGV2YWwsIE1hbmFzaSAmbHQ7bWFuYXNpLmRldmFsQGlu
dGVsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEdldHRpbmcgdG8gY29uc2Vuc3Vz
IG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+c2d0bTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
VGh1LCBBcHIgMjYsIDIwMTggYXQgMTI6MTUgUE0sIElhbiBTd2V0dCAmbHQ7PGEgaHJlZj0ibWFp
bHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pYW5zd2V0dEBnb29nbGUu
Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g
MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0
OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G
cm9tIG15IHBlcnNwZWN0aXZlLCBpdCdzIGp1c3QgJnF1b3Q7bW9yZSB3b3JrJnF1b3Q7IGFuZCBj
ZXJ0YWluIHdvcmtsb2FkcyBhcmUgcmVhbGx5IENQVSBjb3N0IHNlbnNpdGl2ZSBpbiBkYXRhY2Vu
dGVycyBpbiBhIHdheSB0aGF0IGlzbid0IHRydWUgb24gdGhlIHB1YmxpYyBpbnRlcm5ldC48bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgYmVpbmcgc2Fp
ZCwgZGF0YWNlbnRlcnMgbWF5IHN0YXJ0IG1vdmluZyB0byBsYXJnZSBNVFVzIGVhcmxpZXIgdGhh
biB0aGUgcHVibGljIGludGVybmV0LCB3aGljaCB3b3VsZCBncmVhdGx5IGRlY3JlYXNlIHRoZSBw
cmFjdGljYWwgY29zdCBvZiBQTkUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkdpdmVuIHdoZXJlIHdlJ3JlIGF0LCBldmVuIHRob3VnaCBJIGJl
bGlldmUgaXQncyBsaWtlbHkgc29tZW9uZSB3aWxsIHdhbnQgdG8gZGlzYWJsZSBQTkUgZm9yIHNv
bWUgdXNlIGNhc2UgYXQgc29tZSBwb2ludCwgSSB0aGluayB3ZSBzaG91bGQgc3BlYyBQTkUgYXMg
dGhlIG9ubHkgb3B0aW9uIGZvciBub3cgYW5kIHdoZW4gc29tZW9uZSBuZWVkcyB0byBkaXNhYmxl
IGl0LCBpdCBjYW4gYmUgdXAgdG8gdGhlbSB0bw0KIGNyZWF0ZSBhIG1lY2hhbmlzbSwgdXNlIGl0
IGluIHRoZWlyIG93biBpbXBsZW1lbnRhdGlvbiwgYW5kIGlmIHRoZXkgY2FyZSB0byBzdGFuZGFy
ZGl6ZSBpdCwgdGhleSBjYW4/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBcHIgMjYsIDIwMTggYXQgODoz
OCBBTSBQYXRyaWNrIE1jTWFudXMgJmx0OzxhIGhyZWY9Im1haWx0bzpwbWNtYW51c0Btb3ppbGxh
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBtY21hbnVzQG1vemlsbGEuY29tPC9hPiZndDsgd3JvdGU6
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7
bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXByIDI1LCAyMDE4IGF0
IDg6MjEgUE0sIElhbiBTd2V0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0PTQwZ29vZ2xl
LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0PTQwZ29vZ2xlLmNv
bUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv
dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk
ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SXQgaGFzIGJlZW4sIGFuZCBJJ20gcGVyc29uYWxseSBzdXBwb3J0aXZlIG9m
IGl0LCBiZWNhdXNlIEkgYmVsaWV2ZSBpdCdsbCBiZSB1c2VmdWwgZm9yIGRhdGFjZW50ZXIgUVVJ
QyB1c2UgY2FzZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNhbiB5b3UgbGF5b3V0IHRoZSBkYXRhY2VudGVyIGFu
ZCBQTkUgbWlzbWF0Y2g/IEl0IGlzIGp1c3QgJnF1b3Q7bW9yZSB3b3JrJnF1b3Q7IG9yIGlzIGl0
IGFuIGludGVyYWN0aW9uIHdpdGggb3RoZXIgaGFyZHdhcmUgb2ZmbG9hZHM/PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N
CjwvaHRtbD4NCg==

--_000_CY4PR21MB063070BA1A6F891E58D91983B68E0CY4PR21MB0630namp_--


From nobody Thu Apr 26 23:38:44 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419F212D95C for ; Thu, 26 Apr 2018 23:38:42 -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=unavailable 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 O87A4Tl4vlnE for ; Thu, 26 Apr 2018 23:38:39 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28ED2120725 for ; Thu, 26 Apr 2018 23:38:39 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id j5so755660pfh.2 for ; Thu, 26 Apr 2018 23:38:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kGMzlSpaYSt1LZVv0lMnlQsfuwTN2EAxILPIOUTxHUg=; b=s27LhoS1YLZeb4AGRLrc01kUJ+MSkC/OiRrq8BEWGZeeaIxzSd5+Gdbo571bj3r4xV /m+GHtKL3b5XWM09yO7U7nOd6bcp+DmwAS3cQwwDIUlsSEHkrro+8zA/RZf8PM9aTGGo YDmFwcuJUoWfMN3ji60+Pp2OIZ/lSWAEYMSLIq1hhMGCbRXtRN62WF/08xv3v6AG47xq PAC/YnqOpNYPRrkpXwa2mUMMPiU1hWXd9vy32KvHwmYog5tZUZpjoGDgMGdUnVgzCstj ZxjGxICVon1gPMvLUXmolbDBtXIolCaNj1akdCPkwTjUl07d+Yn2jzHivQNZAjwq3+bO EI2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=kGMzlSpaYSt1LZVv0lMnlQsfuwTN2EAxILPIOUTxHUg=; b=ITs4SLRKjSOWmqH/XblGCXQnQcWSzqdSuppK8NEJwa9dUzOsn5XqE2u+pHT5VS7fNH hSsZjZ6cEr8psTFwnqS+M/gl16zkLJIvcDbdgyEUUEE4Yhq+yJ55NMOjTZ7N/5ZGBDz1 JZWkzTeZwHe70W0xdGSgXwBjq4uIUwvq7FriQkSoG1hWbkLmWeg6WGFW1eLVbDPzkn7k FsuaoOPTKtBX70xaeU76ZeC6sWrrIIm8PPUXOCNKKR5Bfbh+FF1kYjOUpbSmFyj4E77J BN9TzyQx5XOLX32nz30Zdp5AcqvbBmLc8uDNUewvWYZXZdxxXO8p3eMFBQrz0K2LaHy1 /idA==
X-Gm-Message-State: ALQs6tD3SDRx+vQux2zsHBXAFXkvKz8F4eOn7bdnE+HIWN2QKh5eGL8d 7vl3St4U9IvyAUV+8HcRZMDu90A+YWqEiq1/tyM=
X-Google-Smtp-Source: AB8JxZp/uM0RHn8TZNWIUCNqySbIrxUSlSEHY/vDPopNjFHwXDWMF2RQUuKKD0BRIbsQymqa6c0qmDDdNtnWLV11Bzw=
X-Received: by 2002:a65:428b:: with SMTP id j11-v6mr1056288pgp.370.1524811118695;  Thu, 26 Apr 2018 23:38:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.137 with HTTP; Thu, 26 Apr 2018 23:38:38 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>         
From: Kazuho Oku 
Date: Fri, 27 Apr 2018 15:38:38 +0900
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: "Lubashev, Igor" 
Cc: Erik Kline , Mark Nottingham , Mike Bishop ,  Ian Swett ,  Christian Huitema , IETF QUIC WG ,  "Deval, Manasi" 
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: Fri, 27 Apr 2018 06:38:42 -0000

2018-04-27 1:51 GMT+09:00 Lubashev, Igor :
>> if some middleboxes decide to pass QUIC without PNE but block QUIC with =
PNE, we might be incentivized to use QUIC without PNE.
>
> If a middlebox really dislikes PNE, it can just block QUIC altogether, fo=
rcing a TCP fallback.  Is TCP better than QUIC-without-PNE from any POV in =
that situation?  (And if so, this should be the recommendation to QUIC stac=
ks with negotiable PNE -- fallback to TCP, if path is blocking PNE.)

The argument here is that if we define PNE as an option turned on by
default and see some middleboxes blocking PNE, we might be
incentivized to turn off PNE for *all* connections, because detecting
blockade and then falling back to a less secure protocol is hard and
time consuming.

> - Igor
>
> -----Original Message-----
> From: Kazuho Oku [mailto:kazuhooku@gmail.com]
> Sent: Wednesday, April 25, 2018 10:25 PM
> To: Erik Kline 
> Cc: Mark Nottingham ; Mike Bishop ; =
Ian Swett ; Christian Huitema ; IETF QUIC WG ; Deval, Manasi 
> Subject: Re: Getting to consensus on packet number encryption
>
> 2018-04-26 10:46 GMT+09:00 Erik Kline :
>> Couldn't a middlebox have a policy where it permits QUIC sessions w/o
>> PNE but blocks sessions with PNE?  Then implementations would be
>> forced to choose how adapt: break altogether, maybe try TCP, or
>> disable PNE and carry on.
>
> There are two ways of negotiating the use (or non-use) of PNE. One is use=
 Transport Parameters and the other is to use a different QUIC version.
>
> Use of Transport Parameters is secure because it is part of the TLS hands=
hake. Version negotiation has it's own protection against downgrade (or upg=
rade) attacks (see https://quicwg.github.io/base-drafts/draft-ietf-quic-tra=
nsport.html#rfc.section.6.4.4).
>
> So I would assume that a middlebox trying to intervene in the negotiation=
 of PNE use can be detected.
>
> That said, I do see your point that if some middleboxes decide to pass QU=
IC without PNE but block QUIC with PNE, we might be incentivized to use QUI=
C without PNE. In such case, we might end up having privacy leaks & ossific=
ation.
>
> I think that is a good argument for always having PNE turned on.
>
>>
>> On 26 April 2018 at 01:22, Kazuho Oku  wrote:
>>> 2018-04-26 9:21 GMT+09:00 Ian Swett :
>>>> It has been, and I'm personally supportive of it, because I believe
>>>> it'll be useful for datacenter QUIC use cases.
>>>>
>>>> But the WG has to decide:
>>>>  1) Is it allowable to disable PNE?
>>>
>>> There are two concerns that PNE is trying to address: ossification and =
privacy.
>>>
>>> I won't mind if some portion of QUIC-like traffic has no mechanism to
>>> prevent ossification. This is because we can train the middleboxes to
>>> not ossify the PN field by having PNE in the majority of the traffic
>>> that they will see.
>>>
>>> OTOH, I would be worried of privacy implications. Once you define a
>>> protocol, it is hard to control how it is going to be used.
>>>
>>> But with that said, I think we might better wait to see if somebody
>>> still thinks he/she *needs* QUIC without PNE.
>>>
>>>>  2) What the mechanism is?  ie: Unilateral via TransportParams or
>>>> negotiated via an extension or ?
>>>>
>>>> On Wed, Apr 25, 2018 at 6:01 PM Mike Bishop  wro=
te:
>>>>>
>>>>> I think that=E2=80=99s been suggested before, though we=E2=80=99d nee=
d to sort out
>>>>> the details of what that looks like.  I don=E2=80=99t have a particul=
ar design in mind.
>>>>>
>>>>>
>>>>>
>>>>> From: Ian Swett [mailto:ianswett@google.com]
>>>>> Sent: Wednesday, April 25, 2018 12:57 PM
>>>>> To: Mike Bishop 
>>>>> Cc: Christian Huitema ; Deval, Manasi
>>>>> ; Mark Nottingham ; IETF
>>>>> QUIC WG 
>>>>> Subject: Re: Getting to consensus on packet number encryption
>>>>>
>>>>>
>>>>>
>>>>> Hi Mike,
>>>>>
>>>>>
>>>>>
>>>>> To clarify, are you suggesting adding a way to disable packet
>>>>> number encryption via negotiation in the v1 spec as well as
>>>>> adopting #1079?  Or would the choice of whether PNE is to be used
>>>>> unilateral, such as a transport param?
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 25, 2018 at 3:54 PM Mike Bishop  wr=
ote:
>>>>>
>>>>> Yes -- it seems that the biggest objection to #1079 was the
>>>>> difficulty in hardware implementation.  If we're hearing that
>>>>> hardware implementation is feasible at a reasonable cost, then I thin=
k we might have a winner.
>>>>>
>>>>> The CPU cost for a software implementation is still worth
>>>>> considering, and an option to not encrypt is probably reasonable to
>>>>> limit that burden for implementations / use cases that don't care.
>>>>>
>>>>> -----Original Message-----
>>>>> From: QUIC  On Behalf Of Christian Huitema
>>>>> Sent: Wednesday, April 25, 2018 3:14 AM
>>>>> To: Deval, Manasi ; Mark Nottingham
>>>>> 
>>>>> Cc: quic@ietf.org
>>>>> Subject: Re: Getting to consensus on packet number encryption
>>>>>
>>>>> On 4/23/2018 6:55 PM, Deval, Manasi wrote:
>>>>>
>>>>> > I had brought up the issue with PNE several weeks ago as a
>>>>> > barrier to hardware offload. After further review, it looks like
>>>>> > a hardware offload can implement the PNE at a small cost.
>>>>> >
>>>>> > The implementation can modify current HW crypto accelerators to
>>>>> > support encrypting a buffer in the first pass and then encrypting
>>>>> > packet number in the 2nd pass as already discussed on this
>>>>> > thread. The exact requirement (header checksum, packet length
>>>>> > encoding) is still in flux so there may be some small variations
>>>>> > depending on the accelerator and final algorithm chosen for PNE.
>>>>> > Future offload designs can do more to further reduce the overhead.
>>>>>
>>>>> Thanks for the information, Manasi. I have modified the wiki page
>>>>> describing the PNE issues and alternatives to reflect this new data:
>>>>>
>>>>> https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encrypti=
on-issues-and-alternatives..
>>>>> With that new information, it appears that PR #1079 is superior to
>>>>> every other alternative.
>>>>>
>>>>> -- Christian Huitema
>>>
>>>
>>>
>>> --
>>> Kazuho Oku
>>>
>
>
>
> --
> Kazuho Oku
>



--=20
Kazuho Oku


From nobody Fri Apr 27 10:10:01 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51126127286 for ; Fri, 27 Apr 2018 10:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWCsWWNBYrCU for ; Fri, 27 Apr 2018 10:09:58 -0700 (PDT)
Received: from mail-yb0-x244.google.com (mail-yb0-x244.google.com [IPv6:2607:f8b0:4002:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E3D127137 for ; Fri, 27 Apr 2018 10:09:58 -0700 (PDT)
Received: by mail-yb0-x244.google.com with SMTP id l9-v6so865581ybm.8 for ; Fri, 27 Apr 2018 10:09:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RwjITyO1YWo6Cb65hgoDv9Y1yc29kWNViOXLlFNrPT8=; b=tDhD8zGRtD402avQv1elrqHIRA3W0n7NNn5pTLFIYxyjnohFbqrNWbIpQLJfIEJjNf HVzc7vI/S/qHlWQXIJe1YKqHFr9Yqwy6FXRRBB9QiAEAhsqZudr4Cto87pJHN9tKLEau RmzJQv//lFHPWHqFGxDpPuPFCFuEuieSUALl5IjhfqFUPouK6bpY81d60deafgVFSnzB n/M6ruShhr2bM/S4k+uek3Zc8B5FcqvxRsWWxNnW7oKKOyhpEU7HdKmRby+qKJJjg6qB 1pz9BDxGcI6QeXo9gUWqut3+jdYIJZUzXMEVN1rV9rbuJmH4nbq8p+q9Q/1JslAS0ed+ 3bQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RwjITyO1YWo6Cb65hgoDv9Y1yc29kWNViOXLlFNrPT8=; b=Z04G1a21SeoURZe6nmQAA2y1c6zF4MxQqajtuWawBr90ynRWnAs5Dp5sQT4IvAegie HFR1irk4LXeZRVW25wFOWPRi20DruJTrWhUbXIP+tHUSNHVM1Z9WH/lu2lXvHGmwesz2 8LwXgFSJA9NybYhShUnqDdKNgqB8s52nWL7Tiq9EIbxTG7A3qjuBszVTV/3ky5wdgNiZ g06dSrFHPcP1wQtwq2dT8GgCQhMsv5alp8tY8JiLSn5Wf/fY9Sk6hq3aidv7vZ/M8Kie dfFu7wodE/HjetEqvJncXeQdbbbIZ7D/rHKaARyaY9SyW7YY6Ar41s29l1E5Gl33MI7R j61w==
X-Gm-Message-State: ALQs6tATIlOJVswIHomYIoJh3i29pRtbxbpG91APn5kVUiNFc7GexVYR j+SQ2jox2UiRGvOTkLHzZAzdjbiL048onOkLqSnzlMxQ
X-Google-Smtp-Source: AB8JxZpvzukVtZcT1R8aIU48bplplD5g7AjMjsmm56v7s854tblVOOQfN9IZ14uzjIoVESxP+ACDbY4zPpRGvLMLmIM=
X-Received: by 2002:a25:910c:: with SMTP id v12-v6mr1709557ybl.413.1524848997063;  Fri, 27 Apr 2018 10:09:57 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Christopher Wood 
Date: Fri, 27 Apr 2018 17:09:46 +0000
Message-ID: 
Subject: Re: Server's Preferred Address
To: ianswett=40google.com@dmarc.ietf.org
Cc: mbishop@evequefou.be, 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: Fri, 27 Apr 2018 17:10:00 -0000

+1

I think this is a compelling change, at least for supporting migration in
the presence of anycast, and especially if the newly probed path properties
are superior to the one on which the handshake was performed.

Best,
Chris
On Thu, Apr 5, 2018 at 10:27 AM Ian Swett  wrote:

> I and the traffic engineers I work with would REALLY like to have this
feature.  Also, in practice it's required to make connection migration work
with anycast.

> At Google, we've started experimenting with this already in gQUIC, and it
works as expected, though you do need to probe before jumping to the new
server IP(as described in Mike's PR), or you risk a small but visible
number of connection failures post-handshake.

> On Thu, Apr 5, 2018 at 1:19 PM Mike Bishop  wrote:

>> As we walk along the spectrum from fixed 4-tuple for the life of a
connection to full multipath, #560 requested a solution to the problem of
Anycast IP addresses.  There are some large server deployments where the
front-end addresses are Anycast-based.  However, for a connection-oriented
protocol, you want to be =E2=80=9Csticky=E2=80=9D to the server endpoint th=
at you did the
handshake with.  Currently, that=E2=80=99s addressed with some amount of
re-forwarding internally and some amount of tolerated connection breakage.
This gets more painful if we support connection migration, as the same
Anycast address likely hits a different server from your new IP address.



>> PR#1251 builds on the path verification approach to enable servers to
hand off to a unicast IP address if desired.  It adds a transport parameter
in which the server supplies:

>> IP version
>> IP address
>> UDP port
>> Connection ID (possibly empty)
>> Stateless Reset Token



>> At the end of the handshake, the client SHOULD perform path validation
on the supplied address; if it succeeds, it transitions to the new
address.  If it fails, it just stays on the original (presumably Anycast)
address and takes the risk that the connection will fail when routing
changes.  (The SHOULD is a matter of some contention =E2=80=93 servers want=
 to be
able to rely on this, but can=E2=80=99t actually tell whether the client=E2=
=80=99s path
validation failed or was never attempted.)



>> It=E2=80=99s important to note that this isn=E2=80=99t full server migra=
tion =E2=80=93 it=E2=80=99s a
step in that direction, but this is scoped strictly to the server making
one change attempt to an address it provides at a specified time.  However,
this isn=E2=80=99t something that has seen broad discussion, so I wanted to=
 raise
it for the WG=E2=80=99s consideration.



>> (If we want to tackle server migration, I think the next piece would be
a frame that carries essentially the same information, requesting the
client to make a probe attempt.  This helps deal with NATs by making
clients speak first, but it assumes that the server always maintains
control of both addresses during a transition.  To support full P2P, where
both sides could be make-after-break, you basically need something like
ICE.)


From nobody Fri Apr 27 10:21:12 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BDA1275FD for ; Fri, 27 Apr 2018 10:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEVvdzb2qeUK for ; Fri, 27 Apr 2018 10:21:07 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D629612DA4C for ; Fri, 27 Apr 2018 10:21:01 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 81390340541; Fri, 27 Apr 2018 19:20:59 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.26388);  Fri, 27 Apr 2018 19:20:54 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri, 27 Apr 2018 19:20:54 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.78]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 53251098; Fri, 27 Apr 2018 19:20:54 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: Getting to consensus on packet number encryption
From: "Brian Trammell (IETF)" 
X-Mailer: iPhone Mail (15E216)
In-Reply-To: 
Date: Fri, 27 Apr 2018 19:20:53 +0200
Cc: "Lubashev, Igor" , Christian Huitema , Mark Nottingham , Mike Bishop , Ian Swett , Erik Kline , IETF QUIC WG , "Deval, Manasi" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <58447D8E-782C-431C-8FC3-71124B10A047@trammell.ch>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>          
To: Kazuho Oku 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 27 Apr 2018 17:21:11 -0000

Hi, all,

I am deeply skeptical of the possible existence of a box that would permit Q=
UIC with unencrypted PN, but not with encrypted PN. The PN is simply not val=
uable enough to the path on its own to do the design work to detect and inte=
rfere with that case. Better in that case just to block QUIC and force TCP f=
allback.

Again, I would like to encourage everyone to consider that a middlebox must s=
erve some perceived function to see deployment.=20

That said, it seems like we have a way forward for not-terrible-for-offload P=
NE, with negotiation to shut it off in controlled environments where one wan=
ts to shave energy expenditure. +1 to Praveen=E2=80=99s suggestion to add tr=
ansport parameters to the standard for this for purposes of interoperability=
.

Cheers, Brian



Sent from my iPhone

> On 27 Apr 2018, at 08:38, Kazuho Oku  wrote:
>=20
> 2018-04-27 1:51 GMT+09:00 Lubashev, Igor :
>>> if some middleboxes decide to pass QUIC without PNE but block QUIC with P=
NE, we might be incentivized to use QUIC without PNE.
>>=20
>> If a middlebox really dislikes PNE, it can just block QUIC altogether, fo=
rcing a TCP fallback.  Is TCP better than QUIC-without-PNE from any POV in t=
hat situation?  (And if so, this should be the recommendation to QUIC stacks=
 with negotiable PNE -- fallback to TCP, if path is blocking PNE.)
>=20
> The argument here is that if we define PNE as an option turned on by
> default and see some middleboxes blocking PNE, we might be
> incentivized to turn off PNE for *all* connections, because detecting
> blockade and then falling back to a less secure protocol is hard and
> time consuming.
>=20
>> - Igor
>>=20
>> -----Original Message-----
>> From: Kazuho Oku [mailto:kazuhooku@gmail.com]
>> Sent: Wednesday, April 25, 2018 10:25 PM
>> To: Erik Kline 
>> Cc: Mark Nottingham ; Mike Bishop ; I=
an Swett ; Christian Huitema ; IETF QUIC WG ; Deval, Manasi 
>> Subject: Re: Getting to consensus on packet number encryption
>>=20
>> 2018-04-26 10:46 GMT+09:00 Erik Kline :
>>> Couldn't a middlebox have a policy where it permits QUIC sessions w/o
>>> PNE but blocks sessions with PNE?  Then implementations would be
>>> forced to choose how adapt: break altogether, maybe try TCP, or
>>> disable PNE and carry on.
>>=20
>> There are two ways of negotiating the use (or non-use) of PNE. One is use=
 Transport Parameters and the other is to use a different QUIC version.
>>=20
>> Use of Transport Parameters is secure because it is part of the TLS hands=
hake. Version negotiation has it's own protection against downgrade (or upgr=
ade) attacks (see https://quicwg.github.io/base-drafts/draft-ietf-quic-trans=
port.html#rfc.section.6.4.4).
>>=20
>> So I would assume that a middlebox trying to intervene in the negotiation=
 of PNE use can be detected.
>>=20
>> That said, I do see your point that if some middleboxes decide to pass QU=
IC without PNE but block QUIC with PNE, we might be incentivized to use QUIC=
 without PNE. In such case, we might end up having privacy leaks & ossificat=
ion.
>>=20
>> I think that is a good argument for always having PNE turned on.
>>=20
>>>=20
>>>> On 26 April 2018 at 01:22, Kazuho Oku  wrote:
>>>> 2018-04-26 9:21 GMT+09:00 Ian Swett :
>>>>> It has been, and I'm personally supportive of it, because I believe
>>>>> it'll be useful for datacenter QUIC use cases.
>>>>>=20
>>>>> But the WG has to decide:
>>>>> 1) Is it allowable to disable PNE?
>>>>=20
>>>> There are two concerns that PNE is trying to address: ossification and p=
rivacy.
>>>>=20
>>>> I won't mind if some portion of QUIC-like traffic has no mechanism to
>>>> prevent ossification. This is because we can train the middleboxes to
>>>> not ossify the PN field by having PNE in the majority of the traffic
>>>> that they will see.
>>>>=20
>>>> OTOH, I would be worried of privacy implications. Once you define a
>>>> protocol, it is hard to control how it is going to be used.
>>>>=20
>>>> But with that said, I think we might better wait to see if somebody
>>>> still thinks he/she *needs* QUIC without PNE.
>>>>=20
>>>>> 2) What the mechanism is?  ie: Unilateral via TransportParams or
>>>>> negotiated via an extension or ?
>>>>>=20
>>>>>> On Wed, Apr 25, 2018 at 6:01 PM Mike Bishop  wr=
ote:
>>>>>>=20
>>>>>> I think that=E2=80=99s been suggested before, though we=E2=80=99d nee=
d to sort out
>>>>>> the details of what that looks like.  I don=E2=80=99t have a particul=
ar design in mind.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> From: Ian Swett [mailto:ianswett@google.com]
>>>>>> Sent: Wednesday, April 25, 2018 12:57 PM
>>>>>> To: Mike Bishop 
>>>>>> Cc: Christian Huitema ; Deval, Manasi
>>>>>> ; Mark Nottingham ; IETF
>>>>>> QUIC WG 
>>>>>> Subject: Re: Getting to consensus on packet number encryption
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Hi Mike,
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> To clarify, are you suggesting adding a way to disable packet
>>>>>> number encryption via negotiation in the v1 spec as well as
>>>>>> adopting #1079?  Or would the choice of whether PNE is to be used
>>>>>> unilateral, such as a transport param?
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Wed, Apr 25, 2018 at 3:54 PM Mike Bishop  wr=
ote:
>>>>>>=20
>>>>>> Yes -- it seems that the biggest objection to #1079 was the
>>>>>> difficulty in hardware implementation.  If we're hearing that
>>>>>> hardware implementation is feasible at a reasonable cost, then I thin=
k we might have a winner.
>>>>>>=20
>>>>>> The CPU cost for a software implementation is still worth
>>>>>> considering, and an option to not encrypt is probably reasonable to
>>>>>> limit that burden for implementations / use cases that don't care.
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: QUIC  On Behalf Of Christian Huitema
>>>>>> Sent: Wednesday, April 25, 2018 3:14 AM
>>>>>> To: Deval, Manasi ; Mark Nottingham
>>>>>> 
>>>>>> Cc: quic@ietf.org
>>>>>> Subject: Re: Getting to consensus on packet number encryption
>>>>>>=20
>>>>>>> On 4/23/2018 6:55 PM, Deval, Manasi wrote:
>>>>>>>=20
>>>>>>> I had brought up the issue with PNE several weeks ago as a
>>>>>>> barrier to hardware offload. After further review, it looks like
>>>>>>> a hardware offload can implement the PNE at a small cost.
>>>>>>>=20
>>>>>>> The implementation can modify current HW crypto accelerators to
>>>>>>> support encrypting a buffer in the first pass and then encrypting
>>>>>>> packet number in the 2nd pass as already discussed on this
>>>>>>> thread. The exact requirement (header checksum, packet length
>>>>>>> encoding) is still in flux so there may be some small variations
>>>>>>> depending on the accelerator and final algorithm chosen for PNE.
>>>>>>> Future offload designs can do more to further reduce the overhead.
>>>>>>=20
>>>>>> Thanks for the information, Manasi. I have modified the wiki page
>>>>>> describing the PNE issues and alternatives to reflect this new data:
>>>>>>=20
>>>>>> https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encrypti=
on-issues-and-alternatives..
>>>>>> With that new information, it appears that PR #1079 is superior to
>>>>>> every other alternative.
>>>>>>=20
>>>>>> -- Christian Huitema
>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Kazuho Oku
>>>>=20
>>=20
>>=20
>>=20
>> --
>> Kazuho Oku
>>=20
>=20
>=20
>=20
> --=20
> Kazuho Oku
>=20


From nobody Fri Apr 27 10:38:04 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA7012711D for ; Fri, 27 Apr 2018 10:38:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level: 
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz5nAInpoMb1 for ; Fri, 27 Apr 2018 10:38:01 -0700 (PDT)
Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 40831126D3F for ; Fri, 27 Apr 2018 10:38:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple;  q=dns/txt; i=@apple.com; t=1524850680; x=2388764280; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xpDgy6ekuWlja0IwRf6yWeHeP/hTVmF9RgJx2zed03c=; b=z/ccK/NQFmS8cq+ktORmD7N3zI+3hMv/VjM6Eud/tACUgXic0VIi5EHzoJQZEz0e zCIgLjDEUA9wOJ6h3K8tqChA9SzwLJNCXtjD3ODb/2UTxmEOgiizfM7L9OMgquc4 t1/cDLWS27lv16gNS3OMm95mRLyPhomKCjzweHpI2VBrlb4nwXDQmtvWNJphCdCe mBpK5ohm4Ub87hcPOLUfQJ7ostvW4CaZTNWoDaSG+eHvTPBWRrsQp1qjyonfePox bhcg4r/m6WhnzMjRMiDzOJzN+RXtGblAIqTIfgIye/rtfBrxYUaqX3Fkqg5O/gZX Vp7hKL+BHAa7s3vE7O8UXQ==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 7C.AA.04908.8FF53EA5; Fri, 27 Apr 2018 10:38:00 -0700 (PDT)
X-AuditID: 11973e16-446529e00000132c-a1-5ae35ff8e929
Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 7D.4E.23861.8FF53EA5; Fri, 27 Apr 2018 10:38:00 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from [17.234.117.50] (unknown [17.234.117.50]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr  3 2018)) with ESMTPSA id <0P7U00LT2UBCLY20@nwk-mmpp-sz09.apple.com>; Fri, 27 Apr 2018 10:38:00 -0700 (PDT)
Sender: rpaulo@apple.com
Subject: Re: Server's Preferred Address
From: Rui Paulo 
In-reply-to: 
Date: Fri, 27 Apr 2018 10:37:59 -0700
Cc: ianswett=40google.com@dmarc.ietf.org, quic@ietf.org, mbishop@evequefou.be
Content-transfer-encoding: quoted-printable
Message-id: <1561491C-0E30-4FB2-98D6-CE5480211D2E@apple.com>
References:   
To: Christopher Wood 
X-Mailer: Apple Mail (2.3445.6.18)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUi2FAYpfsj/nGUwZmbhhbTv19js3j48yuj xa/nXewWPQu4HVg8Tiy7wupx/vgGVo+ds+6yeyxZ8pMpgCWKyyYlNSezLLVI3y6BK6NzwWTG gvnMFZ96njA3MB5l6mLk5JAQMJGY/2UpSxcjF4eQwGomidd7NrLAJD5NeMgMYgsJrGeSuHWH FcTmFRCU+DH5HlANBwezgLrElCm5EL0TmSSmrW9mA6kRFpCQ2H/yITuErS6xdPs0sDlsAkoS z/pOgMU5BYIlbnzrYwKZwyKgKvHgtT9ImFnAV2LSz0NMELa2xJN3F6DW2kjM+/gN6s43jBJr f78AS4gIGEnsfHyKHeJmJYn/u44wgxRJCMxhk7g4+TTLBEbhWUjunoVw9ywkOxYwMq9iFMpN zMzRzcwz10ssKMhJ1UvOz93ECAr/6XZiOxgfrrI6xCjAwajEw8vg+ThKiDWxrLgy9xCjNAeL kjjvGrZHUUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYmWL+J+fVzRM56nv0kcaalUFCk5ny ln9NFezcMbNfOFvy9VbdiUqZ/vc29Z66a9I7z9BLPmDO3s9Mvuw7rB90fVs+U/agwv+NvroK SyYHJeU/9LxjmxRupMMktEXhlu0X6x91L6+IlgrVnvX6eOZZ/owJR5b3czUWvPz0c6OsQ8OH KO35ttt/K7EUZyQaajEXFScCALaP6BpgAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUi2FAcoPsj/nGUwbf5ehbTv19js3j48yuj xa/nXewWPQu4HVg8Tiy7wupx/vgGVo+ds+6yeyxZ8pMpgCWKyyYlNSezLLVI3y6BK6NzwWTG gvnMFZ96njA3MB5l6mLk5JAQMJH4NOEhM4gtJLCeSeLWHVYQm1dAUOLH5HssXYwcHMwC6hJT puR2MXIBlUxkkpi2vpkNpEZYQEJi/8mH7BC2usTS7dPA5rAJKEk86zsBFucUCJa48a2PCWQO i4CqxIPX/iBhZgFfiUk/DzFB2NoST95dgFprIzHv4zcWiF1vGCXW/n4BlhARMJLY+fgUO8TN ShL/dx1hnsAoMAvJqbMQTp2FZOwCRuZVjAJFqTmJlWZ6iQUFOal6yfm5mxjB4VoYtYOxYbnV IUYBDkYlHl4Gz8dRQqyJZcWVuYcYJTiYlUR4d9x+GCXEm5JYWZValB9fVJqTWnyIUZqDRUmc d60FULVAemJJanZqakFqEUyWiYNTqoFxkvpZNaO1J6ayue6u4HHzaRE/L6n4gyfqY7jwltbi 58/7mj8/2v32gQ/3moQPFb8y725fH3Xwpdu7ew8Y9tg/M6zn2VnLXXHAceL3uNb3C59vSzpw VuRRMa/UuhfBjB/WvZb6rWO7rJW9OU799pQzm6sPHTxRw2H7rnGt1P4nMVoZxzVspTdXKLEU ZyQaajEXFScCALgP3PVTAgAA
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 27 Apr 2018 17:38:03 -0000

On Apr 27, 2018, at 10:09, Christopher Wood =
 wrote:
>=20
> +1
>=20
> I think this is a compelling change, at least for supporting migration =
in
> the presence of anycast, and especially if the newly probed path =
properties
> are superior to the one on which the handshake was performed.

I also support this change and the PR looks good to me.

=E2=80=94
Rui Paulo


From nobody Fri Apr 27 17:08:18 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5159F12D72F for ; Fri, 27 Apr 2018 17:08:17 -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=unavailable 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 EZK6PBu0YaUW for ; Fri, 27 Apr 2018 17:08:14 -0700 (PDT)
Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8257B126CBF for ; Fri, 27 Apr 2018 17:08:13 -0700 (PDT)
Received: by mail-wr0-x244.google.com with SMTP id i14-v6so14146wre.2 for ; Fri, 27 Apr 2018 17:08: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=TKPEXGWcExrYlWC4MTaCtizHMNpycnxnLlHJUMs+OcI=; b=f+Kt5YZ2S/GIahmr9nIq3pgs0SrY3PfjMaLrBIT9aCAfe3Q/uLBDNJy5+5uni06Zts aEmh01KnQZHyqhjtu2r0A3+vvsSEUDIA28hLCZpEbHEPk7gwXcj4SlfT+eYUfIbIrOw8 FWhP1v+wmIM91oaVKhjU02vldOKjYx+qmI+E8a2wLryaPXWLKTRsBgqVRq0vSQF5XUYy if41fGrk/DtGrfg65/+TrKfQ8mfabOfMMTjNFjonQg/u1FOSEcQ7gLTfuN5Z9102wi4Z /5ATohovTibsMgehi5f9ME3lfb9a+iXjAcKpF9IaRC2hSVKBu28u3UncBZ7soWPPInrR m3IQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=TKPEXGWcExrYlWC4MTaCtizHMNpycnxnLlHJUMs+OcI=; b=nzpRbS7+i/bxF14fLaMCMtWG/Uu86Zdd13AqlKjAhr3bINZeDKMcQ+xPThjKarwWlu cnQKOOgfEadfs8iYFZRn9RxjxExp1H+YUAa+cv8o5JMRKiSpXg6T6/fN1EC3fYMayd11 gCi4TBQMwBOsXmTLO76Yxh+Rnc8znkEH5pMNW2dYQVfmYy0YgGHgXPndo3RUbgcsoW7L cyeCWtQw8r4daYg4db5qQyDPbLrAspCePTtJUJRzmXMqXwR0r66TwdCRBnMX4bgVCXQi mRMW4Y3BIN+mEmK0r7Q4QTsre4y6b6sdRybPZdJDPjlwZZC62rUiVItAMEh11pDdMyk1 bcmg==
X-Gm-Message-State: ALQs6tDZxxR3ThbYovz7X+7gsr1/hyYfOeVRdX8kFMEemXXOpFxOk00D rBLmSpFtezBqVCFjBPL6NukSNruVLD+ujdCoosY=
X-Google-Smtp-Source: AB8JxZqxi3JZmTnN3D0rnNArkFGmqY66UdgS7ZxNKA2GGCDXb+gqmN0sGvdpF0sLKzGDZ33IasmB5KDiBE8t+EW4/14=
X-Received: by 2002:adf:e312:: with SMTP id b18-v6mr2976036wrj.247.1524874091978;  Fri, 27 Apr 2018 17:08:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.187.9 with HTTP; Fri, 27 Apr 2018 17:08:11 -0700 (PDT)
In-Reply-To: <58447D8E-782C-431C-8FC3-71124B10A047@trammell.ch>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>          <58447D8E-782C-431C-8FC3-71124B10A047@trammell.ch>
From: Jana Iyengar 
Date: Fri, 27 Apr 2018 17:08:11 -0700
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: "Brian Trammell (IETF)" 
Cc: Kazuho Oku , "Lubashev, Igor" ,  Mark Nottingham , Mike Bishop ,  "Deval, Manasi" , Erik Kline ,  Christian Huitema , IETF QUIC WG ,  Ian Swett 
Content-Type: multipart/alternative; boundary="0000000000009467b0056add6ab0"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 28 Apr 2018 00:08:17 -0000

--0000000000009467b0056add6ab0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree that negotiating PNE runs the risk of having two types of
connections on the Internet. I agree that the risk of blockage doesn't seem
high, but honestly, having seen how middlebox features get deployed, I'm
not convinced that it won't happen (though I suspect it's unlikely to
happen at a large scale). I understand the desire to have it off within DCs
though, so I'm sensitive to that need.

I'd like to hear more about why making PNE optional isn't a decision that
we can punt to later though. I'd like to move along with PNE now, and come
back to negotiating this as an option once we have some deployment
work/experience in intra DC environments. I'm not yet convinced that this
is going to be your biggest cost in an intra-DC environment, and if it is,
then we can surely revisit this decision and add a param later to make PNE
optional, either later in v1 or in v2. We are talking about a very narrow
view into total cost at this point -- this one AES op is unlikely to be the
bottleneck. But I have no data, and I don't think anyone has any full
deployment experience yet.

TL;DR: I'd like to suggest that we move ahead with PR #1079, and continue
discussion on adding optional PNE in Issue #1296.

Brian: You're right that a middlebox must serve some perceived function to
see deployment. The problem is that the value and cost of any deployed
function however is also perceived, and everyone has different perceptions.


On Fri, Apr 27, 2018 at 10:20 AM, Brian Trammell (IETF) 
wrote:

> Hi, all,
>
> I am deeply skeptical of the possible existence of a box that would permi=
t
> QUIC with unencrypted PN, but not with encrypted PN. The PN is simply not
> valuable enough to the path on its own to do the design work to detect an=
d
> interfere with that case. Better in that case just to block QUIC and forc=
e
> TCP fallback.
>
> Again, I would like to encourage everyone to consider that a middlebox
> must serve some perceived function to see deployment.
>
> That said, it seems like we have a way forward for
> not-terrible-for-offload PNE, with negotiation to shut it off in controll=
ed
> environments where one wants to shave energy expenditure. +1 to Praveen=
=E2=80=99s
> suggestion to add transport parameters to the standard for this for
> purposes of interoperability..
>
> Cheers, Brian
>
>
>
> Sent from my iPhone
>
> > On 27 Apr 2018, at 08:38, Kazuho Oku  wrote:
> >
> > 2018-04-27 1:51 GMT+09:00 Lubashev, Igor :
> >>> if some middleboxes decide to pass QUIC without PNE but block QUIC
> with PNE, we might be incentivized to use QUIC without PNE.
> >>
> >> If a middlebox really dislikes PNE, it can just block QUIC altogether,
> forcing a TCP fallback.  Is TCP better than QUIC-without-PNE from any POV
> in that situation?  (And if so, this should be the recommendation to QUIC
> stacks with negotiable PNE -- fallback to TCP, if path is blocking PNE.)
> >
> > The argument here is that if we define PNE as an option turned on by
> > default and see some middleboxes blocking PNE, we might be
> > incentivized to turn off PNE for *all* connections, because detecting
> > blockade and then falling back to a less secure protocol is hard and
> > time consuming.
> >
> >> - Igor
> >>
> >> -----Original Message-----
> >> From: Kazuho Oku [mailto:kazuhooku@gmail.com]
> >> Sent: Wednesday, April 25, 2018 10:25 PM
> >> To: Erik Kline 
> >> Cc: Mark Nottingham ; Mike Bishop ;
> Ian Swett ; Christian Huitema <
> huitema@huitema.net>; IETF QUIC WG ; Deval, Manasi <
> manasi.deval@intel.com>
> >> Subject: Re: Getting to consensus on packet number encryption
> >>
> >> 2018-04-26 10:46 GMT+09:00 Erik Kline :
> >>> Couldn't a middlebox have a policy where it permits QUIC sessions w/o
> >>> PNE but blocks sessions with PNE?  Then implementations would be
> >>> forced to choose how adapt: break altogether, maybe try TCP, or
> >>> disable PNE and carry on.
> >>
> >> There are two ways of negotiating the use (or non-use) of PNE. One is
> use Transport Parameters and the other is to use a different QUIC version=
.
> >>
> >> Use of Transport Parameters is secure because it is part of the TLS
> handshake. Version negotiation has it's own protection against downgrade
> (or upgrade) attacks (see https://quicwg.github.io/base-
> drafts/draft-ietf-quic-transport.html#rfc.section.6.4.4).
> >>
> >> So I would assume that a middlebox trying to intervene in the
> negotiation of PNE use can be detected.
> >>
> >> That said, I do see your point that if some middleboxes decide to pass
> QUIC without PNE but block QUIC with PNE, we might be incentivized to use
> QUIC without PNE. In such case, we might end up having privacy leaks &
> ossification.
> >>
> >> I think that is a good argument for always having PNE turned on.
> >>
> >>>
> >>>> On 26 April 2018 at 01:22, Kazuho Oku  wrote:
> >>>> 2018-04-26 9:21 GMT+09:00 Ian Swett  ietf...org>:
> >>>>> It has been, and I'm personally supportive of it, because I believe
> >>>>> it'll be useful for datacenter QUIC use cases.
> >>>>>
> >>>>> But the WG has to decide:
> >>>>> 1) Is it allowable to disable PNE?
> >>>>
> >>>> There are two concerns that PNE is trying to address: ossification
> and privacy.
> >>>>
> >>>> I won't mind if some portion of QUIC-like traffic has no mechanism t=
o
> >>>> prevent ossification. This is because we can train the middleboxes t=
o
> >>>> not ossify the PN field by having PNE in the majority of the traffic
> >>>> that they will see.
> >>>>
> >>>> OTOH, I would be worried of privacy implications. Once you define a
> >>>> protocol, it is hard to control how it is going to be used.
> >>>>
> >>>> But with that said, I think we might better wait to see if somebody
> >>>> still thinks he/she *needs* QUIC without PNE.
> >>>>
> >>>>> 2) What the mechanism is?  ie: Unilateral via TransportParams or
> >>>>> negotiated via an extension or ?
> >>>>>
> >>>>>> On Wed, Apr 25, 2018 at 6:01 PM Mike Bishop 
> wrote:
> >>>>>>
> >>>>>> I think that=E2=80=99s been suggested before, though we=E2=80=99d =
need to sort out
> >>>>>> the details of what that looks like.  I don=E2=80=99t have a parti=
cular
> design in mind.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> From: Ian Swett [mailto:ianswett@google.com]
> >>>>>> Sent: Wednesday, April 25, 2018 12:57 PM
> >>>>>> To: Mike Bishop 
> >>>>>> Cc: Christian Huitema ; Deval, Manasi
> >>>>>> ; Mark Nottingham ; IETF
> >>>>>> QUIC WG 
> >>>>>> Subject: Re: Getting to consensus on packet number encryption
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Hi Mike,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> To clarify, are you suggesting adding a way to disable packet
> >>>>>> number encryption via negotiation in the v1 spec as well as
> >>>>>> adopting #1079?  Or would the choice of whether PNE is to be used
> >>>>>> unilateral, such as a transport param?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Apr 25, 2018 at 3:54 PM Mike Bishop 
> wrote:
> >>>>>>
> >>>>>> Yes -- it seems that the biggest objection to #1079 was the
> >>>>>> difficulty in hardware implementation.  If we're hearing that
> >>>>>> hardware implementation is feasible at a reasonable cost, then I
> think we might have a winner.
> >>>>>>
> >>>>>> The CPU cost for a software implementation is still worth
> >>>>>> considering, and an option to not encrypt is probably reasonable t=
o
> >>>>>> limit that burden for implementations / use cases that don't care.
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: QUIC  On Behalf Of Christian Huitema
> >>>>>> Sent: Wednesday, April 25, 2018 3:14 AM
> >>>>>> To: Deval, Manasi ; Mark Nottingham
> >>>>>> 
> >>>>>> Cc: quic@ietf.org
> >>>>>> Subject: Re: Getting to consensus on packet number encryption
> >>>>>>
> >>>>>>> On 4/23/2018 6:55 PM, Deval, Manasi wrote:
> >>>>>>>
> >>>>>>> I had brought up the issue with PNE several weeks ago as a
> >>>>>>> barrier to hardware offload. After further review, it looks like
> >>>>>>> a hardware offload can implement the PNE at a small cost.
> >>>>>>>
> >>>>>>> The implementation can modify current HW crypto accelerators to
> >>>>>>> support encrypting a buffer in the first pass and then encrypting
> >>>>>>> packet number in the 2nd pass as already discussed on this
> >>>>>>> thread. The exact requirement (header checksum, packet length
> >>>>>>> encoding) is still in flux so there may be some small variations
> >>>>>>> depending on the accelerator and final algorithm chosen for PNE.
> >>>>>>> Future offload designs can do more to further reduce the overhead=
.
> >>>>>>
> >>>>>> Thanks for the information, Manasi. I have modified the wiki page
> >>>>>> describing the PNE issues and alternatives to reflect this new dat=
a:
> >>>>>>
> >>>>>> https://github.com/quicwg/base-drafts/wiki/Summary-of-
> the-PN-encryption-issues-and-alternatives..
> >>>>>> With that new information, it appears that PR #1079 is superior to
> >>>>>> every other alternative.
> >>>>>>
> >>>>>> -- Christian Huitema
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Kazuho Oku
> >>>>
> >>
> >>
> >>
> >> --
> >> Kazuho Oku
> >>
> >
> >
> >
> > --
> > Kazuho Oku
> >
>
>

--0000000000009467b0056add6ab0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I agree that negotiating PNE runs the risk of having two t=
ypes of connections on the Internet. I agree that the risk of blockage does=
n't seem high, but honestly, having seen how middlebox features get dep=
loyed, I'm not=C2=A0convinced that it won't happen (though I suspec=
t it's unlikely to happen at a large scale). I understand the desire to=
 have it off within DCs though, so I'm sensitive to that need.

=

I'd like to hear more about why making PNE optional isn'=
t a decision that we can punt to later though. I'd like to move along w=
ith PNE now, and come back to negotiating this as an option once we have so=
me deployment work/experience in intra DC environments. I'm not yet con=
vinced that this is going to be your biggest cost in an intra-DC environmen=
t, and if it is, then we can surely revisit this decision and add a param l=
ater to make PNE optional, either later in v1 or in v2. We are talking abou=
t a very narrow view into total cost at this point -- this one AES op is un=
likely to be the bottleneck. But I have no data, and I don't think anyo=
ne has any full deployment experience yet.

TL;DR: =
I'd like to suggest that we move ahead with PR #1079, and continue disc=
ussion on adding optional PNE in Issue #1296.

Brian: You're right that a middlebox must serve s=
ome perceived function to see deployment. The problem is that the value and=
 cost of any deployed function however is also perceived, and everyone has =
different perceptions.


<=
div class=3D"gmail_quote">On Fri, Apr 27, 2018 at 10:20 AM, Brian Trammell =
(IETF) <ietf@trammell.ch> wrote:
Hi, all,



I am deeply skeptical of the possible existence of a box that would permit =
QUIC with unencrypted PN, but not with encrypted PN. The PN is simply not v=
aluable enough to the path on its own to do the design work to detect and i=
nterfere with that case. Better in that case just to block QUIC and force T=
CP fallback.



Again, I would like to encourage everyone to consider that a middlebox must=
 serve some perceived function to see deployment. 



That said, it seems like we have a way forward for not-terrible-for-offload=
 PNE, with negotiation to shut it off in controlled environments where one =
wants to shave energy expenditure. +1 to Praveen=E2=80=99s suggestion to ad=
d transport parameters to the standard for this for purposes of interoperab=
ility..



Cheers, Brian







Sent from my iPhone




> On 27 Apr 2018, at 08:38, Kazuho Oku <kazuhooku@gmail.com> wrote:

> 

> 2018-04-27 1:51 GMT+09:00 Lubashev, Igor <ilubashe@akamai.com>:

>>> if some middleboxes decide to pass QUIC without PNE but block =
QUIC with PNE, we might be incentivized to use QUIC without PNE.

>> 

>> If a middlebox really dislikes PNE, it can just block QUIC altoget=
her, forcing a TCP fallback.=C2=A0 Is TCP better than QUIC-without-PNE from=
 any POV in that situation?=C2=A0 (And if so, this should be the recommenda=
tion to QUIC stacks with negotiable PNE -- fallback to TCP, if path is bloc=
king PNE.)

> 

> The argument here is that if we define PNE as an option turned on by
> default and see some middleboxes blocking PNE, we might be

> incentivized to turn off PNE for *all* connections, because detecting<=
br>
> blockade and then falling back to a less secure protocol is hard and
> time consuming.

> 

>> - Igor

>> 

>> -----Original Message-----

>> From: Kazuho Oku [mailto:ka=
zuhooku@gmail.com]

>> Sent: Wednesday, April 25, 2018 10:25 PM

>> To: Erik Kline <ek@google.com<=
/a>>

>> Cc: Mark Nottingham <mnot@mnot=
.net>; Mike Bishop <mbish=
op@evequefou.be>; Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Christian H=
uitema <huitema@huitema.net&g=
t;; IETF QUIC WG <quic@ietf.org>=
; Deval, Manasi <manasi.deval@=
intel.com>

>> Subject: Re: Getting to consensus on packet number encryption

>> 

>> 2018-04-26 10:46 GMT+09:00 Erik Kline <ek@google.com>:

>>> Couldn't a middlebox have a policy where it permits QUIC s=
essions w/o

>>> PNE but blocks sessions with PNE?=C2=A0 Then implementations w=
ould be

>>> forced to choose how adapt: break altogether, maybe try TCP, o=
r

>>> disable PNE and carry on.

>> 

>> There are two ways of negotiating the use (or non-use) of PNE. One=
 is use Transport Parameters and the other is to use a different QUIC versi=
on.

>> 

>> Use of Transport Parameters is secure because it is part of the TL=
S handshake. Version negotiation has it's own protection against downgr=
ade (or upgrade) attacks (see https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.6.4.4).

>> 

>> So I would assume that a middlebox trying to intervene in the nego=
tiation of PNE use can be detected.

>> 

>> That said, I do see your point that if some middleboxes decide to =
pass QUIC without PNE but block QUIC with PNE, we might be incentivized to =
use QUIC without PNE. In such case, we might end up having privacy leaks &a=
mp; ossification.

>> 

>> I think that is a good argument for always having PNE turned on.
>> 

>>> 

>>>> On 26 April 2018 at 01:22, Kazuho Oku <kazuhooku@gmail.com> wrote:


>>>> 2018-0=
4-26 9:21 GMT+09:00 Ian Swett <ianswett=3D40google.com@dmarc.ietf..=
.org>:

>>>>> It has been, and I'm personally supportive of it, =
because I believe

>>>>> it'll be useful for datacenter QUIC use cases.

>>>>> 

>>>>> But the WG has to decide:

>>>>> 1) Is it allowable to disable PNE?

>>>> 

>>>> There are two concerns that PNE is trying to address: ossi=
fication and privacy.

>>>> 

>>>> I won't mind if some portion of QUIC-like traffic has =
no mechanism to

>>>> prevent ossification. This is because we can train the mid=
dleboxes to

>>>> not ossify the PN field by having PNE in the majority of t=
he traffic

>>>> that they will see.

>>>> 

>>>> OTOH, I would be worried of privacy implications. Once you=
 define a

>>>> protocol, it is hard to control how it is going to be used=
.

>>>> 

>>>> But with that said, I think we might better wait to see if=
 somebody

>>>> still thinks he/she *needs* QUIC without PNE.

>>>> 

>>>>> 2) What the mechanism is?=C2=A0 ie: Unilateral via Tra=
nsportParams or

>>>>> negotiated via an extension or ?

>>>>> 

>>>>>> On Wed, Apr 25, 2018 at 6:01 PM Mike Bishop <mbishop@evequefou.be> wrote:
>>>>>> 

>>>>>> I think that=E2=80=99s been suggested before, thou=
gh we=E2=80=99d need to sort out

>>>>>> the details of what that looks like.=C2=A0 I don=
=E2=80=99t have a particular design in mind.

>>>>>> 

>>>>>> 

>>>>>> 

>>>>>> From: Ian Swett [mailto:ianswett@google.com]

>>>>>> Sent: Wednesday, April 25, 2018 12:57 PM

>>>>>> To: Mike Bishop <mbishop@evequefou.be>

>>>>>> Cc: Christian Huitema <huitema@huitema.net>; Deval, Manasi

>>>>>> <mana=
si.deval@intel.com>; Mark Nottingham <mnot@mnot.net>; IETF

>>>>>> QUIC WG <quic@=
ietf.org>

>>>>>> Subject: Re: Getting to consensus on packet number=
 encryption

>>>>>> 

>>>>>> 

>>>>>> 

>>>>>> Hi Mike,

>>>>>> 

>>>>>> 

>>>>>> 

>>>>>> To clarify, are you suggesting adding a way to dis=
able packet

>>>>>> number encryption via negotiation in the v1 spec a=
s well as

>>>>>> adopting #1079?=C2=A0 Or would the choice of wheth=
er PNE is to be used

>>>>>> unilateral, such as a transport param?

>>>>>> 

>>>>>> 

>>>>>> 

>>>>>> On Wed, Apr 25, 2018 at 3:54 PM Mike Bishop <mbishop@evequefou.be> wrote:
>>>>>> 

>>>>>> Yes -- it seems that the biggest objection to #107=
9 was the

>>>>>> difficulty in hardware implementation.=C2=A0 If we=
're hearing that

>>>>>> hardware implementation is feasible at a reasonabl=
e cost, then I think we might have a winner.

>>>>>> 

>>>>>> The CPU cost for a software implementation is stil=
l worth

>>>>>> considering, and an option to not encrypt is proba=
bly reasonable to

>>>>>> limit that burden for implementations / use cases =
that don't care.

>>>>>> 

>>>>>> -----Original Message-----

>>>>>> From: QUIC <quic-bounces@ietf.org> On Behalf Of Christian Huitema

>>>>>> Sent: Wednesday, April 25, 2018 3:14 AM

>>>>>> To: Deval, Manasi <manasi.deval@intel.com>; Mark Nottingham

>>>>>> <mnot@mnot.net=
>

>>>>>> Cc: quic@ietf.org=


>>>>>> Subject: Re: Getting to consensus on packet number=
 encryption

>>>>>> 

>>>>>>> On 4/23/2018 6:55 PM, Deval, Manasi wrote:

>>>>>>> 

>>>>>>> I had brought up the issue with PNE several we=
eks ago as a

>>>>>>> barrier to hardware offload. After further rev=
iew, it looks like

>>>>>>> a hardware offload can implement the PNE at a =
small cost.

>>>>>>> 

>>>>>>> The implementation can modify current HW crypt=
o accelerators to

>>>>>>> support encrypting a buffer in the first pass =
and then encrypting

>>>>>>> packet number in the 2nd pass as already discu=
ssed on this

>>>>>>> thread. The exact requirement (header checksum=
, packet length

>>>>>>> encoding) is still in flux so there may be som=
e small variations

>>>>>>> depending on the accelerator and final algorit=
hm chosen for PNE.

>>>>>>> Future offload designs can do more to further =
reduce the overhead.

>>>>>> 

>>>>>> Thanks for the information, Manasi. I have modifie=
d the wiki page

>>>>>> describing the PNE issues and alternatives to refl=
ect this new data:

>>>>>> 

>>>>>> https://github.com/quicwg/base-drafts/wiki/Summary=
-of-the-PN-encryption-issues-and-alternatives..

>>>>>> With that new information, it appears that PR #107=
9 is superior to

>>>>>> every other alternative.

>>>>>> 

>>>>>> -- Christian Huitema

>>>> 

>>>> 

>>>> 

>>>> --

>>>> Kazuho Oku

>>>> 

>> 

>> 

>> 

>> --

>> Kazuho Oku

>> 

> 

> 

> 

> -- 

> Kazuho Oku

> 







--0000000000009467b0056add6ab0--


From nobody Sun Apr 29 12:25:53 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59878126D45 for ; Sun, 29 Apr 2018 12:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrTLO6yxZyfF for ; Sun, 29 Apr 2018 12:25:48 -0700 (PDT)
Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002: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 A7DCE126BF6 for ; Sun, 29 Apr 2018 12:25:48 -0700 (PDT)
Received: by mail-yb0-x234.google.com with SMTP id b14-v6so2408002ybk.1 for ; Sun, 29 Apr 2018 12:25:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jE2aiTqc5HmH4pPL0Elc5lj0SpAo9LUKe4nAEQcUQgQ=; b=OPYnUwM+cTHABptwTCn2K44d8tO5GIDU2Z1eWt8DM8u2xG0FlVhPaoUWTkUnOiJtHz cA+G0Ku18kbLQJWBZ6y6FvD4Iwt7c6TvxksQUJwVJwOLrIuZFL+rKaOCmpWnlaKklhY/ kRnF8uqydLULO0+sITt3Piew98D7VQi3udNdnSbagXsOz49G8/ZoAHRU+Dir6inY+hN2 tuyUCl4sPClQU3VI2ex6CixoxtMiHi1Uo3i3WOJPa3Pt/yjpQRnWMfxoq4jSCWplxHTQ 7jTZaBJMwC4oDa78Qg90tZo6mTgMp73JsZnYLym1cbub+E1i8gfjXupbEYXMn9mzvVRO AcDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jE2aiTqc5HmH4pPL0Elc5lj0SpAo9LUKe4nAEQcUQgQ=; b=tZdfUcjstRB6Op/3R+g4xeDjyP/IRdu3/Z5aCpH2v/eRX9pRLR7/xaPzcKV/6y7BVv Ffvmj859gUA8OqoZ5vLtufVxnj9Q9GCSeq2TUFJ48uWA9MgCusbabaRtYws3wZe4sKWv pGetJloPbuFZ07EWFdsAhPDHJ2soHlmubqoDdV+n2YeDG67B9NTOVJ6TNKX+WQyGGlQy q1X8CuSf2Cv6vdrEEhVvjcUu0U6C/oFZRFT+RUQYvubWO+6RJjT9BWAKfj1POl7e+Zy4 CnJ80c0w4/QX3YoZp+Pi0oxpGqHh1S1PmU6WkOvh1azoVMBya80bmQZK6Wr/X9LiYpw4 B2CQ==
X-Gm-Message-State: ALQs6tAmKCVwJPwD7FjFC1dUaYWbC8bT1crg292ZCfIbzN6Hwxn9LKnc Xll7bEXQ1sFjg78q7mw1EhE7WfuC91zkSOlAcaY6dQ==
X-Google-Smtp-Source: AB8JxZrV0bpwLV4mONU1xiN6wGYLto8Mj/bqHvNfWawpHP0EqOhXevi9t9xS4g5hSNua6K/1AT4zol4G1QZeN7qh0gE=
X-Received: by 2002:a25:b18b:: with SMTP id h11-v6mr5419889ybj.376.1525029947479;  Sun, 29 Apr 2018 12:25:47 -0700 (PDT)
MIME-Version: 1.0
References: <5c08873a-6ea3-474c-bc9c-6623b67349dc@uclouvain.be>
In-Reply-To: <5c08873a-6ea3-474c-bc9c-6623b67349dc@uclouvain.be>
From: Ian Swett 
Date: Sun, 29 Apr 2018 19:25:36 +0000
Message-ID: 
Subject: Re: Collecting measurements with Multipath QUIC
To: Quentin De Coninck ,  Olivier Bonaventure 
Cc: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000004b402c056b01b41a"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 29 Apr 2018 19:25:51 -0000

--0000000000004b402c056b01b41a
Content-Type: text/plain; charset="UTF-8"

Thanks for the updated doc.  I think it embodies the goals of the QUIC WG
much better than the past version.

Some comments below:

In 3.3 "The negotiated value will determine how many bytes will be used to
encode the Path ID in frames."


I think it's easier, and more in keeping with the overall QUIC design to
use a varint for Path ID?

In 3.5, there is discussion of NEW_CONNECTION_ID in a way that makes me
think this document needs an update now that QUIC has adopted asymmetric
connection IDs?

In 3.6 "The presence of the Path ID in the public header ensures that the
packets sent over a given path will contain monotonically increasing packet
numbers."

There is no explicit Path ID in this draft, so I suspect this should be
reworded to talk about the implicit path ID associated with the connection
ID?

In 3.7, I feel like it's cleaner to supply alternate addresses once in
transport params, which Mike Bishop's PR#1251
 does, though with a
slightly different use case in mind.  As a corollary, I'm not convinced the
REMOVE_ADDRESS frame is really necessary.  If it is, I think I'd rather
combine Mike's PR with an UPDATE_TRANPORT_PARAMS frame, which I have a few
other use cases for already.

In 3.10, I'd prefer to say each path needs to have it's own congestion
controller, rather than just specifying it's own congestion window, since
there are other aspects of congestion control besides a CWND.  And I'm
confused why they MUST be coupled together?  Given the flow control is not
path specific, I'm unclear on the benefits of coupling the congestion
controllers?  Possibly you can send me some background reading to clarify
that?  I read some indication this was for fairness in the RFC, but that
seems questionable, given it's possible no portion of the path is shared
until you get to the host, in which case it's the host's responsibility to
ensure a peer isn't given an unfair share of bandwidth.

5.2  As I mentioned in reference to 3.3, I'd just use a QUIC varint, which
simplifies this quite a bit, and makes the typical cases of a small number
of paths very efficient.

6.1 Given the NEW_CONNECTION_ID frame already has a sequence, it seems
simpler to use that than add another PATH ID.

7.1 MAX_PATHS could also be replaced by an UPDATE_TRANPORT_PARAMS frame.

7.5 It's clear the PATHS frame could be useful to close a path, but I'm not
sure what other uses it has?  If it has no other uses, I'd prefer a
PATH_CLOSE frame.  If it has other uses, can you clarify it's purpose?







On Thu, Mar 22, 2018 at 8:05 AM Quentin De Coninck <
quentin.deconinck@uclouvain.be> wrote:

> Hello,
>
> During today's discussions, we heard several times questions on
> Multipath QUIC and even more mentions on the benefits of having
> measurement data before taking decisions. Multipath QUIC will be
> discussed later this year within the IETF, but in the mean time we have
> already proposed a first design (recently updated, see
> https://datatracker.ietf.org/doc/draft-deconinck-quic-multipath/) and
> even more written an implementation of Multipath QUIC which allows to
> collect data in a variety of networks. Experience with Multipath TCP
> shows that the performance of a multipath transport depends on a variety
> of algorithms such as path management and packet scheduling that
> interact together.
>
> During the MPTCP working group this afternoon, I will briefly present an
> iOS application that includes our Multipath QUIC implementation. It
> allows collecting different types of measurements. As it runs on iOS, we
> can also compare Multipath QUIC and Multipath TCP together. If you have
> an iPhone, I encourage you to install the MultipathTester application
> below and run it in different networks and notably outside the ietf WiFi.
>
> https://itunes.apple.com/us/app/multipathtester/id1351286809
>
> We have already confirmed experimentally the importance of validating
> addresses in QUIC through a firewall that blocks UDP port 443 in one
> direction (see
> https://multipath-quic.org/2018/03/15/firewall-address-validation.html).
> We'll probably find other strange results thanks to your measurements,
> we will update our findings on https://www.multipath-quic.org
>
> Best regards,
>
> Quentin De Coninck
>
>

--0000000000004b402c056b01b41a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for the updated doc.=C2=A0 I think it embodies the =
goals of the QUIC WG much better than the past version.

<=
div>Some comments below:

In 3.3 "T=
he negotiated value will determine how many bytes=C2=A0will be used to encode the Path I=
D in frames."

I think it's easier, and more in keeping with the overall QU=
IC design to use a varint for Path ID?

In 3.5,=
 there is discussion of NEW_CONNECTION_ID in a way that makes me think this=
 document needs an update now that QUIC has adopted asymmetric connection I=
Ds?

In 3.6 "The presence of the Path ID in th=
e public header ensures that the packets sent over a given path will contai=
n monotonically increasing packet numbers."

T=
here is no explicit Path ID in this draft, so I suspect this should be rewo=
rded to talk about the implicit path ID associated with the connection ID?<=
/div>

In 3.7, I feel like it's cleaner to supply alt=
ernate addresses once in transport params, which Mike Bishop's PR#1251 does, thou=
gh with a slightly different use case in mind.=C2=A0 As a corollary, I'=
m not convinced the REMOVE_ADDRESS frame is really necessary.=C2=A0 If it i=
s, I think I'd rather combine Mike's PR with an UPDATE_TRANPORT_PAR=
AMS frame, which I have a few other use cases for already.

In 3.10, I'd prefer to say each path needs to have it's ow=
n congestion controller, rather than just specifying it's own congestio=
n window, since there are other aspects of congestion control besides a CWN=
D.=C2=A0 And I'm confused why they MUST be coupled together?=C2=A0 Give=
n the flow control is not path specific, I'm unclear on the benefits of=
 coupling the congestion controllers?=C2=A0 Possibly you can send me some b=
ackground reading to clarify that?=C2=A0 I read some indication this was fo=
r fairness in the RFC, but that seems questionable, given it's possible=
 no portion of the path is shared until you get to the host, in which case =
it's the host's responsibility to ensure a peer isn't given an =
unfair share of bandwidth.

5.2=C2=A0 As I mentione=
d in reference to 3.3, I'd just use a QUIC varint, which simplifies thi=
s quite a bit, and makes the typical cases of a small number of paths very =
efficient.

6.1 Given the NEW_CONNECTION_ID frame a=
lready has a sequence, it seems simpler to use that than add another PATH I=
D.

7.1 MAX_PATHS could also be replaced by an UPDA=
TE_TRANPORT_PARAMS frame.

7.5 It's clear the P=
ATHS frame could be useful to close a path, but I'm not sure what other=
 uses it has?=C2=A0 If it has no other uses, I'd prefer a PATH_CLOSE fr=
ame.=C2=A0 If it has other uses, can you clarify it's purpose?







On Thu, M=
ar 22, 2018 at 8:05 AM Quentin De Coninck <quentin.deconinck@uclouvain.be&g=
t; wrote:
Hello,



During today's discussions, we heard several times questions on 

Multipath QUIC and even more mentions on the benefits of having 

measurement data before taking decisions. Multipath QUIC will be 

discussed later this year within the IETF, but in the mean time we have 
already proposed a first design (recently updated, see 

https://datatracker.ietf.org/doc/dra=
ft-deconinck-quic-multipath/) and 

even more written an implementation of Multipath QUIC which allows to 

collect data in a variety of networks. Experience with Multipath TCP 

shows that the performance of a multipath transport depends on a variety 
of algorithms such as path management and packet scheduling that 

interact together.



During the MPTCP working group this afternoon, I will briefly present an 
iOS application that includes our Multipath QUIC implementation. It 

allows collecting different types of measurements. As it runs on iOS, we 
can also compare Multipath QUIC and Multipath TCP together. If you have 
an iPhone, I encourage you to install the MultipathTester application 

below and run it in different networks and notably outside the ietf WiFi.


https://itunes.apple.com/us/app/multipat=
htester/id1351286809



We have already confirmed experimentally the importance of validating 

addresses in QUIC through a firewall that blocks UDP port 443 in one 

direction (see 

https://multipath-quic.org/201=
8/03/15/firewall-address-validation.html). 

We'll probably find other strange results thanks to your measurements, =


we will update our findings on https://www.multipath-quic.org



Best regards,



Quentin De Coninck






--0000000000004b402c056b01b41a--


From nobody Sun Apr 29 20:46:36 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36CB12D86F for ; Sun, 29 Apr 2018 20:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5L3ZqRJSOc3Q for ; Sun, 29 Apr 2018 20:46:32 -0700 (PDT)
Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B9B129C6D for ; Sun, 29 Apr 2018 20:46:32 -0700 (PDT)
Received: by mail-ot0-x234.google.com with SMTP id w4-v6so8116055ote.12 for ; Sun, 29 Apr 2018 20:46:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tbZaES9RtVJ9fJT0m/QwvpeJ/4zLaW97tGtIqpJS6EA=; b=jlD5L8dPUilFFdo3J2QNM9RpZJYym7/jZYgQJ/Q1OnMEuRNUpKLcuGRL9Yh2W/bQMM ukSC1rR2mrgzeFLVhWw+S/fVQ8cZNoIsWcGQ22oG/uAWDWofGKR2zk4COPr2xqCmrPli twnIJp/ujdNsQWKdJduxoXsKKeAwDDaiax3CRERNiK90dYhnrgOh9RNRfXbT+DmsEjwp C2H20pOQD3LpKkGMY9I0xqL8EYDRMWnnoAeBhV/s6Ts8Xt+1nkPqaGYxANkBQm/kct9X 6zP+NIdPvEBwnqAvfNg+ADWfFBRZQen4Xs2cnv//aKRsErW9+q4CUz8yUYtohNS8j3kf hzMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=tbZaES9RtVJ9fJT0m/QwvpeJ/4zLaW97tGtIqpJS6EA=; b=nZQW7V5FWr4ygWjQk4K38qWVJwVQ1JTXo3DSS9CXNeXz5A6K1FVLBEJ/puSIBPZWWJ FOip3a6lJesNGj4xN7OqkT5mLWEQCjALCgOr8zhGJLM0zH2rhfAWp0ClhoOs6+ko2V75 kVEX8d7i1CcVrtDZfEWgNpVlnJKO6GfWAOTMnlv2c4yCTvTR9SDbQ0NiGrlpR2/udMlm V+/cMj4u3v9Cvac3QHgygOeQarVz+qQcIUXpLFWBHLHpByMSOpUCQkrPVXoH2KFeeJCa lsihrNDuDAi6gYyS96cckrMcRoiF0EhW1tfCXzXcd1oMgopA4k92NWGlOD7p4fX60ar7 DY1g==
X-Gm-Message-State: ALQs6tBWyve3LF2w0IseTFSt7J8A4BTMSc5j5m3SAB6F9wLpfJTxVBOa 8ApwKTZ5Kvp94mIgQluPxQD91Xgd7R+6XQhB1sg=
X-Google-Smtp-Source: AB8JxZqjINax3bz7cIJVchZIHuUFUO/fWd7pb4sOfepA3EibhZhm6grUw9rfO6jSbflUhawr3mQODkv48ZurLkpO7FU=
X-Received: by 2002:a9d:524d:: with SMTP id q13-v6mr7661327otg.241.1525059991329;  Sun, 29 Apr 2018 20:46:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:29ce:0:0:0:0:0 with HTTP; Sun, 29 Apr 2018 20:46:30 -0700 (PDT)
In-Reply-To: <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>     <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net>
From: Martin Thomson 
Date: Mon, 30 Apr 2018 13:46:30 +1000
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Mark Nottingham 
Cc: IETF QUIC WG , Lars Eggert 
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, 30 Apr 2018 03:46:35 -0000

OK, going back to the OP to close the loop on a few things.

I have updated PR #1079 to rebase it on top of the addition of a
packet length field.  As far as I'm concerned, this is now ready.  We
might later consider a few things, like varint packet numbers and
removal of the sequence number from NEW_CONNECTION_ID, but those are
separate refinements.

I'm glad to see that there is a plausible implementation of this in
hardware that isn't inordinately expensive.  I appreciate that this
complicates offload in some cases, but I still believe this to be the
best design we have right now in terms of all the competing factors
we've considered (and we've probably covered every angle now; more
than once).

My assessment is that we should merge this.  Chairs, is this your assessmen=
t?

On Wed, Apr 4, 2018 at 2:58 PM, Mark Nottingham  wrote:
> Hi everyone,
>
> The editors have told your chairs that this issue is starting to block pr=
ogress on other aspects of QUIC. Coming to consensus on it soon (i.e., befo=
re Stockholm, if possible) would be good.
>
> It looks like this thread has come to a natural pause. Reading through it=
, I think we agree there are some unpleasant tradeoffs here, but so far we =
have only one concrete proposal -- PR#1079.
>
> My AU$.05 - While we're chartered to produce a protocol that's encrypted =
as much as operational concerns allow, and that privacy is a natural extens=
ion of that (especially in light of RFC7258 and RFC6973), there is no *requ=
irement* that we produce a protocol that is able to be accelerated by hardw=
are.
>
> That being the case, I think we need to ask ourselves if we believe that =
inclusion of PR#1079 will significantly inhibit deployment of the protocol.=
 Based on the discussion so far, that doesn't seem to be the case, but I'd =
be interested to hear what others think.
>
> If we can get to consensus to incorporate the PR, and folks come back lat=
er with a more hardware-friendly replacement that doesn't change the Invari=
ants or increase linkability, I suspect the WG will be amenable to that.
>
> What do folks think?
>
> Cheers,
>
>
>> On 29 Mar 2018, at 11:39 am, Ian Swett  wrote:
>>
>> Thanks for the nice summary Jana.
>>
>> As much as I'd love to have easier crypto HW acceleration, I've ended up=
 arriving at the same conclusion.  I don't want to bite off the work to do =
proper multipath in QUIC v1, which I think is the only other reasonable opt=
ion of those Christian outlined.
>>
>> If someone comes up with a way to transform packet number to make it non=
-linkable, but doesn't have the downside of making hardware offload difficu=
lt, then I'm open to it.  But we've been talking about this for 2 months wi=
thout any notable improvements over Martin's PR.
>>
>> Given we never talk about any issue only once in QUIC, I'm sure this wil=
l come up again, but for the time being I think #1079 is the best option we=
 have.
>>
>>
>>
>> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar  wrote:
>> A few quick thoughts as I catch up on this thread.
>>
>> I spent some time last week working through a design using multiple PN s=
paces, and it is quite doable. I suspect we'll head towards multiple PN spa=
ces as we consider multipath in the future. That said, there is complexity =
(as Christian notes). This complexity may be warranted when doing multipath=
 in v2 or later, but I'm not convinced that this is necessary as a design p=
rimitive for QUICv1.
>>
>> We may want to creatively use the PN bits in v2, say to encode a path ID=
 and a PN, for multipath. We want to retain flexibility in these bits going=
 into v2. We've used encryption to ensure that we don't lose flexibility el=
sewhere in the header, and it follows that we should use PNE to retain flex=
ibility in these bits as well. (Simplicity of design is the other value in =
using PNE, since handling migration linkability is non-trivial without it.)
>>
>> This leaves the question of HW acceleration being at loggerheads with th=
e design in PR #1079. First, I expect that the primary benefit of accelerat=
ion will be in DC environments. Yes, there are some gains to be had in serv=
ing the public Internet as well, but I'm unconvinced that this is the drivi=
ng use case for hardware acceleration. I understand that others may disagre=
e with me here.
>>
>> AFAIK, QUIC has not been used in DC environments yet. I expect there are=
 other things in the protocol that we'd want to change as we gain experienc=
e deploying QUIC in DCs. Spinning up a new version to try QUIC within DCs i=
s not only appropriate, I would recommend it. This allows for rapid iterati=
ons internally, and the experience can drive subsequent changes to QUIC. It=
's what *I* would do if I was to deploy QUIC inside a DC.
>>
>> So, in short, I think we should go ahead with PR# 1079. This ensures tha=
t future versions are guaranteed the flexibility to change the PN bits for =
better support of HW acceleration or multipath or what-have-you.
>>
>> - jana
>>
>> On Mar 26, 2018 9:41 AM, "Christian Huitema"  wrote=
:
>>
>> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote:
>>> Looking at https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_=
AMD_x86_architecture it seems to imply a large range of server, desktop and=
 mobile chips all have a CPU instruction set available to do AES accelerati=
on and other similar operations (other instruction sets are also available)=
.
>>>
>>> If we are considering the AES instructions then it looks like it is (or=
 at least will be in the near future) a sizeable proportion of the public i=
nternet have it to be used.
>>>
>>
>> Certainly, but that's not the current debate. PR #1079 is fully compatib=
le with use of the AES instructions. The issue of the debate is that the me=
chanism in PR #1079 required double buffering, first encrypt the payload, t=
hen use the result of the encryption to encrypt the PN. This is not an issu=
e in a software implementation that can readily access all bytes of the pac=
ket from memory, but it may be an issue in some hardware implementations th=
at are designed to do just one pass over the data.
>>
>>
>> -- Christian Huitema
>>
>>
>>
>
> --
> Mark Nottingham   https://www.mnot.net/
>


From nobody Sun Apr 29 23:58:28 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBB912D879 for ; Sun, 29 Apr 2018 23:58:26 -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 (1024-bit key) header.d=mellanox.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_1PLbgKOtg6 for ; Sun, 29 Apr 2018 23:58:24 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on0620.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::620]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094A6124319 for ; Sun, 29 Apr 2018 23:58:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kqHQZsh2OgtAf/66LJ14X4wgCXOkcPsInYNSfGAV3D4=; b=Uzr5F2ClZpaJ7tVhgiIDwli1nUoJ50c+WmpUGh55c9p2CphMlMwxLc8DtihZt+btwuhuwnO/NlgAhlww6kM5Zn9cWTpUogyPuWRRInDwnxaVGnSAP19A1RaaarF/xVqgsi910EPP/ge966yXtVewz2BwySlCIOb0tBTXIWVqv20=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=borisp@mellanox.com; 
Received: from [10.8.2.53] (193.47.165.251) by VI1PR05MB4349.eurprd05.prod.outlook.com (2603:10a6:803:41::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.715.20; Mon, 30 Apr 2018 06:58:19 +0000
Subject: Re: Getting to consensus on packet number encryption
To: Martin Thomson , Mark Nottingham 
Cc: Lars Eggert , IETF QUIC WG , Miriam Menes 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>   <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com>        <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> 
From: Boris Pismenny 
Message-ID: <94756b94-db49-80c2-3486-6a1a827391ad@mellanox.com>
Date: Mon, 30 Apr 2018 09:58:14 +0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.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
X-Originating-IP: [193.47.165.251]
X-ClientProxiedBy: PR0P264CA0033.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1::21) To VI1PR05MB4349.eurprd05.prod.outlook.com (2603:10a6:803:41::25)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(2017052603328)(7153060)(7193020); SRVR:VI1PR05MB4349; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB4349; 3:QsN5ZqKlgqoR4joS6O8jvSqJtP4UaKKChrxCyx4jn04dNrJ+YLwVkIkVMskUdHH0KAVzrkXWM7ip1fKCyxnJyiKy2UBXAaLrUJNKbB/CRunpFoEXxsKsTQTWo9ttzvCMQKIdZ8iy2FIQfcPFtxYFBfabN/7liErngwdUrXpCiYpyp4+0I07AKjk/IkNPw4mri173d+s/43vJionTGmzm2waYqQ0tuWT0GweyAgqvetVtu9xAFyhlpbwHyhys/aMh; 25:ULPiCuKpGwd0qWuycmGd0Dlk3c6Z3+4ohkV3hF6Lwjtott7PpGHEhB3X68oVQqFHM06x9T58m0tFsNS3TLGyP0J3z5st5gnuJ6DbukDFYZyGhJ18wMFzc2J/Wm5ixlArIy3nY/8E1kbnLDoDyXGLNZ3ZcdeFiX72Qd5fAbRK5serkKHKD4Y2TjP0rm3XIc/YQHhYMv4SttEZ3Sy8Lei130P091hNDUeBoYoHPZJPfvYr8P0G428O9MGpsv0YbtDGsz57M5uVr32Qo4zPbGRAOFeSH7DIB3/tJKg6MuBUw+qcNUDOJkdJ3CAs2DlrlGxQ08JTT3dta6I6WGj6pzlJqg==; 31:huCBBKcyiSItmtSKLWGz/20bRBZuiZoDt5yrtsVAEySND4YmOQLfbDY1n+09dBXT0rglS5CqGBA7YJ0Pv0aip5z/37Kv+gQ958YoMXwGA2PawB0DuFvrSCVBO5JtnZp5ra51eUl/s6oY6/o1B9lCACRidUhJ1+Cv/BKF8YcDp4wvZHL0vaEW9Xet08wC79OS1wpewMrevCwpzNlPjxolrL88+BrcUNva+TIJ3qaLpvQ=
X-MS-TrafficTypeDiagnostic: VI1PR05MB4349:
X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB4349; 20:n7fAkJ8SDHukFf2RsWBBoRa04K8KMCOL+I+knQqh5pcoEYB0Pzo+PeSzQIH9/waOCL5WglV2V6uiQO7fBG8BxxlTSCaRNjcJhGNsrOE3irO5JEA7DMHCtlLQbOWSSlGg1Ct8m4Y0LBfu7n5OASPw1pTaqAI3XXj15TnWjSC1n/t+JNrQsNvw6L6Vt4K3WzSNVY2h5g7I4QOLPScrAxZ3zJayWUj0PVyHC6Bkkjuf4SMcD1g9A142mTKHyAfnSDQHOcy3fU/0yRZSganU6yfza8kO8MtkQm4GRV49MHueBPL2MN7gdhLIwFeWedPaDfpizJpD0CVprHIMypxNYeGmhuq74nl/NDADpG3k6kcQ1cgvpdnr9Qnw+jANO51sprE5Uqng7UBWU91Uvjr1YGWE7DW/089WEJkJzpM81+6YpcOFYZj3VBxwB1f604bHdn3RUl3hrLsSZHt3B9CSCx7SnUCMcGibfohnxS5xp0DiaKJLawXDuYgKKrYz60YBsXJB
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(189930954265078)(85827821059158)(100405760836317)(45079756050767)(17755550239193);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(6055026)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR05MB4349; BCL:0; PCL:0; RULEID:; SRVR:VI1PR05MB4349; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB4349; 4:luXp5XJrNEXxgaBAtqTfZQDqzffJZqfUl/hBmaVfLD+fFP360MzsNuPzge/7yNfcyeuZOmmvpUnv58PB/6zaq05ZUqggCIU/rvTEU3jTzQvranQU4d+uSrMnE9PsySezPrDzbexhe52ETUTq0srNgpnd9k91DF2lkgJYFON9HOcR0b9inqoGJQ1t2maG7+K/IAM16u0cEbvbIybCmmgDIqOz3fDmGPyWMm23abVMPMjkLwTiqn48ITcck/MTG4+DttQkMRuZq/vhw5L5ONifvL2gjnyuY2UQBS54/vzPGy29Yw7Mw4GAI5LuBB7Z7U7P8NbEVhXT8YOQRfxNQDINes1CdJSUedss+Rb/4R7ZqNN7YUsA4seUDmQY+Zm0hvJiZ4kx4lryuWM+wgwVHxbd4Wy8NWvg6EWUePwTx+cie/HOpxKrIthSDntCckytMtdz59QxoJa0JoKBUCgj9qdvegWxNvej7uIAbzc56/uamVM=
X-Forefront-PRVS: 0658BAF71F
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(366004)(39380400002)(396003)(346002)(376002)(39860400002)(51914003)(53754006)(199004)(189003)(3846002)(6116002)(36756003)(3260700006)(6306002)(31686004)(6666003)(8676002)(81156014)(5660300001)(8936002)(476003)(4326008)(105586002)(478600001)(2616005)(486006)(81166006)(50466002)(86362001)(316002)(65826007)(31696002)(956004)(966005)(45080400002)(6486002)(67846002)(446003)(25786009)(11346002)(65806001)(229853002)(305945005)(47776003)(561944003)(6246003)(110136005)(66066001)(386003)(230700001)(59450400001)(65956001)(107886003)(93886005)(16576012)(23676004)(52146003)(16526019)(2486003)(58126008)(2906002)(106356001)(53546011)(64126003)(76176011)(54906003)(7736002)(39060400002)(52116002)(26005)(97736004)(68736007)(77096007)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB4349; H:[10.8.2.53]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
Received-SPF: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA1TUI0MzQ5OzIzOjBLZ2JaaEJsN29paStBTWdtSmVkQjZ2WW9h?= =?utf-8?B?c2RYeGc1Zk1HQzRNU01hUzVpYUREZU41WWgzdm93cC9ab01KcngvVEdOTVQ4?= =?utf-8?B?cjNla3ZXYmRuMkJLRTlQWnJSZGxXeFVtbHFxSm43Qy9DNHZYSXFxWU15Z3J3?= =?utf-8?B?ZGV5ZVdwaTBGQjkvb3NCTGRRRFpnWXd2bmkyN29vZ1lPL08yWkVUOWQvK0ZR?= =?utf-8?B?UVMxaTEzK0Uwdk1CelpSTVFDeWFNckcxSEdzbVMyUWRyUWlmOFFwMjZCdk1K?= =?utf-8?B?TzVwRm1ubFdBdjFEb1prUjRqV0NPTVQ2MU1oLzk3S2NwVjgxNmRLOEN1bTB0?= =?utf-8?B?QXN2NDdtV2VnbDJTckI4ZHUvam84aDBlY2pRWk5qd1hxU2U4UjVxbnlaT3NK?= =?utf-8?B?S0E0YmdxTGxjVjJoTk5kdk1DZzNpeUpDS2o4SWtnTlMrT2RVNjhCMysyY2dn?= =?utf-8?B?Z2hPTVhVWHZwZ3BtMFBsNFViUVdqbCtqRnI5YzlrMWcveWpnU2FqV3I5eGdL?= =?utf-8?B?R01GemlPbmNLdGZ0ZDRGdkFNaHpPOWhiNlJyaTk4Rk1vK3I2dEpBbG9UTXZk?= =?utf-8?B?TUVvN0RFMEtLNHl1S3ZYUDdCWGhaT3JWcGlKRWpkcjV0SmZZMEpQNW8vRitM?= =?utf-8?B?STI0MDBORkFRV0dFUWs4Z0t6bWRvUG1rUnJ0WHRzblVneEpDR0RSZEx4Nldy?= =?utf-8?B?QXY3ZzUyblFtTk1tdGlIY1A4MXRJSjI1andXbG5tRmtrMzBKMUs5cnRkcGZs?= =?utf-8?B?Q0ZtRTNGaDRKV2RremZvUnF4bXdSNjJmSkpMVy9YeXcyT1pVM0dlK3BCVDJ1?= =?utf-8?B?b2FKWkFGbFltTjlEdHlPcFlnRVZCYWhkUEVlLzVXQTZvQjV0RHpxMEtDcmxR?= =?utf-8?B?ak1XaXdKL2ZabnpHOUlCaWR3OG9NNEZVRmhSVExNblUwNWd1cENkZy9CMkdR?= =?utf-8?B?emRPSlBhNzlUbEdWQlZabFYza2RFOFgxWEM1S3ZVL3dRNElnYXFOdFFvbHpY?= =?utf-8?B?aHRJZE9XZzlWa2t5RFAvbjgrTXNRYUxwMzU5T094QkNCSTZFWWp0Z1AxNUNB?= =?utf-8?B?eDJDZkJ1VjYxb3RocmVQU3RhaWdyOXM1NFF6cmo2R1JJWHR3SUtwaFVSWHlX?= =?utf-8?B?eXdXbFkzRmE2cC9hT0NtSHZROWZVYVNVVXpjMGxMLzNTUDNMeG1MdnlmSHd2?= =?utf-8?B?ZXY2VWJoMWZOODFYOFlHd0tKNXpIZDBQNkM1K0kwMndYWUdEd1FlbnF3NU9J?= =?utf-8?B?QTd3UjhheGdhMC9EdmMwZ3A0cXRuc0ZQR1dvMWFOT3JsVTBIVlVKWkZweC9i?= =?utf-8?B?UVhSOW5sVDVFSjV1dU44eHZpL1FEdUp5QWc5c3BiRThzejdUeUg0MEVVZmhm?= =?utf-8?B?Z1Fxcm5Ga1ZiQWExOXEyVE5KR2txaDZIeTNUMS9MN3Rwc2YxOEJieUorV01X?= =?utf-8?B?TEFnN242TjRUVy9FZ3V5bDVuNS8zQU5vWmJiVkRBalhzbTB1K3dXL0FVRjRa?= =?utf-8?B?OXVsRGlKUFFEVFFlWERHbDJoV1pENmF0Z2lyUk1FOWQ2aXlBV3UzM292VDZL?= =?utf-8?B?TDJ2WnBRcVhRdm8zdUJCQWFrSVhSaTgwcXlaL2MxK0V0Ym05MGZjYUs2RlZT?= =?utf-8?B?cCs1VDE0YXhmb2FScHNxQWJDclIvQ0dYZk1wWkd4WWthMVJibmdsc3VvYkdv?= =?utf-8?B?SHRRZ3BCK0NDUFQ5Mzkzc3g3VVpyZUpXVnhjQzF3ZE9wT1lSazRsdG8vQ00w?= =?utf-8?B?dUxtVTRjQUwzREJaMzBiUUNoazNjLzdQTHNaYnhYdjNDdUZKVzJuSHlVYktm?= =?utf-8?B?eVBSeFN3cTAyTVJwR2tlNmZEWVBGSmt3LzN4M2o2MUVBTzRBLy8zQVljQzZD?= =?utf-8?B?RUpEUGJZUHF5L3hLNi9oNHJEQXNjOUo4ajdhUnNvckxEUFZjQUMrZU1nckxI?= =?utf-8?B?WjlpU21Mb0lnSUhqWWw2dTArN1JuT0kxN2NIWlBpaEw2Y3UvMks1RmgzdERU?= =?utf-8?B?eFQ1TVZYT2pBQlhtbytKOGhSUjRrT0JEK2VXcnFacFZZQlhzZHNzRmpDczVJ?= =?utf-8?B?bVFxdHZzc21YbExrbXBBTGhaUkFzTEFZQjlmbm9SRGlTV0d2YTQ3TG1IS2Nx?= =?utf-8?B?V2QzQjhFMkg1a0dOM0pacWpVZHljbGlzcXBzU3E5RFRGOEg3eGFqYWRpSHRT?= =?utf-8?B?OW1hS2JpaGpBaTRrR3JBcHRGUHFLS21LZE5iaDJOc1pmdUcxY0czTzVqcC9p?= =?utf-8?B?RDltSTlXMWg2S1RiZ3U2cnpLa3RqMFVRK0E0a1Zob0VEbXRuSng4L3Y5a0dL?= =?utf-8?Q?+4ifUH6SdL7sQq7Q=3D?=
X-Microsoft-Antispam-Message-Info: joM4EHNaKGYhCC/4/2Th9ySCcEKxmN4I3smm/ZDDmI5zqXh1Aj8y2UPD/XcoJXBGSd65Jxk/LdmlUl8/bjwiGJVPZd2N0MzAO6GaY+IbNXWop9dnZiFf45BYS7l1hmHDdAbusfU1Ca0bYhXS+oPKwl/q0wRcM3ITVhkr4QwBIFGYoyM17CyAUPGndyYh+AFz
X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB4349; 6:WoAHlm8/Z+MdykZmK+GmIi/UFBRUR7kk9SrO+QukRXWpw6Fvw/78o/Yp8rilnvZWR6XzeAsBPPReogyCB5YLk8a/xNYg+W0Ga5t183iOOzaooLh2vHiP/Jun5Wj/AQuselqFiBegE1U/xtYOhD3SHK3vZX5tikVor/0zsrvnUSF7iPjivYT1KmCKW0omEuHCBOPLFnZPs06SIaVb3AolCrSsJeFFBngXDNHjpZqCbfYnCszFWAXGWKvyq0CEkzyghO348Z+Ijpx6Ix+KRFONss1ghX2HsD1McHsIgIP7vO0x3g67W0jxY5Bl5roeDOGSxeGQngWDZnMkFvh1pGyIkD7rFu00eUB+E9YArVYjgJCtGHN6J82jP0wKqmyq7grS7YzpcjLuoUMwIaJRpeT2euRs2haNOgO9GYpOv2qwjBrMLeEZuNUANisHGks1b00qfS0QAoUSDwiFeemnVGBh5g==; 5:e8ltbgo5FRDDzdapHInVl9vsx7hu0vlbGslqVQ3ErRrtoBqyzasyMOJ3BdV2nItdbr0bdcdeuhCgtUA8B546H3QCg9KNwaM+j4qLQ+xEEMxrZE0TFaPDU9nrJtTvlJaSGiuX9zgWBMn6ismR+H5XV2GX+bVZfcAFt0V4t15LY8w=; 24:Dqb8zxu6hR3OvtPnaXU0SIjDYQdgv5oTQCox+AoyOi658NHKDIf8WHCOSJmXkO4O8XTgJfcULHEPTRlfDlaqqosQvD2b4oBD7/r3bLSFCko=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB4349; 7:iw4rB4HPIh6TvlXz1G8BfbtE1I4AJSvlqWNtZ3a7eWAjI9z/ahtweNwBoAgMspngaY/fv2GDZOSajrLQZ+6yKxYu3VY/WOCoketUqqV3+k3OtDTokllie89Q1NQh6+iDKsquY1CgYvrzuWRuN7UxgsPRz/jgCkuhKXLqokcxT0z1EX5EuWPQ0zdVMQOBC1/TyEFbys7VuqxyKpdVbqKW6MdSaCtopwfq4CDLjaDyVN+x0859FI3f6GHgqfaRtHWk
X-MS-Office365-Filtering-Correlation-Id: 1ac49364-1df7-4a62-ca96-08d5ae67c212
X-OriginatorOrg: Mellanox.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Apr 2018 06:58:19.7419 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ac49364-1df7-4a62-ca96-08d5ae67c212
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB4349
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 30 Apr 2018 06:58:27 -0000

Hi all,

I'm responsible for the architecture of crypto offload in Mellanox NICs. 
Here are my 2 cents on PNE.

It is possible to implement any PNE scheme in HW, but it is a question 
of cost and ROI.
The current PNE proposal requires an additional AES stage in the NIC 
pipeline - silicon real estate or complex scheduling of a single AES 
engine and two passes over the data. No other network crypto standard 
I've encountered has such a feature. Thus, ROI is likely to be low.

Best,
Boris.

On 4/30/2018 6:46 AM, Martin Thomson wrote:
> OK, going back to the OP to close the loop on a few things.
> 
> I have updated PR #1079 to rebase it on top of the addition of a
> packet length field.  As far as I'm concerned, this is now ready.  We
> might later consider a few things, like varint packet numbers and
> removal of the sequence number from NEW_CONNECTION_ID, but those are
> separate refinements.
> 
> I'm glad to see that there is a plausible implementation of this in
> hardware that isn't inordinately expensive.  I appreciate that this
> complicates offload in some cases, but I still believe this to be the
> best design we have right now in terms of all the competing factors
> we've considered (and we've probably covered every angle now; more
> than once).
> 
> My assessment is that we should merge this.  Chairs, is this your assessment?
> 
> On Wed, Apr 4, 2018 at 2:58 PM, Mark Nottingham  wrote:
>> Hi everyone,
>>
>> The editors have told your chairs that this issue is starting to block progress on other aspects of QUIC. Coming to consensus on it soon (i.e., before Stockholm, if possible) would be good.
>>
>> It looks like this thread has come to a natural pause. Reading through it, I think we agree there are some unpleasant tradeoffs here, but so far we have only one concrete proposal -- PR#1079.
>>
>> My AU$.05 - While we're chartered to produce a protocol that's encrypted as much as operational concerns allow, and that privacy is a natural extension of that (especially in light of RFC7258 and RFC6973), there is no *requirement* that we produce a protocol that is able to be accelerated by hardware.
>>
>> That being the case, I think we need to ask ourselves if we believe that inclusion of PR#1079 will significantly inhibit deployment of the protocol. Based on the discussion so far, that doesn't seem to be the case, but I'd be interested to hear what others think.
>>
>> If we can get to consensus to incorporate the PR, and folks come back later with a more hardware-friendly replacement that doesn't change the Invariants or increase linkability, I suspect the WG will be amenable to that.
>>
>> What do folks think?
>>
>> Cheers,
>>
>>
>>> On 29 Mar 2018, at 11:39 am, Ian Swett  wrote:
>>>
>>> Thanks for the nice summary Jana.
>>>
>>> As much as I'd love to have easier crypto HW acceleration, I've ended up arriving at the same conclusion.  I don't want to bite off the work to do proper multipath in QUIC v1, which I think is the only other reasonable option of those Christian outlined.
>>>
>>> If someone comes up with a way to transform packet number to make it non-linkable, but doesn't have the downside of making hardware offload difficult, then I'm open to it.  But we've been talking about this for 2 months without any notable improvements over Martin's PR.
>>>
>>> Given we never talk about any issue only once in QUIC, I'm sure this will come up again, but for the time being I think #1079 is the best option we have.
>>>
>>>
>>>
>>> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar  wrote:
>>> A few quick thoughts as I catch up on this thread.
>>>
>>> I spent some time last week working through a design using multiple PN spaces, and it is quite doable. I suspect we'll head towards multiple PN spaces as we consider multipath in the future. That said, there is complexity (as Christian notes). This complexity may be warranted when doing multipath in v2 or later, but I'm not convinced that this is necessary as a design primitive for QUICv1.
>>>
>>> We may want to creatively use the PN bits in v2, say to encode a path ID and a PN, for multipath. We want to retain flexibility in these bits going into v2. We've used encryption to ensure that we don't lose flexibility elsewhere in the header, and it follows that we should use PNE to retain flexibility in these bits as well. (Simplicity of design is the other value in using PNE, since handling migration linkability is non-trivial without it.)
>>>
>>> This leaves the question of HW acceleration being at loggerheads with the design in PR #1079. First, I expect that the primary benefit of acceleration will be in DC environments. Yes, there are some gains to be had in serving the public Internet as well, but I'm unconvinced that this is the driving use case for hardware acceleration. I understand that others may disagree with me here.
>>>
>>> AFAIK, QUIC has not been used in DC environments yet. I expect there are other things in the protocol that we'd want to change as we gain experience deploying QUIC in DCs. Spinning up a new version to try QUIC within DCs is not only appropriate, I would recommend it. This allows for rapid iterations internally, and the experience can drive subsequent changes to QUIC. It's what *I* would do if I was to deploy QUIC inside a DC.
>>>
>>> So, in short, I think we should go ahead with PR# 1079. This ensures that future versions are guaranteed the flexibility to change the PN bits for better support of HW acceleration or multipath or what-have-you.
>>>
>>> - jana
>>>
>>> On Mar 26, 2018 9:41 AM, "Christian Huitema"  wrote:
>>>
>>> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote:
>>>> Looking at https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FAES_instruction_set%23Intel_and_AMD_x86_architecture&data=02%7C01%7Cborisp%40mellanox.com%7C426e09d1c4d44186499a08d5ae4cfd51%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C636606568059138841&sdata=xJlYVkw4qoyUyxxdXGjVQ%2B1DBpfcoo2AbkQpj8XZnlg%3D&reserved=0 it seems to imply a large range of server, desktop and mobile chips all have a CPU instruction set available to do AES acceleration and other similar operations (other instruction sets are also available)..
>>>>
>>>> If we are considering the AES instructions then it looks like it is (or at least will be in the near future) a sizeable proportion of the public internet have it to be used.
>>>>
>>>
>>> Certainly, but that's not the current debate. PR #1079 is fully compatible with use of the AES instructions. The issue of the debate is that the mechanism in PR #1079 required double buffering, first encrypt the payload, then use the result of the encryption to encrypt the PN. This is not an issue in a software implementation that can readily access all bytes of the packet from memory, but it may be an issue in some hardware implementations that are designed to do just one pass over the data.
>>>
>>>
>>> -- Christian Huitema
>>>
>>>
>>>
>>
>> --
>> Mark Nottingham   https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7Cborisp%40mellanox.com%7C426e09d1c4d44186499a08d5ae4cfd51%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C636606568059138841&sdata=Gz248vu518Gu2ZxYXDLO8vldtycSv6dok%2FuPrwnQFD4%3D&reserved=0
>>
> 


From nobody Mon Apr 30 13:24:55 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0BF127775 for ; Mon, 30 Apr 2018 13:24:53 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=BXSlgeZh; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ABXOvK0c
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX1S2x79i4A8 for ; Mon, 30 Apr 2018 13:24:50 -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 E2950127735 for ; Mon, 30 Apr 2018 13:24:50 -0700 (PDT)
Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3UKO2D3018774; Mon, 30 Apr 2018 13:24:40 -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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=0y96ojM4AedxQx3SVLeXCkDH2ZCFjuITN+T7WvS8LZ0=; b=BXSlgeZhxLi3/ltPg2N+RZ70AbMSfu9nj7av6EWItYgOn3mJT413tldU7Xt4JU543lAz CxVNbRzToerG2km+Nqk3tgrf9cZcvTBzL5yL2f86j3gaqlrNIZ/yK1xb6xN6Bsv60LcW NLAeU3RWd9P6NNabouVz1u01T2Mxfc14D98= 
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2hp9ty01rm-15 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Apr 2018 13:24:40 -0700
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.31) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 30 Apr 2018 16:23:52 -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=0y96ojM4AedxQx3SVLeXCkDH2ZCFjuITN+T7WvS8LZ0=; b=ABXOvK0cBwlK643CXTlOElTy38Cp+tGiRLmkhxq94tL4n0lp94qozuTjdMRznO9xXRqolp4XSxlUaJgsf/9vsQkjEx753taHGaI/fjlRL7WjyJFOZT8kQZWI+TzVsURvx2E9ygpDkf8Z9HWRPTmSmulF+pJdqmeW93etwkigkXg=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0150.namprd15.prod.outlook.com (10.163.64.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Mon, 30 Apr 2018 20:23:49 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::6c4c:bbf3:ec3b:d45e]) by BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::6c4c:bbf3:ec3b:d45e%14]) with mapi id 15.20.0696.019; Mon, 30 Apr 2018 20:23:49 +0000
From: Roberto Peon 
To: "Lubashev, Igor" , Kazuho Oku , Erik Kline 
CC: Mark Nottingham , Christian Huitema ,  Ian Swett , Mike Bishop , IETF QUIC WG , "Deval, Manasi" 
Subject: Re: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GjyGQaKf4GI0anNhXTngANsKPwZ0sAgAC4ugCAAARcAIAAG5CAgAAFCACAAACJgIAAEVkAgACR+ICAAVFHAIALXUEAgAVKTpWAAJn+AIABxdSAgACOHICAB/EyAIACo7YAgACiL4CAAADQgIAAIs8AgAAm/YCAABExgIAABpIAgAAK6ACAAPIgAIAGDzkA
Date: Mon, 30 Apr 2018 20:23:49 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>         
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-originating-ip: [199.201.64.131]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0150; 7:BSoJ7nn+mGo78Dct0EE4weVufDsSEg9DViUTgo3FP+uPh4sHpb/RDsYkAp80N7nUEq/c5g3X5vichC2v3CLJiSx/6/RTptXGlnvQvCQPa9aYrDTUpQCLWg8NtJoZGw9v0ylzkog4B/4BR64DV5Jk2X8tZygUnZ40ETZHAMUiWdo48MOg0sPRncDW5tL11EDAz99O9e31ilYkDgoH0/pLo+LLe9RIEitbPX2U6ORAcrBmpJFYBIW+E05hijnWv6XI; 20:dcylYLWJ7590FNtut5HSLSAH6u1gZKlKafAOxr+BfYfu48h2ksMBSL1nYjvGVSzDoTKol4XDtn061kU2J6Bl1Fm/4a4yPYQFQggt3+98g5b0gvhA40olbAhxl4MYzOcKMhdeU09PbqTeVV1AGmj+hn2Rl5lfx/HBSWWAblvV37Q=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR15MB0150; 
x-ms-traffictypediagnostic: BY2PR15MB0150:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162)(166708455590820)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(228905959029699);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231254)(11241501184)(944501410)(52105095)(10201501046)(3002001)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BY2PR15MB0150; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0150; 
x-forefront-prvs: 0658BAF71F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(366004)(396003)(346002)(39860400002)(199004)(13464003)(189003)(51914003)(377424004)(51444003)(53546011)(478600001)(105586002)(102836004)(82746002)(6506007)(110136005)(14454004)(8676002)(8936002)(97736004)(106356001)(59450400001)(6306002)(39060400002)(66066001)(6512007)(2900100001)(4326008)(486006)(81166006)(316002)(81156014)(99286004)(25786009)(5660300001)(6246003)(53936002)(76176011)(36756003)(186003)(33656002)(11346002)(3846002)(2906002)(476003)(54906003)(26005)(86362001)(305945005)(58126008)(7736002)(3660700001)(575784001)(6436002)(68736007)(2616005)(229853002)(3280700002)(83716003)(6486002)(446003)(93886005)(6116002)(5250100002)(966005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0150; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: jxw/ZNzRZWkBpCI2MksBzdM8HPz9tj62aNC7q9NqKvFTCU0HR6JkrdmOW+acPs9k9Z2U6edRg0JhlTadD33KjDMqtCEjXVLukIH/WCCDS6Jdz0CghBiPp8LQxfD1Fmi6VnQlirlZHOTQdXImpUtBbnOuhksw6JtqU5C3nGtTr0Moa+y31AE91ZTWrf7jxWtq
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 0ced2bcf-3e22-433c-ab43-08d5aed848a1
X-MS-Exchange-CrossTenant-Network-Message-Id: 0ced2bcf-3e22-433c-ab43-08d5aed848a1
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2018 20:23:49.6110 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0150
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-30_08:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Apr 2018 20:24:53 -0000

VGhpcyBraW5kIG9mICdvYnZpb3VzJyAiYnJlYWthZ2UiIGlzIGxlc3MgZWFzeSB0byBnYW1lIChp
dCBpcyB1bnN1YnRsZSksIGFuZCB0aHVzIHByZWZlcmFibGUuDQotPVINCg0K77u/T24gNC8yNi8x
OCwgOTo1MiBBTSwgIlFVSUMgb24gYmVoYWxmIG9mIEx1YmFzaGV2LCBJZ29yIiA8cXVpYy1ib3Vu
Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbHViYXNoZT00MGFrYW1haS5jb21AZG1hcmMuaWV0
Zi5vcmc+IHdyb3RlOg0KDQogICAgPiBpZiBzb21lIG1pZGRsZWJveGVzIGRlY2lkZSB0byBwYXNz
IFFVSUMgd2l0aG91dCBQTkUgYnV0IGJsb2NrIFFVSUMgd2l0aCBQTkUsIHdlIG1pZ2h0IGJlIGlu
Y2VudGl2aXplZCB0byB1c2UgUVVJQyB3aXRob3V0IFBORS4NCiAgICANCiAgICANCiAgICANCiAg
ICBJZiBhIG1pZGRsZWJveCByZWFsbHkgZGlzbGlrZXMgUE5FLCBpdCBjYW4ganVzdCBibG9jayBR
VUlDIGFsdG9nZXRoZXIsIGZvcmNpbmcgYSBUQ1AgZmFsbGJhY2suICBJcyBUQ1AgYmV0dGVyIHRo
YW4gUVVJQy13aXRob3V0LVBORSBmcm9tIGFueSBQT1YgaW4gdGhhdCBzaXR1YXRpb24/ICAoQW5k
IGlmIHNvLCB0aGlzIHNob3VsZCBiZSB0aGUgcmVjb21tZW5kYXRpb24gdG8gUVVJQyBzdGFja3Mg
d2l0aCBuZWdvdGlhYmxlIFBORSAtLSBmYWxsYmFjayB0byBUQ1AsIGlmIHBhdGggaXMgYmxvY2tp
bmcgUE5FLikNCiAgICANCiAgICANCiAgICANCiAgICAtIElnb3INCiAgICANCiAgICANCiAgICAN
CiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIA0KICAgIEZyb206IEthenVobyBP
a3UgW21haWx0bzprYXp1aG9va3VAZ21haWwuY29tXSANCiAgICANCiAgICBTZW50OiBXZWRuZXNk
YXksIEFwcmlsIDI1LCAyMDE4IDEwOjI1IFBNDQogICAgDQogICAgVG86IEVyaWsgS2xpbmUgPGVr
QGdvb2dsZS5jb20+DQogICAgDQogICAgQ2M6IE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5l
dD47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZT47IElhbiBTd2V0dCA8aWFuc3dl
dHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPjsgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRl
bWFAaHVpdGVtYS5uZXQ+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBEZXZhbCwgTWFu
YXNpIDxtYW5hc2kuZGV2YWxAaW50ZWwuY29tPg0KICAgIA0KICAgIFN1YmplY3Q6IFJlOiBHZXR0
aW5nIHRvIGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCiAgICANCiAgICAN
CiAgICANCiAgICAyMDE4LTA0LTI2IDEwOjQ2IEdNVCswOTowMCBFcmlrIEtsaW5lIDxla0Bnb29n
bGUuY29tPjoNCiAgICANCiAgICA+IENvdWxkbid0IGEgbWlkZGxlYm94IGhhdmUgYSBwb2xpY3kg
d2hlcmUgaXQgcGVybWl0cyBRVUlDIHNlc3Npb25zIHcvbyANCiAgICANCiAgICA+IFBORSBidXQg
YmxvY2tzIHNlc3Npb25zIHdpdGggUE5FPyAgVGhlbiBpbXBsZW1lbnRhdGlvbnMgd291bGQgYmUg
DQogICAgDQogICAgPiBmb3JjZWQgdG8gY2hvb3NlIGhvdyBhZGFwdDogYnJlYWsgYWx0b2dldGhl
ciwgbWF5YmUgdHJ5IFRDUCwgb3IgDQogICAgDQogICAgPiBkaXNhYmxlIFBORSBhbmQgY2Fycnkg
b24uDQogICAgDQogICAgDQogICAgDQogICAgVGhlcmUgYXJlIHR3byB3YXlzIG9mIG5lZ290aWF0
aW5nIHRoZSB1c2UgKG9yIG5vbi11c2UpIG9mIFBORS4gT25lIGlzIHVzZSBUcmFuc3BvcnQgUGFy
YW1ldGVycyBhbmQgdGhlIG90aGVyIGlzIHRvIHVzZSBhIGRpZmZlcmVudCBRVUlDIHZlcnNpb24u
DQogICAgDQogICAgDQogICAgDQogICAgVXNlIG9mIFRyYW5zcG9ydCBQYXJhbWV0ZXJzIGlzIHNl
Y3VyZSBiZWNhdXNlIGl0IGlzIHBhcnQgb2YgdGhlIFRMUyBoYW5kc2hha2UuIFZlcnNpb24gbmVn
b3RpYXRpb24gaGFzIGl0J3Mgb3duIHByb3RlY3Rpb24gYWdhaW5zdCBkb3duZ3JhZGUgKG9yIHVw
Z3JhZGUpIGF0dGFja3MgKHNlZSBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9aHR0cHMtM0FfX3F1aWN3Zy5naXRodWIuaW9fYmFzZS0yRGRyYWZ0c19kcmFmdC0yRGll
dGYtMkRxdWljLTJEdHJhbnNwb3J0Lmh0bWwtMjNyZmMuc2VjdGlvbi42LjQuNCZkPUR3SUdhUSZj
PTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1DMHNVby1MRk5CYVlmeW9hQ3NmNlRBJm09ekMxVkdt
ZjNHUW1XVmU0Njd1ZkxOdWx4dU5oVVRsS0VRd09BODBuQlVVWSZzPWZ2dGNod0FHLVl4SmNSOHdV
QWV6VHdDU042WDhFSDhFLTdNbFNvMXAxbk0mZT0pLg0KICAgIA0KICAgIA0KICAgIA0KICAgIFNv
IEkgd291bGQgYXNzdW1lIHRoYXQgYSBtaWRkbGVib3ggdHJ5aW5nIHRvIGludGVydmVuZSBpbiB0
aGUgbmVnb3RpYXRpb24gb2YgUE5FIHVzZSBjYW4gYmUgZGV0ZWN0ZWQuDQogICAgDQogICAgDQog
ICAgDQogICAgVGhhdCBzYWlkLCBJIGRvIHNlZSB5b3VyIHBvaW50IHRoYXQgaWYgc29tZSBtaWRk
bGVib3hlcyBkZWNpZGUgdG8gcGFzcyBRVUlDIHdpdGhvdXQgUE5FIGJ1dCBibG9jayBRVUlDIHdp
dGggUE5FLCB3ZSBtaWdodCBiZSBpbmNlbnRpdml6ZWQgdG8gdXNlIFFVSUMgd2l0aG91dCBQTkUu
IEluIHN1Y2ggY2FzZSwgd2UgbWlnaHQgZW5kIHVwIGhhdmluZyBwcml2YWN5IGxlYWtzICYgb3Nz
aWZpY2F0aW9uLg0KICAgIA0KICAgIA0KICAgIA0KICAgIEkgdGhpbmsgdGhhdCBpcyBhIGdvb2Qg
YXJndW1lbnQgZm9yIGFsd2F5cyBoYXZpbmcgUE5FIHR1cm5lZCBvbi4NCiAgICANCiAgICANCiAg
ICANCiAgICA+DQogICAgDQogICAgPiBPbiAyNiBBcHJpbCAyMDE4IGF0IDAxOjIyLCBLYXp1aG8g
T2t1IDxrYXp1aG9va3VAZ21haWwuY29tPiB3cm90ZToNCiAgICANCiAgICA+PiAyMDE4LTA0LTI2
IDk6MjEgR01UKzA5OjAwIElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmll
dGYub3JnPjoNCiAgICANCiAgICA+Pj4gSXQgaGFzIGJlZW4sIGFuZCBJJ20gcGVyc29uYWxseSBz
dXBwb3J0aXZlIG9mIGl0LCBiZWNhdXNlIEkgYmVsaWV2ZSANCiAgICANCiAgICA+Pj4gaXQnbGwg
YmUgdXNlZnVsIGZvciBkYXRhY2VudGVyIFFVSUMgdXNlIGNhc2VzLg0KICAgIA0KICAgID4+Pg0K
ICAgIA0KICAgID4+PiBCdXQgdGhlIFdHIGhhcyB0byBkZWNpZGU6DQogICAgDQogICAgPj4+ICAx
KSBJcyBpdCBhbGxvd2FibGUgdG8gZGlzYWJsZSBQTkU/DQogICAgDQogICAgPj4NCiAgICANCiAg
ICA+PiBUaGVyZSBhcmUgdHdvIGNvbmNlcm5zIHRoYXQgUE5FIGlzIHRyeWluZyB0byBhZGRyZXNz
OiBvc3NpZmljYXRpb24gYW5kIHByaXZhY3kuDQogICAgDQogICAgPj4NCiAgICANCiAgICA+PiBJ
IHdvbid0IG1pbmQgaWYgc29tZSBwb3J0aW9uIG9mIFFVSUMtbGlrZSB0cmFmZmljIGhhcyBubyBt
ZWNoYW5pc20gdG8gDQogICAgDQogICAgPj4gcHJldmVudCBvc3NpZmljYXRpb24uIFRoaXMgaXMg
YmVjYXVzZSB3ZSBjYW4gdHJhaW4gdGhlIG1pZGRsZWJveGVzIHRvIA0KICAgIA0KICAgID4+IG5v
dCBvc3NpZnkgdGhlIFBOIGZpZWxkIGJ5IGhhdmluZyBQTkUgaW4gdGhlIG1ham9yaXR5IG9mIHRo
ZSB0cmFmZmljIA0KICAgIA0KICAgID4+IHRoYXQgdGhleSB3aWxsIHNlZS4NCiAgICANCiAgICA+
Pg0KICAgIA0KICAgID4+IE9UT0gsIEkgd291bGQgYmUgd29ycmllZCBvZiBwcml2YWN5IGltcGxp
Y2F0aW9ucy4gT25jZSB5b3UgZGVmaW5lIGEgDQogICAgDQogICAgPj4gcHJvdG9jb2wsIGl0IGlz
IGhhcmQgdG8gY29udHJvbCBob3cgaXQgaXMgZ29pbmcgdG8gYmUgdXNlZC4NCiAgICANCiAgICA+
Pg0KICAgIA0KICAgID4+IEJ1dCB3aXRoIHRoYXQgc2FpZCwgSSB0aGluayB3ZSBtaWdodCBiZXR0
ZXIgd2FpdCB0byBzZWUgaWYgc29tZWJvZHkgDQogICAgDQogICAgPj4gc3RpbGwgdGhpbmtzIGhl
L3NoZSAqbmVlZHMqIFFVSUMgd2l0aG91dCBQTkUuDQogICAgDQogICAgPj4NCiAgICANCiAgICA+
Pj4gIDIpIFdoYXQgdGhlIG1lY2hhbmlzbSBpcz8gIGllOiBVbmlsYXRlcmFsIHZpYSBUcmFuc3Bv
cnRQYXJhbXMgb3IgDQogICAgDQogICAgPj4+IG5lZ290aWF0ZWQgdmlhIGFuIGV4dGVuc2lvbiBv
ciA/DQogICAgDQogICAgPj4+DQogICAgDQogICAgPj4+IE9uIFdlZCwgQXByIDI1LCAyMDE4IGF0
IDY6MDEgUE0gTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPiB3cm90ZToNCiAgICAN
CiAgICA+Pj4+DQogICAgDQogICAgPj4+PiBJIHRoaW5rIHRoYXTigJlzIGJlZW4gc3VnZ2VzdGVk
IGJlZm9yZSwgdGhvdWdoIHdl4oCZZCBuZWVkIHRvIHNvcnQgb3V0IA0KICAgIA0KICAgID4+Pj4g
dGhlIGRldGFpbHMgb2Ygd2hhdCB0aGF0IGxvb2tzIGxpa2UuICBJIGRvbuKAmXQgaGF2ZSBhIHBh
cnRpY3VsYXIgZGVzaWduIGluIG1pbmQuDQogICAgDQogICAgPj4+Pg0KICAgIA0KICAgID4+Pj4N
CiAgICANCiAgICA+Pj4+DQogICAgDQogICAgPj4+PiBGcm9tOiBJYW4gU3dldHQgW21haWx0bzpp
YW5zd2V0dEBnb29nbGUuY29tXQ0KICAgIA0KICAgID4+Pj4gU2VudDogV2VkbmVzZGF5LCBBcHJp
bCAyNSwgMjAxOCAxMjo1NyBQTQ0KICAgIA0KICAgID4+Pj4gVG86IE1pa2UgQmlzaG9wIDxtYmlz
aG9wQGV2ZXF1ZWZvdS5iZT4NCiAgICANCiAgICA+Pj4+IENjOiBDaHJpc3RpYW4gSHVpdGVtYSA8
aHVpdGVtYUBodWl0ZW1hLm5ldD47IERldmFsLCBNYW5hc2kgDQogICAgDQogICAgPj4+PiA8bWFu
YXNpLmRldmFsQGludGVsLmNvbT47IE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldD47IElF
VEYgDQogICAgDQogICAgPj4+PiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KICAgIA0KICAgID4+
Pj4gU3ViamVjdDogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5j
cnlwdGlvbg0KICAgIA0KICAgID4+Pj4NCiAgICANCiAgICA+Pj4+DQogICAgDQogICAgPj4+Pg0K
ICAgIA0KICAgID4+Pj4gSGkgTWlrZSwNCiAgICANCiAgICA+Pj4+DQogICAgDQogICAgPj4+Pg0K
ICAgIA0KICAgID4+Pj4NCiAgICANCiAgICA+Pj4+IFRvIGNsYXJpZnksIGFyZSB5b3Ugc3VnZ2Vz
dGluZyBhZGRpbmcgYSB3YXkgdG8gZGlzYWJsZSBwYWNrZXQgDQogICAgDQogICAgPj4+PiBudW1i
ZXIgZW5jcnlwdGlvbiB2aWEgbmVnb3RpYXRpb24gaW4gdGhlIHYxIHNwZWMgYXMgd2VsbCBhcyAN
CiAgICANCiAgICA+Pj4+IGFkb3B0aW5nICMxMDc5PyAgT3Igd291bGQgdGhlIGNob2ljZSBvZiB3
aGV0aGVyIFBORSBpcyB0byBiZSB1c2VkIA0KICAgIA0KICAgID4+Pj4gdW5pbGF0ZXJhbCwgc3Vj
aCBhcyBhIHRyYW5zcG9ydCBwYXJhbT8NCiAgICANCiAgICA+Pj4+DQogICAgDQogICAgPj4+Pg0K
ICAgIA0KICAgID4+Pj4NCiAgICANCiAgICA+Pj4+IE9uIFdlZCwgQXByIDI1LCAyMDE4IGF0IDM6
NTQgUE0gTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPiB3cm90ZToNCiAgICANCiAg
ICA+Pj4+DQogICAgDQogICAgPj4+PiBZZXMgLS0gaXQgc2VlbXMgdGhhdCB0aGUgYmlnZ2VzdCBv
YmplY3Rpb24gdG8gIzEwNzkgd2FzIHRoZSANCiAgICANCiAgICA+Pj4+IGRpZmZpY3VsdHkgaW4g
aGFyZHdhcmUgaW1wbGVtZW50YXRpb24uICBJZiB3ZSdyZSBoZWFyaW5nIHRoYXQgDQogICAgDQog
ICAgPj4+PiBoYXJkd2FyZSBpbXBsZW1lbnRhdGlvbiBpcyBmZWFzaWJsZSBhdCBhIHJlYXNvbmFi
bGUgY29zdCwgdGhlbiBJIHRoaW5rIHdlIG1pZ2h0IGhhdmUgYSB3aW5uZXIuDQogICAgDQogICAg
Pj4+Pg0KICAgIA0KICAgID4+Pj4gVGhlIENQVSBjb3N0IGZvciBhIHNvZnR3YXJlIGltcGxlbWVu
dGF0aW9uIGlzIHN0aWxsIHdvcnRoIA0KICAgIA0KICAgID4+Pj4gY29uc2lkZXJpbmcsIGFuZCBh
biBvcHRpb24gdG8gbm90IGVuY3J5cHQgaXMgcHJvYmFibHkgcmVhc29uYWJsZSB0byANCiAgICAN
CiAgICA+Pj4+IGxpbWl0IHRoYXQgYnVyZGVuIGZvciBpbXBsZW1lbnRhdGlvbnMgLyB1c2UgY2Fz
ZXMgdGhhdCBkb24ndCBjYXJlLg0KICAgIA0KICAgID4+Pj4NCiAgICANCiAgICA+Pj4+IC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgDQogICAgPj4+PiBGcm9tOiBRVUlDIDxxdWljLWJv
dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RpYW4gSHVpdGVtYQ0KICAgIA0KICAg
ID4+Pj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxOCAzOjE0IEFNDQogICAgDQogICAg
Pj4+PiBUbzogRGV2YWwsIE1hbmFzaSA8bWFuYXNpLmRldmFsQGludGVsLmNvbT47IE1hcmsgTm90
dGluZ2hhbSANCiAgICANCiAgICA+Pj4+IDxtbm90QG1ub3QubmV0Pg0KICAgIA0KICAgID4+Pj4g
Q2M6IHF1aWNAaWV0Zi5vcmcNCiAgICANCiAgICA+Pj4+IFN1YmplY3Q6IFJlOiBHZXR0aW5nIHRv
IGNvbnNlbnN1cyBvbiBwYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCiAgICANCiAgICA+Pj4+DQog
ICAgDQogICAgPj4+PiBPbiA0LzIzLzIwMTggNjo1NSBQTSwgRGV2YWwsIE1hbmFzaSB3cm90ZToN
CiAgICANCiAgICA+Pj4+DQogICAgDQogICAgPj4+PiA+IEkgaGFkIGJyb3VnaHQgdXAgdGhlIGlz
c3VlIHdpdGggUE5FIHNldmVyYWwgd2Vla3MgYWdvIGFzIGEgDQogICAgDQogICAgPj4+PiA+IGJh
cnJpZXIgdG8gaGFyZHdhcmUgb2ZmbG9hZC4gQWZ0ZXIgZnVydGhlciByZXZpZXcsIGl0IGxvb2tz
IGxpa2UgDQogICAgDQogICAgPj4+PiA+IGEgaGFyZHdhcmUgb2ZmbG9hZCBjYW4gaW1wbGVtZW50
IHRoZSBQTkUgYXQgYSBzbWFsbCBjb3N0Lg0KICAgIA0KICAgID4+Pj4gPg0KICAgIA0KICAgID4+
Pj4gPiBUaGUgaW1wbGVtZW50YXRpb24gY2FuIG1vZGlmeSBjdXJyZW50IEhXIGNyeXB0byBhY2Nl
bGVyYXRvcnMgdG8gDQogICAgDQogICAgPj4+PiA+IHN1cHBvcnQgZW5jcnlwdGluZyBhIGJ1ZmZl
ciBpbiB0aGUgZmlyc3QgcGFzcyBhbmQgdGhlbiBlbmNyeXB0aW5nIA0KICAgIA0KICAgID4+Pj4g
PiBwYWNrZXQgbnVtYmVyIGluIHRoZSAybmQgcGFzcyBhcyBhbHJlYWR5IGRpc2N1c3NlZCBvbiB0
aGlzIA0KICAgIA0KICAgID4+Pj4gPiB0aHJlYWQuIFRoZSBleGFjdCByZXF1aXJlbWVudCAoaGVh
ZGVyIGNoZWNrc3VtLCBwYWNrZXQgbGVuZ3RoIA0KICAgIA0KICAgID4+Pj4gPiBlbmNvZGluZykg
aXMgc3RpbGwgaW4gZmx1eCBzbyB0aGVyZSBtYXkgYmUgc29tZSBzbWFsbCB2YXJpYXRpb25zIA0K
ICAgIA0KICAgID4+Pj4gPiBkZXBlbmRpbmcgb24gdGhlIGFjY2VsZXJhdG9yIGFuZCBmaW5hbCBh
bGdvcml0aG0gY2hvc2VuIGZvciBQTkUuIA0KICAgIA0KICAgID4+Pj4gPiBGdXR1cmUgb2ZmbG9h
ZCBkZXNpZ25zIGNhbiBkbyBtb3JlIHRvIGZ1cnRoZXIgcmVkdWNlIHRoZSBvdmVyaGVhZC4NCiAg
ICANCiAgICA+Pj4+DQogICAgDQogICAgPj4+PiBUaGFua3MgZm9yIHRoZSBpbmZvcm1hdGlvbiwg
TWFuYXNpLiBJIGhhdmUgbW9kaWZpZWQgdGhlIHdpa2kgcGFnZSANCiAgICANCiAgICA+Pj4+IGRl
c2NyaWJpbmcgdGhlIFBORSBpc3N1ZXMgYW5kIGFsdGVybmF0aXZlcyB0byByZWZsZWN0IHRoaXMg
bmV3IGRhdGE6DQogICAgDQogICAgPj4+Pg0KICAgIA0KICAgID4+Pj4gaHR0cHM6Ly9naXRodWIu
Y29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL1N1bW1hcnktb2YtdGhlLVBOLWVuY3J5cHRpb24t
aXNzdWVzLWFuZC1hbHRlcm5hdGl2ZXMuLg0KICAgIA0KICAgID4+Pj4gV2l0aCB0aGF0IG5ldyBp
bmZvcm1hdGlvbiwgaXQgYXBwZWFycyB0aGF0IFBSICMxMDc5IGlzIHN1cGVyaW9yIHRvIA0KICAg
IA0KICAgID4+Pj4gZXZlcnkgb3RoZXIgYWx0ZXJuYXRpdmUuDQogICAgDQogICAgPj4+Pg0KICAg
IA0KICAgID4+Pj4gLS0gQ2hyaXN0aWFuIEh1aXRlbWENCiAgICANCiAgICA+Pg0KICAgIA0KICAg
ID4+DQogICAgDQogICAgPj4NCiAgICANCiAgICA+PiAtLQ0KICAgIA0KICAgID4+IEthenVobyBP
a3UNCiAgICANCiAgICA+Pg0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAg
IA0KICAgIC0tDQogICAgDQogICAgS2F6dWhvIE9rdQ0KICAgIA0KICAgIA0KICAgIA0KICAgIA0K
DQo=


From nobody Mon Apr 30 13:34:52 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC01B1270B4 for ; Mon, 30 Apr 2018 13:34:50 -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=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6mb8ZQSL6W1 for ; Mon, 30 Apr 2018 13:34: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 8AFB5127735 for ; Mon, 30 Apr 2018 13:34:49 -0700 (PDT)
Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx44.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fDFVW-0007KP-Fo for quic@ietf.org; Mon, 30 Apr 2018 22:34:47 +0200
Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fDFVR-0002ON-Uk for quic@ietf.org; Mon, 30 Apr 2018 16:34:42 -0400
Received: (qmail 30806 invoked from network); 30 Apr 2018 20:34:38 -0000
Received: from unknown (HELO [192.168.1.16]) (Authenticated-user:_huitema@huitema.net@[90.105.145.87]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Apr 2018 20:34:38 -0000
To: Jana Iyengar , "Brian Trammell (IETF)" 
Cc: "Lubashev, Igor" , Mark Nottingham , Mike Bishop , Ian Swett , Erik Kline , IETF QUIC WG , "Deval, Manasi" , Kazuho Oku 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>          <58447D8E-782C-431C-8FC3-71124B10A047@trammell.ch> 
From: Christian Huitema 
Openpgp: preference=signencrypt
Message-ID: 
Date: Mon, 30 Apr 2018 21:34:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: Getting to consensus on packet number encryption
X-Originating-IP: 168.144.250.231
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.12)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5sy2zDwP7IdZRtxjV3FZuXt602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVi2s2oftdOqkpI6/EafQzARs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB+FWCyy3VMwU/Tu6lpkyLYh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpXDzxM5P50wvQiu34cU//edF8FcHzzV3acxBudgYcInb2qesEv6M3UD 4nxxSzsWcpSZ4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZN1zg8T9ahw4hquQDupK1jlwBl1z1+w2zS/h3e6UiVRfLO3Ah3hBgPbv/ EOrW1lDpNZgenW33adAGHZefc4/zeGeqA47D/juB1cx4exzYk7wfjirBnMSvLt+oZCsKZvqt647l NwN4qOsSZg+fYhVZG9EQ9b9YI+9ZsqMLtlmzzH7VwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg
X-Report-Abuse-To: spam@quarantine6.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, 30 Apr 2018 20:34:51 -0000

On 4/28/2018 1:08 AM, Jana Iyengar wrote:
> I agree that negotiating PNE runs the risk of having two types of
> connections on the Internet. I agree that the risk of blockage doesn't
> seem high, but honestly, having seen how middlebox features get
> deployed, I'm not convinced that it won't happen (though I suspect
> it's unlikely to happen at a large scale). I understand the desire to
> have it off within DCs though, so I'm sensitive to that need.
>
> I'd like to hear more about why making PNE optional isn't a decision
> that we can punt to later though. I'd like to move along with PNE now,
> and come back to negotiating this as an option once we have some
> deployment work/experience in intra DC environments. I'm not yet
> convinced that this is going to be your biggest cost in an intra-DC
> environment, and if it is, then we can surely revisit this decision
> and add a param later to make PNE optional, either later in v1 or in
> v2. We are talking about a very narrow view into total cost at this
> point -- this one AES op is unlikely to be the bottleneck. But I have
> no data, and I don't think anyone has any full deployment experience yet.
>
> TL;DR: I'd like to suggest that we move ahead with PR #1079, and
> continue discussion on adding optional PNE in Issue #1296.

+1

-- Christian Huitema


From nobody Mon Apr 30 13:37:28 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E157B1270AB for ; Mon, 30 Apr 2018 13:37:26 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=XRUBh1pc; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=hd1GBwF5
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id am47WnyMs85m for ; Mon, 30 Apr 2018 13:37:25 -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 D5EA8127078 for ; Mon, 30 Apr 2018 13:37:24 -0700 (PDT)
Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3UKWgr6003705; Mon, 30 Apr 2018 13:37:17 -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=6J4A31tzVfbpyYc2AzJUtYal610N/c2tk2Dd9CTXmdc=; b=XRUBh1pcYUiOtuIzjknZni0vj94NHu7zWV+uFMQGGHN2RYXt7W6rJ4Qp8g07dEcKPEFo ZI6QRPkoy4Z0CAPJmqJab0NkUaE+NEdXaRraRmxv9jsn40EOZ2lcLo5imGWFbF1DUJxH oDlzZ2jnIS/8qIzOfUZytuL9Sn64DB0Z//E= 
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2hp8psg9b9-2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Apr 2018 13:37:17 -0700
Received: from NAM02-BL2-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.361.1; Mon, 30 Apr 2018 13:37:13 -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=6J4A31tzVfbpyYc2AzJUtYal610N/c2tk2Dd9CTXmdc=; b=hd1GBwF50nXgqMxsgoJrO2OcwDrdE58q9JrAQguwQzXssgNajf6RI/EVS8xOLvqKqYM/gHKWQqU5N4cId8GqBDUfpK6+dPCQOmNAnp4x201xcJBIlDEH5Tlns69PA0sQBN0MpZre2vtlgyPEfWGmywPLBPaRk2cFF906ZT/zIcA=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0487.namprd15.prod.outlook.com (10.163.110.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.715.18; Mon, 30 Apr 2018 20:37:11 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::6c4c:bbf3:ec3b:d45e]) by BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::6c4c:bbf3:ec3b:d45e%14]) with mapi id 15.20.0696.019; Mon, 30 Apr 2018 20:37:11 +0000
From: Roberto Peon 
To: Watson Ladd , Mike Bishop 
CC: Praveen Balasubramanian , "Lubashev, Igor" , Ian Swett , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "IETF QUIC WG" , "Deval, Manasi" 
Subject: Re: Impact of hardware offloads on network stack performance
Thread-Topic: Impact of hardware offloads on network stack performance
Thread-Index: AdPMUbL7T8nZAW2ySiO289IPTC0ttgAApm4AADSbFZAACUWYgAAFkLQAACA3b/AAAajkgANRfL2AAAA3SQAAAHMwgAAAR/kAAAEuygAAAJMTgAAAxh6AAAICTwABULcLAA==
Date: Mon, 30 Apr 2018 20:37:11 +0000
Message-ID: 
References:        <1F436ED13A22A246A59CA374CBC543998B60C7AD@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B60C851@ORSMSX111.amr.corp.intel.com>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-originating-ip: [2620:10d:c090:200::6:ddb8]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0487; 7:B6c5lwChIwfTL659PaJlWy60teei7MHuClf60KQBFI1FmFcYGzxRrBnjPsl/immQ50YnvGpyHx3V1Yb//1ZjwUjZgH8+caC0JGKMyYuuvbcnnBSYTVWuWQ5JHgfQrrzKR0fFqLGYNduyIpyZO8PD2L0eXqm3XuMv1M/379ylpZMujEUdWG8Iy8TxipZvVFuxPaOCJW+wd0UL/e14ywaaqFyqfXRFjbLioNGkXhFZgOsiJflOAQrhDuqhNh8BJDok; 20:AbixXuZTZceBQ8aVNUsRrt7IlpMmAZoXuhYmtfsfJRQIf2wUEQXQ4t71r+d36r1MB9c8FhM2/UAAmq+vDmkUBzF/cEdyiWb4kdJWXSwXhP3t7vpftUUb7xwpL/Tnvbfmw3B0wN7b6t8zo+HwhbXPc73+ccaSsy0g5AqToluKV0M=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR15MB0487; 
x-ms-traffictypediagnostic: BY2PR15MB0487:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(21748063052155)(266576461109395)(228905959029699);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(11241501184)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6041310)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:BY2PR15MB0487; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0487; 
x-forefront-prvs: 0658BAF71F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(39380400002)(376002)(346002)(366004)(199004)(189003)(316002)(46003)(110136005)(99286004)(105586002)(39060400002)(97736004)(82746002)(68736007)(14454004)(45080400002)(6486002)(478600001)(229853002)(86362001)(93886005)(6116002)(54906003)(106356001)(33656002)(36756003)(58126008)(186003)(6436002)(3660700001)(76176011)(8936002)(102836004)(2906002)(25786009)(8666007)(11346002)(446003)(2900100001)(3280700002)(83716003)(8676002)(7736002)(486006)(5660300001)(5250100002)(476003)(4326008)(6246003)(54896002)(6506007)(53546011)(53936002)(81166006)(81156014)(6306002)(236005)(6512007)(2616005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0487; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: iYMORoLEtMfL8rmLG6978UQ8tqgSwnubFHDAbXTzU466ZCJyE80yrO8TPfy2ohpa0VgZP9z7IFftbr1oOSHgkYueVEriOaDBKYMI0TC9bmcWdyGW1y1QtRHvwheUBwJehYEsUiQhexT4ScDPpDNYxndPjBPoomLqSwq8Io7Hjml8UnL8GnqeC7M/6KS1H0wI
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_A6F55755D7E140E48EC3D5FE77A2EDBEfbcom_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 5df94358-a4b3-47a6-9957-08d5aeda266c
X-MS-Exchange-CrossTenant-Network-Message-Id: 5df94358-a4b3-47a6-9957-08d5aeda266c
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2018 20:37:11.1673 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0487
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-30_08:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Apr 2018 20:37:27 -0000

--_000_A6F55755D7E140E48EC3D5FE77A2EDBEfbcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UVVJQyAobW9zdGx5KSBkb2VzbuKAmXQgZG8gdGhhdCAocmV4bWl0IGEgcGFja2V0IHZlcmJhdGlt
KeKAlHlvdeKAmWQgbmVlZCBhIG5ldyBwYWNrZXQjIGZvciB0aGUgcmV4bWl0dGVkIHBhY2tldC4N
Ci09Ug0KDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBX
YXRzb24gTGFkZCA8d2F0c29uYmxhZGRAZ21haWwuY29tPg0KRGF0ZTogTW9uZGF5LCBBcHJpbCAy
MywgMjAxOCBhdCAxOjU2IFBNDQpUbzogTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJl
Pg0KQ2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPiwgIkx1
YmFzaGV2LCBJZ29yIiA8aWx1YmFzaGVAYWthbWFpLmNvbT4sIElhbiBTd2V0dCA8aWFuc3dldHQ9
NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPiwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8
bWlra2VsZmpAZ21haWwuY29tPiwgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPiwgIkRldmFs
LCBNYW5hc2kiIDxtYW5hc2kuZGV2YWxAaW50ZWwuY29tPg0KU3ViamVjdDogUmU6IEltcGFjdCBv
ZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3JrIHN0YWNrIHBlcmZvcm1hbmNlDQoNCg0KDQpP
biBNb24sIEFwciAyMywgMjAxOCBhdCAxOjA2IFBNLCBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVx
dWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj4gd3JvdGU6DQpJIGFncmVlIOKA
kyB0aGUgcG9pbnQgb2Ygb2ZmbG9hZGluZyB0aGUgY3J5cHRvIGlzIG5vdCBvbmx5IHRvIHNwYXJl
IHRoYXQgY29zdCBvbiB0aGUgQ1BVLCB0aG91Z2ggdGhhdCBjYW4gYmUgdXNlZnVsLCBpdOKAmXMg
dG8gZW5hYmxlIGZ1cnRoZXIgb2ZmbG9hZHMgdGhhdCBjYW7igJl0IGJlIGRvbmUgb24gdGhlIGVu
Y3J5cHRlZCBwYWNrZXQuDQoNCkxSTyB0aGF0IGNvdWxkIHNpbXBseSBncm91cCBwYWNrZXRzIGJ5
IENJRCBhbmQgZGVsaXZlciBhIHNpbmdsZSBiYXRjaCBvZiBwYWNrZXRzIGZyb20gYSBzaW5nbGUg
Q0lEIGluIGEgc2luZ2xlIGludm9jYXRpb24gc2VlbXMgbGlrZSBhIGdyZWF0IGZpcnN0IHN0ZXAs
IGFuZCBkb2VzbuKAmXQgZXZlbiByZXF1aXJlIGNyeXB0byBvZmZsb2FkLiAgT25jZSB5b3UgaGF2
ZSBjcnlwdG8gb2ZmbG9hZCwgb2YgY291cnNlIHRob3NlIHBhY2tldHMgcGVyIENJRCBjb3VsZCBi
ZSBkZWxpdmVyZWQgYWxyZWFkeSBkZWNyeXB0ZWQuICBJ4oCZZCB3YW50IHRvIHNlZSBkYXRhIG9u
IHdoZXRoZXIgdGhlcmXigJlzIHZhbHVlIGluIG1ha2luZyB0aGUgcmVjZWl2ZWQgZGF0YSBsb29r
IGxpa2Ugb25lIGh1Z2UgcGFja2V0IHdoZW4gdGhlcmXigJlzIG5vdCBhIHNpbmdsZSBieXRlc3Ry
ZWFtLCBidXQgdGhhdOKAmXMgbm90IHNvbWV0aGluZyB3ZSBuZWVkIHRvIHNwZWNpZnkgaGVyZS4N
Cg0KTFNPIGlzIG1vcmUgaW50ZXJlc3RpbmcsIGFuZCB0aGUgY2hhbGxlbmdlIHRoZXJlIGlzIHRo
YXQgdGhlIHRyYW5zcG9ydCBzdGFjayBzdGlsbCBuZWVkcyB0byBrbm93IHdoYXQgZGF0YSB3YXMg
aW4gd2hpY2ggcGFja2V0IHNvIHRoYXQgaXQgY2FuIGRvIGxvc3MgcmVjb3ZlcnkgcHJvcGVybHku
ICBRVUlDIGV4cGxpY2l0bHkgZGlzYWxsb3dzIGZyYWdtZW50YXRpb24gb2YgdGhlIFVEUCBkYXRh
Z3JhbSwgZm9yIHRoZSDigJxwYWluZnVsIGFuZCBwb3RlbnRpYWxseSBub24tZGV0ZXJtaW5pc3Rp
Y+KAnSByZWFzb25zIHlvdSByZWZlcmVuY2VkLg0KDQpGb3JnaXZlIG15IGNvbXBsZXRlIGlnbm9y
YW5jZSwgYnV0IGRvZXNuJ3QgaXQganVzdCBuZWVkIHRvIGtub3cgd2hhdCBwYWNrZXQgaXQgc2Vu
dD8NCg0KTW9yZSBleHBsaWNpdGx5IHRoZSBzZW5kZXIgd291bGQgbWFpbnRhaW4gYSBxdWV1ZSBv
ZiBzZW5kYWJsZSBwYWNrZXRzLCBhbmQgbWFyayB3aGljaCBoYXZlIGJlZW4gc2VudC4gQWNrbm93
bGVkZ2VkIHBhY2tldHMgYXJlIHJlbW92ZWQgZnJvbSB0aGUgcXVldWUuIEluIGV2ZW50IG9mIGxv
c3MsIHRoZXkgc2ltcGx5IHJldHJhbnNtaXQgdGhlIHNhbWUgcGFja2V0LiBJdCdzIHVwIHRvIGhp
Z2hlciBsYXllcnMgdG8gcGljayB0aGUgcmlnaHQgc2l6ZSBvZiBwYWNrZXQgYW5kIHRha2UgZGF0
YSBmcm9tIHRoZSBpbmRpdmlkdWFsIFFVSUMgc3RyZWFtcy4gSWYgeW91IHdhbnRlZCB0byBleHBv
c2UgdGhlIHN0cmVhbSBzdHJ1Y3R1cmUsIHRoYXQgc291bmRzIGEgbG90IG1vcmUgY29tcGxpY2F0
ZWQuDQoNClNpbmNlcmVseSwNCldhdHNvbg0KDQoNCg==

--_000_A6F55755D7E140E48EC3D5FE77A2EDBEfbcom_
Content-Type: text/html; charset="utf-8"
Content-ID: <5A63ABD7ECB2964D859987802AFF756B@namprd15.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv
bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6
bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt
c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi
IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlFVSUMgKG1vc3RseSkgZG9lc27igJl0IGRvIHRoYXQgKHJleG1pdCBhIHBhY2tl
dCB2ZXJiYXRpbSnigJR5b3XigJlkIG5lZWQgYSBuZXcgcGFja2V0IyBmb3IgdGhlIHJleG1pdHRl
ZCBwYWNrZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tPVI8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlFVSUMgJmx0O3F1aWMtYm91bmNl
c0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFdhdHNvbiBMYWRkICZsdDt3YXRzb25ibGFkZEBn
bWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgQXByaWwgMjMsIDIwMTggYXQg
MTo1NiBQTTxicj4NCjxiPlRvOiA8L2I+TWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91
LmJlJmd0Ozxicj4NCjxiPkNjOiA8L2I+UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZi
QG1pY3Jvc29mdC5jb20mZ3Q7LCAmcXVvdDtMdWJhc2hldiwgSWdvciZxdW90OyAmbHQ7aWx1YmFz
aGVAYWthbWFpLmNvbSZndDssIElhbiBTd2V0dCAmbHQ7aWFuc3dldHQ9NDBnb29nbGUuY29tQGRt
YXJjLmlldGYub3JnJmd0OywgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7bWlra2VsZmpA
Z21haWwuY29tJmd0OywgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OywgJnF1b3Q7
RGV2YWwsIE1hbmFzaSZxdW90OyAmbHQ7bWFuYXNpLmRldmFsQGludGVsLmNvbSZndDs8YnI+DQo8
Yj5TdWJqZWN0OiA8L2I+UmU6IEltcGFjdCBvZiBoYXJkd2FyZSBvZmZsb2FkcyBvbiBuZXR3b3Jr
IHN0YWNrIHBlcmZvcm1hbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4m
bmJzcDs8L286cD48L2E+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv
b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5PbiBNb24sIEFwciAyMywgMjAxOCBhdCAxOjA2IFBN
LCBNaWtlIEJpc2hvcCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZv
dS5iZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29r
bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy
Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SSBhZ3JlZSDigJMgdGhl
IHBvaW50IG9mIG9mZmxvYWRpbmcgdGhlIGNyeXB0byBpcyBub3Qgb25seSB0byBzcGFyZSB0aGF0
IGNvc3Qgb24gdGhlIENQVSwgdGhvdWdoIHRoYXQgY2FuIGJlIHVzZWZ1bCwgaXTigJlzIHRvIGVu
YWJsZSBmdXJ0aGVyDQogb2ZmbG9hZHMgdGhhdCBjYW7igJl0IGJlIGRvbmUgb24gdGhlIGVuY3J5
cHRlZCBwYWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkxSTyB0aGF0IGNvdWxkIHNpbXBseSBncm91
cCBwYWNrZXRzIGJ5IENJRCBhbmQgZGVsaXZlciBhIHNpbmdsZSBiYXRjaCBvZiBwYWNrZXRzIGZy
b20gYSBzaW5nbGUgQ0lEIGluIGEgc2luZ2xlIGludm9jYXRpb24gc2VlbXMgbGlrZQ0KIGEgZ3Jl
YXQgZmlyc3Qgc3RlcCwgYW5kIGRvZXNu4oCZdCBldmVuIHJlcXVpcmUgY3J5cHRvIG9mZmxvYWQu
Jm5ic3A7IE9uY2UgeW91IGhhdmUgY3J5cHRvIG9mZmxvYWQsIG9mIGNvdXJzZSB0aG9zZSBwYWNr
ZXRzIHBlciBDSUQgY291bGQgYmUgZGVsaXZlcmVkIGFscmVhZHkgZGVjcnlwdGVkLiZuYnNwOyBJ
4oCZZCB3YW50IHRvIHNlZSBkYXRhIG9uIHdoZXRoZXIgdGhlcmXigJlzIHZhbHVlIGluIG1ha2lu
ZyB0aGUgcmVjZWl2ZWQgZGF0YSBsb29rIGxpa2Ugb25lIGh1Z2UNCiBwYWNrZXQgd2hlbiB0aGVy
ZeKAmXMgbm90IGEgc2luZ2xlIGJ5dGVzdHJlYW0sIGJ1dCB0aGF04oCZcyBub3Qgc29tZXRoaW5n
IHdlIG5lZWQgdG8gc3BlY2lmeSBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k
eSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5MU08gaXMgbW9yZSBp
bnRlcmVzdGluZywgYW5kIHRoZSBjaGFsbGVuZ2UgdGhlcmUgaXMgdGhhdCB0aGUgdHJhbnNwb3J0
IHN0YWNrIHN0aWxsIG5lZWRzIHRvIGtub3cgd2hhdCBkYXRhIHdhcyBpbiB3aGljaCBwYWNrZXQg
c28gdGhhdA0KIGl0IGNhbiBkbyBsb3NzIHJlY292ZXJ5IHByb3Blcmx5LiZuYnNwOyBRVUlDIGV4
cGxpY2l0bHkgZGlzYWxsb3dzIGZyYWdtZW50YXRpb24gb2YgdGhlIFVEUCBkYXRhZ3JhbSwgZm9y
IHRoZSDigJw8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+cGFpbmZ1bCBhbmQgcG90ZW50aWFs
bHkgbm9uLWRldGVybWluaXN0aWM8L3NwYW4+4oCdIHJlYXNvbnMgeW91IHJlZmVyZW5jZWQuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp
Z2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu
YWxCb2R5Ij5Gb3JnaXZlIG15IGNvbXBsZXRlIGlnbm9yYW5jZSwgYnV0IGRvZXNuJ3QgaXQganVz
dCBuZWVkIHRvIGtub3cgd2hhdCBwYWNrZXQgaXQgc2VudD88YnI+DQo8YnI+DQpNb3JlIGV4cGxp
Y2l0bHkgdGhlIHNlbmRlciB3b3VsZCBtYWludGFpbiBhIHF1ZXVlIG9mIHNlbmRhYmxlIHBhY2tl
dHMsIGFuZCBtYXJrIHdoaWNoIGhhdmUgYmVlbiBzZW50LiBBY2tub3dsZWRnZWQgcGFja2V0cyBh
cmUgcmVtb3ZlZCBmcm9tIHRoZSBxdWV1ZS4gSW4gZXZlbnQgb2YgbG9zcywgdGhleSBzaW1wbHkg
cmV0cmFuc21pdCB0aGUgc2FtZSBwYWNrZXQuIEl0J3MgdXAgdG8gaGlnaGVyIGxheWVycyB0byBw
aWNrIHRoZSByaWdodCBzaXplDQogb2YgcGFja2V0IGFuZCB0YWtlIGRhdGEgZnJvbSB0aGUgaW5k
aXZpZHVhbCBRVUlDIHN0cmVhbXMuIElmIHlvdSB3YW50ZWQgdG8gZXhwb3NlIHRoZSBzdHJlYW0g
c3RydWN0dXJlLCB0aGF0IHNvdW5kcyBhIGxvdCBtb3JlIGNvbXBsaWNhdGVkLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NClNpbmNlcmVseSw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5XYXRzb248bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_A6F55755D7E140E48EC3D5FE77A2EDBEfbcom_--


From nobody Mon Apr 30 13:38:44 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290671270B4 for ; Mon, 30 Apr 2018 13:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-DY7mRbHoHr for ; Mon, 30 Apr 2018 13:38:41 -0700 (PDT)
Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13492127078 for ; Mon, 30 Apr 2018 13:38:41 -0700 (PDT)
Received: by mail-yb0-x22d.google.com with SMTP id l9-v6so3511451ybm.8 for ; Mon, 30 Apr 2018 13:38:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ip5nwLGUgviB7qgp0mHP2OBBxHMyBi0RTsL8pF2Ke4Y=; b=d+QpndKyRt05VZBeW705/v3CG7FDglgSmAVj9o9YRauue7S8mG8jzMzNLg8ym5nJ5E wS8eImyp+Az1um8SMAPAmLLrrNLrBT5v5IERrmNM2tJiT014trwk/Yh1sE2Vp4jrlwcL 3x47mAQYDdyLlWPIdtESKds7pTtGKuLHJcd2ek/1+J1Zsao7D8PI62mAjvGEZYCIUusj w6EFwKR5ItE2DQJ/MlKPJMKt7TFYNJ3KeW1AWGezgzMwqYwcsEr0kQgDnczvJusS+Zty BJG8W5Fj6gjf5sNSG+s6nSfbY/KyKQgyD85/pcFboC5h5I/RYRacxO/LpldbmgkUcD+1 JYhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ip5nwLGUgviB7qgp0mHP2OBBxHMyBi0RTsL8pF2Ke4Y=; b=Cv3gVhTf5tnboGeMxWlEaYykSwE6SfLs0tS7N2HpClsrGlCIAV76/RNncNs0jx8iav wRFnm/POadR6yJlg6SBahGWYZyQfq/UIY/ZImA7yhuIxvL/wellMjH1dExUtLA2vrV6b 1OPn6Mc3ZeqB36p2PnOfpUvSnW9LR5f5UisAdmqAdtCoiELfMos32gKM0xfVC+hYKQ+w 9y06kt8+hWyXtdJ7x7dLXTZA+A/DqqYpAMrrL0WwPNqVauZ8jf+mFATrG/2YIvKuAUQp ajd7fVZYtHNEbsetW/1fg9Z7GGtuw+JnzwzX0g/k7YdBSBi9TrFnQetfPh2163mw23ep GxEA==
X-Gm-Message-State: ALQs6tCd7LArI0kDe7HTfwvsBdO717Bcij0lXKchjv8Mw6TFaKW06ek0 lIl/Qtgejn3Z/TNUZiAUIm5mEHJeEwsNBbWquIDlaw==
X-Google-Smtp-Source: AB8JxZqvD90w8SNiBtzjpPNycRaO5AfklNVjuN5usE1ShvjIU6rV8eH+9Dz8u3naOG3q/1d0f/cz8d/x0UNd+rV4EIQ=
X-Received: by 2002:a25:b18b:: with SMTP id h11-v6mr8215170ybj.376.1525120720117;  Mon, 30 Apr 2018 13:38:40 -0700 (PDT)
MIME-Version: 1.0
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>          <58447D8E-782C-431C-8FC3-71124B10A047@trammell.ch>  
In-Reply-To: 
From: Ian Swett 
Date: Mon, 30 Apr 2018 20:38:28 +0000
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Christian Huitema 
Cc: Jana Iyengar , Brian Trammell ,  "Lubashev, Igor" , Mark Nottingham , Mike Bishop ,  Erik Kline , IETF QUIC WG , "Deval, Manasi" , Kazuho Oku 
Content-Type: multipart/alternative; boundary="000000000000c3a60a056b16d69d"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 30 Apr 2018 20:38:43 -0000

--000000000000c3a60a056b16d69d
Content-Type: text/plain; charset="UTF-8"

SGTM

On Mon, Apr 30, 2018 at 4:34 PM Christian Huitema 
wrote:

>
>
> On 4/28/2018 1:08 AM, Jana Iyengar wrote:
> > I agree that negotiating PNE runs the risk of having two types of
> > connections on the Internet. I agree that the risk of blockage doesn't
> > seem high, but honestly, having seen how middlebox features get
> > deployed, I'm not convinced that it won't happen (though I suspect
> > it's unlikely to happen at a large scale). I understand the desire to
> > have it off within DCs though, so I'm sensitive to that need.
> >
> > I'd like to hear more about why making PNE optional isn't a decision
> > that we can punt to later though. I'd like to move along with PNE now,
> > and come back to negotiating this as an option once we have some
> > deployment work/experience in intra DC environments. I'm not yet
> > convinced that this is going to be your biggest cost in an intra-DC
> > environment, and if it is, then we can surely revisit this decision
> > and add a param later to make PNE optional, either later in v1 or in
> > v2. We are talking about a very narrow view into total cost at this
> > point -- this one AES op is unlikely to be the bottleneck. But I have
> > no data, and I don't think anyone has any full deployment experience yet.
> >
> > TL;DR: I'd like to suggest that we move ahead with PR #1079, and
> > continue discussion on adding optional PNE in Issue #1296.
>
> +1
>
> -- Christian Huitema
>

--000000000000c3a60a056b16d69d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


SGTM

On Mon, Apr 30, 2018 at 4:34 PM Christian Huitema <huitema@huitema.net> wrote:




On 4/28/2018 1:08 AM, Jana Iyengar wrote:

> I agree that negotiating PNE runs the risk of having two types of

> connections on the Internet. I agree that the risk of blockage doesn&#=
39;t

> seem high, but honestly, having seen how middlebox features get

> deployed, I'm not=C2=A0convinced that it won't happen (though =
I suspect

> it's unlikely to happen at a large scale). I understand the desire=
 to

> have it off within DCs though, so I'm sensitive to that need.

>

> I'd like to hear more about why making PNE optional isn't a de=
cision

> that we can punt to later though. I'd like to move along with PNE =
now,

> and come back to negotiating this as an option once we have some

> deployment work/experience in intra DC environments. I'm not yet
> convinced that this is going to be your biggest cost in an intra-DC
> environment, and if it is, then we can surely revisit this decision
> and add a param later to make PNE optional, either later in v1 or in
> v2. We are talking about a very narrow view into total cost at this
> point -- this one AES op is unlikely to be the bottleneck. But I have<=
br>
> no data, and I don't think anyone has any full deployment experien=
ce yet.

>

> TL;DR: I'd like to suggest that we move ahead with PR #1079, and
> continue discussion on adding optional PNE in Issue #1296.



+1



-- Christian Huitema




--000000000000c3a60a056b16d69d--


From nobody Mon Apr 30 14:55:40 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE0C127275 for ; Mon, 30 Apr 2018 14:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable 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 fhiO2id_1QJW for ; Mon, 30 Apr 2018 14:55:36 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0120.outbound.protection.outlook.com [104.47.41.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEAF127241 for ; Mon, 30 Apr 2018 14:55:34 -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=IBWG6sSJB5pmGbSPiBnUJoF1uf3FJbi/DIWp6iExWNc=; b=R+OMhEPtl1bFOVbwKokKp7w3sAeJvkN8haBLeYe23bEtxtZqKZ028pidCjPVyYjyFvuxs6+jh9uajLF8yQAfZC+Xpuiz+RMP+EgK095dCRg6f8Vqo9gdGB9c8EsXc/Ltf20FEVBmOa53Q9rpIWzW+xvZYL24FgCkt1JFe7tJ7PE=
Received: from MWHPR21MB0638.namprd21.prod.outlook.com (10.175.141.139) by MWHPR21MB0781.namprd21.prod.outlook.com (10.173.51.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.755.0; Mon, 30 Apr 2018 21:55:32 +0000
Received: from MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::6d48:f7af:d267:2021]) by MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::6d48:f7af:d267:2021%7]) with mapi id 15.20.0735.006; Mon, 30 Apr 2018 21:55:32 +0000
From: Praveen Balasubramanian 
To: Ian Swett , huitema 
CC: Jana Iyengar , "Lubashev, Igor" ,  Mark Nottingham , Mike Bishop , Erik Kline , Brian Trammell , IETF QUIC WG , "Deval,  Manasi" , Kazuho Oku 
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwZ0sAgAC4ugCAAARcAIAAFTbwgAALYgCAAAAgYIAAEcIAgACR+YCAB09lAIAFXyIAgAVK+oCAAJlSAIABxdSAgACOHICAB/EyAIACo7YAgACiMICAAADPgIAAIs8AgAAm/YCAABExgIAABpMAgAAK5wCAAPIgAIAA5wcAgACzcYCAAHHMgIAEe1cAgAABEACAABL8QA==
Date: Mon, 30 Apr 2018 21:55:31 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>          <58447D8E-782C-431C-8FC3-71124B10A047@trammell.ch>   
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::316]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0781; 7:9IdmQpnJFV1dcpP2OOmEfgxRitiv+vxfeTT1u2vEvYWH8t6BuriAAlWAgl4o4eLTQETO4MvllGn+prJLDRdHy/WYX4pFnDRYy19QMFMEpXpdNMTXofSIpk+KxaP7OmnN8945HaqnRr7rb8g0pY7R2j1Uq8ciu2bgXzcoX1ObNDoP/zsdBDLnA63iyAobP+9uACbnejIRzUyr4/lcaVB0uj5tRG2qy6HgvAG8iE7zfRU9ySEFn4o2UsimqhsUkHsA; 20:WqL5/rrukX5V+6XFtXVeubKMdiHpWZPl3NLPANATfW3GUD8V+W7KIdwc3Xo9U61+wf7Q4npFCTGsdRsUWv9T30nd35C3XaJPlf0M/Wriw0a0p70ZKyz+Ki4UnpEHmCw1h0ig2HFctyczQsx7XBQp/WgbH83roBXLC/WfCEWz8wo=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7193020); SRVR:MWHPR21MB0781; 
x-ms-traffictypediagnostic: MWHPR21MB0781:
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(21748063052155)(228905959029699);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231254)(2018427008)(944501410)(52105095)(93006095)(93001095)(6055026)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:MWHPR21MB0781; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0781; 
x-forefront-prvs: 0658BAF71F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(376002)(346002)(39380400002)(396003)(366004)(39860400002)(199004)(189003)(25786009)(59450400001)(53546011)(46003)(478600001)(76176011)(7736002)(6116002)(6506007)(7696005)(10090500001)(102836004)(54906003)(106356001)(5660300001)(105586002)(8676002)(81156014)(186003)(81166006)(110136005)(486006)(99286004)(8990500004)(4326008)(8936002)(790700001)(10290500003)(476003)(446003)(6346003)(11346002)(53936002)(5250100002)(39060400002)(7416002)(316002)(22452003)(6436002)(6306002)(74316002)(68736007)(54896002)(6246003)(236005)(2906002)(55016002)(3660700001)(229853002)(86362001)(14454004)(3280700002)(2900100001)(19609705001)(93886005)(86612001)(9686003)(97736004)(33656002)(61000200001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0781; H:MWHPR21MB0638.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-microsoft-antispam-message-info: x4BI0oUzNKzRs8cnHiBX3z/zdkrwN/XEoiNeHIw4IUcD9kmB5VrH6Nwc7nkmP2bGaCLRBMoNPZr7q+GhpocMUGcDjbSZgFxJUzF8AEGagE2RMHfHf1Jy3b7kg0f20H1j7xDMOpOT/yYDH/KzBYOU/8BSliexsaQ+ebCqieb+vKToA/ZMbY4vU4vwcndpkCqg
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR21MB063869878060E850137210FEB6820MWHPR21MB0638namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: d3acb8c1-2f0b-488c-5087-08d5aee5183c
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d3acb8c1-2f0b-488c-5087-08d5aee5183c
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2018 21:55:31.7640 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0781
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Apr 2018 21:55:39 -0000

--_000_MWHPR21MB063869878060E850137210FEB6820MWHPR21MB0638namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBkaXNhZ3JlZSB0aGF0IHdlIG5lZWQgYW55IG1vcmUgZGF0YSBmb3Igbm90IGRvaW5nIFBORSBp
biB0aGUgZGF0YWNlbnRlci4gV2h5IHdvdWxkIHdlIGFkZCBhbiBleHRyYSBlbmNyeXB0LWRlY3J5
cHQgc3RlcCBmb3Igbm8gb2J2aW91cyBiZW5lZml0PyBUaGUgY29zdCBvZiB0aGlzIG9wZXJhdGlv
biB3aWxsIGtlZXAgbWFnbmlmeWluZyBhcyBVRFAgcGVyZm9ybWFuY2UgaW1wcm92ZXMuIFdlIGhh
dmUgc2V2ZXJhbCBvcHRpbWl6YXRpb25zIHBsYW5uZWQgZm9yIFVEUCwgYnV0IHNob3J0IG9mIGhh
cmR3YXJlIG9mZmxvYWQsIG5vbmUgZm9yIGNyeXB0byDigJMgdGhpcyBpcyBhbiBpbXBvcnRhbnQg
dHJlbmQgdG8gYWNjb3VudCBmb3IgcGVyZm9ybWFuY2Ugd2lzZS4gRm9yIHNob3J0IHBhY2tldHMg
bGlrZSBBQ0tzIGFuIGV4dHJhIGVuY3J5cHQgZGVjcnlwdCBzdGVwIGNhbiBiZWNvbWUgYSBsYXJn
ZSBmcmFjdGlvbiBvZiBDUFUgY29zdCBvdmVyIHRpbWUuDQoNCklmIFFVSUMgaXMgbm90IGludGVu
ZGVkIHRvIGJlIGEgZ2VuZXJhbCBwdXJwb3NlIHRyYW5zcG9ydCBidXQgb25seSBmb3IgdGhlIElu
dGVybmV0LCB0aGVuIHdlIHNob3VsZCBzYXkgc28gaW4gdGhlIGNoYXJ0ZXIuIFRoZW4gd2UgY2Fu
IGludmVudCBjdXN0b20gcHJvdG9jb2xzIG92ZXIgVURQIGZvciBkYXRhY2VudGVyIHNjZW5hcmlv
cyBhbmQgZ2l2ZSB1cCBvbiBpbnRlcm9wLg0KDQpBbHNvLCB3aGF0IGlzIHRoZSB1cmdlbmN5IGJl
aGluZCBnZXR0aW5nIFBORSBhZG9wdGVkIOKAkyBpcyBpdCBibG9ja2luZyBwcm9ncmVzcyBvbiBp
bnRlcm9wIG9yIG90aGVyIGlzc3Vlcz8gSWYgaXQgaXMgZGVlbWVkIHVyZ2VudCB0aGVuIEkgYW0g
ZmluZSB3aXRoIGFkb3B0aW5nIFBORSBhcyBsb25nIGFzIHdlIGFkZCBhIG5lZ290aWF0aW9uIG1l
Y2hhbmlzbSBpbiBWMS4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIElhbiBTd2V0dA0KU2VudDogTW9uZGF5LCBBcHJpbCAzMCwgMjAxOCAx
OjM4IFBNDQpUbzogaHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD4NCkNjOiBKYW5hIEl5ZW5n
YXIgPGpyaS5pZXRmQGdtYWlsLmNvbT47IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWku
Y29tPjsgTWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0PjsgTWlrZSBCaXNob3AgPG1iaXNo
b3BAZXZlcXVlZm91LmJlPjsgRXJpayBLbGluZSA8ZWtAZ29vZ2xlLmNvbT47IEJyaWFuIFRyYW1t
ZWxsIDxpZXRmQHRyYW1tZWxsLmNoPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgRGV2
YWwsIE1hbmFzaSA8bWFuYXNpLmRldmFsQGludGVsLmNvbT47IEthenVobyBPa3UgPGthenVob29r
dUBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogR2V0dGluZyB0byBjb25zZW5zdXMgb24gcGFja2V0
IG51bWJlciBlbmNyeXB0aW9uDQoNClNHVE0NCg0KT24gTW9uLCBBcHIgMzAsIDIwMTggYXQgNDoz
NCBQTSBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86aHVpdGVt
YUBodWl0ZW1hLm5ldD4+IHdyb3RlOg0KDQoNCk9uIDQvMjgvMjAxOCAxOjA4IEFNLCBKYW5hIEl5
ZW5nYXIgd3JvdGU6DQo+IEkgYWdyZWUgdGhhdCBuZWdvdGlhdGluZyBQTkUgcnVucyB0aGUgcmlz
ayBvZiBoYXZpbmcgdHdvIHR5cGVzIG9mDQo+IGNvbm5lY3Rpb25zIG9uIHRoZSBJbnRlcm5ldC4g
SSBhZ3JlZSB0aGF0IHRoZSByaXNrIG9mIGJsb2NrYWdlIGRvZXNuJ3QNCj4gc2VlbSBoaWdoLCBi
dXQgaG9uZXN0bHksIGhhdmluZyBzZWVuIGhvdyBtaWRkbGVib3ggZmVhdHVyZXMgZ2V0DQo+IGRl
cGxveWVkLCBJJ20gbm90IGNvbnZpbmNlZCB0aGF0IGl0IHdvbid0IGhhcHBlbiAodGhvdWdoIEkg
c3VzcGVjdA0KPiBpdCdzIHVubGlrZWx5IHRvIGhhcHBlbiBhdCBhIGxhcmdlIHNjYWxlKS4gSSB1
bmRlcnN0YW5kIHRoZSBkZXNpcmUgdG8NCj4gaGF2ZSBpdCBvZmYgd2l0aGluIERDcyB0aG91Z2gs
IHNvIEknbSBzZW5zaXRpdmUgdG8gdGhhdCBuZWVkLg0KPg0KPiBJJ2QgbGlrZSB0byBoZWFyIG1v
cmUgYWJvdXQgd2h5IG1ha2luZyBQTkUgb3B0aW9uYWwgaXNuJ3QgYSBkZWNpc2lvbg0KPiB0aGF0
IHdlIGNhbiBwdW50IHRvIGxhdGVyIHRob3VnaC4gSSdkIGxpa2UgdG8gbW92ZSBhbG9uZyB3aXRo
IFBORSBub3csDQo+IGFuZCBjb21lIGJhY2sgdG8gbmVnb3RpYXRpbmcgdGhpcyBhcyBhbiBvcHRp
b24gb25jZSB3ZSBoYXZlIHNvbWUNCj4gZGVwbG95bWVudCB3b3JrL2V4cGVyaWVuY2UgaW4gaW50
cmEgREMgZW52aXJvbm1lbnRzLiBJJ20gbm90IHlldA0KPiBjb252aW5jZWQgdGhhdCB0aGlzIGlz
IGdvaW5nIHRvIGJlIHlvdXIgYmlnZ2VzdCBjb3N0IGluIGFuIGludHJhLURDDQo+IGVudmlyb25t
ZW50LCBhbmQgaWYgaXQgaXMsIHRoZW4gd2UgY2FuIHN1cmVseSByZXZpc2l0IHRoaXMgZGVjaXNp
b24NCj4gYW5kIGFkZCBhIHBhcmFtIGxhdGVyIHRvIG1ha2UgUE5FIG9wdGlvbmFsLCBlaXRoZXIg
bGF0ZXIgaW4gdjEgb3IgaW4NCj4gdjIuIFdlIGFyZSB0YWxraW5nIGFib3V0IGEgdmVyeSBuYXJy
b3cgdmlldyBpbnRvIHRvdGFsIGNvc3QgYXQgdGhpcw0KPiBwb2ludCAtLSB0aGlzIG9uZSBBRVMg
b3AgaXMgdW5saWtlbHkgdG8gYmUgdGhlIGJvdHRsZW5lY2suIEJ1dCBJIGhhdmUNCj4gbm8gZGF0
YSwgYW5kIEkgZG9uJ3QgdGhpbmsgYW55b25lIGhhcyBhbnkgZnVsbCBkZXBsb3ltZW50IGV4cGVy
aWVuY2UgeWV0Lg0KPg0KPiBUTDtEUjogSSdkIGxpa2UgdG8gc3VnZ2VzdCB0aGF0IHdlIG1vdmUg
YWhlYWQgd2l0aCBQUiAjMTA3OSwgYW5kDQo+IGNvbnRpbnVlIGRpc2N1c3Npb24gb24gYWRkaW5n
IG9wdGlvbmFsIFBORSBpbiBJc3N1ZSAjMTI5Ni4NCg0KKzENCg0KLS0gQ2hyaXN0aWFuIEh1aXRl
bWENCg==

--_000_MWHPR21MB063869878060E850137210FEB6820MWHPR21MB0638namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC
My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv
ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S
RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj
b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt
LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft
YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9
DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu
aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs
dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw
ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN
Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs
MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn
aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN
CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh
W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9
ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv
dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSBkaXNhZ3JlZSB0aGF0IHdlIG5lZWQgYW55IG1vcmUgZGF0YSBmb3Ig
bm90IGRvaW5nIFBORSBpbiB0aGUgZGF0YWNlbnRlci4gV2h5IHdvdWxkIHdlIGFkZCBhbiBleHRy
YSBlbmNyeXB0LWRlY3J5cHQgc3RlcCBmb3Igbm8gb2J2aW91cyBiZW5lZml0PyBUaGUgY29zdCBv
ZiB0aGlzIG9wZXJhdGlvbiB3aWxsIGtlZXAgbWFnbmlmeWluZyBhcyBVRFAgcGVyZm9ybWFuY2Ug
aW1wcm92ZXMuIFdlIGhhdmUgc2V2ZXJhbA0KIG9wdGltaXphdGlvbnMgcGxhbm5lZCBmb3IgVURQ
LCBidXQgc2hvcnQgb2YgaGFyZHdhcmUgb2ZmbG9hZCwgbm9uZSBmb3IgY3J5cHRvIOKAkyB0aGlz
IGlzIGFuIGltcG9ydGFudCB0cmVuZCB0byBhY2NvdW50IGZvciBwZXJmb3JtYW5jZSB3aXNlLiBG
b3Igc2hvcnQgcGFja2V0cyBsaWtlIEFDS3MgYW4gZXh0cmEgZW5jcnlwdCBkZWNyeXB0IHN0ZXAg
Y2FuIGJlY29tZSBhIGxhcmdlIGZyYWN0aW9uIG9mIENQVSBjb3N0IG92ZXIgdGltZS48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+SWYgUVVJQyBpcyBub3QgaW50ZW5kZWQgdG8gYmUgYSBnZW5lcmFs
IHB1cnBvc2UgdHJhbnNwb3J0IGJ1dCBvbmx5IGZvciB0aGUgSW50ZXJuZXQsIHRoZW4gd2Ugc2hv
dWxkIHNheSBzbyBpbiB0aGUgY2hhcnRlci4gVGhlbiB3ZSBjYW4gaW52ZW50IGN1c3RvbSBwcm90
b2NvbHMgb3ZlciBVRFAgZm9yIGRhdGFjZW50ZXIgc2NlbmFyaW9zIGFuZCBnaXZlIHVwIG9uIGlu
dGVyb3AuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgd2hhdCBpcyB0aGUgdXJnZW5j
eSBiZWhpbmQgZ2V0dGluZyBQTkUgYWRvcHRlZCDigJMgaXMgaXQgYmxvY2tpbmcgcHJvZ3Jlc3Mg
b24gaW50ZXJvcCBvciBvdGhlciBpc3N1ZXM/IElmIGl0IGlzIGRlZW1lZCB1cmdlbnQgdGhlbiBJ
IGFtIGZpbmUgd2l0aCBhZG9wdGluZyBQTkUgYXMgbG9uZyBhcyB3ZSBhZGQgYSBuZWdvdGlhdGlv
biBtZWNoYW5pc20gaW4gVjEuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+
IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9i
PklhbiBTd2V0dDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDMwLCAyMDE4IDE6Mzgg
UE08YnI+DQo8Yj5Ubzo8L2I+IGh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7PGJy
Pg0KPGI+Q2M6PC9iPiBKYW5hIEl5ZW5nYXIgJmx0O2pyaS5pZXRmQGdtYWlsLmNvbSZndDs7IEx1
YmFzaGV2LCBJZ29yICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0OzsgTWFyayBOb3R0aW5naGFt
ICZsdDttbm90QG1ub3QubmV0Jmd0OzsgTWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91
LmJlJmd0OzsgRXJpayBLbGluZSAmbHQ7ZWtAZ29vZ2xlLmNvbSZndDs7IEJyaWFuIFRyYW1tZWxs
ICZsdDtpZXRmQHRyYW1tZWxsLmNoJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3Jn
Jmd0OzsgRGV2YWwsIE1hbmFzaQ0KICZsdDttYW5hc2kuZGV2YWxAaW50ZWwuY29tJmd0OzsgS2F6
dWhvIE9rdSAmbHQ7a2F6dWhvb2t1QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g
UmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U0dUTTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBcHIgMzAsIDIwMTggYXQgNDozNCBQTSBDaHJp
c3RpYW4gSHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQiPmh1
aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg
MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiA0LzI4LzIwMTggMTowOCBBTSwgSmFuYSBJeWVu
Z2FyIHdyb3RlOjxicj4NCiZndDsgSSBhZ3JlZSB0aGF0IG5lZ290aWF0aW5nIFBORSBydW5zIHRo
ZSByaXNrIG9mIGhhdmluZyB0d28gdHlwZXMgb2Y8YnI+DQomZ3Q7IGNvbm5lY3Rpb25zIG9uIHRo
ZSBJbnRlcm5ldC4gSSBhZ3JlZSB0aGF0IHRoZSByaXNrIG9mIGJsb2NrYWdlIGRvZXNuJ3Q8YnI+
DQomZ3Q7IHNlZW0gaGlnaCwgYnV0IGhvbmVzdGx5LCBoYXZpbmcgc2VlbiBob3cgbWlkZGxlYm94
IGZlYXR1cmVzIGdldDxicj4NCiZndDsgZGVwbG95ZWQsIEknbSBub3QmbmJzcDtjb252aW5jZWQg
dGhhdCBpdCB3b24ndCBoYXBwZW4gKHRob3VnaCBJIHN1c3BlY3Q8YnI+DQomZ3Q7IGl0J3MgdW5s
aWtlbHkgdG8gaGFwcGVuIGF0IGEgbGFyZ2Ugc2NhbGUpLiBJIHVuZGVyc3RhbmQgdGhlIGRlc2ly
ZSB0bzxicj4NCiZndDsgaGF2ZSBpdCBvZmYgd2l0aGluIERDcyB0aG91Z2gsIHNvIEknbSBzZW5z
aXRpdmUgdG8gdGhhdCBuZWVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IEknZCBsaWtlIHRvIGhlYXIg
bW9yZSBhYm91dCB3aHkgbWFraW5nIFBORSBvcHRpb25hbCBpc24ndCBhIGRlY2lzaW9uPGJyPg0K
Jmd0OyB0aGF0IHdlIGNhbiBwdW50IHRvIGxhdGVyIHRob3VnaC4gSSdkIGxpa2UgdG8gbW92ZSBh
bG9uZyB3aXRoIFBORSBub3csPGJyPg0KJmd0OyBhbmQgY29tZSBiYWNrIHRvIG5lZ290aWF0aW5n
IHRoaXMgYXMgYW4gb3B0aW9uIG9uY2Ugd2UgaGF2ZSBzb21lPGJyPg0KJmd0OyBkZXBsb3ltZW50
IHdvcmsvZXhwZXJpZW5jZSBpbiBpbnRyYSBEQyBlbnZpcm9ubWVudHMuIEknbSBub3QgeWV0PGJy
Pg0KJmd0OyBjb252aW5jZWQgdGhhdCB0aGlzIGlzIGdvaW5nIHRvIGJlIHlvdXIgYmlnZ2VzdCBj
b3N0IGluIGFuIGludHJhLURDPGJyPg0KJmd0OyBlbnZpcm9ubWVudCwgYW5kIGlmIGl0IGlzLCB0
aGVuIHdlIGNhbiBzdXJlbHkgcmV2aXNpdCB0aGlzIGRlY2lzaW9uPGJyPg0KJmd0OyBhbmQgYWRk
IGEgcGFyYW0gbGF0ZXIgdG8gbWFrZSBQTkUgb3B0aW9uYWwsIGVpdGhlciBsYXRlciBpbiB2MSBv
ciBpbjxicj4NCiZndDsgdjIuIFdlIGFyZSB0YWxraW5nIGFib3V0IGEgdmVyeSBuYXJyb3cgdmll
dyBpbnRvIHRvdGFsIGNvc3QgYXQgdGhpczxicj4NCiZndDsgcG9pbnQgLS0gdGhpcyBvbmUgQUVT
IG9wIGlzIHVubGlrZWx5IHRvIGJlIHRoZSBib3R0bGVuZWNrLiBCdXQgSSBoYXZlPGJyPg0KJmd0
OyBubyBkYXRhLCBhbmQgSSBkb24ndCB0aGluayBhbnlvbmUgaGFzIGFueSBmdWxsIGRlcGxveW1l
bnQgZXhwZXJpZW5jZSB5ZXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgVEw7RFI6IEknZCBsaWtlIHRv
IHN1Z2dlc3QgdGhhdCB3ZSBtb3ZlIGFoZWFkIHdpdGggUFIgIzEwNzksIGFuZDxicj4NCiZndDsg
Y29udGludWUgZGlzY3Vzc2lvbiBvbiBhZGRpbmcgb3B0aW9uYWwgUE5FIGluIElzc3VlICMxMjk2
Ljxicj4NCjxicj4NCiYjNDM7MTxicj4NCjxicj4NCi0tIENocmlzdGlhbiBIdWl0ZW1hPG86cD48
L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_MWHPR21MB063869878060E850137210FEB6820MWHPR21MB0638namp_--


From nobody Mon Apr 30 15:20:22 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB8612D964 for ; Mon, 30 Apr 2018 15:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rls5xQOISdxl for ; Mon, 30 Apr 2018 15:20:18 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8088C12D95F for ; Mon, 30 Apr 2018 15:20:18 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w3UMD4PQ002267; Mon, 30 Apr 2018 23:20:05 +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=AwqmvwCOu4kzLef4jnxA4yjbON9KvPFwS8DQX5f9RcI=; b=DcSM9rAFICbWBthxq6mLxl7Pfang8ondlRE+IepZEqkEH/wvmQ3AQMQtlM2hbZvFUDrJ B0b8/479+o6oRDc0MylmJKgrNT9ipdfPbijY6hfOLFBqyZPwn38XZ7QUkdQBGC0j05i/ 4FicsAoPX1Tvl8ScYoRElaWf9vSvdCZ2v7jZRsqvRvP1JHmhq7PRYflB4d+hv93WBtbv 6QsHhRkpolBl9M8PVV5JOxY4cVB7xjlmkVBEwgcMli2a34fAWwYb298CVAbNAJqedlIG YBEqt+je8h20TqVPLy3wlCjmseJDGLGO2JulegwN7USkp+aI/zVOiQC2fRr4ussIDYq1 QQ== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2hmqpgncgh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Apr 2018 23:20:04 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3UMBiRA032247; Mon, 30 Apr 2018 18:20:03 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint3.akamai.com with ESMTP id 2hmm9w8mcg-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 30 Apr 2018 18:20:03 -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.1365.1; Mon, 30 Apr 2018 18:20:01 -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.1365.000; Mon, 30 Apr 2018 18:20:01 -0400
From: "Lubashev, Igor" 
To: Roberto Peon , Kazuho Oku , Erik Kline 
CC: Mark Nottingham , Christian Huitema ,  Ian Swett , Mike Bishop , "IETF QUIC WG" , "Deval, Manasi" 
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GWvgm/QKk890OIh9EYaPY3H6PwqlkAgAC4ugCAAARcAIAAG5CAgAAFCQCAAACJgIAAEVgAgACR+YCAB09lAIAFXyIAgAVK+oCAAJlSAIABxdSAgACOHYCAB/ExAIACo7YAgACiMICAAADPgIAAIs8AgAAm/YCAABEygIAABpIAgAAK6ACAAK10MIAGyT6A///aIeA=
Date: Mon, 30 Apr 2018 22:20:00 +0000
Message-ID: <4648c175384540a5b5078fc7f8f42997@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch>      <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net>  <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch>   <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>          
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.33.117]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-30_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804300214
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-30_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804300214
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 30 Apr 2018 22:20:21 -0000

SXQgZG9lcyBub3Qgc2VlbSBsaWtlIHRoZXJlIGlzIGFueSBkaWZmZXJlbmNlIGluIHRoZSBzdWJ0
bGV0eSBvZiAiYmxvY2tpbmcgUVVJQyIgYW5kICJibG9ja2luZyBRVUlDIHRoYXQgbmVnb3RpYXRl
ZCBQTkUiLiAgSW4gYm90aCBjYXNlcyB0aGUgY29ubmVjdGlvbiBlbmRzIHVwIGJsb2NrZWQsIGFu
ZCBpdCBpcyB1cCB0byB0aGUgUVVJQyBzdGFjayBob3cgdG8gZmFpbCBvdmVyIChhbmQgaXQgd291
bGQgZmFpbG92ZXIgdG8gYSBub24tUE5FIHRyYW5zcG9ydCkuDQoNCkFzIGxvbmcgYXMgdGhlcmUg
aXMgYSBUQ1AgZmFsbGJhY2ssIGEgbmV0d29yayB0aGF0IGlzIHdpbGxpbmcgdG8gYmxvY2sgdHJh
ZmZpYyB3aXRoIFBORSBibG9jayB0cmFmZmljIHdpdGggUE5FLiAgU2luY2UgUE5FIGlzIHZlcnkg
bGlrZWx5IHRvIGJlIHRoZSBkZWZhdWx0IGZvciB3ZWIgYnJvd3NlcnMsIG5vIG1pZGRsZWJveCBj
YW4gImFjY2lkZW50YWxseSIgYmxvY2sgUE5FLg0KDQotIElnb3INCg0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KRnJvbTogUm9iZXJ0byBQZW9uIFttYWlsdG86ZmVuaXhAZmIuY29tXSAN
ClNlbnQ6IE1vbmRheSwgQXByaWwgMzAsIDIwMTggNDoyNCBQTQ0KVG86IEx1YmFzaGV2LCBJZ29y
IDxpbHViYXNoZUBha2FtYWkuY29tPjsgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbT47
IEVyaWsgS2xpbmUgPGVrQGdvb2dsZS5jb20+DQpDYzogTWFyayBOb3R0aW5naGFtIDxtbm90QG1u
b3QubmV0PjsgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+OyBJYW4gU3dl
dHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3Uu
YmU+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBEZXZhbCwgTWFuYXNpIDxtYW5hc2ku
ZGV2YWxAaW50ZWwuY29tPg0KU3ViamVjdDogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBh
Y2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpUaGlzIGtpbmQgb2YgJ29idmlvdXMnICJicmVha2Fn
ZSIgaXMgbGVzcyBlYXN5IHRvIGdhbWUgKGl0IGlzIHVuc3VidGxlKSwgYW5kIHRodXMgcHJlZmVy
YWJsZS4NCi09Ug0KDQrvu79PbiA0LzI2LzE4LCA5OjUyIEFNLCAiUVVJQyBvbiBiZWhhbGYgb2Yg
THViYXNoZXYsIElnb3IiIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGlsdWJh
c2hlPTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoNCiAgICA+IGlmIHNvbWUg
bWlkZGxlYm94ZXMgZGVjaWRlIHRvIHBhc3MgUVVJQyB3aXRob3V0IFBORSBidXQgYmxvY2sgUVVJ
QyB3aXRoIFBORSwgd2UgbWlnaHQgYmUgaW5jZW50aXZpemVkIHRvIHVzZSBRVUlDIHdpdGhvdXQg
UE5FLg0KICAgIA0KICAgIA0KICAgIA0KICAgIElmIGEgbWlkZGxlYm94IHJlYWxseSBkaXNsaWtl
cyBQTkUsIGl0IGNhbiBqdXN0IGJsb2NrIFFVSUMgYWx0b2dldGhlciwgZm9yY2luZyBhIFRDUCBm
YWxsYmFjay4gIElzIFRDUCBiZXR0ZXIgdGhhbiBRVUlDLXdpdGhvdXQtUE5FIGZyb20gYW55IFBP
ViBpbiB0aGF0IHNpdHVhdGlvbj8gIChBbmQgaWYgc28sIHRoaXMgc2hvdWxkIGJlIHRoZSByZWNv
bW1lbmRhdGlvbiB0byBRVUlDIHN0YWNrcyB3aXRoIG5lZ290aWFibGUgUE5FIC0tIGZhbGxiYWNr
IHRvIFRDUCwgaWYgcGF0aCBpcyBibG9ja2luZyBQTkUuKQ0KICAgIA0KICAgIA0KICAgIA0KICAg
IC0gSWdvcg0KICAgIA0KICAgIA0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQogICAgDQogICAgRnJvbTogS2F6dWhvIE9rdSBbbWFpbHRvOmthenVob29rdUBnbWFpbC5jb21d
IA0KICAgIA0KICAgIFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTggMTA6MjUgUE0NCiAg
ICANCiAgICBUbzogRXJpayBLbGluZSA8ZWtAZ29vZ2xlLmNvbT4NCiAgICANCiAgICBDYzogTWFy
ayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0PjsgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVl
Zm91LmJlPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+
OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD47IElFVEYgUVVJQyBXRyA8
cXVpY0BpZXRmLm9yZz47IERldmFsLCBNYW5hc2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5jb20+DQog
ICAgDQogICAgU3ViamVjdDogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1i
ZXIgZW5jcnlwdGlvbg0KICAgIA0KICAgIA0KICAgIA0KICAgIDIwMTgtMDQtMjYgMTA6NDYgR01U
KzA5OjAwIEVyaWsgS2xpbmUgPGVrQGdvb2dsZS5jb20+Og0KICAgIA0KICAgID4gQ291bGRuJ3Qg
YSBtaWRkbGVib3ggaGF2ZSBhIHBvbGljeSB3aGVyZSBpdCBwZXJtaXRzIFFVSUMgc2Vzc2lvbnMg
dy9vIA0KICAgIA0KICAgID4gUE5FIGJ1dCBibG9ja3Mgc2Vzc2lvbnMgd2l0aCBQTkU/ICBUaGVu
IGltcGxlbWVudGF0aW9ucyB3b3VsZCBiZSANCiAgICANCiAgICA+IGZvcmNlZCB0byBjaG9vc2Ug
aG93IGFkYXB0OiBicmVhayBhbHRvZ2V0aGVyLCBtYXliZSB0cnkgVENQLCBvciANCiAgICANCiAg
ICA+IGRpc2FibGUgUE5FIGFuZCBjYXJyeSBvbi4NCiAgICANCiAgICANCiAgICANCiAgICBUaGVy
ZSBhcmUgdHdvIHdheXMgb2YgbmVnb3RpYXRpbmcgdGhlIHVzZSAob3Igbm9uLXVzZSkgb2YgUE5F
LiBPbmUgaXMgdXNlIFRyYW5zcG9ydCBQYXJhbWV0ZXJzIGFuZCB0aGUgb3RoZXIgaXMgdG8gdXNl
IGEgZGlmZmVyZW50IFFVSUMgdmVyc2lvbi4NCiAgICANCiAgICANCiAgICANCiAgICBVc2Ugb2Yg
VHJhbnNwb3J0IFBhcmFtZXRlcnMgaXMgc2VjdXJlIGJlY2F1c2UgaXQgaXMgcGFydCBvZiB0aGUg
VExTIGhhbmRzaGFrZS4gVmVyc2lvbiBuZWdvdGlhdGlvbiBoYXMgaXQncyBvd24gcHJvdGVjdGlv
biBhZ2FpbnN0IGRvd25ncmFkZSAob3IgdXBncmFkZSkgYXR0YWNrcyAoc2VlIGh0dHBzOi8vdXJs
ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fcXVpY3dnLmdpdGh1Yi5p
b19iYXNlLTJEZHJhZnRzX2RyYWZ0LTJEaWV0Zi0yRHF1aWMtMkR0cmFuc3BvcnQuaHRtbC0yM3Jm
Yy5zZWN0aW9uLjYuNC40JmQ9RHdJR2FRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPUMwc1Vv
LUxGTkJhWWZ5b2FDc2Y2VEEmbT16QzFWR21mM0dRbVdWZTQ2N3VmTE51bHh1TmhVVGxLRVF3T0E4
MG5CVVVZJnM9ZnZ0Y2h3QUctWXhKY1I4d1VBZXpUd0NTTjZYOEVIOEUtN01sU28xcDFuTSZlPSku
DQogICAgDQogICAgDQogICAgDQogICAgU28gSSB3b3VsZCBhc3N1bWUgdGhhdCBhIG1pZGRsZWJv
eCB0cnlpbmcgdG8gaW50ZXJ2ZW5lIGluIHRoZSBuZWdvdGlhdGlvbiBvZiBQTkUgdXNlIGNhbiBi
ZSBkZXRlY3RlZC4NCiAgICANCiAgICANCiAgICANCiAgICBUaGF0IHNhaWQsIEkgZG8gc2VlIHlv
dXIgcG9pbnQgdGhhdCBpZiBzb21lIG1pZGRsZWJveGVzIGRlY2lkZSB0byBwYXNzIFFVSUMgd2l0
aG91dCBQTkUgYnV0IGJsb2NrIFFVSUMgd2l0aCBQTkUsIHdlIG1pZ2h0IGJlIGluY2VudGl2aXpl
ZCB0byB1c2UgUVVJQyB3aXRob3V0IFBORS4gSW4gc3VjaCBjYXNlLCB3ZSBtaWdodCBlbmQgdXAg
aGF2aW5nIHByaXZhY3kgbGVha3MgJiBvc3NpZmljYXRpb24uDQogICAgDQogICAgDQogICAgDQog
ICAgSSB0aGluayB0aGF0IGlzIGEgZ29vZCBhcmd1bWVudCBmb3IgYWx3YXlzIGhhdmluZyBQTkUg
dHVybmVkIG9uLg0KICAgIA0KICAgIA0KICAgIA0KICAgID4NCiAgICANCiAgICA+IE9uIDI2IEFw
cmlsIDIwMTggYXQgMDE6MjIsIEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+IHdyb3Rl
Og0KICAgIA0KICAgID4+IDIwMTgtMDQtMjYgOToyMSBHTVQrMDk6MDAgSWFuIFN3ZXR0IDxpYW5z
d2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+Og0KICAgIA0KICAgID4+PiBJdCBoYXMg
YmVlbiwgYW5kIEknbSBwZXJzb25hbGx5IHN1cHBvcnRpdmUgb2YgaXQsIGJlY2F1c2UgSSBiZWxp
ZXZlIA0KICAgIA0KICAgID4+PiBpdCdsbCBiZSB1c2VmdWwgZm9yIGRhdGFjZW50ZXIgUVVJQyB1
c2UgY2FzZXMuDQogICAgDQogICAgPj4+DQogICAgDQogICAgPj4+IEJ1dCB0aGUgV0cgaGFzIHRv
IGRlY2lkZToNCiAgICANCiAgICA+Pj4gIDEpIElzIGl0IGFsbG93YWJsZSB0byBkaXNhYmxlIFBO
RT8NCiAgICANCiAgICA+Pg0KICAgIA0KICAgID4+IFRoZXJlIGFyZSB0d28gY29uY2VybnMgdGhh
dCBQTkUgaXMgdHJ5aW5nIHRvIGFkZHJlc3M6IG9zc2lmaWNhdGlvbiBhbmQgcHJpdmFjeS4NCiAg
ICANCiAgICA+Pg0KICAgIA0KICAgID4+IEkgd29uJ3QgbWluZCBpZiBzb21lIHBvcnRpb24gb2Yg
UVVJQy1saWtlIHRyYWZmaWMgaGFzIG5vIG1lY2hhbmlzbSB0byANCiAgICANCiAgICA+PiBwcmV2
ZW50IG9zc2lmaWNhdGlvbi4gVGhpcyBpcyBiZWNhdXNlIHdlIGNhbiB0cmFpbiB0aGUgbWlkZGxl
Ym94ZXMgdG8gDQogICAgDQogICAgPj4gbm90IG9zc2lmeSB0aGUgUE4gZmllbGQgYnkgaGF2aW5n
IFBORSBpbiB0aGUgbWFqb3JpdHkgb2YgdGhlIHRyYWZmaWMgDQogICAgDQogICAgPj4gdGhhdCB0
aGV5IHdpbGwgc2VlLg0KICAgIA0KICAgID4+DQogICAgDQogICAgPj4gT1RPSCwgSSB3b3VsZCBi
ZSB3b3JyaWVkIG9mIHByaXZhY3kgaW1wbGljYXRpb25zLiBPbmNlIHlvdSBkZWZpbmUgYSANCiAg
ICANCiAgICA+PiBwcm90b2NvbCwgaXQgaXMgaGFyZCB0byBjb250cm9sIGhvdyBpdCBpcyBnb2lu
ZyB0byBiZSB1c2VkLg0KICAgIA0KICAgID4+DQogICAgDQogICAgPj4gQnV0IHdpdGggdGhhdCBz
YWlkLCBJIHRoaW5rIHdlIG1pZ2h0IGJldHRlciB3YWl0IHRvIHNlZSBpZiBzb21lYm9keSANCiAg
ICANCiAgICA+PiBzdGlsbCB0aGlua3MgaGUvc2hlICpuZWVkcyogUVVJQyB3aXRob3V0IFBORS4N
CiAgICANCiAgICA+Pg0KICAgIA0KICAgID4+PiAgMikgV2hhdCB0aGUgbWVjaGFuaXNtIGlzPyAg
aWU6IFVuaWxhdGVyYWwgdmlhIFRyYW5zcG9ydFBhcmFtcyBvciANCiAgICANCiAgICA+Pj4gbmVn
b3RpYXRlZCB2aWEgYW4gZXh0ZW5zaW9uIG9yID8NCiAgICANCiAgICA+Pj4NCiAgICANCiAgICA+
Pj4gT24gV2VkLCBBcHIgMjUsIDIwMTggYXQgNjowMSBQTSBNaWtlIEJpc2hvcCA8bWJpc2hvcEBl
dmVxdWVmb3UuYmU+IHdyb3RlOg0KICAgIA0KICAgID4+Pj4NCiAgICANCiAgICA+Pj4+IEkgdGhp
bmsgdGhhdOKAmXMgYmVlbiBzdWdnZXN0ZWQgYmVmb3JlLCB0aG91Z2ggd2XigJlkIG5lZWQgdG8g
c29ydCBvdXQgDQogICAgDQogICAgPj4+PiB0aGUgZGV0YWlscyBvZiB3aGF0IHRoYXQgbG9va3Mg
bGlrZS4gIEkgZG9u4oCZdCBoYXZlIGEgcGFydGljdWxhciBkZXNpZ24gaW4gbWluZC4NCiAgICAN
CiAgICA+Pj4+DQogICAgDQogICAgPj4+Pg0KICAgIA0KICAgID4+Pj4NCiAgICANCiAgICA+Pj4+
IEZyb206IElhbiBTd2V0dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb21dDQogICAgDQogICAg
Pj4+PiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI1LCAyMDE4IDEyOjU3IFBNDQogICAgDQogICAg
Pj4+PiBUbzogTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPg0KICAgIA0KICAgID4+
Pj4gQ2M6IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PjsgRGV2YWwsIE1h
bmFzaSANCiAgICANCiAgICA+Pj4+IDxtYW5hc2kuZGV2YWxAaW50ZWwuY29tPjsgTWFyayBOb3R0
aW5naGFtIDxtbm90QG1ub3QubmV0PjsgSUVURiANCiAgICANCiAgICA+Pj4+IFFVSUMgV0cgPHF1
aWNAaWV0Zi5vcmc+DQogICAgDQogICAgPj4+PiBTdWJqZWN0OiBSZTogR2V0dGluZyB0byBjb25z
ZW5zdXMgb24gcGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQogICAgDQogICAgPj4+Pg0KICAgIA0K
ICAgID4+Pj4NCiAgICANCiAgICA+Pj4+DQogICAgDQogICAgPj4+PiBIaSBNaWtlLA0KICAgIA0K
ICAgID4+Pj4NCiAgICANCiAgICA+Pj4+DQogICAgDQogICAgPj4+Pg0KICAgIA0KICAgID4+Pj4g
VG8gY2xhcmlmeSwgYXJlIHlvdSBzdWdnZXN0aW5nIGFkZGluZyBhIHdheSB0byBkaXNhYmxlIHBh
Y2tldCANCiAgICANCiAgICA+Pj4+IG51bWJlciBlbmNyeXB0aW9uIHZpYSBuZWdvdGlhdGlvbiBp
biB0aGUgdjEgc3BlYyBhcyB3ZWxsIGFzIA0KICAgIA0KICAgID4+Pj4gYWRvcHRpbmcgIzEwNzk/
ICBPciB3b3VsZCB0aGUgY2hvaWNlIG9mIHdoZXRoZXIgUE5FIGlzIHRvIGJlIHVzZWQgDQogICAg
DQogICAgPj4+PiB1bmlsYXRlcmFsLCBzdWNoIGFzIGEgdHJhbnNwb3J0IHBhcmFtPw0KICAgIA0K
ICAgID4+Pj4NCiAgICANCiAgICA+Pj4+DQogICAgDQogICAgPj4+Pg0KICAgIA0KICAgID4+Pj4g
T24gV2VkLCBBcHIgMjUsIDIwMTggYXQgMzo1NCBQTSBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVx
dWVmb3UuYmU+IHdyb3RlOg0KICAgIA0KICAgID4+Pj4NCiAgICANCiAgICA+Pj4+IFllcyAtLSBp
dCBzZWVtcyB0aGF0IHRoZSBiaWdnZXN0IG9iamVjdGlvbiB0byAjMTA3OSB3YXMgdGhlIA0KICAg
IA0KICAgID4+Pj4gZGlmZmljdWx0eSBpbiBoYXJkd2FyZSBpbXBsZW1lbnRhdGlvbi4gIElmIHdl
J3JlIGhlYXJpbmcgdGhhdCANCiAgICANCiAgICA+Pj4+IGhhcmR3YXJlIGltcGxlbWVudGF0aW9u
IGlzIGZlYXNpYmxlIGF0IGEgcmVhc29uYWJsZSBjb3N0LCB0aGVuIEkgdGhpbmsgd2UgbWlnaHQg
aGF2ZSBhIHdpbm5lci4NCiAgICANCiAgICA+Pj4+DQogICAgDQogICAgPj4+PiBUaGUgQ1BVIGNv
c3QgZm9yIGEgc29mdHdhcmUgaW1wbGVtZW50YXRpb24gaXMgc3RpbGwgd29ydGggDQogICAgDQog
ICAgPj4+PiBjb25zaWRlcmluZywgYW5kIGFuIG9wdGlvbiB0byBub3QgZW5jcnlwdCBpcyBwcm9i
YWJseSByZWFzb25hYmxlIHRvIA0KICAgIA0KICAgID4+Pj4gbGltaXQgdGhhdCBidXJkZW4gZm9y
IGltcGxlbWVudGF0aW9ucyAvIHVzZSBjYXNlcyB0aGF0IGRvbid0IGNhcmUuDQogICAgDQogICAg
Pj4+Pg0KICAgIA0KICAgID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICANCiAg
ICA+Pj4+IEZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIENo
cmlzdGlhbiBIdWl0ZW1hDQogICAgDQogICAgPj4+PiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI1
LCAyMDE4IDM6MTQgQU0NCiAgICANCiAgICA+Pj4+IFRvOiBEZXZhbCwgTWFuYXNpIDxtYW5hc2ku
ZGV2YWxAaW50ZWwuY29tPjsgTWFyayBOb3R0aW5naGFtIA0KICAgIA0KICAgID4+Pj4gPG1ub3RA
bW5vdC5uZXQ+DQogICAgDQogICAgPj4+PiBDYzogcXVpY0BpZXRmLm9yZw0KICAgIA0KICAgID4+
Pj4gU3ViamVjdDogUmU6IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5j
cnlwdGlvbg0KICAgIA0KICAgID4+Pj4NCiAgICANCiAgICA+Pj4+IE9uIDQvMjMvMjAxOCA2OjU1
IFBNLCBEZXZhbCwgTWFuYXNpIHdyb3RlOg0KICAgIA0KICAgID4+Pj4NCiAgICANCiAgICA+Pj4+
ID4gSSBoYWQgYnJvdWdodCB1cCB0aGUgaXNzdWUgd2l0aCBQTkUgc2V2ZXJhbCB3ZWVrcyBhZ28g
YXMgYSANCiAgICANCiAgICA+Pj4+ID4gYmFycmllciB0byBoYXJkd2FyZSBvZmZsb2FkLiBBZnRl
ciBmdXJ0aGVyIHJldmlldywgaXQgbG9va3MgbGlrZSANCiAgICANCiAgICA+Pj4+ID4gYSBoYXJk
d2FyZSBvZmZsb2FkIGNhbiBpbXBsZW1lbnQgdGhlIFBORSBhdCBhIHNtYWxsIGNvc3QuDQogICAg
DQogICAgPj4+PiA+DQogICAgDQogICAgPj4+PiA+IFRoZSBpbXBsZW1lbnRhdGlvbiBjYW4gbW9k
aWZ5IGN1cnJlbnQgSFcgY3J5cHRvIGFjY2VsZXJhdG9ycyB0byANCiAgICANCiAgICA+Pj4+ID4g
c3VwcG9ydCBlbmNyeXB0aW5nIGEgYnVmZmVyIGluIHRoZSBmaXJzdCBwYXNzIGFuZCB0aGVuIGVu
Y3J5cHRpbmcgDQogICAgDQogICAgPj4+PiA+IHBhY2tldCBudW1iZXIgaW4gdGhlIDJuZCBwYXNz
IGFzIGFscmVhZHkgZGlzY3Vzc2VkIG9uIHRoaXMgDQogICAgDQogICAgPj4+PiA+IHRocmVhZC4g
VGhlIGV4YWN0IHJlcXVpcmVtZW50IChoZWFkZXIgY2hlY2tzdW0sIHBhY2tldCBsZW5ndGggDQog
ICAgDQogICAgPj4+PiA+IGVuY29kaW5nKSBpcyBzdGlsbCBpbiBmbHV4IHNvIHRoZXJlIG1heSBi
ZSBzb21lIHNtYWxsIHZhcmlhdGlvbnMgDQogICAgDQogICAgPj4+PiA+IGRlcGVuZGluZyBvbiB0
aGUgYWNjZWxlcmF0b3IgYW5kIGZpbmFsIGFsZ29yaXRobSBjaG9zZW4gZm9yIFBORS4gDQogICAg
DQogICAgPj4+PiA+IEZ1dHVyZSBvZmZsb2FkIGRlc2lnbnMgY2FuIGRvIG1vcmUgdG8gZnVydGhl
ciByZWR1Y2UgdGhlIG92ZXJoZWFkLg0KICAgIA0KICAgID4+Pj4NCiAgICANCiAgICA+Pj4+IFRo
YW5rcyBmb3IgdGhlIGluZm9ybWF0aW9uLCBNYW5hc2kuIEkgaGF2ZSBtb2RpZmllZCB0aGUgd2lr
aSBwYWdlIA0KICAgIA0KICAgID4+Pj4gZGVzY3JpYmluZyB0aGUgUE5FIGlzc3VlcyBhbmQgYWx0
ZXJuYXRpdmVzIHRvIHJlZmxlY3QgdGhpcyBuZXcgZGF0YToNCiAgICANCiAgICA+Pj4+DQogICAg
DQogICAgPj4+PiBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3dpa2kvU3Vt
bWFyeS1vZi10aGUtUE4tZW5jcnlwdGlvbi1pc3N1ZXMtYW5kLWFsdGVybmF0aXZlcy4uDQogICAg
DQogICAgPj4+PiBXaXRoIHRoYXQgbmV3IGluZm9ybWF0aW9uLCBpdCBhcHBlYXJzIHRoYXQgUFIg
IzEwNzkgaXMgc3VwZXJpb3IgdG8gDQogICAgDQogICAgPj4+PiBldmVyeSBvdGhlciBhbHRlcm5h
dGl2ZS4NCiAgICANCiAgICA+Pj4+DQogICAgDQogICAgPj4+PiAtLSBDaHJpc3RpYW4gSHVpdGVt
YQ0KICAgIA0KICAgID4+DQogICAgDQogICAgPj4NCiAgICANCiAgICA+Pg0KICAgIA0KICAgID4+
IC0tDQogICAgDQogICAgPj4gS2F6dWhvIE9rdQ0KICAgIA0KICAgID4+DQogICAgDQogICAgDQog
ICAgDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgLS0NCiAgICANCiAgICBLYXp1aG8gT2t1
DQogICAgDQogICAgDQogICAgDQogICAgDQoNCg==


From nobody Mon Apr 30 16:49:08 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C823E12D7E2 for ; Mon, 30 Apr 2018 16:49:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkbuxvsAOpSP for ; Mon, 30 Apr 2018 16:49:05 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E63127522 for ; Mon, 30 Apr 2018 16:49:04 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id n65-v6so8941587oig.6 for ; Mon, 30 Apr 2018 16:49:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uUPAs/Hr3PeC7kf69SYAfgk/nivzvd0BwJ+/smCp8fo=; b=htigSUSh0gzTnDI7XtB8VpnmdmhLgqTTt7wcWVKHQOuRlUJ/GPFfx9PphJYLPbeBY9 AYMv9JCPndjDpRaeDKsyCBNjGmy1cTmpGFjCAQZ1ACMvwISsxqD4g1PCL9Ib7t+bxxQu hW8xzv2EUUqJ9RKlwuvmXovsHS8c981cKcIi8rt6jY5z4Dh3cu3C1PdNi6UZ7xosQJB5 nb8uFSdngG+GKQ8adUDjLlcaqwtzJV9E5ygvrGSR19M2qfGR7hKSfn1BCEISPenZgaMu /n7fqEYnJuGluP7SShZlZa/VcCzmB3JTTzc0sHbqZ+BhuH/MSK1zc14RkIDYBREeLcv0 n2nA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=uUPAs/Hr3PeC7kf69SYAfgk/nivzvd0BwJ+/smCp8fo=; b=cZIDdAeWnjPigGG/FaQUTVs3K60ETHYTb/xUhLRu+pFVpBWEQQCiKbZjVkhrDDHShr TJrSOOtoNvAPAx7Ic44iryeNgsMsVvVxWkj9uSCP+Ywa8Uum7oY5kHwdw49PpGcFcGF6 5BIxMxlsC8kjJuT/bx+n1eFYCgVzFjlv4qv4QkEcQDkyA7TU2162IBlGRNdR1G+rd0dQ E8BcM2bS8/TwOC9zOjk4S5rvSLN/Xl0hyyCh+CV9mkp7ptqPCjjd2LZqmQK/Q03GN+rc 9HEJFfto2iawDyxhd4DmcUILbwLkxYqb1hSezgP+rMGoXTaYXOOYLnDNM9/VB7YtjZZZ 2Maw==
X-Gm-Message-State: ALQs6tCGvjao/9oe8EaZFERSHrkzxRW9BcZSLILJyV0pCCg+PRptyd0O 3pYXaw+H07DiYZ0ZEqjKKWOPBnAyHpQ8p6fy9F4=
X-Google-Smtp-Source: AB8JxZrLwKMYrYgxIkCwveiD1iwuuc9W6Q8F4RI7i1371QC78S52j/F8TF04oUWYs7nALp43Neske5Umq2uuq/65c+k=
X-Received: by 2002:aca:4e15:: with SMTP id c21-v6mr7940049oib.254.1525132144308;  Mon, 30 Apr 2018 16:49:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:29ce:0:0:0:0:0 with HTTP; Mon, 30 Apr 2018 16:49:03 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>          <58447D8E-782C-431C-8FC3-71124B10A047@trammell.ch>    
From: Martin Thomson 
Date: Tue, 1 May 2018 09:49:03 +1000
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Praveen Balasubramanian 
Cc: Ian Swett , huitema ,  Jana Iyengar , "Lubashev, Igor" ,  Mark Nottingham , Mike Bishop , Brian Trammell ,  Erik Kline , IETF QUIC WG , "Deval, Manasi" , Kazuho Oku 
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, 30 Apr 2018 23:49:07 -0000

On Tue, May 1, 2018 at 7:55 AM, Praveen Balasubramanian
 wrote:
> Also, what is the urgency behind getting PNE adopted =E2=80=93 is it bloc=
king
> progress on interop or other issues?

Yes.  There are a considerable number of issues backing up behind this now.


From nobody Mon Apr 30 17:32:24 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6C612D965 for ; Mon, 30 Apr 2018 17:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 q1XONWw9aynP for ; Mon, 30 Apr 2018 17:32:21 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0119.outbound.protection.outlook.com [104.47.32.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072CA12DA18 for ; Mon, 30 Apr 2018 17:32:21 -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=mLEgY69oc4JqGCkDvPmOmC+sxkFGKjiTiwaOUi1dqYY=; b=QdVRqWE1mKpPyoZUjFb1R+BaYhumvcLmdB9/t+Ph4Fnt6rf7PPOmusaM82VlPhPp1CDqzb/Gv4nRbMw0udw2YQ2o/v9vkyHnFyIovQOuOwhRBKk7Y1A4Ug2SEe1A6LRm5bsSWiMO9LtnDytBXvc6/mtJpqF9mzxJbPYzQ67T2Ww=
Received: from MWHPR21MB0638.namprd21.prod.outlook.com (10.175.141.139) by MWHPR21MB0797.namprd21.prod.outlook.com (10.175.135.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.735.4; Tue, 1 May 2018 00:32:18 +0000
Received: from MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::6d48:f7af:d267:2021]) by MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::6d48:f7af:d267:2021%7]) with mapi id 15.20.0735.006; Tue, 1 May 2018 00:32:18 +0000
From: Praveen Balasubramanian 
To: Martin Thomson 
CC: Ian Swett , huitema , Jana Iyengar , "Lubashev, Igor" , Mark Nottingham , Mike Bishop , Brian Trammell , Erik Kline , IETF QUIC WG , "Deval, Manasi" , Kazuho Oku 
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwZ0sAgAC4ugCAAARcAIAAFTbwgAALYgCAAAAgYIAAEcIAgACR+YCAB09lAIAFXyIAgAVK+oCAAJlSAIABxdSAgACOHICAB/EyAIACo7YAgACiMICAAADPgIAAIs8AgAAm/YCAABExgIAABpMAgAAK5wCAAPIgAIAA5wcAgACzcYCAAHHMgIAEe1cAgAABEACAABL8QIAAIkOAgAAINfA=
Date: Tue, 1 May 2018 00:32:18 +0000
Message-ID: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>          <58447D8E-782C-431C-8FC3-71124B10A047@trammell.ch>     
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::316]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0797; 7:9pYlYWEbNAjVaVTnMkN1idATSNpOGD64JcqZBeebgSz0bjqu1wG893MfY6TvI4I5jue9hfWc9/wtlD58sREC1M4K3rdPjl59rNwg3vABMvPm4ryNFqQwxzvvjwoyW/+nREotp5lI8p8HHfo82LXaO2KR/M1zPWqJNLDWM7VCCC/Emg7xY4pkljfYYsoxiKOdKjIPuzUN1uuqNsqQiCNnGyEy7/xydd9jiOzu3hhU7w4yxvSIZ2s80aRsmmRYt0UG; 20:NsN3m6ZZyaliBQ0JIuHzfaWrjhphZbov0MeCVE+nuWTYCHHhwsdvX/0O+Jfge6Z0h9jzSQgnIrF8zusDwEyEafPPonUnWORt4NP64uiiGyYfiRqZRup1HEx/bcF4M4ttA/Dxb7rTOLEJVDYZFZHq+xc8LJhRa7T2iINFtIGVmJk=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:MWHPR21MB0797; 
x-ms-traffictypediagnostic: MWHPR21MB0797:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(228905959029699);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(2018427008)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR21MB0797; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0797; 
x-forefront-prvs: 06592CCE58
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(366004)(39380400002)(39860400002)(346002)(199004)(189003)(13464003)(99286004)(6916009)(74316002)(93886005)(446003)(6116002)(81166006)(81156014)(102836004)(10090500001)(59450400001)(86612001)(7696005)(97736004)(11346002)(33656002)(476003)(53546011)(486006)(6506007)(39060400002)(86362001)(5660300001)(4326008)(5250100002)(6246003)(8676002)(7736002)(305945005)(7416002)(53936002)(8936002)(14454004)(22452003)(316002)(8990500004)(55016002)(54906003)(2900100001)(105586002)(106356001)(478600001)(3280700002)(25786009)(68736007)(10290500003)(46003)(6436002)(186003)(9686003)(3660700001)(229853002)(76176011)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0797; H:MWHPR21MB0638.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: RSuKiZJ4m7pH/a6TM8rp5aCw5Yo7byukY+6J1smF9uy6V25SuTwzsKnZuegShcOiR1WfCl1P2bpuf0HIcTmyDaekhP43nlGVI5FVeyuyzliXglWttRdeJpdwHJhtil7LqyxeMSj2N4LeZU066A294868PFBwO5mC8KaNr7y1VVV0YP5V2EvAuv78ik2ZoKvN
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 36342167-aef5-4219-33cc-08d5aefaff36
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 36342167-aef5-4219-33cc-08d5aefaff36
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2018 00:32:18.8401 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0797
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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 May 2018 00:32:23 -0000

V2hhdCBhcmUgdGhlIGV4YW1wbGVzIG9mIGlzc3VlcyB0aGF0IGhhdmUgYSBkZXBlbmRlbmN5IG9u
IFBORT8gVGhpcyBpcyBhIHRyYW5zZm9ybSB0aGF0IGlzIGFwcGxpZWQgcG9zdCBjb25zdHJ1Y3Rp
bmcgdGhlIHBhY2tldCBhbmQgdGhlbiBiZWZvcmUgZGVjcnlwdGlvbiBvbiByZWNlaXZlLCBzbyBJ
IHdhcyBhc3N1bWluZyBpdHMgdmVyeSBkZWNvdXBsZWQgZnJvbSB0aGUgY29yZSBwcm90b2NvbCBh
bmQgY291bGQgYmUgYWRkZWQgYXQgdGhlIGVuZC4gSWYgYW55IHBhcnQgb2YgdGhlIHByb3RvY29s
IGFkZHMgYSBkZXBlbmRlbmN5IG9uIFBORSwgdGhlbiBpdOKAmXMgYSBjYXVzZSBmb3IgY29uY2Vy
biBiZWNhdXNlIGl0IHByZWNsdWRlcyB0aGUgbm8tb3AgdHJhbnNmb3JtIGZvciBkYXRhY2VudGVy
IG9wdGlvbi4gU28gc3RhdGluZyBhbnkgc3VjaCBkZXBlbmRlbmNpZXMgaXMgaW1wb3J0YW50IElN
Ty4gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBb
bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIEFwcmlsIDMw
LCAyMDE4IDQ6NDkgUE0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9z
b2Z0LmNvbT4NCkNjOiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBodWl0ZW1hIDxo
dWl0ZW1hQGh1aXRlbWEubmV0PjsgSmFuYSBJeWVuZ2FyIDxqcmkuaWV0ZkBnbWFpbC5jb20+OyBM
dWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT47IE1hcmsgTm90dGluZ2hhbSA8bW5v
dEBtbm90Lm5ldD47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZT47IEJyaWFuIFRy
YW1tZWxsIDxpZXRmQHRyYW1tZWxsLmNoPjsgRXJpayBLbGluZSA8ZWtAZ29vZ2xlLmNvbT47IElF
VEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IERldmFsLCBNYW5hc2kgPG1hbmFzaS5kZXZhbEBp
bnRlbC5jb20+OyBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPg0KU3ViamVjdDogUmU6
IEdldHRpbmcgdG8gY29uc2Vuc3VzIG9uIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpPbiBU
dWUsIE1heSAxLCAyMDE4IGF0IDc6NTUgQU0sIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2
Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiBBbHNvLCB3aGF0IGlz
IHRoZSB1cmdlbmN5IGJlaGluZCBnZXR0aW5nIFBORSBhZG9wdGVkIOKAkyBpcyBpdCBibG9ja2lu
ZyANCj4gcHJvZ3Jlc3Mgb24gaW50ZXJvcCBvciBvdGhlciBpc3N1ZXM/DQoNClllcy4gIFRoZXJl
IGFyZSBhIGNvbnNpZGVyYWJsZSBudW1iZXIgb2YgaXNzdWVzIGJhY2tpbmcgdXAgYmVoaW5kIHRo
aXMgbm93Lg0K


From nobody Mon Apr 30 17:34:24 2018
Return-Path: 
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59B912DA18 for ; Mon, 30 Apr 2018 17:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ChxQr-VQPW81 for ; Mon, 30 Apr 2018 17:34:20 -0700 (PDT)
Received: from mail-ot0-x243.google.com (mail-ot0-x243.google.com [IPv6:2607:f8b0:4003:c0f::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B9E12D965 for ; Mon, 30 Apr 2018 17:34:20 -0700 (PDT)
Received: by mail-ot0-x243.google.com with SMTP id l13-v6so11528824otk.9 for ; Mon, 30 Apr 2018 17:34: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:content-transfer-encoding; bh=LMXbF2ageFrbPLs7x+wI58ADDfDqNZcJMDUn3fzmHZw=; b=HwQK4WPaS/dyWy/LfqRMQTZyLxhUBvsmGMzaIFV8eMdvYnG77xWNEyJ0X/Tu53plrZ r/4Bp9tZ5diTB+YHewAT10v2zFkiXVOQdw7YjlzCvMD+YKeSFhfqmusNEDDSia0V9QGW rJN4U/dj2dEKQAxzIucIsDMOfsYmyVdvswyalo+Y2VWTrvxTiQ49Ti6jKrPUsG0tEw2l q7QmF1w06QJyuQB3qImSk6682/27A9gKvDItp1QO0AEcfu6uWk7U2gRGfjsJOlGZxw9h Sg2aYXNlrZOm/x9j5kkoVyQCPWC1mcMic7BlPRuRGaIp4Y66r27FOecB5SJ3qgjffcuI PovQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=LMXbF2ageFrbPLs7x+wI58ADDfDqNZcJMDUn3fzmHZw=; b=mnzcHA1jgSqjlemwzTvcj7hQ7fj8ExEKqlmeGgNyCafi5KouDqzewloX2/Yz8cFb3m tH3bp+qPMnGuf3MQjSufASJZTKhEkWIOn93gV2mTL14mh8wM/8roijw/kasPvnpi4CSK 9y8dmPbKWj/ltur8a/4Vcf9arOMATnaZPbG5MJeomWrbiWK+m6ZynYGMf/qMBXqjfl2u 2YZ3iXoRkqvflkpYBUHstmLzw7KIdvqGBjVg1tLsM83Jj5Z046gQWERm64eACcI188WS Ngj97EbbbBJx/AXfkC96syriOSML9kvW+j6uAfNihTo78oECYodfryfR66Xi3nWpP4U7 6PjQ==
X-Gm-Message-State: ALQs6tByUrL8UPPkjwygE5hognx77LzK8jDv+rHRXGbW9gtWGPXmUHKD w511ClQD4qdJvrORGUFENI2cDdfBZCtULavbgZg=
X-Google-Smtp-Source: AB8JxZrrwWKVmjJLVFLEepc/ReW4BRRhF9q9bA7J5r8ezujtuGy63ZoIfyGEOX7qSGpU7aEGR9PaxqXV41gaso0gMFM=
X-Received: by 2002:a9d:2602:: with SMTP id a2-v6mr5753336otb.392.1525134859693;  Mon, 30 Apr 2018 17:34:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:29ce:0:0:0:0:0 with HTTP; Mon, 30 Apr 2018 17:34:18 -0700 (PDT)
In-Reply-To: 
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>  <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>          <58447D8E-782C-431C-8FC3-71124B10A047@trammell.ch>      
From: Martin Thomson 
Date: Tue, 1 May 2018 10:34:18 +1000
Message-ID: 
Subject: Re: Getting to consensus on packet number encryption
To: Praveen Balasubramanian 
Cc: Ian Swett , huitema ,  Jana Iyengar , "Lubashev, Igor" ,  Mark Nottingham , Mike Bishop , Brian Trammell ,  Erik Kline , IETF QUIC WG , "Deval, Manasi" , Kazuho Oku 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 May 2018 00:34:23 -0000

Copying from the PR:

Closes #1174
Closes #1043
Closes #1048
Closes #1034
Closes #850
Closes #990
Closes #734

This isn't about other dependencies, but this is holding a bunch of issues =
open.

On Tue, May 1, 2018 at 10:32 AM, Praveen Balasubramanian
 wrote:
> What are the examples of issues that have a dependency on PNE? This is a =
transform that is applied post constructing the packet and then before decr=
yption on receive, so I was assuming its very decoupled from the core proto=
col and could be added at the end. If any part of the protocol adds a depen=
dency on PNE, then it=E2=80=99s a cause for concern because it precludes th=
e no-op transform for datacenter option. So stating any such dependencies i=
s important IMO.
>
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: Monday, April 30, 2018 4:49 PM
> To: Praveen Balasubramanian 
> Cc: Ian Swett ; huitema ; Jana =
Iyengar ; Lubashev, Igor ; Mark No=
ttingham ; Mike Bishop ; Brian Trammel=
l ; Erik Kline ; IETF QUIC WG ; Deval, Manasi ; Kazuho Oku 
> Subject: Re: Getting to consensus on packet number encryption
>
> On Tue, May 1, 2018 at 7:55 AM, Praveen Balasubramanian  wrote:
>> Also, what is the urgency behind getting PNE adopted =E2=80=93 is it blo=
cking
>> progress on interop or other issues?
>
> Yes.  There are a considerable number of issues backing up behind this no=
w.